2

According to https://superuser.com/a/1081043/380318 there is no such concept as an "active partition" when using GPT.

AFAIK with MBR partitioning, some minimal code in the MBR looks for an "active partition" and executes some boot code in that partition.

When GPT does no longer have that concept of an "active partition", how is the operating system to boot determined then?

Background

After some OS patch update the system didn't boot with message "no operating system found", and I had to reinstall the boot loader. So I'm wondering what might have damaged the boot mechanism for that message to appear.

Maybe I should add that the machine was running under VMware, and I'm not administrator of the VMware configuration. Possibly some "BIOS update" in VMware might have caused the problem, but it only came apparent when the OS was rebooted.

I can't change the setting, but I looked up that the firmware start option is set to "BIOS (recommended)".

The bootloader in effect is GRUB2, and when the system boots I see to partitions on sda, but none of them having the "active flag":

  1. "BIOS boot" (8MB)
  2. "Linux filesystem" (24G)

Maybe these facts make the situation even more complex:

There are two unpartitioned "raw" disks, and there is a bootable medium (DVD image) currently attached that has a MBR label, an EFI (type 0xef) partition and a hidden (type 0x17) partition that is marked active.

Possibly at the time of boot failure that image was not connected.

U. Windl
  • 943

2 Answers2

4

It depends:

  • For pure EFI boot, the firmware NVRAM holds "boot entries" that directly point to a specific partition by its GPT PARTUUID, and to a specific file within that partition. Run efibootmgr (with the -v option on older versions) to see the currently stored NVRAM entries.

    This is stored entirely in NVRAM, not on the disk itself – all boot entries disappear when the firmware settings are reset, or when the NVRAM ("CMOS") is cleared for some reason, and sometimes the firmware will remove "stale" boot entries if it can't find the corresponding partition (e.g. due to the disk being temporarily removed).

    (Multiple boot entries can be "active" at once (including multiple files within the same partition); most EFI implementations offer a menu to choose from them like you would choose from bootable disks. See section 3 of the specification.)

  • For EFI boot from removable disks (or in situations where the NVRAM has no working boot entries), the firmware scans all partitions for a filesystem that it recognizes, then tries to boot a file from the fixed path \EFI\Boot\Boot<arch>.efi (e.g. BootX64.efi); see table.

    This process always uses the first partition that has such a file. The partition's "type GUID" doesn't necessarily affect the process – firmware may scan all partitions regardless of type. (For removable disks, though, the specification actually requires exactly one EFI partition.) It is probably safe to assume that the firmware will scan in partition-table order and will stop looking after the first match.

    While some operating systems install a copy of the bootloader at this location – allowing EFI boot to continue working in case the NVRAM boot entries disappear – not all of them do. For example, GRUB2 does not install itself at bootx64.efi unless specifically told to treat the disk as --removable.

In BIOS boot mode, even if the disk is GPT-partitioned, the initial boot code still lives at the same location in the "protective MBR" and still proceeds in the same way as with pure MBR disks:

  • For BIOS-style boot from a GPT disk using Syslinux, the Syslinux "GPT compatible" MBR uses a mechanism identical to the active bit. Each partition in GPT has 64 flag bits (0–63) associated with it; bit 2 is what Syslinux uses as the "Legacy BIOS bootable" flag.

    You can set the GPT partition attributes through gdisk "extra functionality" menu.

  • For BIOS-style boot from a GPT disk using GRUB… well, GRUB never cared about "active" partitions or their VBRs to begin with – its MBR instead loads the GRUB kernel from a hard-coded start location (which is written to the MBR at grub-install time).

    On GPT disks, the GRUB kernel is installed to a partition with a special type GUID (rather than being stashed in-between partitions), but only grub-install cares about this – the GRUB MBR still loads the kernel from a fixed LBA.

  • It is also possible to have a "hybrid" disk which is normally GPT-partitioned, but its protective MBR has an actual partition entry with the "active" flag pointing at the desired location (instead of the usual protective entry covering the whole disk), allowing GPT-unaware boot sectors to boot from a GPT disk.

grawity
  • 501,077
0

The concept of an "active partition" means that a partition is selected from which the boot loader is read. If there are multiple OS installations, their respective boot loaders will be installed in their respective partitions, so the partition table is used to allow co-installation.

With EFI, the boot loader is a file inside an FAT file system, and co-installation is managed by reserving space in the FAT. This removes the size limit for the boot loader and allows more sophisticated methods of looking for the next stage files, so the "active partition" mechanism is no longer needed.

Basically, this has always been a crutch, because the partition boot loader only has a few hundred bytes of code, and needs to reliably select the correct partition to continue from, even if there are multiple valid candidates, so the MBR loader that selects a partition to boot from will pass down this information.

Modern systems often have additional layers like encryption, redundancy and volume management between the harddisk and the actual file system, so it is quite likely that the early boot stages are completely unaware of where the next stage actually is, so instead of a single flag attached to a partition, there is now a command line given to the boot loader, and the option to load a configuration file from the ESP.

Switching between multiple bootloaders is the task of the BIOS, which keeps a list of boot menu entries in NVRAM. Only the bootx86.efi or bootx64.efi file can be used without registration, this is how removable media boot.

Simon Richter
  • 3,105