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 "system" volume (a.k.a. "system partition") when it is bootstrapped?
This is the Frequently Given Answer to such questions. (How operating systems determine the location of the boot volume is a different Frequently Given Answer, note.)
When an operating system is bootstrapped it must decide which volume is to be the system volume. There are two basic ways in which operating systems do this:
The system volume is a true system volume, and the operating system simply looks for it by its ID in the partition tables of all partitionable discs.
The system volume is a Poor Man's equivalent, and the operating system uses a not very robust mechanism to locate it.
The ARC System Partition and the EFI System Partition
are true system volumes, mandatory on systems with ARC or EFI firmwares,
and reserved to the platform.
The location of the ARC System Partition is designated by the value
SystemPartition variable in the ARC firmware environment
The location of the EFI System Partition is simply read from the partition table.
The UEFI Specification specifies that the EFI System Partition have a particular, standard, type ID. So locating it involves reading the partition tables of all partitionable discs, and looking for partitions with that ID. Version 2 of the specification defined a "hidden" attribute, so that in cases where several discs on a system have an EFI System Partition, all bar the one that the system administrator intends to be the system partition for that machine can be marked "hidden", and will not be recognized as EFI System Partitions.
The same simple procedure for locating an EFI System Partition thus applies to everyone: to the EFI firmware itself, to operating system boot loaders, and to utility programs that deal with the system partition.
For old machines with PC/AT and PC98 firmwares, Microsoft provides a Poor Man's equivalent to the EFI system partition and the ARC System Partition: the System Reserved Partition. This doesn't have a standard type ID for the partition table. It doesn't have well defined, standard, contents, such as the standard directory structure of the EFI System Partition; nor even a standard identifier like a well-known volume label. In fact, it's just another Microsoft Data Partition as far as pretty much everything is concerned.
Microsoft tools such as Microsoft Windows' Disc Management identify the System
Reserved Partition by relying upon
the "active" attribute for partitions
that is used for the old PC/AT and PC98 bootstrap process. The System
Reserved Partition is defined as being a Microsoft Data Partition that is a
primary partition with the "active" attribute.
The "System" flag displayed by Microsoft Windows' Disc Management, and by the
list partition command in Microsoft's
diskpart, thus isn't a real partition table attribute
that is stored on disc. It's a marker in the user interface for the
volume that the tool has decided is the system volume today.
This mechanism for locating the System Reserved Partition isn't a very robust one, it suffering from several problems:
If one has a boot manager installed, then the boot manager's own partition will be marked with the "active" attribute, otherwise it couldn't be startable. Since only one partition on a disc may be "active"/"startable" (IBM's term for active.) at a time, the System Reserved Partition will not be marked as "active", it will look like just an ordinary Microsoft Data Partition; and Disk Management will not find the "system" partition at all.
Worse still, if the boot manager's own partition happens to have a recognizable filesystem format, such as FAT or NTFS, Microsoft's identification scheme will go seriously awry, mis-identifying the boot manager's partition as the "System" partition. Microsoft's tools will look in the wrong place for the BCD file, which is the database that controls the operation of Microsoft's Boot Manager. (Microsoft's tools work on the basis that the BCD file is always on the system partition — EFI or Poor Man's.) Hence it will be difficult to adjust the configuration of Microsoft's Boot Manager.
The system partition — EFI or Poor Man's — is where Microsoft's own Boot Manager is stored. If Microsoft's Boot Manager on one System Reserved Partition chains to another System Reserved Partition (on a second disc, say) or to an instance of Windows where the system and boot partitions have been (unwisely) combined at installation time, then Microsoft Windows' Disc Management and other tools will always find the first system partition and not the second. The tools to update the Boot Configuration Database will again find the wrong BCD and update the wrong things.
If one installs Windows, and one already has a Poor Man's system partition, then one must always choose to use that same single system partition with every other installation of Windows on that machine. Having multiple Poor Man's system partitions will not work correctly.
Microsoft doesn't recognize the "active" flag in EFI partition tables. An "active" flag, for machines with EFI-partitioned hard discs but no EFI firmware, was defined in revision 2.3.1 of the UEFI Specification. Microsoft's tools don't recognize this flag, only recognizing the "active" flag in PC/AT MBR partition tables. So it's impossible to have a System Reserved Partition on an EFI partitioned disc that will be recognized by Microsoft Windows' Disk Management, installation program, et al..
The good news is that one can, of course, have a true EFI System Partition on such a disc instead of making do with its Poor Man's equivalent. The bad news is that in order to bootstrap Microsoft Windows from such a disc, or even to install it in the first place, one needs to have EFI firmware. Microsoft erroneously conflates having EFI firmware with having a hard disc partitioned with the EFI partition table, even though there in fact are defined, standardized, mechanisms for booting partitions on EFI-partitioned discs in the old PC/AT and PC98 way, on machines that don't have EFI firmware.