What is the /boot partition really for?

Question

I'm reading a relatively old text on Linux partitions and file systems (the LPIC 1 Certification Bible). It says:

Some versions of the Linux boot loaders cannot access a kernel that is outside the first 1024 cylinders on a disk. By putting the /boot partition at the beginning of the drive you can be assured of not having a problem when accessing the kernel at boot. This problem shows itself most often in cases of dual booting Linux along with another operating system that is on the first partition.

Why would a boot loader have "no access to the kernel outside the first 1024 cylinders on a disk"?

Also, what does "putting the /boot partition at the beginning of the drive" mean?

Answer 1

This is a limitation imposed by having a very old BIOS and bootloader rather than Linux itself. The BIOS would only be able to access the first 1024 cylinders of the disk (see here for more information on what cylinders/heads/sectors are). This limitation would extend to bootloaders which, due to their simple nature, would not have their own disk drivers and would use the BIOS services to access the disk.

This meant that both the bootloader and the kernel (since it is the bootloader's job to load it) would have to be within the first 1024 cylinders on systems with this limitation. A simple way to do this was to create a separate /boot partition containing the kernel and put it at the beginning of the drive (usually just by making it the first partition). This means that it would physically reside within the first 1024 cylinders, provided of course that the partition wasn't too large.

The limitation is no longer an issue because it only applies to old BIOSes. Also, many modern bootloaders (eg GRUB) have their own disk drivers and so do not need to rely on BIOS services. Modern bootloaders may use /boot for other purposes, but it is no longer required to be both on a separate partition and within the first 1024 cylinders (although there are many cases where it is necessary to have /boot on a separate partition).

Answer 2

The history

/boot contains files that aren't used by the operating system, but by its bootloader. You'll find both files of the bootloader itself (like /boot/grub/* for Grub) and the Linux kernel (/boot/vmlinuz*) and often an associated initrd or initramfs.

On a PC with legacy BIOS (as opposed to the newer UEFI found on most recent computers), the software in ROM loads the first 512 bytes of the boot disk into memory (the boot sector). With only 512 bytes (not all of which even contain code: some of it contains data such as the partition table), the code can't do much — there can't be a real disk driver in there. All that can be done in such limited space is to use a BIOS interface to load more code. This interface provides a command to load the Nth sector on the disk — and the size of N is limited, so only the beginning of the disk can be reached that way.

The BIOS interface has evolved a bit in the three decades or so that it's been around, but its size limitations have struggled to keep up with disk sizes, causing older BIOSes and bootloaders to conk out at 32MB, 512MB, 2GB, 8GB (and possibly other thresholds that I don't remember). The bootloader needs to be able to use the BIOS interface to load all the pieces that are needed to access the disk drive directly. Bootloaders generally don't contain drivers for all the disk controllers around, so everything up to loading the Linux kernel (and the initrd/initramfs) has to use the BIOS interface and thus has to fit at the beginning of the disk.

Note that this is a limitation of the BIOS or of the bootloader, not of Linux itself or of a distribution.

Separate /boot today

On a system with a recent BIOS and a recent bootloader, or with UEFI, size limitations are no longer relevant: disk sizes now have a long time to catch up. However, there are other use cases that make a separate /boot partition useful. It allows the main system to be on a RAID device that the bootloader doesn't support, or on a filesystem type that the bootloader doesn't support. It allows the main system to be on an encrypted device, which Linux can decrypt but not the bootloader.

If none of these limitations and use cases apply to you, keeping /boot as a separate partition isn't useful. But they affect enough people that most distribution support it.

Answer 3

Another reason beside the mentioned BIOS problem is that a separate /boot partition allows the use of a file system for the / volume which the boot loader does not understand (without being limited to block list loading like with lilo).

Answer 4

BOOTING IS HARD

Booting... well... it really is the hardest part. Every time a computer boots it basically meets itself anew. It acquaints itself with its various parts, and for each one it meets it gains capability. But it has to pull itself up by its own bootstraps, so to speak, from square one every time.

When designing a boot process the trick is to bring the machine up in stages. Your boot must be fast and reliable, and it must be both things in a completely unknown environment every time. I won't even venture into a Real/Protected mode conversation (which isn't to say that I even could), but there's a lot going on at boot. As the computer assimilates its various components each time it does so in graduated steps. Probably the most crucial of these is the move from executing on-board code to executing on-disk code, or, in other words - the kernel exec. This is when the firmware (ostensibly) surrenders to the operating system.

Many years ago this was not so much the case. It used to be the BIOS really was the Basic In/Out - regular programs would make calls to the firmware for things like drawing the screen and accessing the disk. These were called interrupts - old hats might remember them best for the thrills of delight they often found in assigning IRQs for their new dot-matrix or USR.

INT13H

It is the interrupt (or INT in assembly lingo) 13H series of functions that the BIOS offers as services for disk access. These are still even used today for BIOS systems in the boot process to make the jump from firmware to disk.

A BIOS system will check the first few bytes of each disk it finds and look for a pattern it recognizes as a Master Boot Record (or MBR). This is a decades-old de-facto standard and includes a bit of raw, executable binary which is written to the head of the disk. The MBR marks a BIOS disk as bootable. It will stop checking when it finds one, and so practically one is all you get without some clever trickery. When it does find one it maps it to memory and executes it (in Real mode, but I'm still not going there).

The executed MBR is almost definitely not your system kernel - 512 bytes (give or take) would be pretty useless in that department. This is probably a bootloader - a program designed specifically to overcome one of the BIOS's many addressing limitations - specifically that it does not understand any kind of file system at all.

When the bootloader reads in the actual kernel and executes it in memory (as we all pray it will every time), it will probably do so by asking the BIOS via an INT13H interrupt call. And if it does not - many fancier bootloaders will mount file systems in the conventional sense and execute the code another way - then it is very little likely that the bootloader has got so fancy without an INT13H or two. Often bootloaders must chainload themselves - or various stages of themselves - because the 512 bytes first allocated them does not suit even their needs.

CHICKEN AND EGG

All of this is a roundabout way of discussing the disk, I know, but by this point it should be abundantly clear that the primary problem - one might call it a chicken-and-egg type - is accessing the disk that contains the program instructions about how to access disks. The key to this problem is firmware - and continues to be in very different ways even on EFI systems - and, weakest or not, the firmware is the most important link in the boot chain.

You see, once the kernel executes, and all of its myriad routines for accessing and controlling hardware initiate, all of these problems sort of disappear (or, at the least, change somewhat), because modern OSes take full-control of a system, but until they do the system's limits extend only so far as the firmware will allow. This is saying a lot - the BIOS has not changed much since the 8086. The INT13H call is an 8086 original. Yes, there have been (myriad) extensions, and hacks of course, but innovations...?

BETTER AND BETTER

Most changes to the BIOS have been mere bandages at best. It used to be a hard-disk had to be physically mapped - various and specific aspects of its geometry were referred to when data was stored to it or retrieved from it. Eventually the conventional hard disk grew to a size that prohibited this. Even just the abstract map was too much information for a BIOS to handle. As it can operate only in Real Mode, the BIOS is limited to 1 MB per memory register. Swell the cylinder map any larger than that, or make any one of its properties larger than can be addressed in so many bits, and the BIOS is literally lost - out of bounds.

This barrier has been met and broken many times. Each time the map has abstracted and encoded in some newer, clever, and less accurate way. And so these days it is literally impossible for a BIOS to accurately map a drive. Logical Block Addressing is the de-facto standard now, though some Cylinder/Head/Sector (or CHS) translations are still necessary. What the mainboard firmware has lost in accuracy/responsibility, such extensions have abstracted and added to the disk firmware responsibilities to fill the gaps.

It is this cat-and-mouse game that is referenced in your question. When the BIOS fails to understand a disk beyond a certain point due to its sheer size, then any data you might want it to retrieve for you at boot - such as a bootloader or kernel - had probably better not be located beyond that point. This is where /boot came from.

MAYBE ACTUALLY BETTER

These days such things are, thankfully, made irrelevant by BIOS's demise. It was 30 years coming, but it has been largely replaced in the past few years by the UEFI (or EFI 2.0) standard. UEFI provides a mount from minute one, it initializes in Protected Mode, it incorporates its own bootloader, it provides reboot-persistent flash-memory variable storage, it is spec'd to handle some umpteen zetabytes or whatever per disk... and much else. It is far from perfect, but it is a vast improvement over its predecessor.

Even arguments for specialized bootloaders involving disk-encryption or layered file systems fall flat when you consider that all of these must be handled by the OS kernel anyway, and if you're provided a mount at boot, you've always got a clear-shot to executing it (especially considering that the Linux kernel, in its default configuration, is an EFI-executable all its own).

And so a separate /boot partition should probably not overly concern you, and if you are on an EFI system, then you've probably already got an analog in the EFI-system partition anyway, as that is a requirement for booting EFI mode.

Answer 5

That there is a /boot directory is historically determined and from there "fixed" in the Filesystem Hierarchy Standard. Having such a standard allows programs (and sysadmins) to expect certain files at certain locations. In this case the files associated with the boot process.

Having a /boot partition at the beginning of a disc made sense for older BIOS'es that were not able to index blocks/sectors in the full range of the drives that were available. Because of this the information that should be loaded should be on a sector that could be indexed, hence a separate partition (with low sector numbers) for /boot from which the BIOS could load additional data/programs (which in turn were capable of addressing the full disc range without using the BIOS).

Answer 6

It can also be very orderly to have a separate /boot partition. On my machine, I have many distros and backups, each in their own partitions, but they all share the same /boot partition, which is where all kernels for all OS reside. Also, all distros point to my one and only copy of lilo.conf which is also in /boot, so I never have to guess what the heck is going on when I add kernels, add distros, whatever. Here's a snip from my lilo.conf:

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=y5--5-Debian1"
label  = y5:D1:16.0-4

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=y8--5-Debian2"
label  = y8:D2:16.0-4

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=y11-5-Debian3"
label  = y11:D3:16.0-4

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=w5--5-Debian1"
label  = w5:D1:16.0-4

... that's just my Debian backups on two disks. See how easy it is to keep track of the kernels? (right now, all backups using the same kernel).

Answer 7

Although on modern systems, a file's sectors can be accessed anywhere on a disk, it still makes sense to confine boot materials to their own boot partition, simply from the principle of "do not put all the eggs in in one basket".

Suppose that the main filesystem is corrupt in such a way that some lower-stage bootloader is not able to read the next stage properly. If instead the bootloader materials are in their own partition, then the kernel can come up and properly deal with the corrupt root partition via fsck. That itself can be in its own partition.

The boot partition can give you options for "rescue", like mounting an alternative root partition. Also, what if you multi-boot different operating systems in different partitions? Then the boot materials do not belong to any one of those systems. It is reasonable for it to have its own partition. You might replace any of the OS partitions with a different OS, yet be able to boot the remaining OS's.

Also, what if you would like to use a filesystem for your main partition that the bootloader doesn't understand at all? Or, say, for which the boot-loader-side support is just experimental? In situations like that, a boot-time file can still be used if there is a sector map (and the boot loader supports such a thing: the good old Linux boot loader LILO used sector maps, and so didn't have to understand filesystem structure at all). But sector maps are inherently flaky. If the filesystem is reorganized, the sectors move around, and so the sector maps become incorrect and must be regenerated, or else the system cannot reboot.

Lastly, there is the organizational principle that even if you don't have an actual partition, it's still a good idea that all the boot stuff is at least under /boot, and not scattered anywhere else.

Answer 8

This wasn't a limitation of the Linux distribution, but it was a limitation of older BIOSes. Back in those days, to ensure Linux could boot, all the boot-related files were placed in their own partition which was made the first partition on the hard drive to ensure the boot loader fell within the first 1024 cylinders. Create a partition that is smaller than whatever size is found in 1024 cylinders (varies from hard drive to hard drive). But if you create a first partition that is larger than this boundary, there is a chance the boot loader files would be located outside 1024 cylinders, and the BIOS would not be able to load them.

You can also achieve the same effect by creating two small partitions, both of which lie within the first 1024 cylinders, and putting all the boot loader files on the second one.

Answer 9

Other reasons for a boot partition these days are:

• Booting from NFS or NBD
• Booting from an encrypted root partition needs some unencrypted files that contain the code to unlock the root partition.
• The /boot partion can be shared between different distributions on the same disk.