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.
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, this usage is predicated upon the idea that operating systems boot along the same old lines as PC/AT systems have traditionally bootstrapped, that thereby denote one volume as a "boot" volume. This is not how the boot processes of modern firmwares work.
Microsoft, in its operating system documentation, employs terminology that is exactly the converse of widespread usage. As standard in Microsoft's documentation:
The system volume is the single, mandatory, disc volume that is reserved for the platform. It contains standalone "pre-boot" utilities that can be run on top of the bare firmware, and the first stage boot loader programs for operating systems. On machines with old PC/AT or PC98 firmwares, it also contains a PC/AT compatible Volume Boot Record that invokes a boot manager of some sort. (Microsoft expects it to be Microsoft's Boot Manager, of course, but it could equally be the TAU Boot Manager or UEFI DUET with its boot manager.)
A "boot" volume is the disc volume contains the remainder of (the currently bootstrapped) operating system, including all of the system utility programs, DLLs, configuration files, and data files. It is largely just an ordinary data volume, except that the data are operating system data rather than user data. Microsoft tools label only the volume of the currently bootstrapped operating system as the "boot" volume, but a system can in reality have multiple "boot" volumes, with multiple separate operating systems.
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.
This converse terminology has its roots in the way that high end server machines and non-Intel systems work — bootstrap procedures that are now becoming common on desktop personal computers, but which have for a long time held sway on the high end server and workstation systems in which Windows NT has its roots. The concepts that underpin Microsoft's terminology have their roots in the ARC firmwares that were employed by machines that Windows NT used to be capable of running on. EFI firmware employs similar mechanisms and notions.
In the EFI and ARC worlds, there is the notion of a disc volume that is dedicated to the platform. It is dedicated to the machine and its firmware — to "the system" in other words, independent of what operating system is installed and booted on "the system". On ARC, this mandatory volume is called the ARC System Partition. On EFI, this mandatory volume is called the EFI System Partition. It is this, single, required-by-the-platform, volume that is the "system" volume. A machine has, and needs, just the one system volume. All installed operating systems share it.
A machine can have, in contrast, many "boot" volumes, containing the system programs, libraries, configuration files, and data files of individual operating systems.
(Just to add to the terminological confusion, this "boot" volume, as Microsoft calls it, is commonly known as the "root" volume on Unices and Linux, and is the volume that is mounted at /.)
On other, older, operating systems, that are not influenced by high-end server and workstation machines, there's no concept of separate "boot" and "system" volumes. OS/2, MS-DOS, PC-DOS, DR-DOS, and others lack this notion, because they were simply not designed for machines with advanced firmwares. However, operating systems that do incorporate the idea of separate "system" and "boot" volumes are now the norm for mainstream personal computers, rather than the rare exception for expensive high-end machines that they used to be.
In Windows NT, a separate system volume, distinct from the main operating system and from other volumes, is actually the default assumption, and has been all along. For example, per Microsoft KnowledgeBase article #301680, a bootable Windows NT 5.0 floppy disc was in reality only a system volume, relying upon the existence of a main operating system "boot" volume on the system's hard disc. The behaviour of the Windows NT 6.1 installer, which creates a system volume even on non-EFI machines, is merely a continuation of the existing Windows NT design philosophy from Itanium, MIPS, DEC Alpha, and other non-x86 non-PC/AT non-PC98 platforms, rather than something truly new.
Witness the EFI boot process, the ARC boot process, and how they lead into the Windows NT 6 boot process.
There are several other special volumes that one can find on a modern personal computer, in addition to an EFI System Partition. These are not tied to the firmware platform as the system volume is.
Boot managers like IBM Boot Manager, the TAU Boot Manager, and GRUB2 employ partitions of their own. They do so because the days in which a boot manager could happily operate exactly like a computer virus, sitting in unused space at the start of the disc, are long gone. (Good riddance to them!) Nowadays, modern properly designed boot managers for PC/AT and PC98 systems live in partitions of their own, dedicated to their use.
On Unices and Linux, such boot manager partitions are conventionally mounted at /boot when access to them is needed during normal system operation.
This partition usually exists on discs that have been formatted with the new EFI partitioning scheme, instead of the old MBR partitioning scheme. It is, in essence, Microsoft's way of reserving space for later use.
The old MBR partitioning scheme provided gaps between partitions, which could be used by operating systems and other softwares to hold metadata for logical volume management in relative safety — albeit that the system would topple like a house of cards if two programs each thought that they could get away with unilaterally appropriating "free" space for their own ends. The new EFI partitioning scheme does not allow for such gaps. But Microsoft Windows needs to have some spare disc space hanging around on a "basic" disc so that it can be later converted to a "dynamic" disc. The conversion involves adding various metadata structures to the disc.So the Microsoft Reserved Partition exists simply to claim such space for later use. The conversion utility looks for a Microsoft Reserved Partition, and slices off some or all of it to turn into the Microsoft LVM configuration data partition that describes the "dynamic" volumes on the disc.
This partition is created by x86 versions of Windows NT 6.1 and later. It is, essentially, a Poor Man's EFI System Partition, for machines that don't have EFI firmwares and don't have a true system partition. It contains the Microsoft Boot Manager and the Windows Recovery Environment, and it is the volume whose VBR is actually bootstrapped on systems with old PC/AT and PC98 firmwares.
On an actual EFI system, the Microsoft Boot Manager and other Microsoft "pre-boot" utility programs are in an /EFI/Microsoft/ directory in the EFI System Partition.
Since a proper EFI System Partition exists, there is no need for its Poor Man's equivalent.
The EFI System Partition is identified by its standardized type ID in the partition table. This Poor Man's equivalent is not. It has the type IDs of an ordinary Microsoft Data Partition. As such, Microsoft Windows recognizes it not by its partition type, but by its attributes. The System Reserved Partition is identified by being a primary partition, with type Microsoft Data, that has the "active" flag set on in its partition table entry. This is not a robust mechanism and suffers from several problems.
Although often confused with the (in Microsoft terminology) system partition, these partitions (sometimes known as "OEM partitions") are not the system partition. They are partitions supplied by the manufacturer of the machine that contain manufacturer-supplied tools for backup and emergency recovery of the machine. They have partition type codes in the partition table that designate them as manufacturer-specific partitions. Sometimes these partitions are intimately tied to the machine firmware.
One such partition, for example, is the so-called "HP TOOLS" partition on Hewlett-Packard laptop machines, that contains QuickLook and the HP System Recovery utility. This is not the system partition. (Neither is it, somewhat confusingly, the HP Service Partition, which is yet another volume still.) The EFI System Partition is marked by a standard type code in the partition table. Whereas the "HP TOOLS" partition is an otherwise entirely ordinary MS Data partition, formatted as FAT32. The laptop's firmware, when a particular key is pressed during Power-On Self-Test, does not execute the normal boot sequence but instead looks for a FAT32 MSData partition with the volume label "HP TOOLS", where it expects to find the various HP-supplied emergency recovery and other utilities in a known subdirectory. This is, naturally, a fragile and easily broken mechanism.
The advantages of a separate EFI System Partition (and of its Poor Man's equivalent for old PC/AT and PC98 systems, the System Reserved Partition, for both of which we use "system partition" in this section) are threefold.
Separation allows system administrators to make the system volume either read-only or even entirely inaccessible once the operating system is running, thus protecting the boot files from accidental damage. The system volume has to be explicitly mounted in order to make it accessible once the operating system is running, and can be mounted as read-only without impacting the read-write status of other volumes on the disc. If it is not mounted at all, the risk that it is accidentally written to is reduced. The only times that the system volume need be mounted, and written to, are when a new operating system is being installed, or the boot configuration is being adjusted. This eliminates the possibility that filesystem corruption would render the system unbootable because of damage to the boot files. If the system volume is not mounted, it isn't dirty, and it therefore isn't potentially in a part-updated state when a dirty shutdown (as resulting from a power loss, say) occurs.
This is why, in normal operation, Windows NT doesn't assign a drive letter to the EFI System Partition (or to the System Reserved Partition).
Separation allows the main operating system volumes to be formatted with a more complex filesystem format than the format used for the system volume. Firmwares don't contain filesystem drivers for every filesystem format under the sun. As a consequence of this, it is often mandatory that the system volume be formatted with a "least common denominator" filesystem format. For example: The EFI System Partition is required to be formatted with the FAT12, FAT16, or FAT32 filesystem format. This can be mounted and maintained by a variety of different operating systems and "emergency rescue" toolkits. Whereas a main operating system volume formatted with (say) the EXT3 filesystem format is only mountable and maintainable through the comparatively smaller set of operating systems and rescue toolkits that understand EXT3.
Finally, separation allows the main operating system volumes to reside on discs that the machine's firmware does not know about (such as on a SCSI discs where the SCSI host bus adapter's ROM firmware has been disabled), on areas of discs 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 discs that the machine's firmware doesn't provide the facility for booting from (such as secondary disc units). The system volume in such cases is a small partition that is accessible by the machine's firmware, containing just enough to get the kernel and its own DASD drivers up and running, with the main operating system volume elsewhere.
Erik B. Andersen noted in 2001 that back when the Linux operating system loaders couldn't see the parts of any disc beyond the 1023rd cylinder, it was common practice to have a separate system volume, containing the boot loader and the kernel image, below the 1024 cylinder line.