On Tue, Apr 5, 2022 at 7:21 AM Marc Pervaz Boocha via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > 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 reset > 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 reboot * 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 further? * Yes there are more gotchas [1]. 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. [1] * 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 reset"... ... 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. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
