Why /boot is recommended?

Project Discussion
,
1

Do we have an explainer somewhere within Fedora space - why do we recommend the /boot partition?

Currently in the Installer UI we say: efi partition is Required, /boot partition is Recommended. But as a user I do not have any information on the impact of that recommendation. What will happen if I follow it? What if not?

I could find the relevant article in https://unix.stackexchange.com/questions/749678/do-i-need-both-boot-and-boot-efi

But 1) it might be outdated 2) it refers to Arch Linux wiki 3) it is rather confusing with respect to encryption.

Can anyone come up with the Fedora version of it?

2 Likes
3

One other reason or benefit for distinct /boot to be recommended is because it is mandatory for full-disk encryption.

Say one launches the storage editor, creates an efipartition, doesn’t create a boot partition (not specifically recommended), then when creating the root partition, they choose encryption. When proceeding with the installation, the user is then notified that storage requirements were not met since the /boot filesystem cannot be on an encrypted drive.

3 Likes
4

Pflaster now has an option to select a different mountpoint for the efi partition. So far, I have not noticed any issues with the encryption. I have only tested the minimal install though. This is the layout after installation:

sda                                             8:0    0 25.3G  0 disk  
├─sda1                                          8:1    0 1023M  0 part  /boot
└─sda2                                          8:2    0   12G  0 part  
  └─luks-3afb1547-cb3e-418e-94e6-ca280e868046 252:0    0   12G  0 crypt 
    ├─vg2-root                                252:1    0  4.5G  0 lvm   /
    ├─vg2-swap                                252:2    0  1.2G  0 lvm   [SWAP]
    └─vg2-home                                252:3    0    6G  0 lvm   /home

This is how you choose the mountpoint

Please select the efi mountpoint
   /boot/efi
-> /boot
   /efi
1 Like
5

We already diverge quite a lot from “what Red Hat says” in Fedora, when it comes to partitioning because of the BTRFS by default. So Fedora could define its own defaults and recommendations if we can agree on some authoritative source for them and come up with a shared understanding.

So the question is more like - what Fedora really wants and why?

  1. Is separate /boot required for encryption or do modern full disk encryption methods work without it? Which type of encryption Fedora uses?

  2. Do we want /efi/ or /boot/efi/ - why? What kind of compatibility issues we need to be aware of?

7
  1. FDE support.
  2. GRUB has major issues with other than ext and FAT file systems and especially BTRFS.
8

This looks like a solved issue where grub2 don’t update the grubenv file, but updates a block at offset 262144 from the start of the partition if boot is stored on a btrfs file system.

9

GRUB2 supports BTRFS only in read-only mode. Some other distributions use a special patch to write grubenv to the BTRFS header instead of directly modifying the block and disrupting the filesystem.

10

That “some other distributions” includes Fedora 44

11

If I understand the issue you’re referring to correctly, I believe this has already been fixed upstream. Please correct me if I’m mistaken.

I also remember that a backport was made for this. I’m not sure whether it has reached the Fedora repositories yet, though. Perhaps @ngompa can clarify.

- https://gitlab.freedesktop.org/gnu-grub/grub/-/commit/6435551a669c66a59e479369a8527b5fe20e516b

12
  1. Because the ESP is shared across operating systems hence it would need to be quite large to contain everything.
  2. Because you might want to use a filesystem on / that your bootloader doesn’t understand (including full disk encryption in some setups).
  3. Because you’re used to it.

Not all Fedora variants have a separate /boot for example Fedora Cloud puts /boot-on-btrfs and it’s also perfectly valid to have no separate-/boot at all provided your bootloader can read whatever filesystem you put your things on (which is how I have my workstation set up).

I don’t find any of the reasons particularly compelling but I also don’t find any of the reasons not to do it particularly compelling. It’s a case-by-case basis.

13

Excuse me if i don’t understand but doesn’t a separate boot partition basically break snapper? I mean if i have a snapper snapshot that depends on a kernel that has “rolled out” because 3 or 4 new kernels have come out since the snapshot, doesn’t that effectively break the snapshot?

I actually got burned by this. Even though i tested a new snapper snapshot when i first set things up, i tested it against a snapshot that used the current kernel. When i later tried to restore an older snapshot it turned into a mess because the kernel that it was expecting was gone. Hope i’m being clear in my concern.

14

I’m not sure the snapper problem is anything to do with /boot being a separate partition. Fedora Linux only keeps N fallback kernels regardless of where they are stored. If you’ve updated past that N revisions and try to rollback to a snapshot that is more than N kernel versions old, then the required kernel is not going to be on the /boot partition or the ESP partition or whereever.[1]

The kernel cannot be kept on the root partition (so that it too would be restored with the rollback) because it (along with the initramfs) handles the decryption (also because no firmware can load a kernel from Btrfs).

Personally, I think the solution Leonhard demoed is the best one – reduce the number of partitions by combining the ESP with /boot. IIUC, what hinders Fedora Linux from doing that is GRUB support. Or at least that used to be a problem because GRUB wanted to create symlinks. I’m not sure if that is still a problem.

  1. Technically, the kernel does still exist on the rolled-back root filesystem under /usr/lib/modules, but the initramfs would need to be regenerated. It could be made to work, but the tool used to do the rollback needs to be specialized to handle running kernel-install as a last step of the rollback process to recreate the initramfs and copy it and the kernel to /boot. ↩︎

15

Note that it’s perfectly fine to have `/boot`-on-root when not using LUKS (and in some cases you can make it work with LUKS as well). So you don’t /need/ a separate-/boot but it depends on what other layout decisions one wants to make.

16

This used to be the case until recently, and GRUB 2.14 also now supports Argon2id, bridging the gap closer. It’s even more bridged with UEFI, where the kernel or initrd could reside on the EFI system partition (a la OpenSUSE, which copies the kernel from /boot). If you want to play around with UKIs, a separate partition for /boot is also not mandatory.

1 Like