How operating systems determine the location of the boot volume when bootstrapped

You've come to this page because you've asked a question similar to the following:

How does an operating system decide which volume is the "boot" volume (a.k.a. "boot partition", "root volume", "root partition", or "root filesystem") when it is bootstrapped?

This is the Frequently Given Answer to such questions. (How operating systems determine the location of the system volume is a different Frequently Given Answer, note.)

When an operating system is bootstrapped it must decide which volume is to be the boot volume — i.e. the volume wherein are found all of the operating system utilities, run-time configuration files, libraries, and system data. There are three basic ways in which operating systems do this:

Using a standard firmware-supplied configuration setting

This is the approach to locating the boot volume that is employed by modern operating system designs. The operating system boot loader, that is invoked by the machine firmware, consults configuration information provided by the machine firmware that specifies the locations of the operating system kernel program image file and of the boot volume. The operation of locating the boot partition is thus a relatively simple one.

What precise form this configuration information takes depends from the machine firmware.

The configuration information is created and written by the operating system installation utility when the operating system is installed. Modern machine firmwares provide facilities to allow system administrators to edit the configuration information without needing to actually bootstrap an operating system in order to run a configuration editing utility.

Standard configuration settings supplied by Extensible Firmware Interface (EFI) firmwares

On machines with EFI firmwares, the location of the boot volume is determined by the value of a machine firmware variable that is stored in non-volatile RAM. Each entry on the EFI Boot Manager menu is defined by the value of a single NVRAM variable, named BootXXXX where XXXX is a number. Each variable's value comprises a rich binary data structure (the EFI_LOAD_OPTION structure) that comprises the whole definition.

This binary data structure contains, amongst other things, an array of EFI Device Paths. (An EFI Device Path is EFI firmware's standard general-purpose mechanism for specifying hardware devices, disc volumes, and files.) The first device path specifies the location of the operating system boot loader program image file itself. This is the program image file that the EFI Boot Manager loads and invokes when the entry is selected from the menu. The second and subsequent paths are for use by the operating system boot loader. They specify the device path to the kernel program image file, the device path of the boot volume, and so forth.

One thus specifies which volume is the boot volume by editing the appropriate device path in the boot menu entry. The operating system boot loader takes the device path and passes it to the operating system kernel, translating it if necessary into whatever internal naming scheme the operating system kernel itself uses for specifying disc volumes. The operating system kernel in turn mounts the designated volume as the boot volume.

Standard configuration settings supplied by Advanced RISC Computing (ARC) firmwares

ARC firmwares are very similar to EFI firmwares. Like EFI firmwares, they have a native general-purpose naming mechanism, ARC Paths, for specifying devices, disc volumes, and files. Like EFI firmwares, they have variables stored in non-volatile RAM that name the program image files of operating system boot loaders and that contain configuration information to pass to those boot loaders, such as the ARC Path of the boot volume.

The only significant difference is in the implementation detail. Whilst EFI firmwares store everything in the value of a single variable, ARC firmwares store the ARC Paths of the operating system boot loader, the kernel program image file that it loads, and the boot volume, in the values of three separate variables: OSLoader, OSLoadFilename, and OSLoadPartition, respectively. Thus the location of the boot volume is the value of the ARC firmware's OSLoadPartition variable, held in NVRAM.

As with EFI firmwares, the operating system boot loader has to translate the ARC Device Path for the boot volume into whatever naming scheme the operating system kernel itself uses for specifying disc volumes.

Windows NT needs no translation at all. The Windows NT kernel directly understands ARC Paths, and Windows NT uses ARC Paths as its mechanism for communicating between boot loader and kernel. NTLDR, the Windows NT operating system boot loader, simply passes the ARC Path taken from OSLoadPartition directly to the kernel, which in turn decodes the ARC Path to determine the actual volume that is the boot volume.

Standard configuration settings supplied by old PC/AT and PC98 firmwares

On machines with old PC/AT and PC98 firmwares, there is no service available from the firmware for specifying the location of the boot volume to the operating system boot loader. Operating systems thus simply pretend that they are using more capable firmwares, employing shim layers that sit between the operating system boot loader proper and the PC/AT or PC98 firmware.

This is the approach taken by Windows NT.

The problems with this approach are akin to the problems with the roll-one's-own explicit configuration mechanism described next.

Rolling one's own explicit configuration mechanisms

Some operating systems make no attempt whatever to use the standard facilities that the machine firmware provides, but instead roll their own non-standard configuration mechanisms for explicitly specifying the location of the boot volume.

Linux is a major sinner in this regard. Linux kernels, for example, make no effort to use the kernel image file and root filesystem device path information that is supplied for the purpose by ARC firmwares and EFI firmwares. Instead, Linux kernels built without the CONFIG_EDD option have the location of the boot volume hardwired into the in-memory image of the operating system kernel itself, as a pair of major+minor device numbers. (Things get worse, not better, with the CONFIG_EDD option, which switches to a system of abusing (or at least attempting to abuse) the system volume as the boot volume, more on which later.)

This pair of values in the kernel image is set manually by the system administrator in one of two ways:

The problems of this approach are severalfold:

Abusing the system volume for the boot volume

Some old operating systems simply do not separate the concepts of "system volume" and "boot volume" at all. They obtain the location of the system volume and they use that as the location of the boot volume. Other operating systems do have separate concepts of system and boot volumes, but simply abuse the former for the latter.

This approach is rarely used on EFI firmware or ARC firmware systems, simply because those systems provide well-defined and simple mechanisms for specifying the location of the boot volume, making it daft to do anything but use those mechanisms.

This approach is commonly used on PC/AT and PC98 compatible firmware, however. Such firmwares provide no services to operating system boot loaders for locating the boot volume, but they do provide services for locating the system volume. Such services are an implicit part of the bootstrap process, which passes the firmware disc unit number of the system volume in a documented CPU register, and the start and length of the system partition on that disc in undocumented fields of the BIOS Parameter Block to the operating system boot loader, which in turn passes them on to the operating system kernel.

The major problem with this mechanism for determining the boot volume is that it requires that the operating system's idea of disc unit numbers exactly matches the machine firmware's idea of disc unit numbers. Thus either the operating system must use the machine firmware for all disc I/O (as operating systems such as PC-DOS, MS-DOS, DR-DOS, and FreeDOS all do), or the operating system's own disc device drivers must exactly mirror the machine firmware's disc device drivers. In particular:

This scheme does not work at all for operating systems that simply do not employ the same disc unit numbering system as the machine's firmware does, but have a very different native disc device naming scheme. This is the case for Linux, for example. There is no straightforward mapping between IBM PC firmware disc unit numbers and the major+minor device number pairs that Linux uses to identify disc volumes.

In order to determine which volume known to the operating system kernel corresponds to the disc unit number supplied by the machine firmware, such operating systems employ a bodge: The operating system boot loader reads data from the system volume, via the machine firmware, and then the operating system kernel reads data from each volume in turn, via its own device drivers, until it finds a volume with matching data. This volume is then designated the boot volume.

This bodge is the mechanism that is employed by Linux kernels built with the CONFIG_EDD option.

It is a problematic mechanism for several reasons:

© Copyright 2006,2011 Jonathan de Boyne Pollard. "Moral" rights asserted.
Permission is hereby granted to copy and to distribute this web page in its original, unmodified form as long as its last modification datestamp is preserved.