I am working with my Jetson Orin NX module. After a reboot, I encountered the error below and the device dropped to a bash shell. Currently, power cycling and reset do not help — the device always drops to a bash shell. What is the cause of this?
[ 16.074955] nvme 0004:01:00.0: Adding to iommu group 5
[ 16.075252] nvme nvme0: pci function 0004:01:00.0
[ 16.075490] nvme 0004:01:00.0: enabling device (0000 → 0002)
[ 16.090328] nvme nvme0: allocated 64 MiB host memory buffer.
[ 16.101028] nvme nvme0: 8/0/0 default/read/poll queues
[ 16.106592] nvme0n1: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 p13 p14 p15 p16 p17 p18
[ 16.132104] Finding OTA work dir on external storage devices
[ 16.156583] mount /dev/nvme0n1p1 /mnt
[ 16.172681] EXT4-fs (nvme0n1p1): recovery complete
[ 16.172825] EXT4-fs (nvme0n1p1): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[ 16.174366] is_boot_part_for_disk_enc /dev/nvme0n1p1 /mnt
[ 16.180487] OTA work directory /mnt/ota_work is not found on /dev/nvme0n1p1
[ 16.189310] Finding OTA work dir on internal storage device
[ 16.190478] mount /dev/mmcblk0 /mnt
[ 16.198764] Failed to mount /dev/mmcblk0 on the /mnt
[ 16.199865] Failed to run “mount_ota_work_partition /dev/mmcblk0 /mnt”
[ 16.201009] OTA work directory is not found on internal and external storage devices
bash-5.1#
*** Please note that this reply is generated by LLM automatically ***
Based on the provided context, it’s difficult to pinpoint the exact cause of the issue you’re experiencing with your Jetson Orin NX module. However, I can provide some insights and potential causes.
Power Sequencing: The Jetson Orin NX module and the carrier board must be power sequenced properly to avoid potential damage to components on either the module or the carrier board system. Ensure that the power sequencing is correct, and the carrier board is not powering up before the Jetson module.
SYS_RESET* Signal: The SYS_RESET* signal is used to indicate when the carrier board can power on. If this signal is not deasserted correctly, it might cause issues during boot. Verify that the SYS_RESET* signal is being deasserted properly.
Thermal Shutdown: The Orin SoC has hardware shutdown mechanisms that enforce a junction temperature limit of 105°C. If the temperature exceeds this limit, the system will automatically halt. Check if the thermal shutdown temperature has been reached, and ensure that the cooling system is functioning correctly.
Module ID Strap: The Module ID strap indicates whether the module is a legacy type supporting only 5V on VDD_IN or an advanced type. Ensure that the Module ID strap is set correctly for your Jetson Orin NX module.
Power Supply: The Jetson Orin NX module requires a minimum of 8.0V to the VDD_IN for MAXN_SUPER at 40W. Verify that the power supply is providing the correct voltage.
Carrier Board Design: The carrier board design should ensure that any pins that connect to devices on the carrier board do not cause damage or excessive leakage to those devices. Review the carrier board design to ensure that it meets the requirements.
Bootloader or Software Issues: It’s possible that the issue is related to the bootloader or software configuration. Try to boot the device in recovery mode or use a different bootloader to isolate the issue.
To troubleshoot the issue, you can try the following steps:
Check the power sequencing and SYS_RESET* signal.
Verify the thermal shutdown temperature and cooling system.
Ensure the Module ID strap is set correctly.
Check the power supply voltage.
Review the carrier board design.
Try booting the device in recovery mode or using a different bootloader.
If none of these steps resolve the issue, it may be helpful to provide more information about the error message you’re seeing or the exact behavior of the device. Additionally, you can refer to the Jetson Orin NX Series Product Design Guide and other documentation for more detailed information on power sequencing, thermal design, and software configuration.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
From the log snippet, the NVMe device is detected and /dev/nvme0n1p1 can be mounted successfully. The failure happens later when the early boot/recovery flow looks for the OTA work directory and then tries the internal storage device
So this does not look like a simple “NVMe is not detected” issue from the current snippet. We need the earlier boot messages to understand why the device entered this path.
Could you help provide the following information?
JetPack/L4T version
Which JetPack or L4T release is installed?
Full serial console log
Please capture the complete log from power-on/reset until it drops to bash-5.1#.
The current snippet starts too late to identify the first boot failure.
Flash information
Was the module flashed by SDK Manager or command line?
Please share the exact flash command and the flash log.
Boot history
Did this same image boot successfully before this reboot?
Before the failure, was there any OTA update, apt upgrade, kernel update, bootloader update, or rootfs/partition change?
For Jetson Orin NX/Nano booting from NVMe, please also make sure the board was flashed with the supported initrd flash flow for your JetPack/L4T version. For JetPack 6 / L4T R36.x, please refer to the “Using initrd Flash with Orin NX and Nano” section in the Jetson Linux Developer Guide:
Thank you for the detailed response and the helpful checklist.
Here are the answers to your questions:
JetPack / L4T Version
• JetPack 6.2 / L4T R36.4.3, running on Jetson Orin NX
Flash Information
• The module was flashed via command line using flash.sh.
• Note: I have re-flashed the device from the command line as a recovery step, and the system is now back online.
Boot History — Important Context
• This is not a first-boot or post-flash issue.
• The device had a working image installed and had been running successfully for some time.
• The failure occurred unexpectedly after a routine reboot — no OTA update, apt upgrade, kernel update, bootloader update, or any partition/rootfs changes were made prior to the reboot.
• This appears to be a spontaneous boot failure on an otherwise stable system.
Full Serial Console Log
• Unfortunately, I did not capture the full serial console log before re-flashing the device, so I am unable to provide it at this point.
Given that the system was stable before and failed only after a normal reboot without any modifications, I am particularly interested in understanding what could have caused this unexpected boot path change.
Please let me know if there is anything else I can provide to help investigate this further.
I haven’t encountered this error again since our last conversation, so I haven’t been able to record and send the UART logs to you. As soon as I face the error again, I will contact you through this issue.