Jetpack 5.1 needs clarification from NVIDIA!

I am not able to get any reliable info if the issues I am experiencing with Jetpack 5.1 are bugs or issues with my custom image.

Can someone please comment on the following issues:

  1. RootfsAB does not boot to the other slot if a kernel panic occurs on the currently active slot (This has been reported multiple times, but NVIDIA keeps telling that it should work) If the issue is on my side, I need support!
  2. Using nvbootctrl to switch the slot does not work (nvbootctrl -t rootfs set-active-boot-slot 1). I tried to boot from slot B and it still attempts to boot from slot A: Current rootfs slot: A Active rootfs slot: A num_slots: 2 slot: 0, retry_count: 2, status: normal slot: 1, retry_count: 3, status: normal

Please tell me if those are known issues in 5.1 or if my transition from 5.0.2 to 5.1 failed…And tell us what we all are doing wrong.

If anyone is using 5.1 and has the two things working, please let me know!

1 Like

Since I observed two issues which could hardly pass a test I tried the same with a unmodified L4T 35.2.1 installation.

  1. Exists in the unmodified L4T 35.2.1 version too, in the previous version it still worked.
  2. Works in the official version, so I’ll search for a mistake on my side.

What I unfortunately noticed is that if I set the currently active slot in the UEFI to unbootable, the system will perform a reboot loop and not attempt to boot from the other slot.

Since #1 also can be reproduced in the sample from NVIDIA I wonder why people keep getting the answer that it works for over a week already?

Hi @seeky15

Sorry to jump into this. I notice you filed some topics recently.
Could you make a summary of what you saw and any background story about your questions? I wasn’t involved in those topics so want to know what happened there.

Hey @WayneWWW I appreciate someone else looking at it since we’ve had multiple people from your side telling that it works, despite there being multiple reports that it doesn’t. I had multiple questions about 5.1:

1. How to set a slot to bootable again after it was marked unbootable (In order to try an update again) Answered by @JerryChang Setting bootable and unbootable AB rootFS slots for L4T r35.1 - #36 by JerryChang

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

Set a slot to unbootable in the UEFI. Afterwards set it to active with nvbootctrl → reboot loop

  1. Why Jetpack 5.1 does not reboot automatically to attempt booting when the current slot is not able to boot:
    Jetpack 5.1 Kernel Panic does not lead to reboot with A/B System → Talking around the topic for days
    Setting bootable and unbootable AB rootFS slots for L4T r35.1 - #38 by Max_Dichler → Read the whole topic here, you will see that they both are not able to get it to reboot.
  2. When updating from 5.0.2 to 5.1 I need to update the bootloader before the rootfs, so I need to use the old bootloader update mechanism. Unfortunately the update works, but afterwarts nvbootctrl tells me that A/B is disabled…I can still switch slots with the tool, but something seems to be wrong.

Now the story why all this together seems to be a big issue for me and others.

The use case of A/B Redundancy is to have a second slot to boot from if a slot gets corrupted. There can be various reasons for the slot to be corrupted, unexpected power loss, deleted files or an update attempt which failed.
In the current 5.1 the system will not automatically reboot to the other slot, if the active one is broken. Taking power away does not fix that, as the scratch register is not updated then. So you’re stuck with an unbootable system forever. Changing the slot to unbootable is not a workable solution in production, but even if it was…it does not work, the system will still not use the other slot.

Now we have been told that in case it WOULD reboot to the other slot, we would be left with an unbootable slot and a bootable slot. In that case an update would have to be placed on the unbootable slot. We have no tool, except the uefi, which we can’t access from the running system, to set the unbootable slot to bootable again.

So the whole idea of using A/B redundancy would not work anymore as soon as something goes wrong 1 single time…you can not update anymore then.

I have not been able to test if the nvbootctrl would set the slot to bootable again if I set it active since we are not able to get the system to mark the slot unbootable when it fails.

The issue about me not being able to switch slots from the topic post seems to be on my side, but the rest seems to affect everyone. Edit: My personal issue that switching A/B was not possible has been resolved after flashing it again…strange. The other issues regarding the A/B failover and the lack of a possibility to make an unbootable slot bootable again still exist.

1 Like

Please check Rootfs A/B redundancy fail-over mechanism in Jetpack5.1 - Jetson & Embedded Systems / Jetson Xavier NX - NVIDIA Developer Forums

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.