Boot stuck after manually signing payloads for UEFI Secureboot [36.3]

Hello Im using the jetson orin AGX devkit,
I signed manually all the payloads on the host and then I updated them on the devkit, I also enrolled the keys. When I boot from the extlinux.conf I have this error: No root-device: Mount failed.

boot_log.txt (88.0 KB)

However when I mount from the kernel partition it seems to boot normally. the secureboot is activated when I checked using the efivar -n variable.

Hi elhamriothman,

bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
bash-5.1# [    8.007939] No root-device: Mount failed

It seems you enter into the recovery boot state.
We would like to check the serial console log before the current log. (i.e. the boot last time)

Please also share the detailed steps what you have done on the devkit.

I don’t really understand what you mean by log before current log is there a folder that contains all the logs of the Jetson or something? cause I did give the log of the serial consol using the usb B port.

I’ll be passing all the steps of the manual singings of the paylods on the next response.

Signed the payloads using db key on the rootfs and the parititions:


openssl cms -sign -signer db.crt -inkey db.key -binary -in extlinux.conf -outform der -out extlinux.conf.sig


openssl cms -sign -signer db.crt -inkey db.key -binary -in initrd -outform der -out initrd.sig

cp Image Image.unsigned

sbsign --key db.key --cert db.crt --output Image Image

openssl cms -sign -signer db.crt -inkey db.key -binary -in kernel_tegra234-p3737-0000+p3701-0000-nv.dtb -outform der -out kernel_tegra234-p3737-0000+p3701-0000-nv.dtb.sig

…/bootloader/mkbootimg --kernel Image --ramdisk initrd --board internal --output boot.img --cmdline “root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 console=ttyAMA0,115200 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0”

openssl cms -sign -signer db.crt -inkey db.key -binary -in boot.img -outform der -out boot.img.sig

truncate -s %2048 boot.img

cat boot.img.sig >> boot.img

Kernel-dtb of the krenel-dtb partition:
cp tegra234-p3737-0000+p3701-0000.dtb tegra234-p3737-0000+p3701-0000.dtb.unsigned

openssl cms -sign -signer db.crt -inkey db.key -binary -in tegra234-p3737-0000+p3701-0000.dtb -outform der -out tegra234-p3737-0000+p3701-0000.dtb.sig

truncate -s %2048 tegra234-p3737-0000+p3701-0000.dtb

cat tegra234-p3737-0000+p3701-0000.dtb.sig >> tegra234-p3701-0004-p3737-0000.dtb

…/bootloader/mkbootimg --kernel Image --ramdisk initrd --board internal --output recovery.img --cmdline “root=/dev/initrd rw rootwait mminit_loglevel=4 console=ttyTCU0,115200 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0”

cp recovery.img recovery.img.unsigned

openssl cms -sign -signer db.crt -inkey db.key -binary -in recovery.img -outform der -out recovery.img.sig

truncate -s %2048 recovery.img
cat recovery.img.sig >> recovery.img

Recovery-kernel-dtb of partition:
cp tegra234-p3737-0000+p3701-0000-nv.dtb.rec tegra234-p3737-0000+p3701-0000-nv.dtb.rec.unsigned

openssl cms -sign -signer db.crt -inkey db.key -binary -in tegra234-p3737-0000+p3701-0000-nv.dtb.rec -outform der -out tegra234-p3737-0000+p3701-0000-nv.dtb.rec.sig

truncate -s %2048 tegra234-p3737-0000+p3701-0000-nv.dtb.rec

cat tegra234-p3737-0000+p3701-0000-nv.dtb.rec.sig>> tegra234-p3737-0000+p3701-0000-nv.dtb.rec

cp BOOTAA64.efi BOOTAA64.efi.unsigned

sbsign --key db.key --cert db.crt --output BOOTAA64.efi BOOTAA64.efi

I then downloaded the paylaods and keys auth on the jetson and pass modified each partition using dd as well as enrolling the keys using efi-updatevar -f, for the rootfs I replaced the filenames on the target like this:

and for the partitions I used the dd command.

What I mean is the full serial console log including the log before your current log.
There should be some helpful messages before your current log showing how it enters into recovery boot.

I found that you open another topic, do you still have the boot stuck issue?

I reflashed the jetson with the uefi keys, I found that doing it manually won’t be our use case, however the other topic will be our workflow, which is to modify payloads when the secureboot is already enabled.

So we can close this one and continue on the other if you would like.