I am trying to restore image taken from working Orin NX 16GB setup (JP6.2.2) with l4t_backup_restore.sh script.
Orin NX module installed in Waveshare Orin Nano/NX Carrier Board.
System was originally flashed with SDK Manager JP6.2.2 to NVMe drive.
Now I am trying to replace drive with larger one and after restoring, system gets stuck in boot:
I do not see any issues in the log:
04072025-BC501-restore.log (119.5 KB)
Image is good because I was able to restore it into original NVMe (128GB Samsung image was taken from) without any problems.
No luck restoring into new larger NVMe (256GB SK Hynix), getting stick on boot every time.
However I was able to flash drive in question with SDK Manager earlier today and it booted just fine. I am trying to flash image to transfer exiting configuration.
How can I troubleshoot this issue?
Update:
Due to the issue with restore I put the original drive back and now this one gets stuck too :-(
When I was testing restored drive, it would try reboot automatically after being stuck for 30s or so.
Now, the original drive seems to get stuck the same way except it does not reboot on its own.
I seem to remember reading at some point that repetitive boot failures may cause jetson to enter in some fail mode and something had to be reset but I cannot remember.
*** Please note that this reply is generated by LLM automatically ***
To troubleshoot the issue of the Jetson Orin NX system getting stuck in the boot image after restoring the image to a larger NVMe drive, follow these steps:
-
Verify the Image: You’ve already confirmed that the image is good by successfully restoring it to the original NVMe drive. However, to rule out any issues with the image, try re-creating the backup using the l4tbackup script and then restore it to the new NVMe drive.
-
Check the NVMe Drive: Since you were able to flash the new NVMe drive with SDK Manager and it booted fine, the drive itself seems to be working correctly. However, there might be some compatibility issues with the specific drive model (SK Hynix 256GB) and the Jetson Orin NX module. Try using a different NVMe drive model to see if the issue persists.
-
Verify the Boot Configuration: Ensure that the boot configuration is set correctly for the new NVMe drive. You can use the sudo ./tools/kernel_flash/l4t_initrd_flash.sh command to flash the drive with the correct boot configuration. For the Jetson Orin NX series, use the following command:
$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -u <pkc_keyfile> [-v <sbk_keyfile>] --uefi-keys uefi_keys/uefi_keys.conf -p "-c ./bootloader/generic/cfg/flash_t234_qspi.xml" -c ./tools/kernel_flash/flash_l4t_t234_nvme.xml --showlogs --network usb0 jetson-orin-nano-devkit external
Replace <pkc_keyfile> and <sbk_keyfile> with your actual key files.
-
Check the UEFI Settings: Ensure that the UEFI settings are set correctly for the new NVMe drive. You can access the UEFI settings by pressing the ‘Esc’ key during boot-up. Verify that the boot order is set to prioritize the NVMe drive.
-
Compare Boot Logs: Compare the boot logs from the successful boot on the original NVMe drive with the boot logs from the failed boot on the new NVMe drive. This might help you identify any specific errors or issues that are causing the boot to fail.
-
Try a Different Restore Method: Instead of using the l4tbackup and l4trestore scripts, try using the nvsdkmanager_flash.sh script to flash the image to the new NVMe drive. This script automatically detects the Jetson device’s type of carrier board and can handle the flashing process for you.
-
Check for Firmware Updates: Ensure that the firmware on the new NVMe drive is up-to-date. You can check for firmware updates using the manufacturer’s tools or by contacting their support.
By following these steps, you should be able to troubleshoot and resolve the issue with the Jetson Orin NX system getting stuck in the boot image after restoring the image to a larger NVMe drive.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
Hi,
Please record the serial console log when boot up.
Thanks
1 Like
I am attaching debug console logs for both NVMe drives:
serial-boot-original-nvme.log (178.4 KB)
serial-boot-restored-nvme.log (178.8 KB)
Logs are very similar, here is diff:
serial-boot-diff.txt (177.2 KB)
Both clearly indicate problem however I am not sure how to resolve it.
egrernel/drivers/usb/gadget/udc/tegra-xudc.ko /lib/st_module02]s/5ttime[0x0.185-t0]
ules/5.15.185-tegra/kernel/drivers/usb/storage/uas.ko /lib/ gr 7
Checking whether device /dev/mmcb[ 15.21568stusb
core: registered new intDevice /d driveblk?p1 does [ .21notist4]
ckiFinding OTA ther deviir extce v/sal existe d
evices
Device /dev/sd?1 does not exist
Checking whether device /dev/nvme?n1p1 exist
Looking for OTA work directory on the device(s): /dev/nvme0n1p1
[ 15.244458] mount /dev/nvme0n1p1 /mnt
[ 15.255417] EXT4-fs (nvme0n1p1): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[ 15.256978] is_boot_part_for_disk_enc /dev/nvme0n1p1 /mnt
[ 15.269000] OTA work directory /mnt/ota_work is not found on /dev/nvme0n1p1
[ 15.286059] Internal storage device(/dev/mmcblk0p1) does not exist
[ 15.287303] OTA work directory is not found on internal and external storage devices
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
bash-5.1#
I can access rootfs partition just fine using drives in USB enclosure.
