A/B boot failure after cloning partition using flash.sh

Robotics & Edge Computing Jetson & Embedded Systems Jetson AGX Xavier
,
1

I have an issue regarding A/B booting on my Nvidia Jetson Xavier, running L4T 35.6.0. My goal is to be able to create an image of a single partition, then flash the image to another partition. My current approach breaks the A/B booting mechanism. Initially, I flashed the device using the flash.sh script:

sudo ROOTFS_AB=1 ROOTFS_RETRY_COUNT_MAX=3 ./flash.sh jetson-agx-xavier-devkit mmcblk0p1

After this, A/B redundancy works prefectly fine. Next, I set up my A partition to include all the installations I need. Now I want to get the B partition (mmcblk0p2) to the same state as the A partition (mmcblk0p1). What I tried is creating an image of my A partition, also using the flash.sh script:

sudo ./flash.sh -r -k APP -G ~/system.img jetson-xavier mmcblk0p1

Then I copy the system.img and system.img.raw files to /Linux_for_Tegra/bootloader/ and run the following command to flash it on my B partition:

sudo ./flash.sh -r -k APP -G jetson-xavier mmcblk0p2

This flashes the partition correctly (validated by mounting it and setting it as the root partition in /etc/extlinux/extlinux.conf, which allows booting on the ), but breaks the A/B booting mechanism. nvbootctrl dump-slots-info tells me two slots are available:

aaeon@aaeon-xavier:~$ sudo nvbootctrl dump-slots-info
Current version: 0.0.1
Capsule update status: 0
Current bootloader slot: A
Active bootloader slot: A
num_slots: 2
slot: 0, status: normal
slot: 1, status: normal

When I change my boot slot using nvbootctrl set-active-boot-slot, nvbootctrl dump-slots-info changes the active bootloader slot as expected:

aaeon@aaeon-xavier:~$ sudo nvbootctrl set-active-boot-slot 1
aaeon@aaeon-xavier:~$ sudo nvbootctrl dump-slots-info
Current version: 0.0.1
Capsule update status: 0
Current bootloader slot: A
Active bootloader slot: B
num_slots: 2
slot: 0, status: normal
slot: 1, status: normal

Unfortuenately, on reboot, the device doesn’t manage to boot into the B partition and falls back into the A partition. As mentioned above, I can force booting into the B partition by adding the UUID or dev path to the /etc/extlinux/extlinux.conf file, so I am assuming this is an issue in the A/B boot config. I would appreciate some guidance on where to look for the A/B booting config to fix this, or a suggestions for an alternative on how to achieve my goal of replicating a partition.

3

hello lorackdev,

please note that, APP and APP_b have different PARTUUIDs,
if they don’t match the PARTUUIDs specified in extlinux.conf, the rootfs can’t be loaded properly.

5

Hello JerryChang,

thank you for your reply. I tested my flashing procedure again and modified the extlinux.conf of both the A and B partition to match the respective PARTUUID of APP and APP_b. Unfortunately, this does not solve my issue and I still run into the same problem I described in my initial post.

6

hello lorackdev,

could you please try backup/restore script for testing?
for instance, $OUT/Linux_for_Tegra/tools/backup_restore/README_backup_restore.txt