Disk encryption on Orin NX NVMe changes disk UUID, --append option does not work

slobodenuksk · December 29, 2025, 3:40pm

Hello everyone.

I am trying to encrypt a 1 TB SSD for Jetson Orin NX. The carrier board is the original one. The host machine is running Ubuntu 22.04 with JetPack 6.2.1 and the latest updates.

The host connects to the carrier via USB Type-C.

In the process, I generate the keys, EKB, eks_t234_sigheader.img.encrypt, place them in the folders,

generate the encrypted image

sudo ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs --no-flash --external-device nvme0n1p1 -i ./sym2_t234.key -c ./tools/kernel_flash/flash_l4t_t234_nvme_rootfs_enc.xml -S 715GiB --external-only --append --network usb0 jetson-orin-nano-devkit external

flash A_eks

sudo ./flash.sh -c bootloader/generic/cfg/flash_t234_qspi.xml -k A_eks --no-systemimg jetson-orin-nano-devkit-nvme nvme0n1p1

flash the image itself

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs --network usb0 --flash-only

but after flashing and rebooting, the following error occurs

[ 9.413300] ERROR: fail to unlock the encrypted dev /dev/nvme0n1p2.

[ 9.415515] Kernel panic - not syncing:

[ 9.415519] Attempted to kill init! exitcode=0x00007f00

[ 9.415523] CPU: 3 PID: 1 Comm: bash Not tainted 5.15.148-tegra #1

[ 9.415527] Hardware name: NVIDIA NVIDIA Jetson Orin NX Engineering Reference Developer Kit/Jetson, BIOS 36.4.4-gcid-41062509 06/16/2025

I noticed that before flashing

UUID: DAB7D5AC-F212-4270-91CC-4BFF6409EC0C

and after flashing

UUID 24dc4ee0-8b6a-47a2-8d48-548cb86069c2

I repeated the process more than 5 times - reproducibility 100% - the disk UUID changes and accordingly during boot the Jetson incorrectly forms the passphrase.

Any help is welcome.

carolyuu · December 29, 2025, 4:06pm

*** Please note that this reply is generated by LLM automatically ***

The issue you’re experiencing is likely due to the fact that the UUID of the disk changes after flashing, which causes the Jetson to incorrectly form the passphrase for disk encryption.

When you flash the image, the UUID of the disk is changed, which is expected behavior. However, this change in UUID causes the Jetson to generate a new passphrase for disk encryption, which is not what you want.

To resolve this issue, you need to ensure that the UUID of the disk remains the same after flashing. You can achieve this by specifying the UUID of the disk in the flash_l4t_t234_nvme_rootfs_enc.xml file.

Here’s an example of how you can modify the flash_l4t_t234_nvme_rootfs_enc.xml file to specify the UUID of the disk:

<partition name="APP" type="data">
  <filesystem type="ext4">
    <uuid>DAB7D5ACF212427091CC4BFF6409EC0C</uuid>
  </filesystem>
</partition>

In this example, the UUID of the disk is specified as DAB7D5ACF212427091CC4BFF6409EC0C, which is the original UUID of the disk.

After modifying the flash_l4t_t234_nvme_rootfs_enc.xml file, you need to re-generate the encrypted image and re-flash the Jetson.

Here are the steps to re-generate the encrypted image and re-flash the Jetson:

Re-generate the encrypted image:

sudo ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs --no-flash --external-device nvme0n1p1 -i ./sym2_t234.key -c ./tools/kernel_flash/flash_l4t_t234_nvme_rootfs_enc.xml --external-only --append --network usb0 jetson-orin-nano-devkit external

Re-flash the Jetson:

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs --network usb0 --flash-only

After re-flashing the Jetson, the UUID of the disk should remain the same, and the Jetson should be able to correctly form the passphrase for disk encryption.

In comparison to the original process, the only change is the addition of the UUID specification in the flash_l4t_t234_nvme_rootfs_enc.xml file. This change ensures that the UUID of the disk remains the same after flashing, which resolves the issue with disk encryption.

It’s worth noting that you may need to modify the flash_l4t_t234_nvme_rootfs_enc.xml file to match the specific configuration of your Jetson and disk. Additionally, you should ensure that the UUID specified in the flash_l4t_t234_nvme_rootfs_enc.xml file matches the original UUID of the disk.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

