How Hardware RAID Presents GPT Disks to UEFI

Hardware RAID controllers act as an abstraction layer between physical drives and the host system, creating a virtual disk that the Unified Extensible Firmware Interface (UEFI) detects as a single, contiguous physical block device. By leveraging onboard UEFI drivers and protocols, the controller translates the underlying multi-drive array into logical block addresses (LBAs) where a standard GUID Partition Table (GPT) structure resides. This article explains the architectural handshake between the RAID controller, UEFI firmware protocols, and GPT structures that make modern enterprise boot operations possible.

The Virtual Disk Abstraction Layer

A hardware RAID controller manages physical drives (SAS, SATA, or NVMe) via its proprietary processor and cache memory. The firmware inside the controller organizes these raw disks into one or more RAID arrays (such as RAID 1, 5, 10) and slices them into one or more Logical Unit Numbers (LUNs), commonly called virtual disks (VDs).

To the host platform, the physical composition—spindle speeds, striping patterns, parity blocks, and drive counts—is completely hidden. The controller abstracts this complexity into a flat, linear array of sectors indexed from Logical Block Address 0 (LBA 0) up to the maximum accessible sector of the configured virtual capacity.

UEFI Driver Integration and Device Path Protocols

During the early Power-On Self-Test (POST) phase, the platform UEFI firmware initializes system buses (such as PCIe) and queries expansion ROMs. The hardware RAID controller provides its own UEFI driver, typically adhering to the UEFI Driver Model.

  1. Driver Binding: The UEFI firmware binds the controller’s UEFI driver to the PCIe handle associated with the RAID card.
  2. Handle Creation: The RAID driver scans its configured virtual disks and installs an instance of the EFI_BLOCK_IO_PROTOCOL and EFI_DISK_INFO_PROTOCOL for each virtual disk onto a new child device handle.
  3. Block IO Interface: The EFI_BLOCK_IO_PROTOCOL exposes basic sector-level read and write primitives (ReadBlocks, WriteBlocks, FlushBlocks) to the UEFI environment. UEFI does not need to understand RAID parity or striping; it simply issues block read and write requests to the handle representing the virtual disk.

Layout of GPT on the Virtual Block Device

Once the EFI_BLOCK_IO_PROTOCOL is published, the UEFI core partition management driver (PartitionBusDriver) attempts to detect a valid partition scheme on the device. Because the virtual disk behaves like any other standard storage drive, GPT structures can be mapped directly to it:

  • LBA 0 (Protective MBR): A legacy MBR sector is positioned at LBA 0 to prevent legacy partitioning tools from misidentifying and overwriting the array.
  • LBA 1 (Primary GPT Header): The primary GPT header defines the disk GUID, header size, CRC32 checksums, and the starting LBA of the Partition Entry Array.
  • LBAs 2–33 (Partition Entries): This space contains individual partition entries, including the partition type GUIDs, unique partition GUIDs, and sector ranges.
  • Backup GPT Structures: Duplicate partition tables and the secondary GPT header are stored across the final LBAs of the virtual disk's accessible space.

When the RAID controller receives a read request for LBA 1, its internal firmware intercepts the command, determines which physical drive and sector holds that data according to the array's stripe map, retrieves the data, and returns it to the UEFI environment as a standard 512-byte or 4096-byte block.

Locating the EFI System Partition and Booting

After parsing the GPT tables on the virtual disk, the UEFI firmware discovers the EFI System Partition (ESP), recognized by its unique type GUID (C12A7328-F81F-11D2-BA4B-00A0C93EC93B).

The UEFI system then attaches the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL to the ESP handle, allowing the firmware to navigate the partition's FAT32 file system. The firmware loads the targeted operating system bootloader (such as bootx64.efi), which executes while still relying on the RAID controller's UEFI driver for disk reads. Once the operating system kernel initializes, it loads its own high-performance, OS-specific storage driver to take over communication with the RAID controller, finalizing the transition out of the UEFI environment.