Occasionally our AGX Orin (running Jetpack 5.1.4) will revert to only trying to boot the recovery kernel. I inspected the debug UART to check if there were kernel panics before the recovery kernel was booted, but the logs show that the previous boot was successful.
I have attached logs that show a soft reboot issued after 1 hour of running the normal/full, kernel, but then the Orin fails to boot it back up again.
Checking the efivars shows that the app partition is not marked bootable. Clearing this field results in the Orin being able to boot the normal kernel again.
bash-5.0# mount -t efivarfs none /sys/firmware/efi/efivars/
bash-5.0# cd /sys/firmware/efi/efivars/
bash-5.0# xxd RootfsStatusSlotA-781e084c-a330-417c-b678-38e696380cb9
00000000: 0700 0000 ff00 0000
Do you know why this might be happening? QSPI Flash corruption?
*** Please note that this reply is generated by LLM automatically ***
The issue you’re experiencing with your Jetson AGX Orin, where it occasionally reverts to only trying to boot the recovery kernel, could be related to several factors. Based on the information provided, here are some potential causes and comparisons with other related issues:
QSPI Flash Corruption: The fact that clearing the app partition’s bootable field in the efivars allows the Orin to boot the normal kernel again suggests that there might be an issue with the QSPI flash. QSPI (Quad SPI) is a type of flash memory used in many embedded systems, including the Jetson AGX Orin. Corruption in this area could lead to boot issues, including the system reverting to the recovery kernel. However, without direct evidence of QSPI flash corruption, this remains a speculative cause.
UEFI Configuration or Firmware Issues: The UEFI (Unified Extensible Firmware Interface) is responsible for booting the system and managing the boot process. Issues with the UEFI configuration or firmware could lead to problems like the one you’re experiencing. This includes incorrect settings in the UEFI menus or issues with the UEFI firmware itself that might cause the system to fail in booting the normal kernel.
Bootloader Issues: The bootloader is another critical component in the boot process. Problems with the bootloader, such as corruption or incorrect configuration, could prevent the system from booting the normal kernel. Given that you’re using Jetpack 5.1.4, any known issues with the bootloader in this version could be a contributing factor.
Power or Hardware Issues: Sometimes, hardware or power-related issues can cause the system to behave erratically, including failing to boot properly. This could be due to overheating, power supply issues, or hardware faults.
Software or Kernel Issues: Although you mentioned that the previous boot was successful and there were no kernel panics, it’s still possible that there’s an underlying software or kernel issue that’s not immediately apparent. This could be related to the specific configuration or software running on your Jetson AGX Orin.
Comparison with Other Issues:
The issue you’re facing seems different from the “Jetson Orin NX Login Issue After OTA Update” or “Problems with follow up OTA update after JP5->JP6 OTA update,” as those issues are more related to login problems or OTA update failures rather than boot issues.
The “Issue that OTA works on some Jetsons but not others” might share some similarities if the root cause is related to bootloader or UEFI issues, but the specifics of your problem point more towards a local configuration or hardware issue rather than a broader OTA update problem.
Recommendations:
Inspect the efivars and UEFI settings: Double-check the UEFI settings and efivars to ensure that everything is correctly configured for booting the normal kernel.
Update Firmware and Software: Ensure that your Jetson AGX Orin is running the latest firmware and software versions. Sometimes, updating can resolve issues like the one you’re experiencing.
Run Diagnostic Tests: Perform diagnostic tests on the QSPI flash and other hardware components to rule out any hardware issues.
Consult NVIDIA Support: Given the complexity of the issue and the potential for it being related to a specific configuration or hardware fault, consulting NVIDIA support might provide more targeted assistance.
Remember, troubleshooting such issues often requires a systematic approach, ruling out potential causes one by one.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
@WayneWWW the service seems to have run successfully based on logs for the last few boots.
```
$ sudo systemctl status nv-l4t-bootloader-config
* nv-l4t-bootloader-config.service - Configure bootloader service
Loaded: loaded (/etc/systemd/system/nv-l4t-bootloader-config.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Sun 2025-11-30 12:30:58 UTC; 15min ago
Main PID: 963 (code=exited, status=0/SUCCESS)
Nov 30 12:30:58 orin nv-l4t-bootloader-config.sh[1417]: TEGRA_EMMC_ONLY false
Nov 30 12:30:58 orin nv-l4t-bootloader-config.sh[1417]: TEGRA_CHIPID 0x23
Nov 30 12:30:58 orin nv-l4t-bootloader-config.sh[1417]: TEGRA_OTA_BOOT_DEVICE /dev/mtdblock0
Nov 30 12:30:58 orin nv-l4t-bootloader-config.sh[1417]: TEGRA_OTA_GPT_DEVICE /dev/mtdblock0
Nov 30 12:30:58 orin nv-l4t-bootloader-config.sh[963]: Info: Write TegraPlatformCompatSpec with 3701--0004--1--jetson-agx-orin-d317ss-.
Nov 30 12:30:58 orin nv-l4t-bootloader-config.sh[963]: Info. Uninstalling mtdblock.
Nov 30 12:30:58 orin nv-l4t-bootloader-config.sh[963]: Info. Verifying boot status.
Nov 30 12:30:58 orin nv-l4t-bootloader-config.sh[1440]: Info: variable BootChainFwStatus is not found.
Nov 30 12:30:58 orin systemd[1]: nv-l4t-bootloader-config.service: Succeeded.
Nov 30 12:30:58 orin systemd[1]: Finished Configure bootloader service.
Nov 30 12:30:57 orin systemd[1]: Starting Configure bootloader service...
Nov 30 12:30:58 orin nv-l4t-bootloader-config.sh[963]: Warning: Cannot get compatible board name.
Nov 30 12:30:58 orin nv-l4t-bootloader-config.sh[963]: 3701--0004--1--jetson-agx-orin-d317ss-
Nov 30 12:30:58 orin nv-l4t-bootloader-config.sh[963]: Info. Installing mtdblock.
Nov 30 12:30:58 orin nv-l4t-bootloader-config.sh[963]: Info. Active boot storage: mmcblk0
Nov 30 12:30:58 orin nv-l4t-bootloader-config.sh[963]: Info. Legacy mode: false
Nov 30 12:30:58 orin nv-l4t-bootloader-config.sh[1417]: TNSPEC 3701-501-0004-E.0-1-1-jetson-agx-orin-d317ss-
Nov 30 12:30:58 orin nv-l4t-bootloader-config.sh[1417]: COMPATIBLE_SPEC 3701--0004--1--jetson-agx-orin-d317ss-
Nov 30 12:30:58 orin nv-l4t-bootloader-config.sh[1417]: TEGRA_LEGACY_UPDATE false
Nov 30 12:30:58 orin nv-l4t-bootloader-config.sh[1417]: TEGRA_BOOT_STORAGE mmcblk0
Nov 30 12:30:58 orin nv-l4t-bootloader-config.sh[1417]: TEGRA_EMMC_ONLY false
Nov 30 12:30:58 orin nv-l4t-bootloader-config.sh[1417]: TEGRA_CHIPID 0x23
Nov 30 12:30:58 orin nv-l4t-bootloader-config.sh[1417]: TEGRA_OTA_BOOT_DEVICE /dev/mtdblock0
Nov 30 12:30:58 orin nv-l4t-bootloader-config.sh[1417]: TEGRA_OTA_GPT_DEVICE /dev/mtdblock0
Nov 30 12:30:58 orin nv-l4t-bootloader-config.sh[963]: Info: Write TegraPlatformCompatSpec with 3701--0004--1--jetson-agx-orin-d317ss-.
Nov 30 12:30:58 orin nv-l4t-bootloader-config.sh[963]: Info. Uninstalling mtdblock.
Nov 30 12:30:58 orin nv-l4t-bootloader-config.sh[963]: Info. Verifying boot status.
Nov 30 12:30:58 orin nv-l4t-bootloader-config.sh[1440]: Info: variable BootChainFwStatus is not found.
Nov 30 12:30:58 orin systemd[1]: nv-l4t-bootloader-config.service: Succeeded.
Nov 30 12:30:58 orin systemd[1]: Finished Configure bootloader service.
Yes it did enter recovery boot after 3 reboots. I think I see the issue; I had modified the nvpmodel.service’s unit file to not do anything. This seems to have affected other dependent services like nv-l4t-bootloader-config.
Thanks for helping clarify why the Orin enters this state!