Jetpack 5.0.2 , boot from SATA SSD on Jetson Xavier NX. error: dev/sda1 not found

Neither of those commands will work. The flash will appear to succeed without erorr, but when rebooting the device will report “sda1 not found” or similar.

Similar issues have been reported in the past, for example:

@lakshantha.d We tried this process last year with jetpack 4. At first, it took some time to write the files. Later, lots of errors occurred and the setup failed. As @geoff.s mentioned, we had a similar error on other tries. Can you guide tell us through the process you mentioned step by step? We would like to try it again.

Just want to clarify… you could read my post here first to understand how those tools work…

First, will not flash any data to external drive. What it can flash are all internal storage. For example, the internal emmc or internal sdcard slot.
If you just run and give it nvme or sda1, then your nvme/SSD will still be empty.
To flash nvme or SSD, please use initrd flash tool instead.

Second, for any boot issue. You must share the log from UART serial console.

It is unlikely to precisely know what goes wrong if you cannot provide log.

Third, please check if your SSD or NVMe drive is able to get detected in emmc boot case first. If it cannot be enumerated, then it is not possible you can boot from it.


Please wait. I will test this further and get back with clear instructions on how to flash to SSD successfully.

@lakshantha.d Our board is Jetson Xavier NX custom board. And we’ve tried jetpack 5.0.2. Please try your installation in this specific board with jetpack 5.0.2

Thank you


This specific board right?

@lakshantha.d Yes. SATA SSD version

Hi @amasud183040

You can check flashing with initrd: NVIDIA Jetpack Flashing with initrd | RidgeRun Developer

Please, let us know your results.

Embedded SW Engineer at RidgeRun
Contact us:
Developers wiki:

last year we used this method for jetpack 4.6.x. But it gave errors. However, this year we’re trying jetpack 5.x and the official manual for initrd is only for jetpack 4.6.x

Hi @amasud183040

Sorry for the late response:

Here is a link to the JetPack 5 documentation to flash using the initrd Flashing Support — Jetson Linux<br/>Developer Guide 34.1 documentation

The initrd script is in /Linux_for_Tegra/‌tools/‌kernel_flash/.

For example:

VIER_NX_TARGETS/Linux_for_Tegra/tools/kernel_flash$ ls

Hope this helps!

Embedded SW Engineer at RidgeRun
Contact us:
Developers wiki:

