separate /boot partition, why?

[sluge]

Many linux distrs install /boot to a separate partition, why? Is any benefit in separate partition?

[Evil_Bert]

I can think of a couple of reasons:

a. It allows (mostly historical) BIOS to always be able to access the /boot partition and therefore the Linux kernel regardless of filesystem, or volume management, and size of the '/' (i.e. "root") partition - this isn't really a problem these days

b. The /boot partition can be made read-only most of the time - write access is only needed for Grub changes or kernel updates (mostly)

Edit: You can also encrypt the '/' filesystem, which will necessitate a separate /boot partition.

[srs5694]

Originally Posted by Evil_Bert

a. It allows (mostly historical) BIOS to always be able to access the /boot partition and therefore the Linux kernel regardless of filesystem, or volume management, and size of the '/' (i.e. "root") partition - this isn't really a problem these days

This is an issue that crops up again and again, then slowly fades away, as disk sizes keep creeping up and then manufacturers release new BIOSes that work around old disk-size limits. In recent years, this issue has faded from view as older BIOSes were retired. With a reasonably modern BIOS that does not support EFI, the issue is becoming relevant again because of 32-bit sector addressing issues. 2^32 x 512 bytes/sector works out to precisely 2 TiB. Although modern BIOSes can supposedly read beyond this value, many boot loaders can't, so we're stuck with a wall at 2 TiB, and of course disks bigger than this already exist. I've tested this using big virtual disks in VirtualBox; booting Linux using GRUB Legacy or GRUB 2 from beyond the 2 TiB limit is impossible. That said, I can't be sure that the limit I ran into is caused by GRUB or by VirtualBox; it could be the latter's BIOS is more limited than the BIOS on a modern computer.

If you've got a motherboard that supports EFI, OTOH, the 2 TiB limit shouldn't exist; such systems should be able to boot from anywhere up to sector 2^64, which is well in excess of any existing hard disk, or even of any RAID array I've ever heard of. That said, there could be bugs in some implementations that might place lower limits on the matter. Also, EFI uses a special partition, known as the EFI System Partition (ESP), which is similar in some respects to a separate /boot partition -- the ESP holds boot loader code, and in some cases Linux kernels and initial RAM disks. It can go anywhere on the disk, but it's conventionally the first partition. In Linux, it's usually mounted at /boot/efi.

Another point for the original question is that a separate /boot partition enables older boot loader, such as GRUB Legacy, to read the kernel and initial RAM disk even if everything else on the computer is in an LVM or Linux RAID configuration. GRUB Legacy can't parse those data structures, so it needs the kernel and initrd outside of them. GRUB 2, OTOH, has LVM and RAID support, so you should be able to boot from a system that uses them without a separate /boot partition. (I've not tested this myself, though.) Also, note that this comment applies to Linux's software RAID, not to hardware RAID controllers. With the latter, even the boot loader sees the RAID array as if it were a single disk.