I am using the Jetson Orin Nano Developer Kit. When I power on the board normally (not in recovery mode), I see several “FAILED” messages appear during the boot process on the connected monitor.
I have not flashed the board recently, and I am using the default Jetson Linux provided.
HDMI output appears
Fan spins
But many services show FAILED status on boot
Examples of what I see:
Failed to start Hostname Service
Failed to start Login Service
Failed to start Load Kernel Modules
Could you please guide me on:
What causes these “failed” boot messages?
Is there a way to reset or reflash the board to fix them?
Any recommended way to clean install JetPack if needed?
I appreciate your help. Please let me know what logs or details are needed.
Yes, I am using an HDMI to DisplayPort adapter because my monitor only supports HDMI.
Could you please confirm whether this type of adapter is compatible with the Jetson Orin Nano Developer Kit?
I’m facing an issue where the board powers on, but I see “FAILED” messages during boot, and there’s no display output on the monitor.
Could this be caused by the adapter or display compatibility?
I would really appreciate it if you could guide me step-by-step to resolve this issue, or suggest any alternative setup (such as using a native DisplayPort monitor or a specific adapter).
Just a comment on one of those errors, the part of Load Kernel Modules error. Regardless of the reason for failing to load modules, this implies none of the drivers or hardware which have drivers in the form of a module will work. Maybe (or maybe not) things like host name service depend on that, e.g., if the network hardware used a module format driver, then host name service could not succeed.
The base kernel Image has its location for where to find modules hard wired into it at the time of compile. There are actually multiple kernels possible on most Jetsons, and perhaps it is loading something other than the one expected due to a filesystem issue. Is this a dev kit, booting to SD card? Or is this a third party carrier board? It changes some answers.
Regardless of the answer, it is likely that the Jetson will need to be flashed. You wouldn’t necessarily need to flash any SD card though. It’s hard to give better advice without knowing exactly whether this is a developer’s kit, or if it uses a third party carrier board, or if it boots to some alternative media (such as NVMe).
Bottom line though is that it cannot find some content on the filesystem, and this triggers a chain of failures.
Yes, I am using the Jetson Orin Nano Developer Kit, and it’s booting from an SD card. I am using an HDMI to DisplayPort adapter, as my monitor only supports HDMI.
During boot, I noticed several “FAILED” messages, and based on one of the errors — particularly the “Load Kernel Modules” failure — I understand that this might prevent drivers or hardware components from functioning correctly. I also read that this may be due to the system not finding expected content in the filesystem, which could trigger a chain of failures.
Could this possibly be caused by the adapter, or is it more likely a filesystem or flashing issue?
If flashing is necessary, I would appreciate your guidance on how to reflash the developer kit correctly using SDK Manager or any recommended method.
Please let me know the best way forward. Thank you so much for your support.
The HDMI to DisplayPort adapter shouldn’t be a problem. Adapters can still fail for various reasons, but that part is usually not a problem. VGA adapters basically guarantee failure.
Have you performed any kind of kernel customization? There is an initrd which is actually the first loaded filesystem. The kernel comes from the SD card for an Orin Nano dev kit, but the first module load is then from the initrd which is also in “/boot”. If the initrd is not found, or if the kernel is not found, or if the modules found in the initrd are incorrect and not compiled against that kernel configuration, then I would expect this to fail. Summary:
Kernel Image is in “/boot”, and this loads.
Module load is expected to find compatible modules in “/lib/modules/$(uname -r)/kernel”.
That location exists on the SD card, but this is not the first location searched or loaded.
There is also a “/lib/modules/$(uname -r)/kernel” in the initial ramdisk. This loads first, and it looks like maybe it was never reached.
This initrd acts as a kind of adapter between first kernel load and actual filesystem load. It is a simplified o/s filesystem tree purely in RAM. The Image is not from the initrd, but what the kernel Image loads is from the initrd. Then there is a pivot root whereby the “/” of the filesystem is transparently switched from the “/” of the initrd and the SD card’s ext4 filesystem. Logs usually mention these events, but I don’t see them.
You really need a serial console boot log to see events and to know for sure. Serial console would show exact details which the video isn’t really able to show. There are some variations on hardware for serial console, but this should be useful: https://jetsonhacks.com/2019/04/19/jetson-nano-serial-console/
This is almost always a flashing issue. Flashing updates the QSPI memory on the module itself, and this has a lot to do with finding the initrd and kernel Image. The SD card can be 100% perfect, but if the module itself has not been flashed, you will get failures like this.
FYI, Jetsons don’t have a hardware BIOS, but they do have the equivalent in software. For a Nano style in a dev kit, there is no eMMC, and that content is stored in the QSPI memory of the module. During flash it isn’t just the operating system which gets flashed, but is also the QSPI. The QSPI basically gets the system to the point of running a bootloader, and eventually this loads the kernel Image and the initrd filesystem. A small subset of critical modules load from the initrd. Then there is a pivot root to put the SD card’s “/” as the root of the filesystem instead of the initrd’s “/”. This results in the rest of the modules (the ones on the SD card instead of the initial ramdisk) being able to load on demand.
What did you do for flash? Incidentally, L4T is what actually gets flashed, and this is just Ubuntu once NVIDIA content has been added; JetPack/SDK Manager are just tools to perform the flash. The two are normally paired together. You can see a list of L4T releases and compatibilities here: https://developer.nvidia.com/linux-tegra
For Orin both L4T R35.x and R36.x are available (maybe also a new release when Jetson Thor comes out). Once you have flashed with R36.x then any of the SD card images from R36.x will work without flashing again. Similarly, if you have R35.x flashed, then any of the SD card images for R35.x will work without flashing again. You cannot mix an R35.x flash with an R36.x SD card (or vice versa).
