Mark bootloader bootable

Hey @JerryChang,

you remember the topic about making the A/B boot slots bootable again:

I’ve run into an issue where the system reports that the bootloader is not bootable anymore:

nvbootctrl dump-slots-info                                    Current bootloader slot: A
Active bootloader slot: A
num_slots: 2
slot: 0,             status: normal
slot: 1,             status: unbootable

The rootFS slot is fine:

Current rootfs slot: A
Active rootfs slot: A
num_slots: 2
slot: 0,             retry_count: 3,             status: normal
slot: 1,             retry_count: 3,             status: normal

The command nvbootctrl -t rootfs set-active-boot-slot 1
Will set both the rootfs and the bootloader to B:


root@localhost:~# nvbootctrl -t rootfs set-active-boot-slot 1
root@localhost:~# nvbootctrl -t rootfs dump-slots-info
Current rootfs slot: A
Active rootfs slot: B
num_slots: 2
slot: 0,             retry_count: 3,             status: normal
slot: 1,             retry_count: 3,             status: normal
root@localhost:~# nvbootctrl dump-slots-info
Current bootloader slot: A
Active bootloader slot: B
num_slots: 2
slot: 0,             status: normal
slot: 1,             status: unbootable

The commands you shared only reset the state of the rootfs bootable flag.

Can you please share the same procedure for the bootloader? I have not updated the bootloader (Just replaced the rootfs content) and I am sure that it will boot once reset.

hello seeky15,

the status is… we will support to reset the bootloader slot status in the next public release.
let me consult with internal team for alternative ways to achieve this.

Hey @JerryChang ,

yes I am aware it will not be supported out of the box. The thing is that my system for some reason marked the bootloader as unbootable, which is incorrect. I’d like to know which uefi variable to modify to reset it and make it bootable again.

Otherwise the rootFS update won’t work either. Then we can’t create a product with this hardware. A possibility to update the system is not optional for us.

Sorry for hijacking this topic, but my question is directly related to marking the rootfs bootable (from which this question stemmed). The other topic is closed to replies.

@seeky15 I am in the same boat, needing rootfs redundancy for OTA updates. I noticed you figure out how to mark the rootfs A slot bootable here: L4T 35.1.0 nvbootctrl mark as bootable - #11 by seeky15

May I ask how you managed to figure out those bits and the procedure to reset the flag? Or if you can point me to info on the UEFI spec for this, that would also be greatly appreciated.

I am in the position where my rootfs B slot is unbootable (as opposed to A).

Hey @alok.deshpande ,

actually @JerryChang did post them after I requested the info.

I had a similar info from trial and error, which only works if you have two boards, otherwise you break the one you want to fix.

The board has to run in A/B mode of course.
I flashed the board and made a hexdump for every file in /sys/firmware/efi/efivars. Store it somewhere where both rootFS can access.

Afterwards I removed the content of the currently running rootFS partition. Waited 3 times for the automatic system to switch to the other partition. Did the same hexdumps again and compared them.

From those tests I could see that for each slot two bits are set to 1 to mark the respective partition unbootable.

If you run a Xavier NX on R35 I’d suggest to use exactly what Jerry posted. It worked for me flawlessly for now. Unfortunately the method he suggested only resets the rootFS slot, not the bootloader slot.

@JerryChang any news on resetting the bootloader?

I see, that makes sense. Good idea

Unfortunately, I’m running AGX Orin, and I only have access to one board at the moment (well, only one that I can flash manually to enable A/B in the first place). Otherwise I would definitely try this out.

Hopefully @JerryChang might be able to provide info for rootfs A/B on Orin as well. But I’ll post about that in a different topic under Orin.

Hey @alok.deshpande

Maybe the uefi for the two boards does not differ in this case. What is your output from

hexdump -C /sys/firmware/efi/efivars/RootfsInfo-781e084c-a330-417c-b678-38e696380cb9

I get this for a working system:

07 00 00 00 3c c0 01 00

@seeky15

I only have the info for my current system, which is not working. The rootfs B slot is unbootable. The output of hexdump is:

07 00 00 00 e0 c0 01 00

