I can use BTRFS to hold data for the rootfs in three different subvolumes (at minimum): root-A, root-B, root-Z.
That is basically rpm-ostree or BTRFS snapshots, I dont see the point yet
root-Z is my golden image and it represents what I want root to look like after reboot.
So like the upstream ostree remote or OCI image? I think you have a big thought flaw here
root-A and root-B are the active and passive instances of rootfs, but which one is active will flip-flop after every reboot.
On every reboot they flip flop? Why??
So if I boot with A, B gets replaced with the contents of Z. This means all changes you do are removed after a reboot. rpm-ostree and ostree admin both have this feature for testing but the use case is small.
If you have an imahe Z, this is like the uBlue main image, or the Fedora OSTree remote. It is the updated vanilla thing.
Not like on OpenSUSE microOS where you at most have some vanilla BTRFS snapshot from directly after the install, but the vanilla, tested, stable base set of packages.
If you replace the stuff with that always, it is like an rpm-ostree reset but always, and with a local image.
I see the benefit of having a local reset image, as internet is not always available.
But a reset really is only needed when an update breaks things, as the base is immutanle. So no.
In the meantime I can do whatever I want with A.
So you have one testing persistent image? Or is this only temporary?
Not sure how I’ll update Z (chroot or “promote” the active subvol to be Z) but without an update every reboot is an automatic rollback.
This has little sense and honestly rpm-ostree has ephemeral changes only on the live system that will vanish when rebooting.
I dont know the use case really. We are currently working on a change proposal to fix the permissions so changing the OS is pretty privileged.
The software stores handle the system updates but dont show RPMs for installation anymore. Most people will never touch the system.
Or if they do, the system is reset to the base on every update and the changeset is permanently reapplied, every time anew. You are always rebasing off upstream, your installed OS is literally not important.
Its just the diffs that are calculated and changed.
OpenSUSE microOS/ microOS Desktop (Aeon, Kalpa) does this.
They use a complete “changes go to the next system” thing also using BTRFS.
But they dont use OSTree so the system is fundamentally flawed.
Advantages of ostree are
complete transparency over package changes rpm-ostree db diff
complete transparency over /etc changes (the upstream is in /usr/etc and can be reset, see here
the OS is always based on a complete upstream remote, your local system does not matter at all. You can rebase, reset etc without being dependent on anything on the local OS.
Example: I could rebase from Fedora OSTree to CentOS OSTree. They are working on bootc images, which are bootable OCI images and in theory only one step away from uBlue-like distribution.
If you do anything relying on local package management like OpenSUSE does, you can snapshot between changes but still mess up.
So I would always base off OSTree.
What I dont get though is the reliance on reboots and images. OSTree works on all filesystems and doesnt need images, it is simply like a Git repo.
So what I would change is, to enable random local changes with a flag –direct and simply apply the changes live. I mean, that is what DNF and all the distros do too.
Only if you need a kernel upgrade you do stuff with a reboot. Version upgrades are also WAY better than the unstable mess on standard Fedora or other distros.
So track everything with OSTree, allow resets, rebases etc, but dont force all the image stuff. This is the reason why rpm-ostree takes so long and is so inefficient compared no DNF.
Just using OSTree you could only install RPMs, use a nonwheel user, SELinux confined users and have a secure and slim system.
I dont know if I miss something here. Android is rootless but the base OS is still immutable and uses A/B root, so writing only happens to the inactive partition. I dont know if immutability is some core security feature.
Rpm-ostree is really good as an allrounder, but I think a bit overkill. It does support installing packages live, but this does the same action afaik and just swaps the OS image without a reboot.