System stuck at transition from L4T 36.4.3 to L4T 36.4.4

Hello, can you help me with next topic:

I am using Orin nano P3767-0003 inserted in original development kit from nvidia.

Commands to flash the system:

SKU=“0003”
tar xf ~/common_files/Jetson_Linux_r36.4.3_aarch64.tbz2
sudo tar xf ~/common_files/Tegra_Linux_Sample-Root-Filesystem_r36.4.3_aarch64.tbz2 -C Linux_for_Tegra/rootfs/
tar xf ~/common_files/public_sources.tbz2
cd Linux_for_Tegra/source
tar xf nvidia-jetson-optee-source.tbz2
cd ../..

cp ~/my_data/tegra234-mb2-bct-misc-p3767-0000.dts Linux_for_Tegra/bootloader/generic/BCT/
#with:

//cvb_eeprom_read_size = <0x100>;

cvb_eeprom_read_size = <0x0>;

cd Linux_for_Tegra
openssl rand -rand /dev/random -hex 16 > sym2_t234.key
echo “0000000000000000000000000000000000000000000000000000000000000000” > oem_k1.key
python3 ./source/optee/samples/hwkey-agent/host/tool/gen_ekb/gen_ekb.py -chip t234 -oem_k1_key oem_k1.key -in_sym_key2 ./sym2_t234.key -out bootloader/eks_t234.img

sudo BOARDID=3767 BOARDSKU=$SKU ADDITIONAL_DTB_OVERLAY_OPT=“BootOrderNvme.dtbo” ./tools/kernel_flash/l4t_initrd_flash.sh --network usb0 --no-flash --showlogs -p “-c bootloader/generic/cfg/flash_t234_qspi.xml” jetson-orin-nano-devkit-super internal

sudo BOARDID=3767 BOARDSKU=$SKU 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_my.xml -S 100GiB --external-only --append --network usb0 jetson-orin-nano-devkit-super external sudo BOARDID=3767 BOARDSKU=$SKU ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs --network usb0 --flash-only

At startup everything is ok, UDA and APP_ENC partition is decrypted automatically
After few reboots every think is ok.
But after I connect device to Wifi
call sudo apt-get update && sudo apt-get upgrade -y
I am asked to reboot to finish installation.
At reboot I see:
update process:


and after this a error about uda partion:

sudo cat /etc/apt/sources.list.d/nvidia-l4t-apt-source.list

deb https://repo.download.nvidia.com/jetson/common r36.4 main
deb https://repo.download.nvidia.com/jetson/t234 r36.4 main
deb https://repo.download.nvidia.com/jetson/ffmpeg r36.4 main

show

I have few device with encryption, which upgraded to L4T 36.4.4 without any troubles:


They all are flashed using the same script.
So looks behavior is sporadic.

I do need disk encryption.

Does somebody know what I am doing wrong?

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

The issue you’re encountering with your Jetson Orin Nano device, specifically the error related to the UDA partition after attempting to update and upgrade using sudo apt-get update and sudo apt-get upgrade, suggests a problem with how the UDA (User Data Area) partition is being handled during the update process. The UDA partition is crucial for storing sensitive data and is encrypted for security reasons.

Given the context, here are a few potential issues and solutions to consider:

  1. UDA Partition Encryption and Decryption: The fact that the UDA partition is decrypted automatically at startup suggests that the initial setup and configuration are correct. However, the error message indicating an issue with the UDA partition after updating and attempting to reboot could imply a problem with how updates are being applied to the encrypted partition.

  2. Update Process: The update process involves downloading and installing new packages, which might include updates to the boot loader, kernel, and other system components. If the update process is not properly handling the encrypted UDA partition, it could lead to errors.

  3. APT Sources and Package Updates: The apt sources list you provided shows that you are using NVIDIA’s repositories for updates. Ensure that these repositories are correctly configured and that you are not mixing package sources that could lead to compatibility issues.

  4. Secure Boot and UEFI Firmware: If Secure Boot is enabled, it might interfere with the update process, especially if the updated boot loader or kernel images are not properly signed. The UEFI firmware update procedure you mentioned involves specific commands to update the firmware using a capsule payload, which is a secure way to update the UEFI firmware.

  5. Comparison with Other Jetson Devices: The Jetson Orin Nano, like other Jetson devices, uses a similar Linux-based operating system and update mechanism. However, specific models might have unique configurations or requirements, especially regarding secure boot, UDA partition handling, and firmware updates.

To troubleshoot the issue:

  • Verify UDA Partition Configuration: Ensure that the UDA partition is correctly configured and that the decryption process at startup is properly set up.
  • Check Update Logs: Look into the update logs to see if there are any specific error messages related to the UDA partition or the update process.
  • Secure Boot Configuration: If Secure Boot is enabled, try disabling it temporarily to see if it resolves the update issue. Be cautious, as disabling Secure Boot can have security implications.
  • Firmware and Boot Loader Updates: Ensure that the firmware and boot loader are up to date and properly configured. You might need to manually update these components using the provided UEFI firmware update procedure.
  • NVIDIA Support and Documentation: Consult NVIDIA’s official documentation and support forums for specific guidance on updating the Jetson Orin Nano and troubleshooting UDA partition issues.

In summary, the error you’re experiencing seems related to how the UDA partition is handled during the update process. By carefully examining the update logs, verifying the UDA partition configuration, and ensuring that Secure Boot and firmware are properly set up, you should be able to identify and potentially resolve the issue. If problems persist, seeking guidance from NVIDIA’s support resources may provide more tailored solutions.

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

Add logs from debug uart:

Cannot decrypt app_enc after update to 36.4.4
WithError.txt (72.8 KB)

