Inspired by Bazzite OS, and remind me of experience on Armbian (not just armbian), basically on Orange PI 5/ OPI5+, it'll be solid OS if update failure/ anything went wrong can rollback to previous safe copy.

Pain-point: I just want to use the system, not keep re-flashing OS.

nixOS is good, but I don't want to re-learn everything ... and giving up my Ubuntu eco-system.

Sorry I'm still testing out, and failing with existing Armbian-Config approach, I'm trying my own appraoch, Iknew the rules here, wait until I success I'll share it here. (note: or anyone did it before, can give me some direction)

 

Inspired by Bazzite OS, and remind me of experience on Armbian (not just armbian), basically on Orange PI 5/ OPI5+, it'll be solid OS if update failure/ anything went wrong can rollback to previous safe copy.

Pain-point: I just want to use the system, not keep re-flashing OS.

nixOS is good, but I don't want to re-learn everything ... and giving up my Ubuntu eco-system.

Edited September 7Sep 7 by Avatar Ng

1 hour ago, Avatar Ng said:

Pain-point: I just want to use the system, not keep re-flashing OS.

Yes I see a lot of 'pain' from people wiping there SD-cards (where all still worked usually) by overwriting it with some (latest) image and then 'things don't work'.

 

What I do for many years already is convert image to Btrfs (the rootfs) and mostly also add/use an extra small boot partition, can be FAT/ESP or Ext4. You can also use Armbian Build to create this in 1 automated step as it allows specifying an extra boot partition for example.

Example is all my NanoPi-NEO's, which are all headless and operated via ssh. I use an own naming scheme mostly compatible how Opensuse Tumbleweed has it for years already by default, done by the installer when the computer can boot via UEFI. But SUSE has their own enhanced GRUB which can boot from snapper created snapshots, there in no such option in Debian based. So I do it manually and it works good enough as it is quite rare nowadays that an update would ruin things in such way that you give up on  endless fixing, but just want to go back to previous snapshot. Note that this is not really A/B unattended, but potentially many known-good snapshots back in time, depends on how you configured snapshotting.

 

An OPi5 can use the well-known EDK2 UEFI as fimware/bootloader, so then it is just like a PC and it is then possible to install a standard OS/distro, also the mentioned Tumbleweed as that is rolling release and  currently at kernel 7.2.2 (for aarch64). But that is not easy images and Armbian.  And for the many many other SBC's, it is U-Boot only. AFAIK U-Boot support A/B, but that is 2x Ext4 rootfs I think, it works, but not as powerfull as Btrfs filesystem with subvolumes/snapshots. First thing to do I think is to make sure U-Boot understands Btrfs, which is easy to accomplish and for some SBC's it is already the case. The hard part is then snapshots and failure detection I think and at what level. Have you used extlimux for booting multiple kernels with Armbian?

Hi Avatar, You don't actually need U-Boot to understand Btrfs. Keep kernel + initrd + extlinux.conf on a small separate /boot (ext4 or ESP) and put only the rootfs on Btrfs subvolumes — booting a snapshot is then just a cmdline change: rootflags=subvol=@snapshots/42/snapshot. U-Boot loads the kernel from ext4 like everywhere else, the kernel mounts the snapshot. That's also why SUSE only needs their enhanced GRUB for convenience. For failure detection, U-Boot already ships the primitive: CONFIG_BOOTCOUNT_LIMIT with bootcmd/altbootcmd. Set fw_setenv upgrade_available 1 before an update, clear bootcount from a systemd oneshot at multi-user.target, and let altbootcmd boot the previous snapshot's extlinux label when bootcount exceeds BOOT_LIMIT. snapper pre/post snapshots, and the rest is just scripting around extlinux.conf — the grub-btrfs menu logic ports over nicely. One footgun to watch: /boot isn't captured by snapshots, so after a rollback make sure initrd/dtb still match the rolled-back kernel.