How can I tell whether my specific system needs a boot partition?

Question

I know the general story of why we have separate boot partitions historically:

What is the /boot partition really for?

and on a new computer, I might not bother with one. However - I'm installing Linux on a 20-yro system, with a non-UEFI BIOS (which can't even boot from USB). This will not be a multi-boot machine, or anything complicated: No LVM, no disk encryption, no RAID etc.

How can I tell whether my specific computer, with my specific HDD, needs a boot partition?

Note:

• In case it matters - the distribution I intended to install is antiX Linux 19.3 i386. It invokes gparted to let you edit the partitions.
• The boot loader will naturally be the one my distribution installs, which AFAICT is grub2.

Answer 1

If a system is about from year 1994 or older, its BIOS might not be able to handle disks with Clusters/Heads/Sectors geometry larger than 1024/16/63, which works out to a limit of 504 MiB (528.4 MB). The reason for this was an inconvenient interaction of two sets of limits:

• the classic unextended BIOS INT 13h function accepted a maximum disk geometry of 1024/255/63
• the IDE (PATA) hardware would accept a maximum geometry of 65536/16/63
• so far, trivial implementations just picked the smallest limit in each value, resulting in a limit of 1024/16/63.

In July 1994, a new BIOS feature "Enhanced Disk Drive Services" (EDD for short) was developed to work around this limit. It shifted bits between the Clusters and Heads parts of the geometry between BIOS representation and the IDE hardware interface (called "geometry translation"), as a workaround for this limit.

Some BIOS versions also had bugs at disk geometry 4096/16/16 or its "translated" form 1024/64/63.

At disk geometry of 16383/16/63 (or 1024/255/63 in translated form), the maximum limit of classic C/H/S disk addressing was reached: the data input formats of the BIOS functions handling this kind of disk addressing simply did not have enough bits to handle disks bigger than this. This limit was reached at disk size of 7.87 GiB (8.45 GB), or exactly 16 450 560 disk blocks.

The IDE (PATA) specification included a feature that could work around this, but it was initially specified as optional feature, and not all BIOSes implemented it. It was called Logical Block Addressing, or LBA for short. As disk sizes grew, most disks released after 1996 or so did support LBA.

But then another BIOS bug was discovered: some BIOSes had a faulty LBA implementation that failed if more than 26 bits was required to represent the disk block number. This affected some BIOS versions released in August 1999 or older, and it caused a limit at disk size of exactly 32 GiB (33.8 GB).

The LBA specification that was released in 1994 had allocated only 28 bits for the disk block number, and this caused a yet another disk size limit at exactly 128 GiB disk size. The ATA-6 specification released in year 2003 specified 48-bit versions of the LBA disk access functions, which is what we're currently using with modern SATA disks. It should work until disk sizes grow to 128 PiB.

---

It was often possible to work around these limitations by deliberately specifying an incorrect disk geometry in BIOS, telling it that the disk was smaller than the offending limit, and making /boot a partition that fit completely within the fake geometry.

Sometimes (after the LBA support was introduced) it was enough that the /boot partition was within the appropriate size limit.

The bootloader would use BIOS routines to load the Linux kernel (and optionally an initrd file) from this partition, and once the kernel was started, its drivers would take over disk access, bypassing BIOS altogether and making its limitations irrelevant as long as the OS was running. At this point, the real disk geometry would usually be auto-detected by the kernel.

So, what does this mean?

• if your system has a BIOS release date in year 2004 or older, you may need to create a /boot partition that fits entirely within the first 128 GiB of the disk, or else the BIOS might fail to boot the OS. (This is usually a problem for dual-boot and other multi-OS setups only.)
• if your system has a BIOS release date of before year 2000, you might want to create a separate /boot partition within the first 32 GiB of the disk, just to be safe from LBA implementation bugs.
• if the system is from 1996 or older and does not mention "LBA" anywhere in BIOS settings, you might have to specify a fake disk geometry and make sure your /boot partition is both within the fake geometry and within the first 7.87 GiB of the disk.
• anything older than that: "It belongs to a museum." :-) But if you must, see above for the relevant limits.