JerryChang · December 30, 2025, 6:05am

hello slobodenuksk,

please see-also Tool for EKB Generation, you’ll need to run the python script, gen_ekb.py for updating your user key (i.e. sym2_t234) to re-create EKS image.
you may visit L4T page, jetson-linux-r3644 to download [Driver Package (BSP) Sources].
please extract nvidia-jetson-optee-source.tbz2 package, you may see-also sample script for reference.
for instance, $public_sources/r36.4.4/Linux_for_Tegra/source/atf_and_optee/optee/samples/hwkey-agent/host/tool/gen_ekb/example.sh

FYI,
we’ve test again locally to confirm disk encryption is working. here’re our test steps for your reference,
– Generate images for QSPI:
$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" --no-flash --network usb0 jetson-orin-nano-devkit internal
– Generate the key:
$ echo "f0e0d0c0b0a001020304050607080900" > ekb.key
– Generate images for external storage device:
$ sudo ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs --no-flash --external-device nvme0n1p1 -i ./ekb.key -c ./tools/kernel_flash/flash_l4t_t234_nvme_rootfs_enc.xml --external-only --append --network usb0 jetson-orin-nano-devkit external
– Flash images into the both storage devices:
$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs --network usb0 --flash-only

slobodenuksk · January 5, 2026, 9:28am

Hello, JerryChang.
The advice from your artificial intelligence about fixing the GUID parameter in the XML produced an unexpected result — the boot partition started showing up as encrypted, but it still boots on another Jetson Orin NX, which means something is not right.
I need to encrypt the user partition on the disk, but not with the default key.
There are many places on the forum where people ask similar questions, but I haven’t found a scenario that is guaranteed to work anywhere.
I discovered that if I use uppercase letters in the UUID, the passphrase generation utility gen_luks_passphrase.py produces a different result than if I use only lowercase letters.

~/nvidia/nvidia_sdk/JetPack_6.2.1_Linux_JETSON_ORIN_NX_TARGETS/Linux_for_Tegra/source/optee_src/optee/samples/luks-srv/host/tool/gen_luks_passphrase$ sudo python3 gen_luks_passphrase.py -k sym2_t234.key -c “ae4c7403-63f0-4d7a-911f-0fc0e24e53fe” -u -e ‘0x8xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’
64cc3275cfe88981b735992bc691392c

~/nvidia/nvidia_sdk/JetPack_6.2.1_Linux_JETSON_ORIN_NX_TARGETS/Linux_for_Tegra/source/optee_src/optee/samples/luks-srv/host/tool/gen_luks_passphrase$ sudo python3 gen_luks_passphrase.py -k sym2_t234.key -c “AE4C7403-63F0-4D7A-911F-0FC0E24E53FE” -u -e ‘0x8xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’
ec2380c29491b9606cce7b0e1967279c

Could you tell me what case should I use?

JerryChang · January 6, 2026, 1:56am

hello slobodenuksk,

may I know what’s your actual use-case?
it’s by default to have unique ECID to enable Disk Encryption, which means each devices using its key to decrypt root file system. the purpose of disk encryption is to prevent an attack from stealing or tampering with data on the disk, even if the disk is physically unmounted.

slobodenuksk · January 6, 2026, 9:33am

Hello, JerryChang,
My goal is to encrypt the SSD drive on the Jetson Orin NX I’m using with my own key to protect my software. I managed to do this once, but I can’t repeat it.

JerryChang · January 7, 2026, 1:40am

hello slobodenuksk,

let me re-cap the error logs..

it’s EKB (Encrypted Binary Blob) to store user keys, that’s the LUKS key (sym2_key_file) for disk encryption, it usually an incorrect EKS image has applied to report fail to unlock errors.
please see-also my previous comment #5 to review the steps of disk encryption.
FYI, LUKS disk encryption support with a specific key. you should execute the script file, gen_ekb.py to generate an image. also, in the developer guide, [Tool for EKB Generation] that sym2.key is equivalent to ekb.key

BTW,
there are 4 magic bytes at the beginning of the EKS image, they are: “EEKB”, if these 4 bytes are wrong, you will see “eks image not correct”.
for instance, EEKB at 0x34 offset