I found a reliable way to install jetpack 5.0.2 on ssd. I found this after method after some searching.
This installs on both NVME drive and on internal emmc, but makes NVME the default boot drive:

  1. Install to emmc using sdkmanager (or (maybe REDUNDANT?)
    1.1. Download l4t BSP and sample rootfs, build it (shown in above)
    1.2. You can flash via command line:
    1.2.1. sudo ./ jetson-xavier-nx-devkit-emmc mmcblk0p1
    1.3. Or just use sdk_manager

  2. Boot to setup, then to desktop, make sure nvme0n1p1 is available (type “parted” in search bar)
    2.1. If not available, delete all partitions in nvme0 using “parted”

  3. Flash jetpack to SSD (***NOTE: can’t be used here):
    3.1. sudo ./ --storage nvme0n1p1
    3.2. JETSON WILL BOOT TO BLACK SCREEN, this is expected.

  4. Re-flash jetson to EMMC again (use sdkmanager)
    4.1. sudo ./ jetson-xavier-nx-devkit-emmc nvme0n1p1

  5. Set it up again. Then reboot.

  6. Press escape to go to bios

  7. Set SSD as initial boot device

thank you for your concern @EduardoSalazar96
however, it did not work

while installing, it doesn’t give any error. But it does not boot from SSD. Instead it boots from previously installed emmc drive.

please change the ATA driver from module (.ko) to built-in in kernel image. This requires to rebuild the kernel.

can you give me the process / tutorial?

The official docs come with the particular release you are using and are for cross compiling on a host PC. See to particular release you are using (L4T release found with “head -n 1 /etc/nv_tegra_release”):

More of a tutorial on kernel build configuration:

More of a tutorial on building a kernel:

i am not a poweruser. can you please give me the abstraction over the solution?

Some background might help…

The kernel basically is what talks to the “bare metal”. It talks directly to hardware, e.g., to the disk controller. Without that there can be no software to “abstract” other drivers. In this case “SATA” is the abstraction, and another set of software (linked to this) talks directly to the disk controller. The software for either the disk controller or the SATA abstraction (abstraction meaning it provides some “standardized” interface where anything knowing that abstraction can also talk to the same hardware) can be put into the kernel in either of two ways. That’s what the solution is about…those two different ways of putting the software in.

The Linux kernel has most of its functionality in a single file, and on the Jetson, that’s usually “/boot/Image”. Anything in that file could be considered “integrated” directly into the kernel. However, sometimes it is nice to be able to load other drivers or parts at a later time since not everyone uses those features or drivers.

For example, everyone needs certain types of memory and memory management. This is always integrated. Other people might need a driver for some obscure satellite radio. Why clutter up the system with that obscure driver by default? It is better if something like that can be “loaded dynamically” (indeed, it is a “loadable module”…a separate file which is only installed at a later time when the kernel is already up and running). Currently you have a loadable module for the ATA driver.

During boot the boot software eventually gets to a point where it puts the integrated kernel into memory. Anything that kernel can do (any feature or driver present in the kernel) is now functional. However, modules are not yet functional because they have not been loaded (including the ATA driver; this is one of the abstractions to make disk drive access available with a common interface; this beats everyone writing a different custom driver for their disk or controller). One has to load the ATA driver module before the controller can look for a disk.

Suppose the kernel module (a separate file not in the “/boot” directory; it is somewhere under “/lib/modules/$(uname -r)/kernel”) is itself on a disk. But ATA is needed to find the disk. All you have to do is load the driver from the ATA disk in order to read the ATA disk. Trouble in paradise (or at least in modules)!

It is easy to load the kernel itself (the integrated kernel Image). The bootloader has methods to do so. If the modules were on the same disk as the kernel, then everyone would be happy. However, the ATA driver is on the external drive and not on the same drive the kernel is on. You get the proverbial “catch 22”.

You have two choices in how to get that module loaded in this case. The more complicated choice is to use an initial ramdisk (initrd) which basically has a miniature filesystem containing the module, and the bootloader starts with that, followed by switching over to the real filesystem after the module is loaded (which is the part which gives the kernel the knowledge to know how to do so).

The simpler choice is to move the feature out of the module and instead into the kernel Image file itself. Then there is no need for the initial ramdisk. The boot software already knows how to load the kernel Image file (the integrated kernel).

The gist is that a kernel has a bunch of optional features, and you need to find the existing set of features, and match that before building a kernel. Then you use a proper configuration editor, and simply switch the ATA driver from being built as a module to instead being built as an integrated feature. In a menu editor (there are several, it is a matter of preference), when you first start, you simply load a configuration copy. You then find the ATA driver. The install status will show as “m” since it is built as a module. You simply switch it to “y” (for “yes, build this into the kernel”). Then you build that kernel. The result is a kernel which matches the original features, but the ATA driver is now in the kernel Image file rather than being a module.

After that you only need to install the kernel. You should probably ask about this rather than simply installing it once you have it. There are actually two methods by which the kernel Image can be installed, and one is vastly simpler than the other. Also, when you rebuild a kernel, sometimes you must rebuild all of the modules as well. Those modules tend to require being arranged correctly, and that might arrange differently when you change the integrated kernel.

The URLs I gave before are a way to learn more, but you can always ask questions at any step. To get you started though, here are some details:

  1. Which release of L4T is your Jetson currently flashed with? See “head -n 1 /etc/nv_tegra_release”.
  2. Go to that L4T release via (your particular JetPack release ties to this release).
  3. For the kernel source, download the “Driver Package (BSP) Sources”, which produces a file “public_sources.tbz2”.
  4. That file has several things in it. The goal is to unpack the one which is “Linux_for_Tegra/source/public/kernel_src.tbz2”.
  5. To unpack just that file:
    tar -jxf public_sources.tbz2 'Linux_for_Tegra/source/public/kernel_src.tbz2'
  6. If you have that file you can now delete public_sources.tbz2.
  7. You now have to unpack the file you just unpacked:
    cd Linux_for_Tegra/source/public/
    tar xvfj kernel_src.tbz2
  8. You could (if you want) now delete “kernel_src.tbz2”. It might be useful to keep this around until you are done just so you can easily start over, although using the right build options means you’ll never need to unpack this again unless you want to move to a different location.
  9. Go to the location where most build commands will be from:
    cd kernel/kernel-5.10
  10. Often this will be referred to as the “top” directory location…the root of the kernel file build. If you want to temporarily memorize this location for that particular terminal you are working from (logout or going to a new terminal will erase this):
export TOP=`pwd`
# and verify:
echo $TOP
  1. Most documentation will simply say “TOP” or “$TOP” (the “$” means the data pointed to by environment variable “TOP”).
  2. Now read any documentation on configuration. The “make” command target “tegra_defconfig” will be found in many NVIDIA docs. This is the default configuration the Jetson will ship with. Alternatively, the kernel will reflect its current configuration in file “/proc/config.gz”. Mostly the two will match, but if you are ever in doubt, and if the current modules will be reused, then refer to a copy of the “/proc/config.gz” (the other URLs I gave talk more about this).
  3. Pay special attention in any documents to the feature “CONFIG_LOCALVERSION”. This is not preserved in either “make tegra_defconfig” or in “/proc/config.gz”. If you run the command “uname -r”, then the suffix is what “CONFIG_LOCALVERSION” was set to during the build of the running kernel. This almost always defaults to “-tegra”. If you are installing modules as well as changing the integrated kernel, then you might want to change this, e.g., to “-tegra2” or “-test”; if not, then you’d want this to remain an exact match with “-tegra”.

If you will build this on the host PC it isn’t a problem. Just install the tools in the documents which come with that release for “kernel customization”. Build steps will be the same other than some different environment variables, e.g., for cross compile you’ll see an “export” of “ARCH” and “CROSS_COMPILE”; for natively compiling (directly on the Jetson) you wouldn’t use those.

The Jetson itself is unlikely to have enough disk space for this. Any temporary external media is useful for this, e.g., you could use a USB thumb drive to build on. Or just build it on the PC with those slightly different environment variables. Those other URLs should provide where to continue once you get that kernel source, but just ask if anything needs clarification. Definitely ask more before installing any kernel or module to the Jetson.

1 Like

no error while installation. however it loads my old os from eMMC

Changing the kernel does not change the o/s itself. Only the kernel behind the o/s changes. If you mean that the kernel does not change, then:

  • How are you determining it did not change?
  • What is the result of “uname -r”?
  • Was there a particular configuration you changed, and if so, how many of the changes were in the format of a module, and how many were changes to the actual integrated kernel Image?

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