I’ve looked at a lot of other immutable distros and I might just end up using one of those, but I feel like taking on a bit of a challenge and there’s a few things I’m not very keen on with existing solutions (last paragraph is my idea if you want to skip the context).

Most immutable systems I’ve seen require a reboot in order to apply system changes. What is this, Windows? Yeah, reboots are quick but restoring my windows and getting back into my groove is not quick. Also, every immutable OS I’ve seen wants you to opt-in to a rollback. Rarely do I see the full effects of installing a package or altering a config immediately. By the time I notice an issue maybe it’s too late to rollback to before the change or maybe I’ve done a few other things since and I don’t want to rollback everything. I would much prefer to make “rolling forward” or persisting changes to be a very conscious process.

I started messing with BTRFS and I think I’ve come up with a process that will get me what I want, no matter the distro. Please poke holes in my idea. So I think I can use BTRFS to hold data for the rootfs in three different subvolumes (at minimum): root-A, root-B, root-Z. root-Z is my golden image and it represents what I want root to look like after reboot. root-A and root-B are the active and passive instances of rootfs, but which one is active will flip-flop after every reboot. So if I boot with A, B gets replaced with the contents of Z. In the meantime I can do whatever I want with A. 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.

Thoughts?

  • boredsquirrel@slrpnk.net
    1·
    5 months ago

    But to OPs actual ideas:

    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.