8 ms·

You can have multiple EFI system partitions on the same disk. The Windows installer does not like this, but it won't affect the actual boot process after it's i

You can have multiple EFI system partitions on the same disk. The Windows installer does not like this, but it won't affect the actual boot process after it's installed. The Linux distros I've seen don't mind at all, since /boot/efi is usually mounted by UUID in your fstab.

ComputerGuru 9y ago
No you really can't. There can only be one ESP and that's in the spec. You can have multiple partitions each assigned as /boot for a different OS, but there can only be one ESP which is used by the firmware to store its settings, etc. The EFI spec [0] is officially silent about the presence of multiple EFI system partitions on non-removable hard drives, but explicitly forbids multiple ESPs on removable disks, per §11.2.1.3: > For removable media devices there must be only one EFI system partition, and that partition must contain an EFI defined directory in the root directory But in practice, Bad Things (TM) happen if you have more than one ESP on the boot disk. An ESP isn't just a partition mounted to /boot or one that has bootfiles or a bootloader, it's (in practice) a FAT32 partition that has a different filesystem ID, in particular, the magic GUID {C12A7328-F81F-11d2-BA4B-00A0C93EC93B} I'm the author of EasyBCD and numerous other boot utilities and spent a hell of a lot of a time (too much time) researching and working around the various UEFI deficiencies in various desktops, laptops, firmware implementations, bootloaders, and operating systems. Here's a Microsoft bulletin on the matter: https://support.microsoft.com/en-us/help/2879602/unable-to-boot-if-more-than-one-efi-system-partition-is-present https://support.microsoft.com/en-us/help/2879602/unable-to-b... (long story short, the Windows kernel may bork if it runs into multiple ESPs and fail to load. Our bootable boot repair CDs wouldn't boot into the WinPE kernel because the disk management subsystem would hit an infinite loop in certain cases (not this case). We ended up switching to FreeBSD for our live CDs and writing our own disk repair subroutines to get around cases where even Windows live CDs wouldn't boot so we could fix the customer's PCs) Linux may not hang if there are multiple ESPs (except it sometimes does), but it certainly doesn't support treating multiple partitions as the ESP simultaneously, either: https://superuser.com/questions/688617/how-many-efi-system-partitions-esp-can-a-computer-have https://superuser.com/questions/688617/how-many-efi-system-p... [0]: https://www.intel.com/content/dam/doc/product-specification/efi-v1-10-specification.pdf https://www.intel.com/content/dam/doc/product-specification/...
- danudey 9y ago
  > I'm the author of EasyBCD Thank you! Also, maybe you can answer this: what's the 'correct' way for systems to handle multiple disks with an ESP partition each? In other words, if I'm using software RAID and clone the partition tables, should I assume that the UEFI firmware will default to the first disk's ESP, or is that set when boot configurations are updated?
  - ComputerGuru 9y ago
    > Thank you! No problem! Glad you found it useful. > if I'm using software RAID and clone the partition tables, should I assume that the UEFI firmware will default to the first disk's ESP With regards to your question: I guess it depends on what you mean by "software" raid. Enabling RAID in the "BIOS" (that term has now come to encompass the firmware configuration utility for UEFI motherboards as well) (typically Intel "RST" rapid storage RAID, nvraid for nVidia chipsets (less common these days), AMD raid, etc.) is 100% software raid, which does nothing more than make the BIOS aware of its presence (and toggle a flag so that RAID drivers can find the array) so that it doesn't run into exactly the problem you describe, i.e. it'll be aware of the cloning at a level higher than the UEFI bootloader init, which will only see the virtual raid volumes rather than their independent components. Now if you put all that aside and are just wondering how it selects in the presence of multiple ESPs on different devices that made it through to the bootloader layer: the UEFI "BIOS" doesn't know (and can't know) since UEFI has done away with the concept of drive order entirely. You can set the order manually in the "boot device order" section (typically on the boot tab in the BIOS config) or choose the one-time boot target via F11 or F12 at the boot-up screen, but otherwise it's just a tossup and the BIOS is free to chose any local device's ESP as "the" ESP. In practice, it'll choose one of the SATA drives (assuming a mix of other interfaces such as NVMe), either the first to respond (not an issue with SSDs which respond quickly, but magnetic media takes time to spin up if you're still using old HDDs) or the first to be enumerated by the SATA controller (which has its _own_ firmware and its own level of abstraction and logic (and bugs) and whatnot). BUT in the case of software raid, that RAID 0 should actually extend to the GPT itself and both drives will have the same content and mirrored ESPs, so in practice it won't matter which is loaded (so long as your OS doesn't do anything stupid like try to modify the on-disk structure before loading the RAID-aware storage driver. I've seen BIOSes that "helpfully" store a copy of the current firmware to a locally-attached disk with an understandable partition format (so FAT32) that ended up breaking a RAID because the drives were no longer in sync because the BIOS wasn't aware of the mirror).
cmurf 9y ago
From my reading of the UEFI spec, much of the language assumes one EFI system partition per device, for example see the capsule updating language on page 262 of the version 2.4 spec. The directory \EFI\UpdateCapsule is checked for capsules only withing the EFI system partition on the device specified in the active boot option determine by reference to BootNext variable or BootOrder variable processing. and later The system firmware is not required to check mass storage devices that do not contain boot target that is highest priority for boot nor to check a second EFI system partition not the target of the active boot variable. There's no accounting for two ESP's for one device, and how to resolve the ensuing ambiguity, which one is the primary one? Are you certain Windows updates distinguish between two EFI system partitions, should an update need to update the Windows bootloader or its config?
- ComputerGuru 9y ago
  Actually, it's even worse than that. As the BIOS no longer has a concept of "active device," multiple ESPs on separate devices are also a problem; the user would have to actively pick the one to load at boot time via the non-EFI "boot device menu" at the boot screen.

