Hi, could we please propose this topic for next meeting?

I'm uncertain how many users depend on graphical manual partitioning. Is it a scant minority or a significant minority? I don' t know.

I'm also not sure what are the difficult logical cases to code, and the simpler ones. If I knew for sure the actual partitioning logic and action were the hard part - I'd say it's fine to let the user do all the partitioning in some other tool entirely - and Anaconda's manual partitioning could just enable mount point assignment per discovered partition/LV/subvolume.

But possibly the hard part is discovering and presenting UI for the user to understand what they need to do, what they are doing, what they have done. Today's Custom UI is well suited for folks who need just a little bit of customization, but still need guardrails. Whereas it's to limited for those who need Advanced-Custom which has essentially no guardrails. If only one manual/custom partitioning UI will exist going forward, it's a difficult choice. Reduce the guardrails on Custom UI so it can more meet the needs of advanced users, while allowing some non-advanced users to get into trouble? Or keep the Custom UI safety net up, while leaving advanced users without an interface?

I suppose I would pick manual partitioning with some guardrails remaining. And let more advanced folks depend on kickstart.

The main thing we need a discoverable interface for, is reusing /home. It can be done in the custom partitioning UI's but it's not obvious how to do it - partly because of the requirement to create a new / (not obvious). And then the UI curiously suggests on Btrfs that it will reformat (grayed out reformat checkbox that you can't uncheck, for all the mount points using this Btrfs file system). That really blows people's minds. But otherwise Custom partitioning largely works.

The difficult part is that the partioning task has no inherently intuitive or correct graphical equivalent.

I really like your point of view. Yes, I'm on the same level of thinking. I'm not aware of easy (generally praised) custom partitioning solution. It's too simple or too hard to understand. Which is expected as you said partitioning is not intuitive or easy so the UI can't be too.

About the mount point assignment. The benefit of this solution is that it's not overload user with stuff. For each possible mount point you have to resolve this:

1. identify your storage device (/dev/sda1, BTRFS subvol, LVM logvol) [the most complicated part]
2. select mount point (we can guide user with requiring / to be set and proposing /hame...)
3. Do you want to reformat (not an option for /)

Ideally (future extension?) we would also tell user that this device can't be used for / because it doesn't have enough space.

This solution require user to take extra step before the installation but it is not problematic to understand in the UI.

guess one could use Gparted or gnome-disks i guess those would be installed on Fedora Workstation, but might be good to have a simpler interface to set up mount points and format disks and stuff under an Advanced button or something in Anaconda

The Workstation SIG agreed on using the mount point assignment as must have feature.

The Workstation SIG agreed on using the mount point assignment as must have feature.

The main point the working group has is that it should be possible to use custom disk layouts. The hard requirement for us is that users shouldn't find themselves unable to use Fedora due to wanting a particular storage configuration.

The other point that was raised - we'll need good documentation if we're going to rely on mount point assignment. That will likely need to contain:

• the system requirements for disk layout
• which types of layout are supported
• which tools can and should be used to configure the disk
• what the default disk layout is, and perhaps how to create it manually (so it can be used as a starting point for customisation)

I think that this issue is done from a working group perspective, at least for now.