DRIVE OS Version: 6.2
Issue Description: I am trying to boot from slot A or slot B. But when I switch to “kernel partition” mode:
I only can boot from slot A. Even thought I change the boot-sloot with nvbootctrl:
or I break the slot A, it only starts from slot A and never with slot B. I suspect that “OS chain B status” should be appearing here, but it is not:
May I know which platform you’re using?
Jetson AGX Orin or DRIVE AGX Orin platform?
Thanks
We are using a Jetson Orin Nano customized
hello rgmartin,
may I have more details.. could you please run nvbootctrl dump-slots-info to share two slots status.
please also note that, there’s -t options to specify the target types, which can be either bootloader or rootfs.
besides.. please also setup serial console to gather the bootloader logs for more details.
hello Jerry,
here it is the output of the command, which shows that current and active slot is B
Nevertheless, although B slot is shown as active here, the system boots from slot A (I checked it by putting all 0’s on kernel A slot partition and seeing that the boot then fails).
I attached the boot log
boot.log (77.2 KB)
, in which although early boot stage shows that B slot is active (), B kernel/B DTB is never triggered, but A is.
To give you more information, we are using this SDK to flash: ~/nvidia/nvidia_sdk/JetPack_6.2_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra. Maybe we should change anything inside this.
hello rgmartin,
this is already the logs boot from slot-B.
[0000.317] I> RAM_CODE 0x4000421
[0000.320] I> Loading MEMBCT
[0000.323] I> Slot: 1
could you please switch the slot, and gathering the logs for double check, thanks
hello Jerry,
Here you have it:
boot-swich-A-to-B.log (115.3 KB)
In this log, we change from slot A (0) to slot B (1), as you can see there are 2 MB1 boots.
hello rgmartin,
it looks expected? it’s continue to reboot to a new boot chain.
Jetson System firmware version 36.4.4-gcid-41062509 date 2025-06-16T15:25:51+00:
00
ESC to enter Setup.
F11 to enter Boot Manager Menu.
Enter to continue boot.
Rebooting to new boot chain
ÿäÿâShutdown state requested 1
Rebooting system ...
ÿâ
anyways.. may I know what’s the actual use-case?
your very first booting message has indicate you’ve boot from slot-B, which is differ from your description.
Hi Jerry,
Let us clarify the exact issue we are facing:
When Slot A is active (i.e., nvbootctrl dump-slots-info returns Slot 0): Everything works perfectly. The system successfully boots using the Device Tree (DT) and the kernel from Partition A.
When we switch to Slot B (using sudo nvbootctrl set-active-boot-slot 1): We see the logs we previously shared. Even though the logs indicate a slot switch and nvbootctrl dump-slots-info successfully reports Slot 1 as active, the system actually still boots from Slot A (Kernel A and DT A) instead of Slot B.
In short, there is a mismatch: the tool claims Slot B is active, but the system continues to load Slot A’s resources. We don’t understand why this is happening. Any insights?
hello rgmartin,
please dig into bootloader logs. the logs this is already the logs boot from slot-B.
for instance,
[0000.317] I> RAM_CODE 0x4000421
[0000.320] I> Loading MEMBCT
[0000.323] I> Slot: 1
just an FYI.
please refer to developer guide, Updating DTB Files.
it’s UEFI by default checks /boot/extlinux/extlinux.conf, and loads the binary via file system.
for example, it loads kernel dtb from the FDT entry, if you did not have an entry, it fall back to its own dtb file to load the kernel dtb.
please note that, You can specify FDT alone. You can specify FDT + OVERLAYS. You cannot do only OVERLAYS though. Overlays from Rootfs are processed only if DTB is coming from Rootfs. when FDT entry is not present in extlinux.conf UEFI DTB is used.
Hi Jerry,
Thank you for your response. As we mentioned previously, we changed the boot mode inside the L4T configuration so that instead of using extlinux.conf, it uses Kernel Partition. This way, the system detects the partitions directly and ignores both the extlinux file and the DTB located in /boot/dtb.
In theory, under this Kernel Partition mode, Slot A should load the kernel from partition nvme0n1p3 and the DTB from nvme0n1p4, whereas Slot B should load the kernel from nvme0n1p6 and the DTB from nvme0n1p7.
However, as we have already pointed out, despite switching to Slot B—and even though the nvbootctrl dump-slots-info command confirms that the current slot is 1 (Slot B)—the system continues to boot from Slot A.
We verified this because if we intentionally corrupt/break the kernel in Slot A, the boot process fails entirely, even if we explicitly force the system to use Slot B.
hello rgmartin,
but.. I don’t see the logs to indicate it boots from slot-A, please try gathering the complete bootloader logs for reference.