Encrypted RootFS Boot Failure After NVIDIA System Update – "crypt_UDA: command not found" (Jetson Orin NX 16GB)

[imran.khalid]

Hello NVIDIA team,

I am facing a blocking issue with encrypted root filesystem on Jetson Orin NX 16GB, and I need clarification and guidance for production-safe updates.

Summary of the Issue

I successfully flashed my Jetson Orin NX (NVMe rootfs) using:

• ROOTFS_ENC=1

• sym2_t234.key

• Custom eks_t234.img

• Standard L4T kernel_flash flows (internal → external → flash-only)

The encrypted SSD booted correctly and worked without any issues.

However, after an NVIDIA update (via apt), the device rebooted and now fails to unlock the encrypted rootfs with the following error during early boot:

/bin/bash: line 1: crypt_UDA: command not found
ERROR: fail to unlock encrypted dev /dev/nvme..

This error prevents the rootfs from unlocking, and the system cannot boot.

What I believe happened

It appears that the update replaced or modified components such as:

• nvidia-l4t-initrd

• nvidia-l4t-kernel

• Bootloader/initrd scripts

• Or related BSP packages

This seems to have removed or overwritten the custom encryption logic (crypt_UDA, luks-srv interaction), causing the initrd to lose its ability to decrypt the encrypted rootfs.

My Setup

• Jetson Orin NX 16GB

• NVMe root filesystem

• Disk encryption using ROOTFS_ENC=1

• eks_t234.img generated using gen_ekb.py

• OP-TEE + OEM_K1-based EKB flow

• JetPack / L4T version: (please confirm if the exact version is needed)

• System was working perfectly before the update

Questions for NVIDIA

1. Is it expected behavior that system updates modify initrd/boot components in a way that breaks encrypted rootfs boot?

2. What is the recommended NVIDIA-supported procedure to:

   • Prevent BSP/kernel/initrd packages from updating accidentally?

   • Ensure production devices with encrypted rootfs do not get invalid initrds?

3. Is there an official method for performing safe OTA updates or kernel changes while maintaining encrypted rootfs compatibility?
   (e.g., supported image-based OTA for encrypted NVMe rootfs)

4. Is there a documented workaround or recovery process for restoring crypt_UDA functionality without fully reflashing the board?

5. For production:

   • Should all BSP packages be pinned (apt-mark hold)?

   • Is it safe to disable unattended-upgrades for L4T-based devices?

Additional Context

This issue can completely brick production devices that rely on encrypted rootfs, because:

• Updates change initrd

• Initrd no longer contains encryption hooks

• Boot process breaks before rootfs unlock

• Device becomes inaccessible

This poses a significant risk in field deployments.

What I Need

• Confirmation on correct production practices

• Guidance on preventing unwanted updates

• Recommendations for supporting secure/consistent OTA updates

• Clarification on how to fix systems once they hit this error

Any help or official documentation links would be greatly appreciated.

Thank you.

If you want, I can also:

• Add logs / exact command outputs

• Tailor the post for JetPack 5.x or 6.x depending on your version

• Attach boot logs in the format NVIDIA prefers

• Make a shorter or more formal corporate-friendly version

Would you like me to tune it further?

[JerryChang]

imran.khalid,

@imran.khalid

after an NVIDIA update (via apt),

may I know what’s your base version, were you based-on r36.3 update to a new point release (r36.3 to r36.4) or.. you’re updating from r35 to a new minor release.

it might due to apt update has overwrite the EKS image, which contain the user key to decrypt the ROOTFS_ENC.
you may try Generating a Specified Partition BUP to update EKS image for confirmation.

[imran.khalid]

@JerryChang is this correct solution that I have omitted all Nvidia packages out of upgrade list. In that way any accidental upgrade will not create problems.

[imran.khalid]

I am not entirely sure as this happened accidentally. I could not record base versions.

[JerryChang]

hello imran.khalid,

you should avoid apt update, please do Image-based OTA if you need moving forward BSP version.