Changes/BtrfsWithFullSystemSnapshots

Btrfs with Full System Snapshots

Summary

This change is about fixing the remaining issues in the installer, bootloader setup, and software management stack so that when a user selects a Btrfs-based installation in Fedora, it will set up Btrfs with an optional Btrfs configuration (including /boot as a btrfs subvolume) and be configured such that full OS snapshots are made for each package management transaction, which the correct configuration installed to the boot loader such that the user can boot into the older state if necessary.

Owner

• Name: Neal Gompa
• Email: ngompa13@gmail.com
• Release notes owner:

Current status

• Targeted release: Fedora 29
• Last updated: 2018-06-27
• Tracker bug: <will be assigned by the Wrangler>

Detailed Description

Btrfs is a next-generation volume-managing filesystem that provides facilities for spanning multiple disks with integrated RAID, cheap file system snapshots due to its copy-on-write nature, and strong integrity though data and metadata checksumming. However, in Fedora, the ability to take advantage of this has been handicapped by issues across Fedora-specific tools at the lower levels of the distribution that kept us from using these features to their fullest extent.

This change encompasses the work to fix these issues in those tools so that if a user wishes to set up Fedora with Btrfs, they get a first-class experience using the filesystem.

Benefit to Fedora

This will enable users on Fedora to finally be able to use a full Btrfs disk configuration without custom work outside of the installer. It will also help with improving the safety of software updates for those using Btrfs by having the system configured to automatically generate full system snapshots and boot entries for those snapshots for rescue/recovery purposes. In addition, this will enable future work on interesting custom alternative approaches for producing appliances (such as appliances built so that they receive updates via btrfs send/receive atomically and re-root) without unusual tooling.

Scope

• Proposal owners:

1. Remove the restriction on /boot as a Btrfs subvolume in Anaconda

2. Adjust the default proposed Btrfs layout by Anaconda to be more optional (potentially derived from the openSUSE one). This may also include moving rpmdb from /var/lib/rpm to /usr/lib/sysimage/rpm as openSUSE did (and Atomic/CoreOS has done) to maintain a simpler subvolume layout. This will also involve fixing the SELinux policy so that /usr/lib/sysimage/rpm is treated the same as /var/lib/rpm. (See this and this for rationale.)

3. Add support for automatically configuring Snapper and the Snapper DNF plugin on Btrfs installs

4. Enable Snapper's ability to generate boot entries for GRUB 2 with the snapper plugin (or alternatively use Boom with snapper if we're using BLS)

• Other developers:

1. Include snapper and dnf-plugin-snapper in the live/install media so that it can be configured.

• Release engineering: #Releng issue number (a check of an impact with Release Engineering is needed)
  • List of deliverables: N/A (not a System Wide Change)

• Policies and guidelines: N/A (not needed for this Change)

• Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

Most aspects of this Change do not impact upgrades, except for one. If the the rpmdb moves from /var/lib/rpm to /usr/lib/sysimage/rpm, then the major upgrade impact will be that /var/lib/rpm becomes a symlink to /usr/lib/sysimage/rpm. This migration will happen automatically.

How To Test

If the rpmdb is moved, then an upgrade test is required to verify that package management works post-rpmdb move.

The remaining test case would be to validate that a Btrfs install does the following:

• Sets up the system fully on Btrfs
• Takes snapshots when package management actions happen
• The snapshot is registered and able to be selected to boot from in the boot menu
• The boot-to-snapshot function lets you boot into that older system

N/A (not a System Wide Change)

User Experience

When users select Btrfs for the system on install, they will get a Fedora system that will automatically snapshot itself on software management actions and have the ability to select those snapshots from the boot menu to boot into for recovery purposes.

Dependencies

• anaconda
• boom-boot (if we're using BLS)
• grub2
• rpm
• snapper
• dnf-plugins-extras

Contingency Plan

• Contingency mechanism: Revert allowing /boot as btrfs and disable auto-configuration of snapper in Anaconda. Revert rpmdb move if needed.
• Contingency deadline: Beta freeze
• Blocks release? Yes
• Blocks product? N/A

Documentation

• openSUSE Btrfs layout
• Initial proposal by openSUSE to move rpmdb on rpm-ecosystem ML
• Suggestion from Panu Matilainen on rpm-ecosystem ML
• Snapper website