Hi：
After enabling RootFS A/B on Orin, we have recently encountered multiple product issues caused by unexpected power loss, such as:
- The active rootfs slot switching unexpectedly.
- The system entering recovery mode and failing to boot into Linux.
Based on these observations, we would like to ask:
- Is the A/B slot switching logic only triggered by OTA updates or by boot-failure handling (for example, when the retry counter reaches its threshold)?
- Issues related to unexpected power loss seem to occur quite frequently in our products. Are there any recommended methods or best practices to mitigate or prevent these problems?
Any guidance or suggested solutions would be greatly appreciated. thanks
Add JetPack 6.2.2，L4T 36.5.0，
error_log.txt (71.8 KB)
hello rico.deng,
may I know how you enabling root file system redundancy?
since it needs to partition layout, you’ll need to perform complete image flash, you cannot use image-based OTA to enable Rootfs-A/B.
Hi Jerry:
A/B partitioning was enabled directly through the SDK, and the device was flashed using a full-device image (full flash) ,any suggestion for prevent these problems?
thanks
hello rico.deng,
actually.. you should have ROOTFS_AB=1 in the flash commands to enable root file system redundancy.
see-also developer guide, Flashing the Target Board with a Redundant Root File Systems.
you may also check nvbootctrl for confirmation,
for instance, $ sudo nvbootctrl -t rootfs dump-slots-info
Hi Jerry:
we use l4t_initrd_flash.sh and below its the nvbootctrl information, have another two logs for A to B, its on the same board.
A2B (1).txt (79.4 KB)
A2B.txt (78.1 KB)
root@tegra-ubuntu:/home/robot# sudo nvbootctrl -t rootfs dump-slots-info
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@tegra-ubuntu:/home/robot#
hello rico.deng,
as mentioned by Rootfs Selection, let me re-cap the Note section as following.
Ensure that the background service successfully completed before issuing a reboot command in kernel command line. To check the status of the background service, run sudo systemctl status nv-l4t-bootloader-config. The status field in the output should be 0/SUCCESS.
let me have confirmation.
how often is an unexpected power loss happened? is power loss before boot validation (i.e. nv-l4t-bootloader-config.service)?
FYI, rootfs-A/B does not detect a “power loss” itself.
It detects whether Linux successfully validated the previous boot.
for instance,
UEFI starts slot A and decrements its retry count
│
├─ Linux reaches nv-l4t-bootloader-config.service
│ → nvbootctrl verify clears the failure state
│ → next boot stays on A
│
└─ power is lost / system crashes / validation fails first
→ boot remains unverified
→ repeated unverified attempts exhaust retries
→ switch to B
the default limit is three failed or unverified boot attempts. if B also becomes unbootable, UEFI enters the recovery kernel.
see-also.. Root File System — NVIDIA Jetson Linux Developer Guide.
Hi Jerry:
Unexpected power loss is after boot validation, it`s random occur， for example, after a power loss yesterday, the system switched to B restart today. How can we identify the root cause of the system’s switching behavior？
hello rico.deng,
the best confirmation test is:
- Start from slot A.
- Capture continuous UART without restarting the terminal capture.
- Let Linux boot fully.
- Confirm with..
systemctl status nv-rootfs-validation-config.service
systemctl status nv-l4t-bootloader-config.service
- Only remove power after
nv-l4t-bootloader-config.service shows 0/SUCCESS.
- Repeat several times.
if it stays on slot-A when power is removed after validation, but switches when power is removed during early boot, the cause is confirmed.
or.. if it still switches after successful validation, the custom UEFI/service behavior needs investigation.
Hi Jerry:
we have done a testing that system power loss after the kernel started eight times, it`s still on solt A,
hello rico.deng,
all right, so that power loss after a healthy boot did not cause A → B switch.
it could be that slot-B was already selected as the next active slot before the power loss.
please keep continuous UART across the entire transition for the root cause.
you should also log both current and active bootloader/rootfs slots continuously before the power loss.
in short,
we need to determine whether BootChainFwNext=B was already set by OTA, nvbootctrl, or another custom service before the power cycle.
Hi Jerry:
which branch should be used for UEFI in L4T 36.5? thanks
