Hi
We are running L4T R36.4.4 on Orin NX. After the system runs normally for some time, rebooting has a non-negligible probability of booting into recovery mode persistently. We have captured the serial debug log saved as recovery.log under this faulty state.
We attempted to press ESC during boot to enter the UEFI menu, then navigated to Device Manager → NVIDIA Configuration → L4T, and changed the OS Chain A status to Normal. This switches the boot flow to Direct Boot, yet the system still fails to load into the desktop environment; the corresponding serial log is attached as direct_boot.log.
From the captured logs, the NVMe drive is successfully enumerated. The UUID settings inside extlinux.conf are configured correctly. Nevertheless, the system continuously throws errors indicating it cannot locate the partition matching the specified UUID.
This issue reproduces frequently. Once the fault occurs, the only available workaround is re-flashing the entire system via flash.sh. We are reaching out to inquire about the root cause of this failure and feasible mitigation methods to prevent future occurrences.
Thanks.
direct_boot.log (93.1 KB)
recovery.log (77.9 KB)
here is the log.
Hi liyuan190,
Are you using the devkit or custom board for Orin NX?
I would like to check the logs during the transition from the working state to the failed state.
OpenAndReadUntrustedFileToBuffer: Failed to open \boot\dtb\kernel_tegra234-p3768
-0000+p3767-0000-nv.dtb: Not Found
ExtLinuxBoot: Failed to authenticate boot\extlinux\extlinux.conf (Not Found)
..
[ 15.849544] ERROR: mounting PARTUUID=e3afb048-79a0-45ee-a3cd-781169e02003 as /mnt fail...
[ 15.851451] ERROR: PARTUUID=e3afb048-79a0-45ee-a3cd-781169e02003 mount fail...
From direct_boot.log you shared, the dtb and extlinux.conf can not be recognized
Do you modify them manually?
How do you reproduce the issue? Any application was running? Or just doing reboot stress test?
Hi KevinFFF.
We adopt the Orin NX core module paired with our self-designed carrier board. The device tree referenced in extlinux.conf is stored under /boot/dtb within the root filesystem. The system boots up normally after full flashing via flash.sh.
This failure occurs intermittently, and we have not yet identified a reliable, consistent reproduction procedure. However, every instance of this issue follows the exact same trigger sequence: after executing poweroff, the next power-on boot fails. After three consecutive failed boot attempts, the device permanently enters recovery mode.
We have a custom GUI application running on the system. The fault has been observed under two distinct runtime scenarios:
-
Our custom GUI app had been launched prior to poweroff;
-
Only the vanilla Ubuntu system was running, with our GUI app never opened at all.
What logs should we collect, or what troubleshooting methods can we use to narrow down the scope and pinpoint the root cause of this issue?
It is the expected behavior that it will boot into recovery kernel after 3 times boot failed.
Do you mean the boot issue was caused from your GUI?
I would suggest comparing for the difference(no matter HW or SW running) between the devkit and your custom carrier board.
You need to check the serial console log for the boot issue.
Hi KevinFFF.
Sometimes we just boot into Ubuntu without running any apps, then reboot, and the system fails to start up.
We compile code with the attached build.sh. It runs ./generic_rt_build.sh "enable" to turn on RT kernel. We want to know if this RT setting causes system instability.
build.txt (965 Bytes)
Do you refer to the commands in Kernel Customization — NVIDIA Jetson Linux Developer Guide for r36.4.4?
It seems you didn’t perform5. To update the initramfs, run the following commands: to update initramfs.
Please help to clarify if the issue is specific to the rt-kernel or your custom carrier board.
Yes. After updating the kernel and modules, we ran sudo ./tools/l4t_update_initrd.sh in the flashing environment. Then we flashed the system to NVMe with this command:
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml -p ‘-c bootloader/generic/cfg/flash_t234_qspi.xml’ --showlogs --network usb0 jetson-orin-nano-devkit external
There is no update from you for a period, assuming this is not an issue anymore.
Hence, we are closing this topic. If need further support, please open a new one.
Thanks ~0708
As we don’t see such issue on the devkit, please help to clarify the following:
- If the issue is specific to the custom carrier board.
- could you reproduce the issue w/o enabling the rt-kernel?
- would you hit the issue after updating to the latest JP6.2.2(R36.5)?