Follow-up to the closed thread https://forums.developer.nvidia.com/t/boot-failure-on-jetson-orin-nano-uefi-variables-corrupted-os-chain-a-unbootable/362474 — same “OS chain A Unbootable” symptom, posting a working diagnostic and fix.
Setup: Jetson Orin Nano dev kit, JetPack 6 (L4T 36.4.7), split-boot config — SD card holds bootloader and kernel, NVMe holds rootfs at /dev/nvme0n1p2.
Trigger: routine apt upgrade pulled nvidia-l4t-kernel from 5.15.148-tegra to 5.15.185-tegra. The package wrote new /boot/Image and /lib/modules/5.15.185-tegra/ to NVMe (because / was mounted there during apt). SD’s /boot/Image was untouched and still contained 5.15.148.
On next boot, L4tLauncher loaded SD’s 148 kernel against NVMe’s 185 module tree. No matching modules for the running kernel — no WiFi driver (rtl8822ce), no full GPU init, hangs/black screens. After several failed boots, UEFI flagged OS chain A as Unbootable and started dropping to UEFI Interactive Shell. UEFI Setup form save failed with “Submit Fail For Form: Grace Configuration” when trying to flip OS chain A back to Normal — same as the OP.
Diagnostic (boot via F11 → SD entry to bypass broken Direct Boot):
uname -r # 5.15.148-tegra running
ls /lib/modules/ # both 148 and 185 dirs
mount | grep ' / ' # /dev/nvme0n1p2 on /
find / -name "*8822*" 2>/dev/null # rtl8822ce.ko ONLY in 185 tree
sudo strings /boot/Image | grep -m1 "Linux version" # NVMe Image: 5.15.185
sudo mount /dev/mmcblk0p1 /mnt/sd
sudo strings /mnt/sd/boot/Image | grep -m1 "Linux version" # SD Image: 5.15.148 (the bug)
Fix Stage 1 — get bootable: copy NVMe’s 185 kernel onto SD so UEFI loads a kernel matching the modules.
sudo mount /dev/mmcblk0p1 /mnt/sd
sudo cp /mnt/sd/boot/Image /mnt/sd/boot/Image.148-backup
sudo cp /boot/Image /mnt/sd/boot/Image
sudo cp /boot/initrd.img-5.15.185-tegra /mnt/sd/boot/initrd
sync && sudo umount /mnt/sd
sudo reboot
After reboot, F11 → SD entry. Kernel 185 loads, modules match, rtl8822ce auto-loads, NetworkManager comes up.
Fix Stage 2 — eliminate SD dependency: NVMe already had a working /boot/extlinux/extlinux.conf and /boot/efi/EFI/BOOT/BOOTAA64.efi. UEFI had auto-discovered NVMe boot entries but BootOrder put UEFI SD Device first. Reorder so NVMe is tried first:
sudo efibootmgr -v # confirm "NVMe Boot" entry exists
sudo efibootmgr -o 0009,0008,0001,... # NVMe first, SD as fallback
After this, Direct Boot goes straight to NVMe. The OS chain A Unbootable flag becomes irrelevant — UEFI no longer attempts the broken auto-discovery path that flagged it.
Outstanding: the QSPI Unbootable flag itself is still set. nv-l4t-bootloader-config.service runs with status 0/SUCCESS each boot but doesn’t clear it. The BootOrder reorder sidesteps the problem. If anyone has docs on the OS chain status variable’s exact name and byte format for L4T 36.x in /sys/firmware/efi/efivars/, would be useful for future cases.
Lesson: split-boot Jetson configs (SD bootloader + NVMe rootfs) silently desync on every kernel apt-upgrade. Either migrate to NVMe-only boot via efibootmgr reorder (recommended), or manually copy /boot/Image and /boot/initrd* from NVMe to SD after every kernel update.
Full writeup including all the diagnostic dead-ends I tried first (rootfs A/B nvbootctrl variables, wrong driver name rtw_8822ce vs rtl8822ce, futile extlinux edits, “Submit Fail For Form: Grace Configuration” UEFI loop):