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:
extlinux.conf:
openssl cms -sign -signer db.crt -inkey db.key -binary -in extlinux.conf -outform der -out extlinux.conf.sig
initrd:
openssl cms -sign -signer db.crt -inkey db.key -binary -in initrd -outform der -out initrd.sig
Kernel:
cp Image Image.unsigned
sbsign --key db.key --cert db.crt --output Image Image
Kernel-dtb:
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
boot.img:
…/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
Recovery.image:
…/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
BOOTAA64.efi:
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.
I have been through the same problem while trying to modify signing operation of nvidia. So I’m using yocto to build branch kirkstone but this is not out case. So I’d recommend you to check boot.img size if it is different from the working one or if you’ve made boot.img manually. So what is the content in it ? The problem that there is no filesystem in boot.img so it would be hard to tell unless you check the size. So your issue actaully consists of two subproblems. First one which lists partitions. This issue happens because bootloader is not found and first of all try to mount esp.img if it is not mounted so the problem is not necesserly in it. I’ll tell what happened with me when I tried to extract the yocto output artifact which is tegraflash.bla bla bla I used the default archive manager gui in ubuntu. Try to run this for extraction -in case you’re using yocto as me- “mkdir temp && tar -xvf artifactname.tegraflash.tar.gz -C temp/”
If you’ve found this usefull to you please ping me cause I have some questions related to encryption. I’ve started with signing and then encryption. And also I’m making signing with aws-kms backend in a workflow so If you’ve further question regarding signing in a workflow don’t hesitate asking me.,
Hello hussein,
Thanks for the reply in fact I don’t have this issue yet, the thing is Im gonna doing something else right now but before the end of this week I’ll try to actually modify a payload and sign it it, because that’s the issue im having right now, I don’t even know if it’s supported by nvidiea the fact that you can modify a payload and sign it while secureboot is on.
Hi,
I’ll suggest you some steps. First of all disable secure-boot totally and start modifying your payload once it worked, start signing these payloads and I’m pretty sure that it will work. I’d also suggest you to use gtkterm to communcate with the device as minicom and other programs tend to delete some lines in booting when there is such problem as bootloader not found so I weren’t able to debug correctly.
Hey hussein,
Yeah but my purpose is to test it while secure-boot is on not when it’s off.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
