From Fedora Project Wiki
Line 61: Line 61:
** 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".
** 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)
*** possible liability, determine whether the the addition of /var mount point for Btrfs scheme results in /var mount point for other schemes (and inhibit)
* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
* Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
* Policies and guidelines: N/A (not needed for this Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. Please submit a pull request with the proposed changes before submitting your Change proposal. -->
* Trademark approval: N/A (not needed for this Change)
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://pagure.io/Fedora-Council/tickets/issues ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. -->
* Alignment with Objectives:
<!-- Does your proposal align with the current Fedora Objectives: https://docs.fedoraproject.org/en-US/project/objectives/ ? It's okay if it doesn't, but it's something to consider -->


== Upgrade/compatibility impact ==
== Upgrade/compatibility impact ==

Revision as of 03:27, 18 January 2022

Silverblue and Kinoite will have /var on its own Btrfs subvolume

Summary

Silverblue and Kinoite: For new clean automatic (guided) installations, create a "var" subvolume to be mounted at /var.


Owner


Current status

  • Targeted release: Fedora Linux 36
  • Last updated: 2022-01-18
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

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.

Feedback

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, and so on.
  • 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 mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: beta freeze (not a System Wide Change)
  • Blocks release? No


Documentation

No significant documentation is planned other than this change proposal.

N/A (not a System Wide Change)

Release Notes