Jetson Xavier NX stuck in Timeout and then exited while flashing with disk encryption enabled with R35.4.1 BSP

[adit_bhrgv]

Hi,

I am using new BSP r35.4.1 and a carrier board Jetson Xavier NX (it is unfused board)
I created a sample customized rootfs and enabled disk encryption but during flashing the Jetson Xavier NX board failed to boot and get stuck in “Waiting for target to boot-up…” . Log coming from
Linux_for_Tegra/tools/kernel_flash/l4t_initrd_flash_internal.sh

NOTE: I am not using any docker environment. I am using an Ubuntu 20.04 based PC.

However, I didn’t face this issue in earlier BSP r35.1

The command I used to flash the jetson is :

sudo ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh -p "-i ./ekb.key" --external-device nvme0n1p1 -c ./tools/kernel_flash/flash_l4t_nvme_rootfs_enc.xml --external-only -S 40GiB --showlogs --network usb0 jetson-xavier-nx-devkit-emmc nvme0n1p1

I also noticed l4t_initrd_flash_internal.sh file has changed since r35.1 to r35.4.1 version. That’s why I used --network usb0 flag in my flash command. But still can’t make it to work .

Could you please let me know the reason for it and how can I make it work with new BSP r35.4.1

Thanks !

Logs:

Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…

Timeout
Cleaning up…

I also saw that it got stuck in loop in l4t_initrd_flash_internal.sh with parameters :

netpath =

sys/class/net/docker0
/sys/class/net/enp0s25
/sys/class/net/lo
/sys/class/net/wlo1
/sys/class/net/wwan0

netserialnumber = 6180EC262C42C5M0
netconfiguration = WMC Device with GPS

[JerryChang]

hello adit_bhrgv,

could you please confirm it’s due to ROOTFS_ENC?
can you flash the target normally by using r35.4.1 release version.

BTW, are you using SDKManager to install JP-5.1.2 image,
or, you’re downloading the sources, and compile the file system by yourself?

[adit_bhrgv]

Hi,

I am also getting the same issue without disk encryption:

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c ./tools/kernel_flash/flash_l4t_nvme.xml -S 40GiB --showlogs  jetson-xavier-nx-devkit-emmc nvme0n1p1

I am not using SDKManager to install JP-5.1.2. I have created a customized rootfs which I want to flash on the Xavier NX board. Could there be something wrong here ?

THanks !

[JerryChang]

@adit_bhrgv

SDKManager to install JP-5.1.2.

please give it a try to download the Jetpack release for confirmation.

[adit_bhrgv]

Hi,

I think we have figured out the problem with this “Timeout” issue.
We changed the bootloader/l4t_initrd.img by following the below steps:

decompress:

cp bootloader/l4t_initrd.img ~/initrd/
cd ~/initrd/
gzip -cd l4t_initrd.img | cpio -imd --quiet
vi init #Just added a echo statement in “init” file
rm l4t_initrd.img

compress after modifying init file:

find . | cpio --quiet -H newc -o | gzip -9 -n > ~/l4t_initrd.img
cp ~/l4t_initrd.img bootloader/

In earlier BSP 35.1, modifying the init file in l4t_initrd.img was working perfectly fine.
But in this BSP 35.4.1, even adding a simple echo statement in initrd is leading to “Timeout” issue. but if we don’t modify this init file, it works perfectly while flashing without “Timeout” issue.

Could this be the case because initrd needs to be signed by uefi keys ? Secure Boot — Jetson Linux Developer Guide documentation

If yes, how can we do that ? We tried this approach by using flag "–uefi-keys uefi.conf " with l4t_initrd_flash.sh script but it didn’t generate initrd.sig.

Note: We tried signing the initrd both for fused and unfused boards but it didn’t work either.

Thanks

[JerryChang]

@adit_bhrgv

modifying the init file in l4t_initrd.img

so… it means you’re able to flash the target with disk encryption enabled on default r35.4.1 release image.
may I have more the details to update init file?

[adit_bhrgv]

Yes disk encryption also works with BSP 35.4.1.

We extract init file from l4t_initrd.img and then edit the init file by just putting an echo statement, nothing more, then we repackage the initrd contents into l4t_initrd.img and copy it to bootloader. Thats it…

decompress:

cp bootloader/l4t_initrd.img ~/initrd/
cd ~/initrd/
gzip -cd l4t_initrd.img | cpio -imd --quiet
vi init #Just added a echo statement in “init” file
rm l4t_initrd.img

compress after modifying init file:

find . | cpio --quiet -H newc -o | gzip -9 -n > ~/l4t_initrd.img
chown root:root ~/l4t_initrd.img
cp ~/l4t_initrd.img bootloader/

[adit_bhrgv]

I also tried to modify initrd directly following this link:
https://docs.nvidia.com/jetson/archives/r35.4.1/DeveloperGuide/text/SD/FlashingSupport.html#to-modify-ram-disk

But during flashing the initrd contents (init file which I modified with an echo statement gets overwritten) are overwritten with default values. Why are my changes in initrd gets lost when I run the l4t_initrd.flash.sh script ?

[JerryChang]

we’ve not test this scenario.
however, may I have details, or your real use-case to modify init file with disk encryption enabled?

[adit_bhrgv]

Hi,

We want to modify the initrd in order to implement generic passphrase based disk encryption.
As the generic passphrase based implementation is not directly supported by Nvidia, we want to try it ourselves.

Could you please let us know what exactly changed from BSP 35.1 to BSP 35.4.1 while modifying “l4t_initrd.img” ?
Because I was able to modify l4t_initrd.img in BSP 35.1 by modifying init file and flash the jetson but this leads to “Timeout” in new BSP 35.4.1 as I mentioned earlier. If you could help us resolving this , that would be great help.

Also, according to link : Flashing Support — Jetson Linux Developer Guide documentation , we can also modify initrd contents, but this leads to our changes gets overwritten during flashing. So, this method doesn’t work for us either.

Thanks !

[adit_bhrgv]

Hi @JerryChang,

Do we have any update on this ?
I saw the tag is changed to nvbugs.

Thanks !

[JerryChang]

hello adit_bhrgv,

I’ve put this into internal discussion, and it may takes some time to come out conclusion.
anyways, could you please see-also Topic 266810 for the steps to modify initrd for testing.

[JerryChang]

BTW,
please note that you should do "sudo su" before modifying the initrd, or it may cause a problem.
for the steps to modify the initrd (on target or on the host), you must use the parameters in these commands EXACTLY,
for instance, To Modify Ram Disk.

[adit_bhrgv]

Thanks @JerryChang .
It was indeed the issue of sudo permissions.
While modifying init file l4t_initrd.img with old BSP 35.1, I was using “sudo su” but somehow it got skipped while migrating to new BSP 35.4.1.

I re-ran the steps of modifying init file with “sudo su” and now the “Timeout” issue is not there anymore.

Thank you again for your suggestion and reminder to use “sudo su”.