Boot from external drive

@WayneWWW this file does not exist /etc/nv_boot_control.conf

Then it means something is missing in your file system over the external drive. How did you prepare your rootfs?

Followed the (NVMe + Xavier NX as example) steps from the link to create and mount rootfs from external device - Jetson/L4T/Boot From External Device - eLinux.org

Because I couldn’t connect the external sda drive (SATA) to my host machine, I directly downloaded L4T Driver Package (BSP) and Sample Root Filesystem to (previously flashed) emmc’s Downloads folder and then followed steps 1.2 - 6 (skipped step 5) of Use NVMe + Xavier NX as example section to create the rootfs, partition (sda1) and then flash the device. For flashing, I used sudo ./flash.sh jetson-xavier-nx-devkit-emmc sda1. After it got flashed emmc had only the boot folder

Do you remember to run apply_binaries.sh?

yes we have run apply_binaries.sh

Can you let sdkmanager download one package for you and you just copy that rootfs on your disk? I mean using the package prepared by sdkm instead of download the BSP and rootfs by yourself. You can also check if the package from sdkm has this nv_boot_control.conf or not.

It should be there.

I am checking the launch of the official Jetson Nano image Ubuntu (with kernel 4.9) from an external USB media. It is enough to edit /boot/extlinux/extlinux.conf after writing the image to USB media (replace APPEND root=/dev/mmcblk0p1 with /dev/sda1) and the system starts up and works fine from USB media. But when I try to start another system (Armbian) with the same kernel 4.9 from USB media, I get a root system mount error. When checking the UART log, I see that the kernel does not use APPEND from extlinux.conf, but uses a variant from u-boot (where root=/dev/mmcblk0p1). I.e. the kernel ignores the value of the variable from extlinux.conf. At the same time, the exact same system with the same extlinux.conf values works fine with a USB with a 5.15\16 kernel and correctly installs the kernel command line. Maybe I’m using something wrong with the official Jetson Nano kernel 4.9 in the configuration or settings?

This is confusing. I have tried to follow the instructions from:
https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/flashing.html#wwpID0E0QN0HA

So this is my setup: I have an eMMC 16GB that boots alright. I have flashed my J NX using the SDK Manager.
Now I want to use the NVME to boot from. Or rather, any of the options is ok, mount file system or booting too. But I cant get the flashing to nvme to work.

I connect the Jetson to a linux 18.04 machine via USB and reboots with 9/10 bridged. I remove it after a while.
Then I have seen that nVidia device appears in lsusb. So far so good. BUT I cant get : sudo BOOTDEV=nvme0n1p1 ./flash.sh --no-flash nvme0n1p1 to work I get : bash: board: No such file or directory. Why? I have created the p1 partition and formated as ext4.

any ideas?

Because you didn’t give the board config to flash.sh as parameters. The parameters are not just “board” string. You need to give the one that you use for flashing.

2 Likes

I figured as much but what is that?
looking in the flash.sh and cant understand the name you look for?
Is it Jetson NX? or jetson_nx ??

sudo BOOTDEV=nvme0n1p1 ./flash.sh --no-flash <board> nvme0n1p1 (The board part was removed due to html-formating)

what should I write instead of “<board>”
Also. Where will I run this? On the Jetson where I have flashed the eMMC and booted or on the Host-machine where I have connected the USB cable

I figured it out. Looking in the tegra folder I found the .config files and figured you talked about those. So I replaced <\board> with jetson-xavier and then it continued. Should mention that in “childs” language that it should be like that. Perhaps an example along-side the instruction would be nice.

Thanks for now…

For clarification

Should mention that in “childs” language that it should be like that.

I mean that the instruction should be easier so that a child can understand. Couldn’t edit my previous answer sorry.
Also that is a bit unclear is when you mention the host computer vs. Jetson. As I understand you have to prepare the nvme on a host linux machine. It says so, but not so straight forward

//M

Hi,

  1. I assume that most people would have some basic ideas about how to use flash.sh. So this is not mentioned inside this post. For someone who didn’t use this tool before, you can follow the quick start guide. Flash the board’s emmc or sdcard first as practice.
    https://developer.nvidia.com/embedded/downloads#?search=quick

  2. Actually sdkmanager is able to directly flash to external NVMe after jeptack4.6 for TX2 series and Xavier series. The post above is mostly for users who are using old jetpack release. The concept is still similar. Just the way to prepare NVMe may not be needed anymore.

2 Likes

Hi, I have used the SDKManager now, but need to run the 4.5.1 Jetpack. Is this what controls the flashing options? Cause it seems I cant select the NVME as target only flash to emmc.

Also. About basic knowledge. Previous installations has been using a flash-memory card and is very straight forward since you can flash the Jetpack linux image directly to the memory card. But for SSD it seems to be more tricky. Sorry to say is that the official guides are quite difficult to follow as well as referencing back and forth. The SDK-manager though is Awsome improvement! It would be very nice if you could add the function to create an image from an existing installation too. So you can “backup” your Jetson. This would greatly improve when I need to deploy multiple installations… The regular tools to create image in linux has not been very good since you need to unmount the drive in which the system runs.

Thanks for the feedback though, this is very much appreciated!

1 Like

Thanks for your comprehensive explanation!
I will try to mount the file system from external for my nano-emmc later!

1 Like

Or you could install my project and you don’t have to flash anything

Kim

1 Like

Or the sbts-base project which creates some read/write partitions but is intended to mount the OS read-only with a memory overlayfs. This works around the problem of disk corruption (Due to unexpected power outages for example) causing the boot process to hand. The normal behavior of Linux when encountering some levels of disk corruption is to hang and let the user interact with the console to guide fsck. If on an embedded system you don’t have a console then the system simply refuses to boot. In jetpack 5.0.2 which currently doesn’t support a frame buffer console the situation is even worse, because then you would have to connect up a serial port console as you won’t get any interaction via a connected monitor and keyboard I understand:

So you might consider this approach even more desirable than the flashing approach because sbts-base does a force fsck -y on the read-write partitions because mounting them and doesn’t mount them via /etc/fstab. This means that even if that fails the system will still boot and allow you to connect in via ssh to repair it. All in all a much more desirable approach to pure booting to fsck via a flashed approach in my opinion.

Kim

Oh just some production insights here. The approach to keeping the OS partition mounted read-only came after I release a commercial embedded product back in 2010 (My open source project is actually, the open sourcing of that commercial production from way back then). Then after shipping to customers, they were all coming back with the same problem. Corruption in the disk (Then SD disk) was causing all of the units to hang during boot. A very serious problem to encounter after going into production.

I don’t know how product manufacturers for jetson devices are dealing with this problem, but it’s a problem that eventually all product manufacturers will need to face I think.

Just sharing the insight and lession learnt.

Kim