Btrfs root default with @root and @home subvolumes

[mmstick]

Finished

Closes #221
Closes #256

[Absolucy]

Looks good to me, although I don't feel comfortable approving due to not being overly familiar with the internals of distinst.

I did see some areas where code neatness could be improved, mostly in the name of reducing indent levels and doing things in "less" steps.

[linuxgnuru]

When trying to remove existing partitions the installer crashed. The previous install was a custom install with 512MB /boot, 4GB swap, btrfs (remainder of drive) for / with file encryption. I'm including the journalctl and installer logs.

journal.log

installer.log

[XV-02]

While this seems to be installing a "clean install" onto a btrfs partition, I've had issues with trying to custom install to a btrfs partition. The install proceeds as desired, but on reboot, the computer hangs on the System76 splash screen.

[linuxgnuru]

@mmstick Retested and same issue with installer crashing. Attaching installer.log

Steps to recreate:

• Install pop 22.04 custom install
• 500MB /boot fat 32
• 4GB swap
• rest BTRFS
• continue install as normal
• reboot, kill installer and clone pop-os/pop
• ./pop/scripts/apt add btrfs
• sudo apt update && sudo apt upgrade
• restart installer
• select clean install
• after a while installer will crash

installer.log

[XV-02]

Just to formalize a few of the issues we're seeing into a single request:

• If you built a previous custom btrfs install using the currently released version of distinst, attempting a new clean install fails, as previously noted by @linuxgnuru
• If you attempt a custom install over a previous btrfs clean install - both the custom install and prior clean install executed with this branch present - and just select and format the existing partitions, the system hangs on boot and reports i915 0000:00:02.0: [drm] *ERROR* CPU pipe A FIFO underrun: transcoder or displays a system76 splash screen.
• Attempting to decrypt an encrypted btrfs partiton from a previous encrypted install fails during a refresh install. The "decrypt" button appears to do nothing.

[mmstick]

So far I've successfully done

• Custom install, reinstalled over encrypted install
• Clean install over a custom install
• Refreshed an encrypted btrfs install

[linuxgnuru]

Tested and looks ok

[XV-02]

When attempting to refresh install from a non-btrfs iso, the install fails and renders the system conventionally unusable when restarted. This could be a situation if someone finds they need to roll-back to an older iso's install for some reason.

Refresh install over current ext4 based install retained previous file system, and succesfully completed.

[mmstick]

The ability to refresh a subvolume-based installation requires this PR, since subvolume support is what this PR adds. Systems that are installed with this update will already have this version on their recovery partition.

[XV-02]

Everything looks good to go. I'm holding off on approval per internal discussions. However, I would be comfortable to approve this once those discussions have settled, as evidence suggests this is functional and sane. The only risk appears to be attempting to use an older ISO to perform a refresh install, which represents an unusual and naturally counter-intuitive edge case, and I do not believe should be considered a blocker.

No longer relevent.

[why-not-try-calmer]

'been waiting for this for a long time :) Is there a blocker on this?

[jacobgkau]

'been waiting for this for a long time :) Is there a blocker on this?

You can configure BTRFS manually using the custom install option if you want to use BTRFS now. I believe we are not currently planning to switch the default filesystem until the next major release of Pop!_OS (it will not happen during 22.04 LTS), since that is a major change.

[ximian]

Weren't plans for updated ISO with btrfs branch of distinst with subvolume support?

[wmutschl]

What was the decision process to call the default subvolume @root and @home instead of the Ubuntu-based @ and @home or the Fedora-based root and home subvolume names? Or is there a way to change the names during the installation process.

[Conan-Kudo]

What was the decision process to call the default subvolume @root and @home instead of the Ubuntu-based @ and @home or the Fedora-based root and home subvolume names? Or is there a way to change the names during the installation process.

Putting the root filesystem in its own subvolume rather than putting it at the top-level makes it easy to blow away the rootfs and reinstall without blowing away the home data. The @ prefix is somewhat confusing for people, which is why Fedora doesn't use it for its subvolume names.