If a system's BIOS release date is only just after the date of a particular specification update, it might or might not have the updated specification: after each specification update was released, it took some time for the new implementations to become ubiquitous.

Answer 2

tl;dr: You don't need a boot partition.

Even for an old computer from the 1990s, you don't need a boot partition.

... "but how can this be," you might ask, "considering how we've been told for years that we need one because of the BIOS limitations?"

The reason is that a modern Linux distribution (like your antiX 19.3) will install the grub2 boot loader; and a grub2 installation can include drivers, with which the boot loader can access your partitions with no limits; it will not need the BIOS facilities for HDD access.

There is, however, a caveat: those drivers need to actually get installed, and they don't necessarily get installed automatically.

... but you must leave space for the grub2 drivers

First, grub2 needs space to store these drivers. Luckily, if your first partition is not situated immediately after the MBR, at the start of the disk, the grub2 installation will store the drivers in this non-partition space (it only needs a small amount of space, perhaps just 20KiB) and you're good to go.

So, you will need to make sure you create your first partition with 1MiB alignment (and perhaps all partitions with this alignment).

In your specific case of the antiX installer, the gparted utility is used for defining/creating partitions. gparted defaults to 1 MiB alignment, and shows you this choice when creating a partition:

so just don't change that setting.

... and make sure the appropriate drivers are installed

Linux distro installers, specifically antiX' installer, default to having grub2 using BIOS/UEFI facilities rather than its own driver. You need to make sure that grub2 is installed with grub-install --disk-module=native. Doing that is covered in another question:

How to make sure grub2 has the drivers it needs during a Linux installation?

---

_{Thanks goes to @cas, @isaac and @telcoM for their insightful answers and helping me synthesize this one.}

Answer 3

Whether or not your system needs a /boot directory is entirely defined by the distro you choose to install.

Whether that directory (/boot) is in a separate partition is also optional (not required), but quite useful in some conditions.

The distro you selected (AntiX) is a Debian derivative. Debian may use a /boot partition but it is not a requirement. Debian is also able to use several bootloaders (lilo, grub, etc.).

It is the bootloader the part that is affected by the BIOS ability to load sectors at some distance of the start. But GRUB2 is perfectly capable of bypassing any such limitation provided it could use about 80 sectors (́~20k) after the MBR. Which it normally could, especially with a 1M aligned partition.

In short: create a /boot partition as the first one of about 200 Mbyte (plenty of space), make it bootable (a DOS requirement), and install grub to the MBR. You could additionally install grub to that partition, but there is no real need for the complexity.

You need not to concern about any of several DOS disk limits, Grub2 is perfectly capable of solving any configuration (with access to MBR and following sectors).

Please read the detail in the grub documentation.

there are two ways to install GRUB: it can be embedded in the area between the MBR and the first partition (called by various names, such as the "boot track", "MBR gap", or "embedding area", and which is usually at least 31 KiB)

And the description of core.img in the grub documentation

This is the core image of GRUB.

built dynamically from the kernel image and an arbitrary list of modules by the grub-mkimage program.

Depending on the filesystem (for example) a module that reads ext4, zfs, or else will be used. Other conditions will trigger the loading of more modules.

Usually, it contains enough modules to access /boot/grub, and loads everything else (including menu handling, the ability to load target operating systems, and so on) from the file system at run-time.

In a nutshell, the inner workings of GRUB.

The modular design allows the core image to be kept small, since the areas of disk where it must be installed are often as small as 32KB.

One of the conditions GRUB has to operate.

---

If you are willing to try:

1. Leave a big chunk of space, bigger than any DOS limit, as the first partition of the disk (or as free space). No need to format it, you will not use it in this test.
2. Make a partition (for /) far ahead in the disk of Say 50GB to install a test OS. To make things even harder for GRUB, don't make a partition for /boot.
3. DO format this partition on a filesystem that grub understand, maybe ext4.
4. Make other partitions as you wish (after the free space).
5. Make sure to install GRUB to the main disk (sda, not sda1 or sdaX).
6. End installation, reboot. Does it work?

If it works, GRUB has just shown that it can manage the old BIOS you've got.