Learn RAID - Boot, Partitioning & OS Integration

#Introduction

Up to episode 10, your arrays only stored data. Episode 11 tackles something more complicated: how to make a system boot directly from RAID. Not every Linux component understands RAID — the bootloader, initramfs, and partition table each have their own limitations.

Common mistakes like using the wrong metadata or forgetting to update the initramfs make the system fail to boot with "unable to find root device". This episode breaks those problems down one by one: /boot on an array, GRUB, partition tables, and the encryption ordering. Let's start with /boot.

#/boot on an Array

#The Right Metadata for Boot

Not all metadata locations are compatible with the bootloader. To boot from an array, the metadata must be placed where GRUB can read it:

• Metadata 1.0 (at the end of the disk): most compatible with GRUB.
• Metadata 1.2 (at the beginning of the disk): newer, but some GRUB versions struggle.

sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 --metadata=1.0 /dev/sdb1 /dev/sdc1

The mdadm --create --metadata=1.0 command above places the superblock at the end of the partition, keeping the initial area available for the bootloader. For /boot, RAID 1 is the standard choice — boot doesn't need large capacity, but its redundancy is highly valued.

#Making Sure the initramfs Loads MD

After creating or changing an array, update the initramfs and boot configuration:

sudo update-initramfs -u
sudo update-grub

The update-grub output shows the new menu entries. Without update-initramfs -u, the kernel can fail to find the root because the initramfs doesn't know about the array yet.

#GRUB Integration with RAID

#GRUB and /boot on mdadm

GRUB 2 supports booting from RAID arrays with metadata 0.90 and 1.0. For root-on-RAID, GRUB loads the kernel and initramfs from /boot, then hands the root mount process over to the kernel, which is equipped with MD drivers in the initramfs.

sudo grub-install /dev/sdb
sudo grub-install /dev/sdc

The grub-install command must be run for every member disk, not just one, so the server can still boot if one disk dies. Install to whole disks (not partitions) according to your distro's configuration.

#Booting from a Degraded Array

The real test of boot resilience is when one member disk goes missing. With GRUB installed on all disks and metadata 1.0, the server should still boot even if one disk is dead. Do this test in the lab before production — not during an incident.

#Partitioning: GPT vs MBR

#Partition Tables on Arrays

In general, you write a partition table on the array device (/dev/md0) and create partitions inside it:

• MBR: classic, limited to under 2TB and a maximum of four primary partitions.
• GPT: modern, supports disks far beyond 2TB and nearly unlimited partition counts.

sudo parted /dev/md0 mklabel gpt
sudo parted /dev/md0 mkpart primary ext4 1MiB 100%

The parted mklabel gpt command creates a GPT partition table on the array, and mkpart creates one data partition. With GPT, partition sizes can exceed MBR's 2TB limit.

#When a Partition Table Is Needed

For a pure data array, a partition table is often unnecessary — the filesystem can be created directly on /dev/md0. A partition table is only useful if you want to separate several areas, for example placing LVM inside it. Always consider: does a partition add value, or just another layer?

#4K Alignment and Encryption

#Advanced Format Alignment

Modern disks use 4K physical sectors (Advanced Format). Partitions that aren't aligned to 4K boundaries cause every read-write operation to touch two sectors — wasting performance. Always start partitions at a multiple of 1MiB:

sudo parted /dev/sdb align-check optimal 1

The parted align-check optimal 1 output shows 1 aligned if the partition is aligned. This matters especially for RAID arrays whose stripes layer on top of disk sectors.

#Luks-on-raid vs Raid-on-luks

There are two ways to combine encryption and RAID:

• Luks-on-raid: the RAID is created first, then LUKS sits on top of /dev/md0. All disks are decrypted as one unit; you enter one passphrase for the whole array.
• Raid-on-luks: each disk is encrypted first, then combined into RAID. Every disk has its own LUKS; rebuilding onto a new disk requires re-encrypting and the same passphrase.

sudo cryptsetup luksFormat /dev/md0
sudo cryptsetup open /dev/md0 raid_crypt

The luksFormat /dev/md0 then open sequence opens a LUKS container on top of the array. The luks-on-raid approach is simpler and more common; raid-on-luks is more flexible for certain scenarios. We'll cover both in more depth in episode 14.

#Conclusion

Episode 11 tied RAID together with the operating system: placing /boot on an array with metadata 1.0, installing GRUB on all member disks, choosing GPT for large arrays, maintaining 4K alignment, and understanding the luks-on-raid versus raid-on-luks ordering.

Key takeaways:

• For boot, use metadata 1.0 or 0.90 on /boot to stay GRUB-compatible.
• Update initramfs and update-grub every time the array structure changes.
• Install GRUB on all member disks so the server still boots when one disk dies.
• GPT supports arrays above 2TB; MBR is limited and dated.
• Make sure partitions are 4K-aligned with parted align-check.
• Luks-on-raid is simpler; raid-on-luks is more flexible per disk.

In the next episode, episode 12, we'll discuss backup & disaster recovery — why RAID isn't a backup, combining RAID with ZFS or btrfs snapshots and remote replication, plus the reassemble procedure and rebuild ordering after partial failures. You'll learn to build layered defense.