Slot switch failed

Robotics & Edge Computing Jetson Systems Jetson Thor
, ,
1

NVIDIA experts, I am using the latest version of r38.4 and have found that nvbootctrl set-active-boot-slot can successfully switch between slot A and slot B. However, after upgrading slot B bootloader from slot A, the system switches to slot B on boot, but the rootfs is still nvme0n1p1. What’s going on here?I feel it should correspond to nvme0n1p2.

root@tegra-ubuntu:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p1  177G   28G  140G  17% /
tmpfs            62G  140K   62G   1% /dev/shm
tmpfs            25G   23M   25G   1% /run
tmpfs           5.0M  8.0K  5.0M   1% /run/lock
efivarfs        256K   12K  245K   5% /sys/firmware/efi/efivars
/dev/nvme0n1p5  505M   78K  505M   1% /boot/efi
tmpfs            13G  112K   13G   1% /run/user/121
tmpfs            13G   96K   13G   1% /run/user/0
root@tegra-ubuntu:~# nvbootctrl dump-slots-info
Current version: 38.4.0
Capsule update status: 1
Current bootloader slot: B
Active bootloader slot: B
num_slots: 2
slot: 0,             status: normal
slot: 1,             status: normal


root@tegra-ubuntu:~# cat /sys/devices/virtual/dmi/id/bios_version
202512.0-39e87081
root@tegra-ubuntu:~#
root@tegra-ubuntu:~#
root@tegra-ubuntu:~# cat /sys/devices/virtual/dmi/id/bios_date
12/31/2025
root@tegra-ubuntu:~#
How to flash Thor using flash.sh with ROOTFS_AB=1?
3

hello wpceswpces,

may I know what’s your flash command-line, did you flash a target with ROOTFS_AB=1?

4

hi,JerryChang

Yes, I added ROOTFS_AB=1 in the flashing command.

sudo ROOTFS_AB=1 ./l4t_initrd_flash.sh \
      --external-device nvme0n1 \
      [ -c ./tools/kernel_flash/flash_l4t_t264_nvme_rootfs_ab.xml ] \
      jetson-agx-thor-devkit \
      external

I can switch to slot B using set-active-boot-slot, and I see it shows nvme0n1p2. when I check with fdisk -l, I can see that there are two rootfs partitions.


root@tegra-ubuntu:~# fdisk -l
Disk /dev/loop0: 16 MiB, 16777216 bytes, 32768 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000


Disk /dev/nvme0n1: 3.73 TiB, 4096805658624 bytes, 8001573552 sectors
Disk model: S1200ITT4-T2M24T-C1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 340E1840-0C92-4A3B-9CC2-F73B7FE1E879

Device              Start       End   Sectors   Size Type
/dev/nvme0n1p1    5591104 383078463 377487360   180G Microsoft basic data
/dev/nvme0n1p2  383078464 760565823 377487360   180G Microsoft basic data
/dev/nvme0n1p3         40    204839    204800   100M Microsoft basic data
/dev/nvme0n1p4     204840    206375      1536   768K Microsoft basic data
/dev/nvme0n1p5     206376   1254951   1048576   512M EFI System
/dev/nvme0n1p6    1254952   2042919    787968 384.8M Microsoft basic data
/dev/nvme0n1p7    2042920   2247719    204800   100M Microsoft basic data
/dev/nvme0n1p8    2247720   2249255      1536   768K Microsoft basic data
/dev/nvme0n1p9    2249256   3297831   1048576   512M Microsoft basic data
/dev/nvme0n1p10   3297832   4085799    787968 384.8M Microsoft basic data
/dev/nvme0n1p11   4085824   4905023    819200   400M Microsoft basic data
/dev/nvme0n1p12   4905024   5591103    686080   335M Microsoft basic data

One thing I’d like to add is that I modified the UEFI, and possibly disabled some configurations. I don’t think these should have any impact, though.

Switching via nvbootctrl set-active-boot-slot works normally, but it’s not working properly through the update capsule.

root@tegra-ubuntu:~# nvbootctrl dump-slots-info
Current version: 38.4.0
Capsule update status: 0
Current bootloader slot: B
Active bootloader slot: B
num_slots: 2
slot: 0,             status: normal
slot: 1,             status: normal
root@tegra-ubuntu:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  177G   28G  140G  17% /
tmpfs            62G  140K   62G   1% /dev/shm
tmpfs            25G   23M   25G   1% /run
tmpfs           5.0M  8.0K  5.0M   1% /run/lock
efivarfs        256K   12K  244K   5% /sys/firmware/efi/efivars
/dev/nvme0n1p5  505M   78K  505M   1% /boot/efi
tmpfs            13G   96K   13G   1% /run/user/0
tmpfs            13G  112K   13G   1% /run/user/121
root@tegra-ubuntu:~#
7

Could you share the full log when you were generating the capsule payload on the host?
And also, the log when you performed capsule update on the board.

It may not affect the result, but it will be great if you can also verify on the devkit w/o any custom change.