It's OK for guided/automatic installation to exclude a means for repartitioning. i.e. add/remove/modify size for any MBR, GPT, or LVM block device.

For standard partitions and LVM, there'd need to be UI to identify a file system to assign to /home. But also to identify a partition to reformat and assign to /, and a partition to reuse and assign to /boot

For Btrfs, the least necessary UI needed is for the user to identify a subvolume to assign to /home.

Deleting arbitrary subvolumes is probably not a good idea. Users are already using them to separate /var (the default in Silverblue and Kinoite), /srv,/var/lib/libvirt/images,/var/lib/flatpak, as well as containers. Timeshift and Snapper are being used to snapshot various things, including user data. Snapshots are subvolumes. If present, non-default subvolumes should not be removed.

It is a tricky question how to handle the old root subvolume...

If the old root subvolume isn't removed by the installer, the user is unlikely to discov it's still present, because it doesn't appear in the mounted file system hierarchy. (We mount subvolumes explicitly to their mountpoint in Fedora, we don't mount the top-level of the Btrfs file system where the subvolumes are located). Yet it does take up space.

We could assume, with nearly 100% safety, that any Btrfs volume containing subvolumes named root home or root home var (again, rpm-ostree based desktops), should have the home subvolume preserved and the others removed. But if the subvolumes are renamed from default, or there are more subvolumes present - then preserving everything is the only safe option in my opinion.

The agreement for first version on the meeting was:

• support for BTRFS only is enough
• detecting /home subvolume,, giving user an option to decide, removing all other subvolumes, and installing into the BTRFS with the /home subvolume

@chrismurphy hi, as I stated in the comment above. We can extend the behavior in the future but with first version we would go with just remove every other subvolume in the volume of BTRFS and re-use /home subvolume.

I'm not sure how problematic would be to define the "standard" subvolumes. That could mean something else for everyone. What I can think of is to remove only / subvolume if we are able to detect it, but that may not be enough for the installation.

We can extend the behavior in the future but with first version we would go with just remove every other subvolume in the volume of BTRFS and re-use /home subvolume.

I think this will lead to unintended data loss, and subvolumes must be preserved if there's no other option available.

I don't even think it's adequate to inform the user that all subvolumes will be deleted except for home. If the user has created nested subvolumes within ~/ as far as they are concerned those subvolumes should be protected by virtue of being within /home. But it creates an ambiguity whether really all subvolumes will be deleted or not.

So your suggestion is to re-use /home, /boot and remove / everything else leaving untouched?

I would suggest to remove /boot and not preserve it. Leave /boot could lead into problematic states.

So your suggestion is to re-use /home, /boot and remove / everything else leaving untouched?

Mostly yes.

Reuse the user selected home (it should be named home, but for various reasons may have a different name.)

Likewise, / should be named root but it might be different.

A rare use case, but one I use a lot, is multiple roots on a single Btrfs. i.e. root37 root38 rootrawhide.

Consider if subvolumes were LVM LV's. If the installer were to delete all LV's except for "home" LV, I think we'd all expect major blowback from users. Btrfs subvolumes are manifestly the same thing to users.

I would suggest to remove /boot and not preserve it. Leave /boot could lead into problematic states.

I have no strong opinion on what is done with the separate 1-2G "boot" volume in the short term, mainly because we're not fully conforming to Boot Loader Spec, and we're not setting XBOOTLDR partition type GUID in the GPT entry for it.

However, there is work slowly being done to better align Fedora with Boot Loader Spec. And it prescribes that XBOOTLDR is shared. This introduces a new concept of shared volumes, with ownership of certain directories on that volume - so yeah we can clean up older Fedora directories if we want, though an option to inhibit would be useful because after all, shared boot could mean multiple Fedora versions or variants on the same system. Shared boot but separate roots.

At some point sooner than later, Anaconda needs to know what XBOOTLDR is, and how to handle it. Either it needs to understand how to share it, or refuse to use it. If it were to reformat or remove XBOOTLDR it would need very strongly worded "are you sure?!" notification because it would plausibly break the boot of any other OS on the computer.

This issue seems like a duplicate of #376 . Can you confirm, @jkonecny ?

@aday it is not. It's easy to take this two issues as one.

The difference is:
https://pagure.io/fedora-workstation/issue/376 -- ability for user to create a separate /home partition during the installation process

<this issue> -- ability for users to use /home partition from the previous installation (request from SIG)

<this issue> -- ability for users to use /home partition from the previous installation (request from SIG)

Thanks for the clarification.

The view of the WG is that, for F39, it should be technically possible to manually reuse a /home partition or subvolume from a previous installation. This could be through the mount point assignment workflow.

In subsequent releases, we'd really like to see a guided experience for /home reuse, which makes it easy for users to do a "repair" or "upgrade" install without needing to be familiar with the technical details.

Adding link to the document how the re-usable /home workflow could look like:

https://docs.google.com/document/d/e/2PACX-1vRo4bFq12iqmhLux8ur-XaeiaPoMvKvTFHOdcpUdCfwSI-NrVV70R9a3_3T18-5K4ujvZjHRK8_x45g/pub

This is first draft so it could definitely change.