Just my two cents, but my recommended solution to that problem would be to do away with those obscure requirements. They are both artifacts of using the GRUB boot loader. If Fedora Linux supported systemd-boot, only /boot (the ESP) and / would be required.
FWIW (probably not much), here is an interesting post about how Linux OSs ought to be partitioned: lnussel.github.io/_posts/2020-12-16-fslayout.md at fs · lnussel/lnussel.github.io · GitHub
Well, it’s a bit ambiguous for me how the method I use will be supported in the new installer, so I just describe what I’ve used for years (actually, the new one was also not clear in the old installer, I just found out about it in Internet):
NOTE: I always boot new ISO residing on my /home partition from Grub, and install from there. I hope this will be still supported in the new Anaconda.
Rational for the below method: I have a production Fedora. When a new version is released (actually, usually when the next Beta comes out), I do a fresh install beside my existing Fedora to try out. After preparing the new installation, if everything is working properly in the new Fedora, I switch to the new Fedora installation and mount my old /home in the new Fedora. If there are any problems, I keep using the old installation until it’s fixed (fortunately, it has not happened for years!).
Also note I use a shared /boot, so I don’t format it. It works fine except that Anaconda removed old loader directory, so I should create a backup from my old loader entries before installing the new Fedora. I hope Anaconda starts supporting using a shared /boot at least for Fedora installations.
So, this is the high level view of my disk space used for Fedora:
Pre-BTRFS era: in those times, I had a separate ext4 partition for each /. For new installations, I used custom partitioning and selected the older (FedoraN) / partition to reformat and used it as the / partition for new Fedora installation with an appropriate label (FedoraN+2). I selected the shared /boot and /boot/efi partitions for boot. I either added shared /home during install, or added it manually after ensuring that I want to switch to new Fedora.
In BTRFS era: Now, I have a single BTRFS volume, used for /home/, and both / subvolumes. What I do for new installations is to select Custom partitioning, remove FedoraN subvolume, and press + which magically decides to use the BTRFS volume for the new mount point (this part was what I didn’t expect and didn’t know about until I read about it somewhere), so I just use FedoraN+1 as the new subvolume name and use it as / for the new Fedora installation.
In both cases, I don’t have any existing free space for the installer to use. In the former case, I expected the installer to give me a way to remove an existing partition and add a new one (or actually just reformatting an existing partition). But in the latter case, I just want to created a new subvolume in existing BTRFS volume (I wonder if free space in a BTRFS volume is considered free space when selecting Use free space for the installation in guided partitioning!).
I wonder if such use cases are covered by the new Anaconda, or I’ll need to resort to using Cockpit UI (which, I don’t know how much BTRFS support provides).
This is a fairly naive and not reasonably actionable suggestion. For a start, we support more arches than systemd-boot has ever thought about. For a second, we have 25 years of history of using grub which it is not at all simple to just throw away overnight.
It’s easy to whiteboard ideal layouts in ideal scenarios where you only have to care about one type of firmware. It’s easy to suggest just throwing out old boring stuff and replacing it with new shiny stuff. It is much, much harder to do, without breaking something for someone. It is even harder to convince 100% of the people who have been using your stuff for 25 years that the new shiny is definitely better than the old boring.
It doesn’t have to replace GRUB, but Fedora Linux should support systemd-boot. And the installer should be able to accommodate a simpler partition layout by selecting a compatible boot loader.
That only makes the problem harder, though. Adding more choices makes the design more difficult, not easier. If we don’t throw away grub, we have to keep all the constraints that apply to it, but also manage to correctly not apply them to systemd-boot. Adding more paths only ever makes things harder. It never makes them easier. I can tell you this from copper-bottomed decades of experience with this exact area. Trying to reason about or implement any kind of change to the bootloader code in Fedora/anaconda is kind of a nightmare exactly because it is a terrifying conditional forest that has to support several completely different bootloaders on completely different platforms. The - in my opinion, ill-advised - additions of “alternative paths” for systemd-boot and bootupd have only made this worse, not better.
Admittedly, I wasn’t thinking in terms of how hard/easy things were for the maintainers. I was speaking in terms of making things easier for the end user.
I’ve avoided systemd-boot discussion here because i think its OT, but:
As one of the instigators of some of this systemd-boot stuff, I’ve tried really hard to make it largely a drop in replacement for grub on UEFI systems. This means things like ignoring people who want to change the fedora /boot/efi mountpoints, or the half dozen other things that really in the end bring little value, except to fuzz up code paths with if $bootloader checks. And well, for those who have missed some of the fallout, unexpected things have happened.
But, its unlikely systemd-boot will ever completely replace grub, for all those reasons you suggest, unless one of two things happen. Systemd-boot becomes grub, and its been trying to do that for as you put it ill-advised reasons, which defeats the entire purpose IMHO, which is to simplify what is running in a UEFI context. Or secondly, a hard stop is put on architectures that aren’t using some kind of UEFI like shim on top of their proprietary nonstandard bootloaders. UEFI has been around for a couple decades now, and there are, 5 different architecture which have some kind of UEFI support (x86, itanium, arm, risc-v and loongarch) at this point. Its not a hard thing to support, there are fully open source implementations, and it solves a load of questions around, how do I secure boot this platform or how do I manage firmware updates, and dozens of other things that are mostly ignored by the nonstandard bootloader crowd. And some of it seems questionable because there is an edk2 port to POWER (well there are actually a couple), which could be completed and all the proprietary POWER bootloader stuff could be removed from fedora as well.
So, to return to an on topic discussion, I’ve also wondered if the webui as is was a bit of a mistake since the underlying .glade XML files are pretty nice UI descriptions. Rather than trying to rewrite all the glade stuff, GtkBuilder could be extracted from the project (or not?) and a glade->html renderer added. That sounds bad, but the existing .glade files aren’t actually that far away from HTML, and a runtime translator looks like a lot less work than trying to rewrite the entire anaconda UI.
Yep this is very true. If the custom partitioning group is a small one, the members of that group who can do the partitioning on the back of a paper napkin before getting started is a vanishingly small one.
There are a lot of hidden guardrails in this UI. Some folks find it too constraining (hence advanced-custom came to be) but it significantly helped users avoid getting hurt. Pretty much all other custom partitioning options are hurt me buttons in comparison to this UI/UX.
cryptsetup folks have said it’s not happening anytime soon because the format isn’t fully documented. They know enough to reliably support unlocking BitLocker volumes, but not enough to modify them.
Added engineering and removed Site Help & Feedback, question
Removed fedora-infrastructure-projects
Could you be please more precise of what effort will consume our resources?
These are great points. Thanks a lot for mentioning them here.
The other point of view is that if users don’t understand what BIOS boot partition is, should they be facing the complexity of it in the custom partitioning. It could easily get you to situation “WTF is still creating this - I don’t want it!” kind a replies. Yes, I know, maybe I’m getting a bit too over the common reaction but I hope you see my point.
What I want to say is that custom partitioning should be taken only in case you really know what you are doing. If that is not the case then I would rather like to redirect people to guided solution instead.
On second thought, what is the desired approach here? If the point of I need Custom partitioning is that I want to have / so big and /home a bit smaller, then we can simplify this to a simplified custom partitioning for this. With just specifying mount points and sizes - nothing more. This could effectively hide the boot insanity which is quite hard in general.
Thank you for sharing this.
The BTRFS solution should work even now, with exception that in Mount point mapping we don’t support creation of a new subvolume of BTRFS. Not sure if we want to add something like that now. However, the only thing you should be required to do is to create a new subvolume before starting installation or in the Cockpit Storage.
I think that bootloader shouldn’t be visible at all to the end user to make installation easier for user.
If you start mixing specifics of sdboot and grub2, it starts to be even more confusing to users.
Thanks for the reply
The BTRFS solution should work even now, with exception that in Mount point mapping we don’t support creation of a new subvolume of BTRFS.
Well, that’s a bit unfortunate. And it looks like that a BTRFS volume is considered ‘used’ space right?
However, the only thing you should be required to do is to create a new subvolume before starting installation or in the Cockpit Storage.
And this confuses me. If a BTRFS volume & inside sub-volumes are regarded as ‘used’ space, so how can I assign it to a mount point? Or… does the installer let us map a ‘used’ disk to a mount point? How does it work with normal partitions? e.g. you map /dev/sda2 to / without formatting?
IMHO, free space in a BTRFS volume (maybe, only a volume which has subvolumes in its root) can be treated as free space, just like non-partitioned space. Since the installer creates partitions in non-partitioned space, the same way it can also create subvolumes in a BTRFS volume with some names (and the problem of multiple BTRFS volumes is same as multiple disjoint non-partitioned spaces). It uses a version specific name (e.g. f40-root rather than root), it won’t be too general and probably not clash with any other default names.
And, I wonder if the new installer supports specifying a /boot partition without formatting it?
Using preexisting filesystems without reformatting is actually now possible (at least in backend, I am not sure if the frontend changes are released yet) – the filesystem needs to be empty, but it no longer needs to be reformatted (or recreated in case of btrfs subvolumes).
We’ve sit down on feedback mentioned here and created an action plan for us. I would like to share this plan with you so you can give us feedback about missing or wrong ideas from your point.
Use free space solution, so you can free up the space easilyWe also have a list of nice to have things:
Please note: Everything mentioned here is subject to change. Take this list as informative only.
One of my pet peeves of Fedora is the Anaconda installer and I am happy that it is being improved!
For me, the current second “Custom” option when configuring drives is a bit confusing to use so I always either choose Automatic when I have formatted my drives or I partition them manually.
Having a guideline for what partitions are needed for the installation when manually partitioning is very useful, especially when Silverblue has a separate /boot and /var partitions.
Also, I like the idea of keeping the structure of my partitions and instead erasing / only, keeping the /home partition intact, very convenient!
Also a note that with this list we decided to postpone Web UI to Fedora 42. Explanation is on devel mailing list.