Startup on 36.4.3:
StartupWithDecrypton36.4.3.txt (80.3 KB)

Starup on 36.4.4:
StartupWithDecryption36.4.4.txt (81.9 KB)
prove from device on 36.4.4 via ssh:
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/crypt_root 98G 24G 70G 26% /
/dev/mapper/crypt_UDA 344M 24K 317M 1% /mnt/crypt_UDA
tmpfs 3.8G 176K 3.8G 1% /dev/shm
tmpfs 1.5G 27M 1.5G 2% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
/dev/nvme0n1p1 359M 63M 268M 19% /boot
/dev/nvme0n1p11 63M 110K 63M 1% /boot/efi
/dev/mapper/net_disk 18G 96M 17G 1% /mnt/net_disk
tmpfs 762M 92K 762M 1% /run/user/128
tmpfs 762M 80K 762M 1% /run/user/1000
cat /etc/nv_tegra_release

R36 (release), REVISION: 4.4, GCID: 41062509, BOARD: generic, EABI: aarch64, DATE: Mon Jun 16 16:07:13 UTC 2025

KERNEL_VARIANT: oot

TARGET_USERSPACE_LIB_DIR=nvidia
TARGET_USERSPACE_LIB_DIR_PATH=usr/lib/aarch64-linux-gnu/nvidia

1 Diff:
During booting with error it tries to load from slot 1

2 Diff:
It does not load something and starts form B_spec_fw:

fyi:
Attach logs from UART during transition on 36.4.4 on encrypted device and on not encrypted device(sorry removed timestamps for easiest diff)
UARTupdateprogressOnEncrypted.txt.txt (95.6 KB)
UARTupdateprogressOnNotEncrypted.txt.txt (100.6 KB)

Add logs during update process:
updatelogsEncr.txt.txt (128.9 KB)
updateNotEncrypted.log (138.2 KB)
Diffs I see:




Hi,

Please use the image-based OTA instead.

We have similar topic related to OTA upgrade with ROOFS_ENC, please refer to

Thanks

Hello @DavidDDD
Thank for an answer, can you please point exact what do you think it is the different can solve our problem?

FYI:
We already have 5 device with Secureboot + UEFI secureboot + Disk-Encryption were flashed with 36.4.3 and they successfully updated to 36.4.4.
But because we cannot pass the “ERROR: might be timeout in USB write” error on next devices,
we leave just Disk-Encryption
and already have 2 device which were flashed with this script(Just disc encryption
) and they updated to 36.4.4. But next few device cannot update to 36.4.4. Maybe it is reproduced sporadically.

Is there a method to block updates to 36.4.4, after sudo apt-get upgrade?

Hi,

Let me understand the situation:
You had two devices that could do disk encryption under r36.4.3 and do sudo apt upgrade to r36.4.4 successfully, but now, following the same approach, some devices cannot complete the upgrade?

Is your carrier board a dev kit or a custom board?

Thanks

Yes you understood correct, we already have few working.
Like this one, it is encrypted and after sudo apt-get upgrade, updated to 36.4.4 and it is working:

we put p3767 003 in original development kit, flash them in original devkit with this changes:
cp ~/my_data/tegra234-mb2-bct-misc-p3767-0000.dts Linux_for_Tegra/bootloader/generic/BCT/
#with:

//cvb_eeprom_read_size = <0x100>;

connect to wifi, call sudo apt-get update && sudo apt-get upgrade -y. install other libraries and put this orin nano in our custom board.

Hello, @DavidDDD @carolyuu Thank you for your time, found the difference. I have 4 types of device upgraded to 36.4.4 successfully:
1)flashed with SKU=0005 and allow to read eeprom(do not comment cvb_eeprom_read_size=<0x100>), it was p3767 0005 (with sd card slot) in original development kit(with AT24C02D-MAHM-T_1Kb on I2C2)
2)flashed with SKU=0003 and allow to read eeprom(do not comment cvb_eeprom_read_size=<0x100>), it was p3767 0003 (without sd card slot) in original development kit(with AT24C02D-MAHM-T_1Kb on I2C2)
3)flashed with SKU=0003 and restrict to read eeprom(comment cvb_eeprom_read_size=<0x100>), it was p3767 0003 (without sd card slot) T201 board from twowin(without AT24C02D-MAHM-T_1Kb on I2C2)
4)flashed with SKU=0003 and restrict to read eeprom(comment cvb_eeprom_read_size=<0x100>), it was p3767 0003 (without sd card slot) our customer board (without AT24C02D-MAHM-T_1Kb on I2C2)

So the solution was to flash and connect to the Wifi in original devkit, but call sudo apt-get upgrade -y already in a customer board without eeprom on I2C2 in case i commented
“cvb_eeprom_read_size=<0x100>”.

For the history:

This command does not block partial upgrade to 36.4.4:
$sudo apt-mark showhold
nvidia-l4t-display-kernel
nvidia-l4t-kernel
nvidia-l4t-kernel-dtbs
nvidia-l4t-kernel-headers
nvidia-l4t-kernel-oot-headers
nvidia-l4t-kernel-oot-modules
$ cat /etc/nv_tegra_release

R36 (release), REVISION: 4.4, GCID: 41062509, BOARD: generic, EABI: aarch64, DATE: Mon Jun 16 16:07:13 UTC 2025

KERNEL_VARIANT: oot

TARGET_USERSPACE_LIB_DIR=nvidia
TARGET_USERSPACE_LIB_DIR_PATH=usr/lib/aarch64-linux-gnu/nvidia

As during boot on UART and Display it shows 36.4.3, but when nv_tegra_release shows 36.4.4

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