On Tue, Jan 18, 2022 at 3:44 PM Ben Cotton <bcotton@xxxxxxxxxx> wrote: > > https://fedoraproject.org/wiki/Changes/VarSubvol4SilverblueKinoite > > == Summary == > Silverblue and Kinoite: For new clean automatic (guided) > installations, create a "var" subvolume to be mounted at /var. > > > == Owner == > * Name: [[User:chrismurphy| Chris Murphy]] > * Email: bugzilla@xxxxxxxxxxxxxxxxx > > > == Detailed Description == > Currently, Silverblue and Kinoite mimic other Fedora desktops. There > is a "root" subvolume mounted at `/` and a "home" subvolume mounted at > `/home`. > > This proposal adds a "var" subvolume to be mounted at `/var`. > > The "var" subvolume will be located at the top-level of the Btrfs file > system, along-side the "root" and "home" subvolumes. An entry in > `/etc/fstab` will mount it at `/var` during startup. > > > == Benefit to Fedora == > > Users who opt into Btrfs features like snapshots and rollbacks. > > * By moving /var into its own subvolume, it will be excluded from > snapshots and rollbacks of the "root" subvolume, which contains `/etc` > and `/usr`. > * Users will find it straightforward to rollback "root" while not > rolling back "var": including logs, VMs, databases, flatpaks, etc. > * The ability to snapshot only "var" and use Btrfs send/receive to > replicate only "var" permits for an efficient way of backing up the > variable system data. > ** A clean install can restore the "root", therefore it doesn't > strictly need to be backed up. Meanwhile "var" and "home" can be > restored using snapshot replication via send/receive. > > > == Scope == > * Proposal owners: > ** changes to lorax and anaconda as needed so that Silverblue and > Kinoite variants have their own installation kickstart, such that > automatic/guided installation automatically creates "var". > *** possible liability, determine whether the the addition of /var > mount point for Btrfs scheme results in /var mount point for other > schemes (and inhibit) > > > == Upgrade/compatibility impact == > Change will not be applied to upgrades. But we can document steps to > apply the change to existing installations. > > > == How To Test == > > * Do a clean installation and check `df` and `/etc/fstab` for an > explicitly listed `/var` mount point. > > > == User Experience == > > * The change won't generally be noticeable to users > * Users will see an additional `/var` mount point in /etc/fstab, and `df` > * Some utilities, notably backup programs like borg backup, and rsync > with -x option, will treat Btrfs subvolumes as separate file systems > and may not descend (recursively) into them. > > > == Dependencies == > > * Anaconda/blivet, lorax, and possibly kickstarts > > > == Contingency Plan == > > * Contingency deadline: beta freeze > * Blocks release? No > > == Documentation == > No significant documentation is planned other than this change proposal. > > > == Release Notes == > > This is a nice enhancement and works fine because the rpmdb is already on /usr with rpm-ostree. I'm not sure if Anaconda supports custom storage configurations per type in the profiles used to define variant configurations? -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