ComputerGuru 9y ago

No you really can't. There can only be one ESP and that's in the spec. You can have multiple partitions each assigned as /boot for a different OS, but there can only be one ESP which is used by the firmware to store its settings, etc. The EFI spec [0] is officially silent about the presence of multiple EFI system partitions on non-removable hard drives, but explicitly forbids multiple ESPs on removable disks, per §11.2.1.3: > For removable media devices there must be only one EFI system partition, and that partition must contain an EFI defined directory in the root directory But in practice, Bad Things (TM) happen if you have more than one ESP on the boot disk. An ESP isn't just a partition mounted to /boot or one that has bootfiles or a bootloader, it's (in practice) a FAT32 partition that has a different filesystem ID, in particular, the magic GUID {C12A7328-F81F-11d2-BA4B-00A0C93EC93B} I'm the author of EasyBCD and numerous other boot utilities and spent a hell of a lot of a time (too much time) researching and working around the various UEFI deficiencies in various desktops, laptops, firmware implementations, bootloaders, and operating systems. Here's a Microsoft bulletin on the matter: https://support.microsoft.com/en-us/help/2879602/unable-to-boot-if-more-than-one-efi-system-partition-is-present https://support.microsoft.com/en-us/help/2879602/unable-to-b... (long story short, the Windows kernel may bork if it runs into multiple ESPs and fail to load. Our bootable boot repair CDs wouldn't boot into the WinPE kernel because the disk management subsystem would hit an infinite loop in certain cases (not this case). We ended up switching to FreeBSD for our live CDs and writing our own disk repair subroutines to get around cases where even Windows live CDs wouldn't boot so we could fix the customer's PCs) Linux may not hang if there are multiple ESPs (except it sometimes does), but it certainly doesn't support treating multiple partitions as the ESP simultaneously, either: https://superuser.com/questions/688617/how-many-efi-system-partitions-esp-can-a-computer-have https://superuser.com/questions/688617/how-many-efi-system-p... [0]: https://www.intel.com/content/dam/doc/product-specification/efi-v1-10-specification.pdf https://www.intel.com/content/dam/doc/product-specification/...

danudey 9y ago
> I'm the author of EasyBCD Thank you! Also, maybe you can answer this: what's the 'correct' way for systems to handle multiple disks with an ESP partition each? In other words, if I'm using software RAID and clone the partition tables, should I assume that the UEFI firmware will default to the first disk's ESP, or is that set when boot configurations are updated?
- ComputerGuru 9y ago
  > Thank you! No problem! Glad you found it useful. > if I'm using software RAID and clone the partition tables, should I assume that the UEFI firmware will default to the first disk's ESP With regards to your question: I guess it depends on what you mean by "software" raid. Enabling RAID in the "BIOS" (that term has now come to encompass the firmware configuration utility for UEFI motherboards as well) (typically Intel "RST" rapid storage RAID, nvraid for nVidia chipsets (less common these days), AMD raid, etc.) is 100% software raid, which does nothing more than make the BIOS aware of its presence (and toggle a flag so that RAID drivers can find the array) so that it doesn't run into exactly the problem you describe, i.e. it'll be aware of the cloning at a level higher than the UEFI bootloader init, which will only see the virtual raid volumes rather than their independent components. Now if you put all that aside and are just wondering how it selects in the presence of multiple ESPs on different devices that made it through to the bootloader layer: the UEFI "BIOS" doesn't know (and can't know) since UEFI has done away with the concept of drive order entirely. You can set the order manually in the "boot device order" section (typically on the boot tab in the BIOS config) or choose the one-time boot target via F11 or F12 at the boot-up screen, but otherwise it's just a tossup and the BIOS is free to chose any local device's ESP as "the" ESP. In practice, it'll choose one of the SATA drives (assuming a mix of other interfaces such as NVMe), either the first to respond (not an issue with SSDs which respond quickly, but magnetic media takes time to spin up if you're still using old HDDs) or the first to be enumerated by the SATA controller (which has its _own_ firmware and its own level of abstraction and logic (and bugs) and whatnot). BUT in the case of software raid, that RAID 0 should actually extend to the GPT itself and both drives will have the same content and mirrored ESPs, so in practice it won't matter which is loaded (so long as your OS doesn't do anything stupid like try to modify the on-disk structure before loading the RAID-aware storage driver. I've seen BIOSes that "helpfully" store a copy of the current firmware to a locally-attached disk with an understandable partition format (so FAT32) that ended up breaking a RAID because the drives were no longer in sync because the BIOS wasn't aware of the mirror).

cmurf 9y ago

From my reading of the UEFI spec, much of the language assumes one EFI system partition per device, for example see the capsule updating language on page 262 of the version 2.4 spec. The directory \EFI\UpdateCapsule is checked for capsules only withing the EFI system partition on the device specified in the active boot option determine by reference to BootNext variable or BootOrder variable processing. and later The system firmware is not required to check mass storage devices that do not contain boot target that is highest priority for boot nor to check a second EFI system partition not the target of the active boot variable. There's no accounting for two ESP's for one device, and how to resolve the ensuing ambiguity, which one is the primary one? Are you certain Windows updates distinguish between two EFI system partitions, should an update need to update the Windows bootloader or its config?

ComputerGuru 9y ago
Actually, it's even worse than that. As the BIOS no longer has a concept of "active device," multiple ESPs on separate devices are also a problem; the user would have to actively pick the one to load at boot time via the non-EFI "boot device menu" at the boot screen.