Wandering Thoughts archives

2022-11-03

On not having a separate /boot filesystem on modern (x86) Linux

I recently read Lennart Poettering's Linux Boot Partitions and How to Set Them Up (via), which suggests in passing that having a separate /boot partition is still a thing in general. At first I had a relatively strong negative reaction to this and in favour of putting everything in the root filesystem, but after thinking about it more I've realized that there are a number of situations where it's sensible to have a separate /boot. My new view is that on modern Linux, you should trust the choice your distribution's installer has made about /boot unless you have a strong reason to know better. Also, generally I think that normal, boring server installs should not wind up with a separate /boot filesystem; if your server install does, it's probably a sign that you're doing something a bit exciting.

(A normal boring server install should use a well proven choice for the root filesystem, and GRUB can deal with all of them. Today, generally you don't encrypt the root filesystem on servers that you need to (re)boot automatically, although someday maybe TPMs will be pervasive enough in x86 servers that you can rely on them for automatic key management.)

Once up on a time there were good reasons to use a separate /boot filesystem, but they've gone away these days in basic configurations. No x86 system's firmware has problems reading all of your disks, and if you're sticking to non-exotic storage devices, the firmware can boot from anything you want to use. There remain reasons like having your root filesystem encrypted or using btrfs for it (the current Fedora default), but if your Linux distribution does this, the installer should get it right if you need a separate /boot (and also if you don't).

(I feel that filesystem or disk encryption isn't a basic configuration, although it's often a standard one. I may be biased by mostly working on servers, but I remain twitchy about disk encryption in general and mostly consider it a necessary evil.)

If the distribution's installer picks a separate /boot filesystem, it should get things like the size and the filesystem type correct (ie, big enough for the distribution's future needs, and of a type that the distribution will make sure its bootloaders always support). If you override the defaults to add a separate /boot filesystem, getting all of those aspects correct is on you. Similarly, if a distribution doesn't use a separate /boot filesystem in your configuration, it's telling you that it's made its bootloader work with the filesystem type, storage configuration, and so on that you've chosen (and also that it believes that not having a separate /boot is a sensible choice).

I think that it's a good thing to maintain Linux's ability to have a separate /boot filesystem because it allows us to stay agile on things like root filesystems and disk encryption, and thus to support experiments with them. If Linux absolutely didn't support a separate /boot, we'd be locked to whatever bootloaders supported. This doesn't mean that any particular distribution has to be completely flexible; it's sensible for a distribution to narrow what it officially supports, especially in the installer. The onus of making weird things work can be on the people doing them.

It's possible that someday this separate boot filesystem will actually be the UEFI ESP. However, regardless of what some people want, I think it will be many years before people stop booting systems with old fashioned non-UEFI BIOS MBR booting. And it will probably be quite some time before replicated UEFI ESP partitions are well supported in Linux distributions, although Ubuntu has made strides in supporting them.

PS: I can't speak about whether non-x86 Linux platforms really need a separate /boot or whether they're fine without it; I don't have the knowledge and experience.

linux/SeparateBootMostlyNot written at 21:52:16; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.