Improve support in installer for smaller EFI partition, and offer more flexibility for boot and system partitions

[brainchild0]

Background

The automatic allocation scheme of the installer resolves a capacity of about one half gigabyte for a EFI partition, and about another gigabyte for a dedicated boot partition. In practice, the GRUB bootloader files loaded onto the EFI partition consume no more than a few percent of the capacity chosen. Requirements of the boot partition are highly variable, as some administrators prefer to keep many kernel versions available, for efficient resolution of unexpected regressions.

Problem

Since resizing the boot partition is cumbersome, it is helpful to allocate a capacity in excess of expected need, but the present choice is extreme. Installers for some OSs enforce a minimum of one quarter gigabyte, and even a capacity so high seems extreme. Unless a system is to be loaded with utilities from the hardware vendor that would run in the EFI environment, usage requirements exceeding one hundred megabytes would be quite rare.

Meanwhile, when a system is installed on an Btrfs partition, subvolumes support a separation otherwise generally only available through partitions, and no requirement prevents files under /boot from appearing on a subvolume designated for them, if not simply in a directory of such name on the subvolume representing the root mount.

Alternatives

The installer supports advanced partition allocation, but numerous requirements make it difficult for the user to choose a scheme that leads to a bootable system. Missing particular requirements have variously lead to the installer rejecting the scheme, to the installer accepting it but eventually failing at a later stage, or to the installer reporting a successful installation even while the new system will not boot successfully.

Use of the advanced options to achieve a successful installation requires specific knowledge about the system not clear from the design of the tool or even a general knowledge about related systems. Many variations may seem reasonable to the user though remaining unsupported by the system.

Solutions

Some improvements to the design may include the following:

1. Use a smaller default size for the EFI partition.
2. Integrate the boot and system partitions.
3. Provide more hints in the installer, and more rigorous checking, for acceptability of the a partitioning scheme entered manually.
4. Allow manual allocation of EFI versus system partitions, including a Btrfs system partition, while also supporting automatic creation and mapping of default subvolumes (e.g. for /, /home, /var).
5. In the partitioning tool, when a Btrfs partition is created, automatically populate the represetation, or include a command for doing so, with a default mapping of subvolumes.

Environment

Observations were made creating a system from the Fedora Silverlight 36 installation media, for x86/64-bit targets. The machine was a QEMU/KVM guest on a host running Linux Mint 21 with a kernel version 6.0.5.

[tpopela]

We share the same installer with the rest of the Fedora - Anaconda - please move the RFE to https://bugzilla.redhat.com/enter_bug.cgi?component=anaconda&product=Fedora&version=rawhide as this is not Silverblue specific.

[brainchild0]

Thank you for the direction. I am new to the current generation of Red Hat family operating systems.

I have made a submission to the other system, as suggested. Please advise if any changes are needed.

[tpopela]

Thank you @brainchild0 ! I will close this issue as it's now tracked on the right place.