On Tue, Apr 5, 2022 at 7:21 AM Marc Pervaz Boocha via devel
There are a couple of things.
One important but overlooked usecase is offline repartioning. Modifing
the disk partioning is imposiple on a live disk(maybe with lvm). Its
nice to to have a equivalent of gparted live available for such works.
Yeah when the disk containing an active root file system has its
partition modified, the kernel will not update its view of that
partition map. It requires a reboot. It's a little annoying. The
traditional answer is, device-mapper. I'm not sure what it would take
to review the limitation still in place for conventional partitions.
Another interesting idea is factory reset where the disk image is
to default fedora spin installation while maintaining /home.
This is logically straightforward if we use btrfs snapshots.
We could make a read-only snapshot from within the installer, once the
installation is done. e.g. the current default creates two btrfs
subvolumes at the top-level of the file system: root and home, mounted
at / and /home respectively. Once installation is complete, one of the
last steps could be:
btrfs subvolume snapshot -r root root.rescue
Later on, a fairly heavy weight rollback could be as simple as:
mv root root.old
btrfs subvolume snapshot root.rescue root
* Changing the name of a subvolume while it's in use is not a problem.
* Btrfs snapshots are cheap and fast, they take up no additional
space, initially; as root subvolume is updated, space is consumed
because the old binaries aren't freed due to the snapshot.
* The user could easily choose to delete root.rescue if they prefer to
have that space back, instead of graphical rescue. It's much easier to
opt out than with a dedicated partition.
* There are two roots following a reset. We'd need to consider garbage
collection. One idea is to immediately delete root.old/usr - because
that's fairly safe but also space conserving. The root.old/var could
still be pretty huge though, and it's more controversial to just
obliterate it. Maybe some select subdirs could be pruned though like
for caches and debuginfos? Or use subvolumes to split those areas out
* Yes there are more gotchas .
Every "what if" and decision point comes with a deeper rabbit hole
that needs to be explored to discover liabilities. And then we need to
consider the cost of those liabilities knowing it's less about right
vs wrong, and more about a bunch of trade offs. And the hard work is
finding all the tradeoffs and weighing them against each other.
* it rolls back everything system related including logs and VM's and
reverts everything the user has uninstalled or installed;
* yes we could split out a subvolume "varlog" mounted at /var/log, and
neither snapshot it nor roll it back so that the log always carries
forward in time, similar to "home" subvolume;
* also could have a subvolume "varlibvirtimages" mounted at
/var/lib/libvirt/images, so that VM's aren't snapshot or rolled back;
* and still another "varlibflatpaks" mounted at /var/lib/flatpaks, so
that flatpaks aren't snapshot or rolled back;
* this rescue environment essentially comes with root privileges,
unless we do something to constrain it;
* the rescue environment probably should be updated or it'll go stale
and likely become a security risk,
* the less customized the root.rescue, the more similar it is to a
clean install, when doing a "system reset", but;
* the less customized the root.rescue, the more cluttered it is as a
rescue environment, and
* the more customized (minimized) the root.rescue, it makes for a
simpler/cleaner rescue environment, but not as good for "system
... So we'd need to think through how to handle this aspect, perhaps
with some kind of filtered view (i.e. all the preinstalled apps are
really there but aren't seen in the rescue boot, but are seen
following a reset). An alternative is a minimalist rescue and reset
snapshot, which keeps the footprint small. But then needs to be built
back up somehow, following the reboot from being reset, e.g. dnf group
install "Fedora Workstation" or "KDE Plasma Workspaces" etc.