Getting into buildroot and yocto seems a bit too much for me to get an A+B style update possibility. I would like to stick with the quality images provided by Armbian. The following applies to a NanoPi-NEO3 others SBC might have different partition layouts. From what I understood is that uboot looks for /boot in /dev/mmcblk0p1 reads the boot.cmd/scr and armbianEnv.txt and then boots the kernel accordingly. The armbianEnv.txt seems to point the kernel to the root partition using the rootdev directive. If /dev/mmcblk0p1 would now only hold /boot would it be possible to point to a different partition for the rootfs using armbianEnv.txt? If so I could imagine changing the partition layout to the following: /dev/mmcblk0: /dev/mmcblk0p1: boot partition /dev/mmcblk0p2: rootfs partitionA /dev/mmcblk0p3: rootfs partitionB /dev/mmcblk0pX: multiple more partitions that survive updates Too now allow consistency with the rootfs partitions also the boot partition directory structure would slightly change. It would contain 2 directories: /bootA, /bootB AND a hardlink /boot which either points to /bootA or /bootB In the running rootfs the fitting /boot is mounted via a bind mount hoping normal apt-get updates can deal with this. This would allow creating a rootfs by updating and verifying everything works locally and then creating an image from it. Now to OTA a relatively simple script running from rootfsA can download a new rootfs image/file structure and place it in the partition of rootfsB. Same with the new boot partition just into /bootB. The values of the armbianEnv.txt from the new boot image always point to the corresponding rootfs partition either because the image was already built for this or the script dynamically adjusts them. Same goes for fstab, machine-id, ssh identity and other rootfs specifics. The script will then verify that the write worked to avoid sd card issues. The (almost) atomic operation for switching the systems would be changing the hardlink of /boot to the /bootB directory and reboot. This idea will not detect any boot issues and revert automatically back as uboot is not involved. Also this only works if uboot is still compatible with the new boot files provided. But an additional new uboot image could also be provided during the update. Reverting can be done manually (relatively fast) by changing the hardlink back and rewriting a previously created backup copy of a might be updated uboot image. Independent of the fact that buildroot, yocto, rauc, mender… systems have a better feature set, do you think this could work?

Today armbian-config doesn't show other kernels, it's impossible to switch. * Show only mainstream kernels on the list? => no * No other kernels available! => ok

Yes, I did read that. I was also thinking maybe the decompression on-the-fly could be a point of failure. Just now, I installed USBImager and wrote the image to a uSD. No presets applied (.not_looged_in_yet) First boot went smoothly. I updated with armbian-upgrade and rebooted and all looked OK. 🤷🏻‍♂️ Since I changed 2 things (using USBImager and no presets) I can't say what helped.

You need an overlay for that camera and 6.1.115-vendor-rk35xx does not have that AFAIR, older legacy 5.10 has it AFAIR. Look for something called RPi camera v1 or that sensor name.

It would be interesting to compare corrupt and non corrupt cards, including partition tables, etc. Windows might be playing bad with partition tables - if one only inserts ESXi boot disk into windows machine, such disk becomes non bootable. AFAIR this is because ESXi relies on records order in the gpt table of the disk, while windows strips away blank records so that if eg second and third records are blank then windows will move the fourth record to the second place, while ESXi relies on the fourth record in a table. I personally met this issue a few years ago and it took a while to find the solution of reordering gpt table records back to restore ESXi boot.