Boot from USB

Hi there,

I tried to perform a boot from USB by using GitHub - jetsonhacks/bootFromUSB: Boot NVIDIA Nano Jetson Developer Kit from a mass storage USB device (Jetson Nano devices A02, B01, 2GB and possibly Jetson TX1) on a Jetson Nano device.

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.

Can anyone give me a tip?

Thanks in advance,

Flávio Mello


I’m moving your topic to the Jetson Nano category for better visibility.

Hi flavio.mello,

Are you using the devkit or custom board?
What’s your L4T version?

You could refer to the procedure of Flashing to a USB drive from developer guide.

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.

Do you hit any key to stop at Uboot and change the boot order?
# setenv boot_targets usb0 mmc1 mmc0 nvme0 pxe dhcp
# saveenv
# boot

And could you help to provide the full serial console log for further check?
Jetson Nano Style - Serial Console - JetsonHacks

You might want to try my sbts-boot-from-SSD project

It will configure this for you with just one command.

Kim Hendrikse

setenv is a “command not found”

In attachment is the log of dmesg --follow
log.txt (58.9 KB)


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:

  1. 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.

  1. Removed the HDD from USB port, plugged again the SDcard into the Jetson, it stops boot with the prompt root@(none):/#

I can see that it is looking for the /dev/sda1, the mounting point of the external HDD that is unpluged. Is it possible to roll back?

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

cp /boot/extlinux/orig_extlinux.cfg /boot/extlinux/extlinux.cfg

and then power up. Otherwise you can do something like:

mkdir /tmp
mount /dev/mmcblk0p1 /tmp/mnt

cd /tmp/mnt/extlinux
cp extlinux.cfg

cd /tmp
umount mnt

and then power cycle.


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:

sudo ./sbts-bin/

sudo reboot


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.

Ah I see. Good point!

I’ll make a note of clarifying this on my project page, thanks for clearing this up.


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.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.