I guess the output you saw on your system with slot A being unbootable would have looked different from this, right? So I’m not sure we can infer that both of the boards have the same output when working since we don’t have comparable cases when slots are unbootable.

I appreciate the help, though.

That looks similar to what I saw, but not exactly. Better wait for a seperate answer from Jerry.

1 Like

hi all,

as I mentioned in comment #3, I’ve already bring this to internal team for checking, no updates yet.

hello seeky15,

may I know the steps in details to report that the bootloader is not bootable anymore. did you just replaced the rootfs content?
we would like to reproduce the same issue locally, please share your steps to reproduce this on DevKits for reference.
thanks

Hey @JerryChang

I cannot provide detailed steps on how to reproduce this. What I can tell you is that it has happened two times to me after updating the sytem with a non bootable rootFS on the next slot. Usually the system attempts to boot it 3 times. I might have tried to unplug the system after it ran into the kernel panic to speed the process up. But I noticed that this does not count towards the 3 boots.

What I am sure about it that the only thing I did was replace the content of the rootFS partitions and change the variable to bootable with your command first and then with nvbootctrl to the other slot.

No changes to the QSPI or any other partition except APP and APP_b were performed.

hello seeky15,

please configure to boot from bootloader slot B by nvbootctrl set-active-boot-slot 1 and reboot; when system boot to login again, please dump the slot information;

if boot from bootloader B successfully, the bootloader B status will be marked as normal,
if boot from bootloader B failed, the bootloader B status will be marked as unbootable.

since we don’t have detail steps, we can not reproduce the issue internally.

Hey @JerryChang

my system currently is not in that state.
Will try to damage it a bit when I can, currently on another issue though.

Maybe some additional information:

  • when I use nvbootctl -t rootfs set-active-boot-slot 1 the system sets slot B for both the bootloader and the rootfs. When I reboot the system, the boot will be from slot 0. I guess that is due to the bootloader slot B being unbootable.

When you say you cannot reproduce it, is that required to be able to reset the bootloader slot to be bootable again?
Don’t you have a command that can set the bootloader state to it’s “normal” state?

hello seeky15,

you’re not changing bootloader.
it’s nvbootctrl to manage the slots, but you’ve assign -t rootfs to specify the type of target as rootfs.

note,
it’ll control bootloader when the -t option is not used.

Hey @JerryChang

well maybe there is an issue with nvbootctrl then?

Look at this:

root@localhost:~# nvbootctrl dump-slots-info;nvbootctrl -t rootfs dump-slots-info
Current bootloader slot: A
Active bootloader slot: A
num_slots: 2
slot: 0,             status: normal
slot: 1,             status: normal
Current rootfs slot: A
Active rootfs slot: A
num_slots: 2
slot: 0,             retry_count: 3,             status: normal
slot: 1,             retry_count: 3,             status: normal

root@localhost:~# nvbootctrl -t rootfs set-active-boot-slot 1

Current bootloader slot: A
Active bootloader slot: B
num_slots: 2
slot: 0,             status: normal
slot: 1,             status: normal
Current rootfs slot: A
Active rootfs slot: B
num_slots: 2
slot: 0,             retry_count: 3,             status: normal
slot: 1,             retry_count: 3,             status: normal

The command for changing the rootfs slot to 1 automatically changes the bootloader slot to 1 too for me.
I thought that was related to the boot slots being linked.

hello seeky15,

according to Rootfs Selection with Unified Bootloader and Rootfs A/B Enabled. it’s ROOTFS_BL_UNIFIED_AB configuration for the bootloader slot and the rootfs slot switched together.

however, this is r35.1 default behavior, rootfs slot is tied together with bootloader slot.
and… in the next release (i.e. l4t-r35.2), rootfs slot is always tied together with bootloader slot.

Hey @JerryChang

I get the impression we do not talk about the same.
I’d ike to get a way to reset the bootloader state from unbootable to bootable. Is that possible even without you knowing how to get it into the unbootable state?

hello seeky15,

may I know the test results of running this command, $ nvbootctrl is-slot-marked-successful 1

Unfortunately that seems not possible in REL 35.1

Warning: not support yet!