Altering/Editing the UUID of a JP5.1 Jetson Xavier NX Device While Flashing


Some Context:
We are trying to switch over to JetPack 5.1 V1.0. We previously had our devices running JP 4.6 V1.1.
In JP4.6 V1.1, we could install an SSD, and alter a few files in the /boot/extlinux directory to include the UUID of /dev/sda1 (the SSD), which would have the device running on the SSD, rather than the EMMC, on the next boot. This is important as when installing SSD’s, we would Image them with a predefined image we have, and that causes all the SSD’s to have the Same UUID.

Attempting to do the same thing in JP5.1 V1.0, the device attempts to boot, and then starts spewing out “Cannot find device ”
We can, after the 30 second timeout, reboot, and manually select the /dev/sda1 device (In the F2 Boot Menu), but we would like it to boot from the SSD right after we copy the files in, so everything can be automated using a Shell script. (E.g. The human will not have to touch the F2 Boot Menu on the device)

We believe this probably has something to do with the altered bootloader, and we were wondering if there was a way that we could statically address a UUID when we flash the device with JP5.1, possibly by altering one of the files in the SDK?

Let me know if we need more information (And in particular, what may be needed) and I’ll do my best to answer in a timely fashion.

Thank you!


You should check Workflow 3 in Linux_for_Tegra/tools/kernel_flash/README_initrd_flash.txt, and there’s a section:

  • (Optional) Declare ADDITIONAL_DTB_OVERLAY_OPT= where can be BootOrderNvme.dtbo.
    This allows UEFI to prioritize booting from NVMe SSD. can also be BootOrderUsb.dtbo, which
    allows UEFI to prioritize booting from the USB storage drive

I believe this is what you are looking for.

I’ll look into this a bit, thank you!

After looking through some of this:

It should be noted that I am using the “BootOrderSata.dtbo” File, as our devices utilize SATA Drives. I assume this file has the same function, different protocol.

We flashed a device using Workflow 3, but the device still booted off of EMMC by default.
I attempted our standard configuration (Imagine the SSD with our image, installing the SSD, Manually mounting the SSD as it did not auto mount, Copying the modified extlinux.conf files to both the SSD and the EMMC, which point to the SSD as the primary partition and EMMC as the secondary, reboot). On Reboot, the device attempted to PXE boot. I hit enter to continue past this, and then we ran into the same error as before. “mount: /mnt/: can’t find PARTUUID={UUID of SSD}” “/mnt/ is not a mountpoint”
From here, we can reboot and manually select the SSD from the F2 Boot Menu.

Looking around the SDK, I saw a few things of interest.

  • I noticed within Workflow 3, there is a section:

Flash an NVMe SSD and use the partition UUID (that is specified in l4t-rootfs-uuid.txt_ext) as the root filesystem:
sudo ADDITIONAL_DTB_OVERLAY_OPT=“BootOrderNvme.dtbo” ./tools/kernel_flash/ --external-device nvme0n1p1 -c ./tools/kernel_flash/flash_l4t_external.xml --showlogs jetson-xavier external

The “l4t-rootfs-uuid.txt_ext” file does not exist anywhere within the SDK that we have. We have verified the Checksum several times as well, and everything is kosher there. I’m wondering if this file was renamed or otherwise altered, as it appears (from what workflow 3 says) that it could set a static UUID for the device (which is what we want)

  • I also noticed that for the flashing tool, it disables udisks2.service.
    I re-enabled the service on one of our test devices, and it did not auto-mount the SSD. We’re looking into this as in JP4.6, the SSD would mount on startup, which 5.1 does not. This could also be causing our error, we believe (“Cannot find device ”) Is there another item altered, preventing the automatic mounting of the SSD in JP5.1 V1.0?

Apologies for the massive posts, and thank you for your time!


pointing the rootfs in extlinux.conf is the way to do it in r32, and you don’t do it in r35 with UEFI. I’m sure there is no need of playing with UUID anymore.

If it still does not work, I’ll try on our side to see if it’s indeed a bug.

Thank you!

This has solved the original issue, I edited the dtbo’s in the kernel directory, and the device now boots from the SSD (After copying Extlinux.conf files, still, but that is acceptable)

One small note:
In the dtbo’s, I have the boot order defined as “usb,sata,nvme,emmc”
When booting, if a LAN cable is connected, the device will spend about 6 minutes attempting to boot from first HTTP, and then PXE. We can remedy this by simply not having a LAN cable plugged in, but any ideas on what might be causing it to attempt those first when they aren’t even defined in the boot order?


we’d suggest not plug in the Ethernet cable when the device is booting up. Some users also hit this issue, but it seems to happen randomly, and cannot be consistently re-produced.


Is this actively being worked on? In other words, do you have an estimate when this issue might be fixed?
In the meantime, is there a HTTP/PXE timeout we can adjust, so that it doesn’t take 6-10 minutes to boot every time?

Thank you!


I just tested on my Xavier NX with LAB cable plugged in during boot up, and I didn’t encounter the same issue.
Can you try if flashing the SSD with SDK Manager still causes the same issue (by default boot from eMMC/SD, stuck at network boot)
If it’s still the same, we would just suggest this:

I will attempt an SDK Manager flash.
As for the remedy:
We have devices that are remote that we cannot always physically access. For the devices at HQ, unplugging the LAN works, but for the remote devices, we can’t always do that.
HTTP/PXE appear to time out after a few minutes each, is this timeout something we can adjust? (Like, make it 1 second so it doesn’t take so long to reboot?)


sorry that it’s not configurable.
Instead, you can remove line #187~209 in this file, compile the UEFI source code, and flash again with the UEFI binary you just get, so it won’t try HTTP/PXE upon boot.

Guide for building UEFI binary is available here:

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