Verifying A/B bootloader fallback

I have seen several threads with the subject of bootloader fallback, but they are all really about the rootfs fallback. Basically, what I am trying to do is corrupt only the bootloader and have the system automatically fallback from B to A (or A to B). When I corrupt the bootloader, the system fails to boot and hangs up in the UEFI shell. I was expecting it to reboot to the B side on fail. So, what do I have wrong?

Hi neil30,

Are you using the devkit or custom board for AGX Orin?
What’s your Jetpack version in use?

Do you enable rootfs A/B in your case?

Please share the full steps how you reproduce this issue.
(i.e. how do you corrupt the bootloader?)

Thanks for your response. Here are some details. First off, I am not using rootfs redundancy. I am only interested in bootloader redundancy. I am using JetPack 5.1.2. After booting to Jetson UEFI, I then boot from an extlinux.conf . This file lives on /boot on what I believe is the UEFI eMMC Device.What I do to effect a failure is rename the bootloader file bootaa64.efi to something else. The boot fails but does not fallback. I am now suspicious that it is because of the intermediate extlinux.conf - which I am required to use in my application for our own rootfs management system to work. SO I guess maybe the question is how to I compose an extlinux.conf so it can manage the fallback?

Could you elaborate the details about this?
Do you perform this in UEFI shell or the console after your boot up?

extlinux.conf is stored in the rootfs.

Here is some additional background and a better phrased question. The way my boot sequence is configured is that the system boots to UEFI. The UEFI is set up to boot from eMMC and use extlinux. So once UEFI is invoked, the next step is to go to execute /boot/extlinux/extlinux.conf. The contents of that file are:

MENU TITLE L4T boot options
DEFAULT primary
LABEL primary
        MENU LABEL primary
        LINUX /boot/Image
        INITRD /boot/initrd
        APPEND ${cbootargs} root=/dev/mmcblk0p1 rauc.slot=A rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 console=tty0 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0
LABEL secondary
        MENU LABEL secondary
        LINUX /boot/Image
        INITRD /boot/initrd
        APPEND ${cbootargs} root=/dev/mmcblk0p2 rauc.slot=B rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 console=tty0 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0

The system boots from “primary” as expected (if I do not change the default).

If I delete (or rename) /boot/Image the system fails to boot. So, what I believe it then does is go back to the UEFI boot order and try the next boot method. It cycles through those until it ends up in the UEFI shell and hangs. Depending on how I break the bootloader it sometimes will simply try a kernel boot as a recovery method instead of cycling through the UEFI boot order, but kernel boot does not boot the system with the boot args that I need.

This all illustrates that what I really want it to do is not go back to UEFI and try the next boot method from the boot order, rather I want to try the next method in the extlinux.conf (that is, I want to go to secondary if primary fails). The reason I need the extlinux.conf is to support the system update technique I am using which is already working and provides finer resolution on updates than the built-in rootfs A/B redundancy that Nvidia provides.

Is there a way to accomplish what I am trying to do which is when extlinux.conf fails on “primary” it just tries “secondary”?

It seems not the mechanism what we design to work with.

We have redundant bootloader and rootfs and you could use nvbootctrl to check the current status.
If it is booted failed from slot A for few times(3 by default), it will switch to slot B with fail-over mechanism.
You don’t need to modify extlinux.conf manually.

As a follow-up to your response:

  1. How do I guarantee my system is setup properly for a bootloader fallback (i.e., A to B) operation? Are there any special options or modifications I need to implement or is it enable “out of the box”? NOTE: I only care about the bootloader - not rootfs - only the bootloader.
  2. What would be the recommended way to force a bootloader failure to see the built-in switch from A to B in action? Again, I just want to force a bootloader failure - not rootfs.


If the system warm reboot before reaching the UEFI, BootRom will switch the bootloader slot.

Currently, it is hard to force to reproduce this case manually since you can’t access the board before UEFI.

I have a use case, which could cause it switching the boot slot.
Please refer to the following guide to update spe_t234.bin.
but DO NOT apply the change in tegra234-mb2-bct-scr-p3701-0000-override.dts.
It can make spi_test failed to access the register so that it would trigger reset before entering UEFI.