Slot A (199 kernel) boots once successfully with working WiFi, then silently reverts to Slot B (185) on every subsequent boot

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
, ,
1

Board: Jetson Orin Nano Super Developer Kit (reference carrier, purchased via Tanna TechBiz reseller)
TNSPEC: 3767-300-0005-W.1-1-1-jetson-orin-nano-devkit-super-
JetPack/L4T: 36.5.2 (bootloader), kernel packages installed only for 5.15.199-tegra

Symptom:
After a JetPack firmware/OTA update, WiFi (RTL8822CE) and Bluetooth stopped working. Investigation found:

  • /boot/Image on the NVMe rootfs correctly contains 5.15.199-tegra, matching installed nvidia-l4t-kernel packages (36.5.2-20260716114719).
  • However, nvbootctrl dump-slots-info consistently shows the system booting from Slot B, which runs 5.15.185-tegra (uname -r).
  • A_kernel and B_kernel raw partitions confirmed via dd + strings: A = 199 (Jul 16 build), B = 185 (Jan 15 build) — consistent with /opt/ota_package/A_kernel.log showing a successful, verified write to slot A only (“Write successfully to individual partition A_kernel”), as expected for A/B (writing to the inactive slot while running B).
  • Manually running “sudo nvbootctrl set-active-boot-slot 0” + reboot DID successfully boot into slot A at least once — confirmed via uname -r = 5.15.199-tegra and WiFi (wlP1p1s0) successfully associating to a network.
  • On every subsequent reboot (including clean, uninterrupted attempts with no power cuts), the system silently reverts back to Slot B. dump-slots-info afterward shows Current/Active bootloader slot: B again, with both slots still reporting status: normal.
  • /lib/modules/5.15.185-tegra/ exists but its modules.dep, modules.builtin.bin, modules.devname, modules.softdep are all 0 bytes, and there is no nvidia-l4t-kernel package installed for 185 — only for 199. depmod -a 5.15.185-tegra fails with “could not open modules.order”.

Question: Since Slot B has no matching kernel module package and can’t have WiFi/BT drivers rebuilt locally, getting Slot A to persist is the real fix needed. What determines/clears the boot-success confirmation for a slot on this board (similar to the RootfsStatusSlotB UEFI variable mentioned in the forum thread “The OTA cannot reset the B partition status”)? Is there a way to inspect or manually clear the retry/rollback counter, or verify whether the Slot A OTA payload was correctly matched to this board’s TNSPEC?

3_slot-flip_before-after
3_slot-flip_before-after1920×1440 561 KB

IMG_20260807_110603
IMG_20260807_1106031920×1647 711 KB

2

Hello @aryanrajyaguru2007!

Based on the title and content of your topic, it looks like it may receive better visibility and feedback in a different category. We took the liberty of moving it for you.

If this was an incorrect assessment, please send me a direct message.

Disclaimer: this moderation suggestion and message were generated with AI assistance.

4

hello aryanrajyaguru2007,

we’ll need complete bootloader logs for understanding the root cause.
for instance, for the first successful A boot, please collect below before system reboot.
you may setup a serial console via host desktop to keep gathering the logs.
$ uname -r
$ sudo nvbootctrl dump-slots-info
$ sudo nvbootctrl -t rootfs dump-slots-info
$ sudo nvbootctrl is-rootfs-ab-enabled; echo "rc=$?"