At my USB 3.0 port I have and HDD256GB. Everything ended fine: I see the hole rootfs at the USB drive, also edited extlinux.conf correctly. I took the SDcard from Jetson Nano, and restarted the system. However, the boot hangs, even that splash screen from Nvidia is never show.
I seems that BootROM is not delivering the boot to /dev/sda1.
I also tried to change extlinux.conf replacing root=/dev/sda1 to use the PARTUUID, but nothing happens. No boot at all, and no error messages.
I am using the devkit. L4T version is: # R32 (release), REVISION: 5.1, GCID: 26202423, BOARD:t210ref, EABI: aarch64, DATE: Fri Feb 19 16:45:52 UTC 2021.
I followed the procedures from “Flashing to a USB drive”. I still can’t boot, but now the boot loader is trying to reach the external HDD that is plugged into USB port. The PARTUUID is correct, but the installation didn’t mounted it. So boot is trying to find something in /mnt, but there is nothing there.
I guess you didn’t fully understand what Kevin is trying to tell you…
This “setenv” is not a command in kernel. It is for uboot to use. You need to follow the website link he posted to enable serial console so that you can use uboot console…
I cloned the repo, and ran sbts_install_boot_from_SSD. Selected patition and so on. It copied the rootfs to the USB disk. But it didn’t boot correctly. I made 2 tests for boot:
Removed the SDcard, keeping the external HDD plugled into the USB port (the one I selected during sbts_install_boot_fromSSD). It hangs at Nvidia splashscreen.
First of all a few clarifications. My approach relies on the boot process trying to boot the SD card, the script takes care of booting from the SSD. You have in the past changed some of the boot environment I understand. Maybe that’s interfering with the process.
Also, currently the last version of jetpack I tested with was 4.6. I don’t know what version you have there.
What type of USB connected SSD are you using ? To be fair I’ve only tested with Samsung portable SSD and nvme devices on NX.
It’s good that the first part of the process was able to work. It’s possible that the auto modification of the extlinux.cfg didn’t go correctly if you have made modifications in there. Such as trying other kernels, commenting parts out etc. If that was the cause of the problem, then the fix could be to make sure that your starting point is a freshly installed SD card without previous modifications to the extlinux.cfg file.
Rolling back can be done by putting back the original extlinux.cfg file which should be saved as orig_extlinux.conf and rebooting. You can do this by either mounting the SD card on another system. Or potentially on the root shell it drops you into when it fails.
That /dev/sda1 is not visible after it successfully creating and populated that partition suggests to me that there is a problem in getting the USB devices loaded, which suggests that potentially it’s not booting the kernel that I expected it to, which was the default kernel that you would get when booting the jetpack 4.6.x images.
I see that you have a root shell there. If /boot is still mounted then you can simply type in
Also, with my approach you need to keep the SD card in the system. You mentioned that you removed the SD card then booted and it hung. It would do. Put the SD card back in and boot again, it only accesses the SD card for a small amount of time then pivots the root to continue booting from the SSD card. (so the long explanation above wasn’t necessary actually, sorry :) )
It’s not intended to modify direct booting from SSD. This has it’s advantages. You don’t have to mess with low level booting so in principle it’s less risky to carry out.It’s also easy to roll back and use with other SD cards anytime for other purposes.
If you want to roll back, then you boot off SSD in the process that you are supposed to, by keeping the SD card in there, then run:
Trivia: Some boot setups will name a specific device. That device can directly boot, or it can point to yet another boot setup. The latter is a “chain boot”, and this is what is happening. The other device is not replacing the original device, but the original device is used to point to the new device, and so both are required in this chain boot scheme. If each device has an extlinux.conf, then both might apply.
Yeah, I’m just saying that my auto install process uses a reasonably simplistic pattern match to modify the original extlinux.conf file. If additional things are in there, then it might mess that up. I didn’t write a fully compliant parser and editor routine for this purpose.
That’s not what happened here this time though. He simply pulled out the SD card, when my approach requires you to leave it in.
But thanks for entering the conversation with additional insights :)
I was just suggesting why removing the SD card would fail (and why it couldn’t be removed): Due to chain load instead of direct load. A number of people run into this and don’t understand why they can’t remove the SD card if the rootfs is another device.
So, it took some time to roll back the previous operations, but now I am back to the beginning.
By now, I am following the procedures from Jetson Nano Style - Serial Console - JetsonHacks . What I didn’t expected was the need for that serial cable, I have just order one and I will need to wait for its delivery in order to provide full serial console log.
