When installing Linux with software MD RAID, there is a temptation to use a partitionable software RAID, to reduce maintenance burden for the case of failed drive replacing and repartitioning. In this case one creates an array out of raw unpartitioned devices, and the partitions it.

TL;DR: don't fall for this temptation. The supposed reduced maintenance burden here is bogus for most practical cases.

Problems arise when one desires to also boot from this array. Now, not only Linux must understand the structure on disks, but system firmware too. Firmware, on the other hand, won't interpret the MD superblock (metadata) which describes the shape of the array. Disks must look “normal” to the firmware even without metadata interpretation.

The obvious first consequence is that we are bound to RAID1 (mirror), because this is the only case which stores data on disks as is, on all components. But there's more.

There are two types of MD superblocks (blue):

• version 0.9 (deprecated) and version 1.0 are placed near the end of the component device (regardless of the array size!), not farther than 128KiB to the end.
• version 1.1 is placed at the beginning of component devices
• version 1.2 is placed at 4KiB past the beginning of component devices

If the full device capacity is used (when e.g. all component devices are the same size), the size of a data area (green) is slightly smaller, between 64KiB and 128KiB less than device size. This area in case of RAID1 would be the virtual disk size.

Now let's observe how partition tables look from the point of view of the firmware who doesn't interpret the MD metadata.

MBR partition table contains the bootloader code for “legacy” boot; it is 512 bytes stored in the very first sector of the device (LBA 0), so if we partition our array, the very beginning of the data area (green) will be the MBR. The partition table permits to partition only first 2TiB of the device, because it uses 32-bit signed integers to specify first and last sectors of the partition.

• v0.9 or v1.0: the partition table and the bootloader code is in its expected place, partition locations in the table are correct. The last partition never covers the few thousands of sectors at the end, which is fine. The disk can contain “extended” partition (the trick in the MBR partitioning scheme which allows having more than 4 partitions); this structure will also fully possible.
• v1.1: the place where MBR is expected to be found we see the MD superblock which looks like garbage to the firmware. This disk structure is invalid and disk is not bootable.
• v1.2: normally there will be no MBR in the place where firmware expects it, but it is possible to carefully craft a special MBR with the bootloader in such a way so it properly points to the really existing partitions needed to boot, and place it into the free use area (orange).

GPT partition table is stored within the first 34 sectors (occupying 17408 bytes¹⁾), and the last 33 sectors (16896 bytes²⁾), so again, if we partition the array, it occupies the very beginning and very end of the data area. The first sector (LBA 0) is the protective MBR header which can contain the bootloader code for the “legacy” boot; it also can be the normal MBR defining the same partitions as are defined in the GPT (only four of them; this time the extended partition trick won't work). GPT is the only scheme that enables the UEFI boot, which also requires the existence of special partition with GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B, called EFI System Partition containing the EFI Executable file with the bootloader code. GRUB needs a place for its stage 1.5 loader, which is not possible to place after the partition table, but it can be placed into the special partition with GUID 21686148-6449-6E6F-744E-656564454649, called BIOS boot, so it's possible to legacy boot from GPT disks.

• v0.9 or v1.0, GPT: the first GPT appears to be in its normal place, but the second copy of the GPT at the end is missing. (It is actually exists on the disk but not at the place firmware expects it to be, so it considers it to be non-existing). This disk partition table is invalid so not bootable. It is possible to craft yet another GPT copy at the very end of the device into “lost space” area, but
  1. that area might be not big enough to hold a GPT,
  2. the first GPT header contains the actual address of the header of the copy, and that would be the address of really existing “normal” copy, not the crafted one. So this structure will still be considered invalid. The protective MBR, however, can still be used to legacy boot.
• v1.1, GPT: no partition table copies appear on their usual places; the place where first partition table is expected to be found we see MD superblock. This is not bootable.
• v1.2, GPT: for the same reason as previous, it's not bootable. At first sight it might look like both places where GPT should appear are unused and we should be able to make it if we craft both copies with first one having correct pointer to the second one, but the GPT is much larger than 4KiB that is left for us in the free use area, and the lost space area at the end might be not big enough too. As in v1.2 MBR case, we can craft a special MBR with bootloader and put it into free use area, but that will only enable the legacy boot.

In addition to crafting the MBR where it's possible one will need to maintain it: update the bootloader code with system updates, manually clone in case of disk replacement, and update the partition table if things important for boot change. This MBR can also provide false hints; it's a dirty hack so it's dangerous. For the MBR, the 4KiB of space v1.2 superblock gives is not enough to place GRUB stage 1.5 code, so another bootloader must be used. For GPT case the BIOS boot partition can't really be used to place GRUB code³⁾. All of this defeats the purpose of having partitionable RAID to reduce maintenance.

Here's a summary table:

In addition to these complications, UEFI specification provides no support for OS-managed software RAID, like MD. ESP must be a simple GPT partition.

So, partitiontable MD RAID actually provides easier maintenance for legacy boot systems with boot disk of less than 2TiB, only RAID1, and is impossible to boot from with UEFI. This kind of a setup is obsolete and very limiting.

What to do? Do not use partitionable RAID. Partition each disk separately into whatever scheme you decided (always use GPT for UEFI boot and for disks larger than 2TiB); create few small partitions required to boot (ESP or a BIOS boot and separate partition for /boot to build a RAID1 from). The rest of the space will be one big partition to hold software RAID of whatever level you want; you're not restricted to RAID1 anymore. LVM is superior to whatever partition table we considering, it can be placed upon this big MD RAID and used to manage volumes. You can also add additional layers: over the MD RAID goes LUKS for crypto, then there might be VDO for deduplication and compression, and now the LVM. Disk replacement will require partitioning the new disk into the same structure and re-installation of the bootloader (or re-creation the firmware boot entry), but all steps will be standard and obvious, and no dangerous configuration will be there. This is proper, robust and most flexible way to use Linux software RAID.