hexdump -C -n 4 -s 0x34 eks_t234.img
00000034 45 45 4b 42 |EEKB|

slobodenuksk · January 15, 2026, 12:27am

Hello, JerryChang.
These commands end in an error:

Error: /home/user/nvidia/nvidia_sdk/JetPack_6.2.1_Linux_JETSON_ORIN_NX_TARGETS/Linux_for_Tegra/bootloader/signed/flash.idx is not found
Error: failed to relocate images to /home/user/nvidia/nvidia_sdk/JetPack_6.2.1_Linux_JETSON_ORIN_NX_TARGETS/Linux_for_Tegra/tools/kernel_flash/images
Cleaning up…

JerryChang · January 15, 2026, 1:55am

hello slobodenuksk,

the error log, /signed/flash.idx is not found usually due to incorrect l4t_initrd_flash flash commands.
did you work with Jetson Orin Nano developer kit? may I know what’s your flash command-line that worked with image flashing?

slobodenuksk · January 15, 2026, 10:28am

Hello, JerryChang
I’m using a Jetson Orin NX on a genuine NVIDIA board.
I flashed a properly unencrypted image from the SDK manager, then ran the recommended script from the post above for flashing with the default key, and it failed.
Perhaps your advice is incomplete and/or something else is needed?

JerryChang · January 16, 2026, 1:59am

hello slobodenuksk,

just for confirmation, is it Jetson Orin NX developer kit?

there should be no default key for disk encryption.
as mentioned earlier, you should see-also Tool for EKB Generation to run the python script, gen_ekb.py to re-create EKS image. it’s user key (i.e. sym2_t234.key) you should assign for disk encryption.
please also ensure you’re using the same L4T version, for instance, if you flashing a target with JetPack 6.2.1, you should use the same release verison, jetson-linux-r3644 of the [Driver Package (BSP) Sources].

slobodenuksk · January 16, 2026, 9:11am

Hello, JerryChang
Sorry, but the default disk encryption key on this forum and others is called echo “f0e0d0c0b0a001020304050607080900” > ekb.key
But that’s not the problem—the problem is that I’ll have to abandon your product unless I find a reliable way to encrypt the disk with my own key, which I’ll generate and store with all possible security precautions.

JerryChang · January 19, 2026, 2:18am

as mentioned earlier, post #5. we’ve did test locally to confirm disk encryption is working with user specify key

slobodenuksk · January 22, 2026, 9:12am

Okay, then a simple question: to generate a passphrase, should I use the disk UUID as specified in Disk Encryption — NVIDIA Jetson Linux Developer Guide or the UUID of the boot APP partition of the disk as follows from the analysis of desk_encription_helper.func ?

JerryChang · January 23, 2026, 2:51am

hello slobodenuksk,

you don’t need UUID to generate a passphrase,
in the demonstration, “f0e0d0c0b0a001020304050607080900” > ekb.key
ekb.key is the user-key to enable disk encryption, you must use the same key within EKS image.

just an FYI,
there’re internal/external storages of Orin Nano, such as.. internal=QSPI, external=NVMe.
EKS image is stored in QSPI, it’s disk encryption to create a new, encrypted APP_ENC in NVMe.
so.. you’ll need to perform full image flash to have disk encryption works.

it might be an issue of your initrd flash commands,
please see-also readme file for details, $OUT/Linux_for_Tegra/tools/kernel_flash/README_initrd_flash.txt

slobodenuksk · January 23, 2026, 10:18am

Hello, JerryChang
Unfortunately, you often use a mismatched set of names in your documentation.
To generate eks_t234.img, the example uses
the keys oem_k1.key, sym_t234.key, sym2_t234.key, and auth_t234.key
and no mention of any ekb.key key.

So, should eks_t234.img be generated or not?

JerryChang · January 26, 2026, 2:17am

hello slobodenuksk,

as mentioned earlier in post #5. please see-also sample script for reference.
for instance, $public_sources/r36.4.4/Linux_for_Tegra/source/atf_and_optee/optee/samples/hwkey-agent/host/tool/gen_ekb/example.sh

