While testing some software on our AGX Orin box, we noticed that the system was becoming unresponsive. By this we mean that our mouse clicks were not being registered within the Ubuntu menus. To try and resolve this issue, we tried rebooting our system by pressing the reboot switch on the box, but after we did, the system has not been able to successfully boot back up. Every few minutes, we see a Nvidia splash screen show up on our monitor, with a loading bar at the bottom of the screen. When the loading bar finishes after a few seconds, the screen goes black. It appears our AGX Orin box is stuck in a boot loop. Right before this issue occurred, we saw a warning on the Jetson that it was running out of storage space. We freed up some space right before this error started occurring. Overall, were wondering if there are any additional steps we can try to get our box to boot correctly, or if we need to re image it.
Hi aobrien,
Are you using the devkit or custom board for AGX Orin ?
What’s your Jetpack version in use?
If your board can not boot up successfully, how do you free up the space?
Please share the full serial console log for further check.
- We are using the dev kit, and jetpack 6
- I think my message was a little unclear. We noticed the space issue before we had this boot loop issue. We saw the space warning, deleted some txt and jpg files to free space, rebooted the box by pressing the reboot button, and then we encountered this boot loop issue. We not sure if this is related to the boot loop issue, but just wanted to mention the last thing we did on the box before encountering the issue.
Is the boot issue caused from deleting something?
Please refer to the following instruction to capture serial console log for further check.
NVIDIA Jetson Orin - Serial Console (ridgerun.com)
Hi KevinFFF, sorry for the delay. I was able to grab some of the serial logs from the device, and they are attached to this reply. In the logs, I saw the following error: " /mnt/ota_work is not found on /dev/mmcblk0p1". I was curious if that error is related to our boot loop issue?
log.txt (54.3 KB)
It seems you boot into recovery kernel.
I would like to check the log earlier. (i.e. the previous boot)
There may be something error so that it boots into recovery kernel.
Hi KevinFFF,
Sadly I do not have any previous logs, that show why it is booting into this state. Is there any sort of additional logging I can generate that could give us this information? Also, is it possible to configure the Jetson to boot into the “normal” kernel, rather than the recovery kernel? I’m mainly wondering if there are any boot loader settings I can try to get it to boot to the normal kernel.
Could you refer to the following steps to configure the slot A status to Normal and check if it could boot succesfully?
a. Press `ESC` to enter UEFI Menu
b. choose Device Manager -> NVIDIA Configuration -> L4T Configuration
c. OS chain A status: The value is Unbootable if UEFI attempts recovery kernel, choose Normal
d. Save and exit, reboot, UEFI will try Direct Boot
Thank you for these instructions. We have actually already tried to boot to the normal kernel using these steps. When we try to make it direct boot, the system still goes into the boot loop state.
Based on the information we’ve found in this thread, this is a summary of the issue we are facing:
- Our AGX Orin is stuck in a boot loop, meaning it will not boot to the Ubuntu desktop. The Nvidia splash screen is shown every few minutes, while the box is in this state.
- Per the serial logs, it appears the system is booting into the recovery kernel. I do not have earlier boot logs, from before we were facing the boot loop issue.
- Selecting the normal kernel in the UEFI menu does not work. We have tried this in the past, and it does not fix our boot issue. I tried this option before I shared the serial logs, so it seems that the system is still booting into the recovery kernel, even when we tell it to boot to the normal kernel in the UEFI menu.
There is no update from you for a period, assuming this is not an issue any more.
Hence we are closing this topic. If need further support, please open a new one.
Thanks
I think your issue is about the “boot loop”.
We have to check the full serial console log for the details.