You've come to this page because you've asked a question similar to the following:
What are meant by "boot" and "system" volumes (a.k.a. "boot partition" and "system partition")?
This is the Frequently Given Answer to such questions.
There are two answers to this question. In widespread usage:
A "boot" volume is the disc volume from which an operating system is bootstrapped. It is the volume whose bootstrap code is loaded and invoked by the machine's firmware.
A "system" volume is the disc volume that contains the remainder of an operating system, including all of the system utility programs, DLLs, configuration files, and data files.
However, Microsoft, in its operating system documentation, gets this exactly backwards. In Microsoft's documentation, the "system" volume is the volume containing the bootstrap code, and the "boot" volume is the volume containing the operating system. As William Boswell puts it, in Inside Windows 2000 Server: "You may find [the Microsoft documentation's] definitions to be a little cross-eyed. […] In a nutshell, the boot files in the system partition load the system files from the boot partition. Confusing? You bet it is."
For most operating systems, including MS/PC/DR-DOS and OS/2, the two are one and the same, and no distinction is made between the two. However, several operating systems allow the "boot" and the "system" volumes to be separate from each another.
| File/directory name | Description and function |
|---|---|
\TAU mini-filesystem driver for fs-type
|
The mini-FSD for the filesystem type. |
\TAU\Boot |
The directory containing the TAU boot program image files. |
\TAU\Boot\OSLOAD.COM |
The filesystem-independent boot loader. |
\TAU\Boot\OSLOAD.CFG |
The boot loader's configuration file. |
\TAU\Boot\OSKRNL.EXE |
The kernel loader and kernel itself. |
\TAU\Boot\OSKRNL.CFG |
A kernel configuration file. (There may be more than one. Other
possible names include afe.CFG and
Normal.CFG.) |
\TAU\Boot\*.DRV |
Device driver files
(e.g. PCIBUS.DRV, ATABUS.DRV, and
ATACHAN.DRV). This is the conventional location, although
any directory on the "boot" volume can be specified in the kernel
configuration file.
|
In TAU, the "boot" volume is the volume that is accessed via the micro-FSD and the mini-FSD. It is the volume from which kernel loader, kernel image file, and device driver files are read. The "system" volume is the first volume that the kernel mounts, at boot time, and where the kernel expects to find the image files and DLLs for the initial process.
The mini-FSD passes disc slice information for the "boot" volume to the kernel loader, and by default this is then passed to the kernel. The kernel mounts this volume as the first volume and assigns a drive letter to it. By default, therefore, the "boot" volume becomes the "system" volume.
However, TAU allows system administrators to configure the kernel loader (by specifying replacement values in the kernel configuration file) to pass different disc slice information to the kernel, replacing the information provided by the mini-FSD. Thus the "boot" volume and the "system" volume can be divorced from each other.
TAU does this in order to allow system administrators to make the "boot" volume entirely inaccessible once the operating system is running, thus protecting the kernel, device drivers, and kernel configuration files from accidental damage. If the "boot" and "system" volumes are separate, the "boot" volume has to be explicitly mounted by a DASD manager in order to make it accessible once the operating system is running. If it is not mounted at all, the risk that it is accidentally written to is reduced.
Separating the "boot" and "system" volumes also eliminates the possibility that filesystem corruption (as would result from a dirty shutdown or a power loss, for example) renders the system unbootable because of damage to the kernel image and device driver files. The only times that the "boot" volume need be mounted, and written to, are when a new kernel or a new device driver is being installed, or the kernel configuration is being adjusted.
Finally, separating the "boot" and "system" volumes allows the "system" volume to reside on a disc that the machine's firmware does not know about (such as on a SCSI disc where the SCSI host bus adapter's ROM firmware has been disabled), on an area of a disc,that the machine's firmware cannot reach (such as beyond the 1024th cylinder of a disc on machines where the machine's firmware has a 1024 cylinder limitation), or on a disc that the machine's firmware doesn't provide the facility for booting from (such as secondary disc units). The "boot" volume is a small partition accessible to and bootable by the machine's firmware, containing just enough to get the kernel and its own DASD drivers up and running, with the "system" volume elsewhere.
OS/2 programs that request the "boot drive letter" on TAU are given the drive letter for the "system" volume, on the grounds that:
If the "boot" and "system" volumes have been separated, the "system" volume is what applications programs are actually looking for when they request the "boot drive letter", since it is the "system" volume that contains the applications-visible system files that applications generally look for on "the boot drive".
If the "boot" and "system" volumes have been separated, the "boot" volume doesn't necessarily even have a drive letter. The DASD manager(s) may not have even created a disc slice for it, let alone mounted it and assigned it a drive letter. The "system" volume, in contrast, is always mounted and assigned a drive letter at system initialization, by the kernel.
In Linux, the "boot" volume is the volume containing the kernel loader
(e.g. GRUB) and from which the kernel image file (and boot-class device
drivers, compiled into the kernel image) is read. By convention, it is
mounted at /boot. The "system" volume is more commonly known
as the "root" volume, and is the volume that is mounted at /.
Linux separates "boot" and "system" volumes in this manner for the same three major reasons that TAU does (as per this, this, and many others): Separating the twain allows the "boot" volume to be mounted read-only, or not to be mounted at all. It eliminates the possibility that a power loss or dirty shutdown will corrupt the volume containing the critical kernel boot files. And it allows the "system" volume to not be subject to 1024 cylinder placement limitations and to be locatable on non-firmware-accessible or non-firmware-bootable devices.
Furthermore, it allows the "boot" volume to be formatted with a less complex filesystem format that the format used for the "system" volume, which can yield speed, compatibility, or maintainability advantages.
Erik B. Andersen uses a separate "boot" volume formatted with the old EXT2 options, because xyr "system" volume is formatted with new EXT2 options that other softwares on his machine do not understand.
If the "system" volume is under the control of the logical volume manager, there must be a separate "boot" partition because LVM-managed volumes are not directly bootable.
Windows NT has the ability to have separate "boot" and "system" volumes.
(As previously mentioned, Microsoft gets the terminology the wrong way
around, however.) The bootstrap volume contains (on Windows NT version 6)
bootmgr and BCD, or (on Windows NT version 5.2
and earlier) ntldr, ntdetect.com,
ntbootdd.sys, and boot.ini. The operating
system volume contains the registry hives, system programs, system DLLs,
and other system files. On Windows NT version 6 it is also where
winload.exe is located.
In addition to getting the terminology wrong, Windows NT is slightly different to other operating systems in other respects.
Unlike other operating systems, Windows NT does not separate the two volumes in order to enable critical system files to be protected. The kernel image file and boot-class device driver files in Windows NT are located on the operating system volume, for example, not on the bootstrap volume as is the case with other operating systems.
Nor does Windows NT separate the twain in order to overcome machine firmware limitations. If the machine's firmware has a 1024 cylinder limitation, then that applies to the operating system volume as well as to the bootstrap volume. (For other operating systems, it only applies to the bootstrap volume.)
The major impetus for Windows NT's separation of the "boot" and "system"
volume is in fact dual booting when upgrading from MS/PC/DR-DOS or
DOS-Windows 3.x/9x/ME. The design was created so that the bulk of Windows
NT could be installed in a secondary partition, with a minimal set of
files added to an existing primary partition, containing the
prior operating system. ntldr is a "dual boot" mechanism
that either reads the kernel, registry hives, and boot-class
device drivers from the secondary partition and boots Windows NT
or loads the original bootstrap code from the prior operating
system and boots the operating system that resides in the primary
partition.
Indeed, in Windows NT separation of "boot" and "system" volumes is the default assumption, and it is in fact difficult to combine the two in some circumstances. Whereas both TAU and Linux allow system administrators to combine the "boot" and "system" volumes into one so that the operating system can be booted from a self-contained floppy disc, and this is fully supported by the toolset provided with the operating system, this is not the case with Windows NT. Bootable Windows NT floppy discs made by the tools that Microsoft supplies to system administrators in fact only contain the bootstrap volume. (See Microsoft KnowledgeBase article #301680.) An operating system volume is required on a hard disc in order to boot Windows NT "from floppy disc". Only Microsoft itself can access the secret seven on the dice that allows the creation of bootable standalone floppy discs and CD-ROMs.
Windows NT's philosophy is that of all other Microsoft operating systems: There is only one bootstrap volume in the system, and it is the active primary partition on the first hard disc. A complex system of overlaid dual boot systems allows MS-DOS, DOS-Windows, and Windows NT to all share that single partition.
This contrasts with the philosophy of other operating systems. The TAU philosophy, for example, is that it can be placed entirely in a secondary partition if some other operating system requires placement in the active primary partition, and that it is not up to TAU itself to arrange for anything more than that loading and running the boot sector of whatever partition it finds itself in will boot TAU. The actual loading and running of the boot sector of a secondary partition, in the first place, is the province of a boot manager, not of TAU. Many boot managers have no trouble at all with such a thing. We aren't in 1986 any more, Toto.