Hello,
When I was performing a simulation test of the capsule_updater, I found that it requires two reboots to be triggered.
Test condition: ROOTFS_AB=0.
In rc.local, if the current slot is SlotB, the script triggers the update by calling nv_bootloader_capsule_updater.sh.
Test procedure:
-
Start from SlotA — the updater is not triggered.
-
Use set-active-boot-slot 1 to switch to SlotB.
-
On the next boot, the updater is triggered (confirmed by the rc.local log), and the system correctly boots into SlotB.
-
Then, perform a manual reboot. Expected result: The UEFI process should update SlotA Actual result: No update happens; the system boots directly into SlotB again.
-
In this state, the system automatically runs nv_bootloader_capsule_updater.sh once more.
-
After another reboot, the update finally succeeds and the system boots into SlotA.
I believe there should be nothing wrong with my testing method, but the behavior does not match the expected result.
hello wpceswpces,
we would like to test this locally for confirmation,
may I know which Jetpack public release version you’re working with,
thanks
Hi,JerryChang
We are using jetpack6.0，orin industry custom board
hello wpceswpces,
we’ve test this locally with AGX Orin/r36.4.4 to start capsule update from slot-B.
it looks correct, no additional reboots per our test results.
you may see-also.. Capsule-Update_R36.4.4_AGX-Orin_Uart.log (111.4 KB)
I’ve tested it manually and it works.
Is it possible that, since I’m running it relatively early in rc.local, after modifying the EFI environment variables, some other service might be resetting them later?
Or perhaps, because it’s executed too early in rc.local, the EFI variables haven’t been exported or initialized yet at that point?
hello wpceswpces,
you may refer to developer guide, Rootfs Selection.
please add some check of these two background services l4t-rootfs-validation-config.service and nv-l4tbootloader-config.service before system reboot for verification.
Hi，JerryChang
The l4t-rootfs-validation-config.service is in a dead state, and the nv-l4tbootloader-config.service cannot be found. Sorry, I can’t reproduce it now. I’ll try a few more times.
Hi,JerryChang
I think I have reproduced it again Sometimes. When logging in via SSH on SlotB, rebooting once does not trigger an upgrade and the system still boots into SlotB. Only after the system starts and I reboot via SSH a second time does the upgrade occur. Rebooting via the serial console always triggers the upgrade.Can you reproduce it on your side?
hello wpceswpces,
we’ve tests via ssh and serial console, both approaches able to perform capsule update correctly. (no two reboots)
FYI, we’re tested on JP-6.2.1/r36.4.4 for confirmation, please moving forward if you would like to fix this issue.
Hi,JerryChang
COM13 (USB Serial Port (COM13))_2025-11-06-140318.log (1.3 MB)
I replaced it with the debug version of the UEFI. In the logs, there was one instance where updating A under condition B didn’t get triggered, and it only triggered successfully after the second reboot. Could you help check the reason? I think it might be probabilistic.
I compared the two logs and found some differences here.
[2025-11-06 14:09:23] FmpTegraCheckImage: Missing required image for partition mb1: Not Found
[2025-11-06 14:09:23] FmpDxe(NVIDIA System Firmware): CheckTheImage() - FmpDeviceLib CheckImage failed. Status = Aborted
[2025-11-06 14:09:23] FmpDxe(NVIDIA System Firmware): SetTheImage() - Check The Image failed with Aborted.
[2025-11-06 14:09:23] HandleCapsules: resetting to activate new firmware ...
Why would it fail? In my case, ROOTFS_AB=0, so there’s only one rootfs on mmcblk0. The upgrade payload is stored in mmcblk0p10, and it has never been deleted. And every time I boot from B, it copies again.And I also ran a sync after each copy.
hello wpceswpces,
BTW, nvbootctrl dupmp-slots-info this is by default report the bootloader slots info.
you may need to add -t rootfs options for checking rootfs slot info.
Hi,JerryChang
I know that — I didn’t enable rootfsAB. Did you receive the serial log I sent above?
root@tegra-ubuntu:~# nvbootctrl -t rootfs dump-slots-info
RootFS A/B is not enabled.
root@tegra-ubuntu:~#
hello wpceswpces,
here should be the root cause.. you’re missing binary file hence it’s not trigger updating.
[2025-11-06 14:09:23] FmpTegraCheckImage: Missing required image for partition mb1: Not Found
[2025-11-06 14:09:23] FmpDxe(NVIDIA System Firmware): CheckTheImage() - FmpDeviceLib CheckImage failed. Status = Aborted
[2025-11-06 14:09:23] FmpDxe(NVIDIA System Firmware): SetTheImage() - Check The Image failed with Aborted.
Hi，JerryChang
I think I mentioned earlier that I use nv_bootloader_capsule_updater.sh to copy the files and set the environment variables. The files must exist in the filesystem. Every time I boot from Slot B, I run nv_bootloader_capsule_updater.sh again.
hello wpceswpces,
please refer to.. Commits · NVIDIA/edk2-nvidia · GitHub
you may give it a try to apply these two fixes for confirmation.
5d37a55: fix: reset the meas buffer after computing the first measurement
4507c8c: fix: don’t try to erase early vars partition in Jetson
Hi,JerryChang
Thank you. I’ll give it a try and report the results to you.
Hi,JerryChang
I’m sorry for I just checked the two commits above. The changes have been merged on my side, mainly to address the previous issue where UEFI would hit an assert and hang, preventing boot.
hello wpceswpces,
as you may know, we’re tested on JP-6.2.1/r36.4.4 for confirmation.
is there a strong request for not having 2 reboot to perform capsule update?
if that’s possible, please moving forward to the latest release version.
Hi,JerryChang
I want to know the root cause of the issue, and you can’t guarantee that updating to the latest version will resolve the problem. Updating the version will involve a lot of work for us.
here’s the root cause.. post #20.