Hello everyone, I am using an Orin AGX 32GB to run my project, but it suddenly fails to boot, the AGX doesn’t even have the NVIDIA logo, just a black screen. I am running the system using an M.2 SSD, and I have checked that the SSD is working fine.
I have tried reflashing another AGX with a new SSD and swapping the old SSD after finishing, but the system just blackscreens after some boot messages. I can successfully boot with the new SSD.
Is it possible to create a bootable base machine that can boot my old SSD, eliminating the need to rebuild my system?
I am using Jetpack 5.1.3 and a 1TB SSD. The new SSD is just a 256GB one I had lying around. I don’t think that’s the issue?
Thank you very much!
*** Please note that this reply is generated by LLM automatically ***
Based on the provided context, I’ll try to help you troubleshoot the issue with your Jetson AGX Orin 32GB.
Firstly, it’s great that you’ve tried reflashing another AGX with a new SSD and swapping the old SSD, which suggests that the issue might not be with the SSD itself. Since you can successfully boot with the new SSD, it’s likely that the problem lies with the old SSD or the boot configuration.
Given that you’re using Jetpack 5.1.3 and a 1TB SSD, I’ll provide some potential solutions and comparisons to help you resolve the issue.
- Boot Validation: Have you tried running the Boot Validation tests for the Jetson AGX Orin series? This might help identify any issues with the boot process. You can refer to the Boot Validation procedure in the context.
- Boot to kernel command line or custom desktop: Try booting to the kernel command line or a custom desktop to see if you can get any error messages or clues about what’s causing the issue. This might help you identify if the problem is with the boot process or the desktop environment.
- Recovery mode: You can try enabling the AGX Orin in USB3 Recovery Mode using the procedure provided in the context. This might allow you to recover your system or at least access the boot logs to diagnose the issue.
- Boot logo: Since you mentioned that the NVIDIA logo doesn’t appear, it’s possible that the boot logo is not being displayed correctly. You can try including a custom boot logo in a single backup/restore cycle on JetPack 6.2, as described in the context.
- Boot configuration: Compare the boot configuration between the old and new SSDs. Make sure that the boot configuration is correct and that the old SSD is not causing any conflicts.
- Hardware validation: Run the Bring-up Hardware Validation tests for the Jetson AGX Orin series to ensure that the hardware is functioning correctly.
- Create a bootable base machine: While it’s possible to create a bootable base machine, it might not be the most efficient solution. Instead, you could try to identify the root cause of the issue and fix it. If you still want to create a bootable base machine, you can try using the Jetson AGX Orin board-design and configuring it to boot from the old SSD.
Comparing your issue with similar ones in the context:
- The issue “Support for Jetson AGX Orin Developer Kit 32GB: not boot OS and can’t connect to NVIDIA SDK Manager” seems similar, but it’s related to the developer kit, whereas you’re using a custom setup.
- The issue “Boot fails after restoring a Jetson orin NX” is related to the Orin NX, but it might be worth checking the boot configuration and recovery mode procedures.
In conclusion, I recommend trying the Boot Validation tests, booting to the kernel command line or custom desktop, and enabling the AGX Orin in USB3 Recovery Mode to diagnose the issue. If you’re still unable to resolve the problem, you can try creating a bootable base machine, but it’s essential to identify the root cause of the issue to avoid similar problems in the future.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
You can always clone an SSD if you have the space on another Linux computer and can mount it there.
FYI, Jetsons do not have an actual BIOS, and every flash is essentially also a BIOS flash. Much content exists in software which goes into eMMC partitions of an AGX Orin, but only the rootfs should be on the SSD (it might change something though if you have something like A/B scheme).
The flash content is L4T, or Linux for Tegra, and is just Ubuntu plus NVIDIA content on top of that. The rootfs is almost purely Ubuntu, and if you have a proper saved image, then there are a lot of ways to reuse this in another flash. Beware though that some compatibilities with that flash content is required. If you flash with the same L4T release, and have a saved clone somewhere for the rootfs, then in theory it should be able to boot this. Do beware though that sometimes a partition UID/UUID is used to find the partition, and so even if partitions are otherwise identical, then in some cases the partition won’t be found due to the changed ID. Cloning and other tools can easily clone, change, or match IDs. You simply need a lot of space and root access to use dd to clone an entire SSD or a single partition of the SSD.
JetPack 5.1.3 will correspond to L4T R35.5.0. See:
https://developer.nvidia.com/embedded/jetpack-archive
If you have a newer JetPack, then you can start it like this to pick older releases such that it exactly matches what you’ve cloned:
sdkmanager --archived-versions
Listed via L4T release instead:
https://developer.nvidia.com/linux-tegra
There are a lot of things you can do to try to restore such a system, but all can be risky. If you have a clone, then it isn’t very risky and you can afford to make mistakes. If you have the SSD connected to another Linux host PC computer, then what do you see for that specific device when you run the command:
lsblk -f -T
Also, what do you see on the host PC when you name the SSD via:
blkid /dev/...whatever the device is...
There will be a lot of required space if you do this. So many options on what to do and how to do it that it can be confusing. If you have a single partition clone though, you can loopback mount it, examine it, edit it, copy it, clone it, use it as the image for flash when loopback mounted, so on. There is a complete backup and restore script, but that assumes it is booting.
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 ~0813
hello fanstan.project,
we may also dig into bootloader logs for the details,
please try setup serial console to gather the complete UART logs for reference.