In an earlier post, I asked whether (as a backup) it would be ok to clone the SSD onto another SSD. If I understood the reply correctly, the answer was that if the Orin were exactly the same and if the Jetpack version were the same, then it should be possible to use a cloned SSD.
I then bought two SSD enclosures, took out the Orin SSD, and cloned it onto another SSD of exactly the same size and brand using the EASYUS cloning tool on a Win11 PC. I suspected it to be easier than the procedure described in the docs. Apparently I was wrong, because now the Jetson Orin won’t boot at all from neither the source SSD nor the target SSD. So it seems that I have many hours ahead to reinstall the whole thing. Rather stupid of me.
If anybody can suggest a way to fix the boot problem, so I can recover the old, source SSD, it would save me for many hours of work :-)
Hi,
Could you try to boot with source SSD and record the serial console log?
Thanks
I found another post dealing with a similar problem: [AGX Orin Recovery Boot - #5 by user117897]. The fix is to do this:
“Press ESC to enter UEFI Menu, then choose Device Manager → NVIDIA Configuration → L4T Configuration → OS chain A status → (The value is Unbootable if UEFI attemps recovery kernel) choose Normal → Save and exit, reboot, UEFI will try Direct Boot.”
I believe that the boot process gives up after some failed attempts, hence one has to manually force it to not give up after going back to the original SSD.
So the problem is solved.
Serial console log from another PC would help far more than screenshots.
I do have a suggestion though that if you can temporarily put each SSD on a Linux host PC, and run the command “lsblk -f” and report what you see for each SSD, then that might also help. One of the parts which can change in a clone (depending on the tool used and commands) are disk or partition UUIDs. Those IDs are typically used for finding a specific partition, and if they change, boot will fail to find that; the serial console log can answer if this is the problem, and seeing the “lsblk -f” on another PC will say if the UUID is valid. Furthermore, if it is a UUID issue, then the UUID can be updated on the other host PC to the value the serial console log is looking for. That’s the most likely issue, but serial console logging is rather important because it can tell us where boot fails.
Thanks a lot for the advice, I will find a suitable computer and do what you suggest
Linuxdev suggested above to use a serial console from another PC. I am sure that this is a trivial question for many of you, but how do you do that?
When I have started a clean Jetson nano orin, I have just connected a keyboard and a display to it. Then I installed “no-machine”, so I later can login remotely. If I am right, to start up a Jetson the first time with an external PC, one needs an UART to establish a serial connection through USB from the correct pins on the Jetson developer board? Is that what you people do to connect with a serial console during cold start-up the first time?
Serial console is just a text console exactly like opening a text console in the original machine, but the keyboard/monitor are on a separate computer (the host PC). Because that terminal program runs on that other computer it is able to be logged from that other computer despite being logged in to the Jetson. There are a number of of serial console programs (which talk to serial UARTs). A common (but more complicated) serial console program is minicom. I like gtkterm. Lots of other serial UART/serial console programs exist. Usually the hard part is knowing where the connector is since some models use actual pins on the Jetson, but more modern Jetsons have a device mode USB port and you simply connect the correct USB cable from the Jetson to the host PC. I don’t have an Orin Nano, so I can’t verify directly which port/wire to use, but I think it is the same for Orin Nano, Xavier Nano, and older Nano. Check out these:
- https://www.youtube.com/watch?v=Kwpxhw41W50
- https://www.jetsonhacks.com/2019/04/19/jetson-nano-serial-console/
If this is not correct for your case, just post here and I’ll find some more exact information.
Some general information about the serial ports on Jetsons when they go to header pins and not USB:
- They are 3.3V level.
- Setting is always
115200 8N1. Speed 115200, 8 bits, no parity, 1 stop bit. No CTS/RTS flow control. - For a USB version the settings are the same, but there is no need to think about “3.3V level”.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.