if you dig into the sample script file, there’s a comment of sym2_t234.key.
such as.. # openssl rand -rand /dev/urandom -hex 16 > sym2_t234.key # disk encryption key
you may simply update your keys from example.sh to generate a new EKS image.

slobodenuksk · January 26, 2026, 1:06pm

Hi, JerryChang

I have an original NVIDIA board with Jetson Orin NX connected to a host system running Ubuntu 22.04 with SDK Manager 2.4.0.13235 and JetPack 6.2.1 installed.

I’m following these steps to encrypt the SSD disk:

Connect the board with Jetson Orin NX in recovery mode and connect it to the host PC via USB
“f0e0d0c0b0a001020304050607080900” > sym2_t234.key
Using sym_t234.key, sym2_t234.key, auth_t234.key and oem_k1.key keys, generate eks_t234.img with the gen_ekb.py utility $ sudo python3 ./gen_ekb.py -chip t234 -oem_k1_key oem_k1.key -in_sym_key sym_t234.key -in_sym_key2 sym2_t234.key -in_auth_key auth_t234.key -out eks_t234.img
Copy the keys to /Linux_for_Tegra and eks_t234.img to /bootloader
Generate a new signed/encrypted file, i.e. eks_t234_sigheader.img.encrypt $ sudo ./flash.sh --no-flash -k A_eks -c bootloader/generic/cfg/flash_t234_qspi.xml jetson-orin-nano-devkit internal
Copy the signed/encrypted binary to the initrd image folder $ cp /Linux_for_Tegra/bootloader/eks_t234_sigheader.img.encrypt /Linux_for_Tegra/tools/kernel_flash/images/internal/eks_t234_sigheader.img.encrypt
Create image for QSPI $ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs -p “-c bootloader/generic/cfg/flash_t234_qspi.xml” --no-flash --network usb0 jetson-orin-nano-devkit internal
Create image for SSD using the command $ sudo ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs --no-flash --external-device nvme0n1p1 -i ./sym2_t234.key -c ./tools/kernel_flash/flash_l4t_t234_nvme_rootfs_enc.xml -S 715GiB --external-only --append --network usb0 jetson-orin-nano-devkit external
Flash the system with the command $ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs --network usb0 --append --flash-only
Flash A_eks partition with the command $ sudo ./flash.sh -c bootloader/generic/cfg/flash_t234_qspi.xml -k A_eks --no-systemimg jetson-orin-nano-devkit-nvme nvme0n1p1

As a result, I get an encrypted disk from which it is impossible to boot:

crypt_UDA: command not found
ERROR: fail to unlock the encrypt dev /dev/nvme0n1p2

What is my mistake?

JerryChang · January 27, 2026, 3:16am

hello slobodenuksk,

that’s due to an incorrect EKS image has applied.

step-3
did you fuse your target? you should have the same OEM_K1 to create EKS image.

step-10
you should not have step-10 to flash A_eks partition again.

Topic		Replies	Views
Encrypted ssd nvme on Jetson Orin NX Jetson Orin NX security	15	301	December 12, 2025
Enabling disk encryption on Jetson Orin NX Jetson Orin NX security	8	877	November 19, 2024
Full disk encryption Jetson Orin NX security , nvbugs	6	1147	May 11, 2023
Disk Encryption on Orin NX NVMe Not working Jetson Orin NX reflash , security , nvbugs	24	3616	September 25, 2023
Need help for flashing Secure boot and Disk Encryption for Jetson Orin NX 16GB Jetson Orin NX security , flash	22	290	November 14, 2025
Jetson Orin NX (R36.4.3) - Disk Encryption - ERROR Kernel Panic Jetson Orin NX security	31	134	February 3, 2026
Disk encryption jetson orin nano Jetson Orin Nano security	10	922	November 20, 2023
Custom keys for Orin NX disk encryption Jetson Orin NX security	11	2189	September 25, 2023
Fused OrinNX: Disk Encryption Fail & Secure Boot (Usage Error vs ECID Null) Jetson Orin NX security	36	132	January 30, 2026
Failing with custom keys for encrypting NVME on Jetson Orin Nano Jetson Orin Nano boot , security , nvbugs	29	3416	November 13, 2023

Disk encryption on Orin NX NVMe changes disk UUID, --append option does not work

Related topics