The big motivation for a separate /boot partition

April 20, 2017

In a recent comment on my entry on how there's no point in multiple system filesystems any more, I was asked:

What about old(er) computers stuck with BIOS booting? Wasn't the whole seperate /boot/ partially there to appease those systems?

There have been two historical motivations for a separate /boot filesystem in Linux. The lesser motivation is mismatches between what GRUB understands versus what your system does; with a separate /boot you can still have a root filesystem that is, say, the latest BTRFS format, without requiring a bootloader that understands the latest BTRFS. Instead you make a small /boot that uses whatever basic filesystem your bootloader is happy with, possibly all the way down to ext2.

The bigger motivation has been machines where the BIOS couldn't read data from the entire hard disk. All the stages of the bootloader read data using BIOS services, so all of the data they need had to be within a portion of the disk that the BIOS could reach; in fact, they all had to be within the area reachable by whatever (old and basic) BIOS service the bootloader was using. The first stage of the bootloader is at the start of the disk, so that's no problem, and the second stage is usually embedded shortly after it, which is also no problem. The real problem is things that fully live in the filesystem, like the GRUB grub.cfg menu and especially the kernel and initramfs that the bootloader needed to load into memory in order to boot.

(There have been various BIOS limits over the years (see also), and some of the early ones are rather small.)

If your /boot was part of the root filesystem, you had to make sure that your entire root filesystem was inside the area that the BIOS could read. On old machines with limited BIOSes, this could drastically constrain both the size and position of your entire root filesystem. If you had a (small) separate /boot filesystem, only the /boot filesystem had to be within this limited area of BIOS readable disk space; your root filesystem could spill outside of it without problems. You could make / as big as you wanted and put it wherever you wanted.

(If you care about this, it's not enough to have a separate /boot and to make it small; you need to put it as close to the start of the disk as possible, and it's been traditional to make it a primary partition instead of an extended one. Linux installers may or may not do this for you if you tell them to make a separate /boot filesystem.)

Today this concern is mostly obsolete and has been for some time. Even BIOS MBR only machines can generally boot from anywhere on the disk, or at least anywhere on the disk that the MBR partitions can address (which is anything up to 2 TB). In theory you could get into trouble if you had a HD larger than 2 TB, used GPT partitioning, put your root filesystem partly or completely after the 2 TB boundary, and your bootloader and BIOS didn't use LBA48 sector addressing. However I think that even this is relatively unlikely, given that LBA48 is pretty old by now.

(This was once common knowledge in the Linux world, but that was back in the days when it was actually necessary to know this because you might run into such a machine. Those days are probably at least half a decade ago, and probably more than that.)


Comments on this page:

By Diego at 2017-04-20 05:46:58:

I personally reuse the EFI System Partition as /boot partition, it seems to be the recommended way of using modern pure UEFI bootloaders such as systemd-boot. Or at least it's what the arch wiki says...it certainly seems cleaner than other setups. The only disadvantage is that it feels weird to make a FAT filesystem part of my Linux boot :P

By John Wiersba at 2017-04-21 08:32:51:

Another reason: a (LUKS) encrypted / with a non-encrypted /boot.

By Anon at 2017-04-22 01:35:49:

Thanks for the comprehensive follow up in this and the previous post - it thoroughly explains why you used to have to care so much (I never knew BIOS services were still being used so late into the boot process) and how things changed over time to the point where a separate /boot is moot for many cases.

By Mantas at 2017-05-03 17:05:59:

This also reminds me of a recent systemd-devel thread, which concluded that although grub claims to support xfs, btrfs, etc. that doesn't mean it'll actually work every time – both the fact that it has to maintain its own drivers (which naturally lag in terms of features) and that it's its own OS mean there's always the chance Linux will write some critical files in a way grub is unable to understand.

(The specific example was rebooting right after an upgrade, which meant xfs had only committed the new kernel files to the journal but not the main filesystem.)

So it still makes a lot of sense for /boot to use a much simpler filesystem than the rootfs, and let Linux itself handle all the fancy stuff.

Written on 20 April 2017.
« Some things on how PCs boot the old fashioned BIOS way
A surprising reason grep may think a file is a binary file »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Thu Apr 20 00:19:49 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.