Hello everyone,
I wanted to ask a feature request for MAAS regarding software RAID and to make UEFI reliable even when losing the boot disk.
Problem
In a scenario where hardware RAID is not available, software RAID is a viable solution to have a filesystem over multiple disks.
Especially on some servers where there is not always a hardware RAID controller over NVMe drives, or not without some serious limitations regarding performances.
Sadly software RAID cannot be used for UEFI/ESP partitions, but some works do exist to circumvent this issue : Subiquity is already able to handle multiple ESPs entries, and GRUB can update multiple UEFI partition at the same time without requiring any filesystem to be mounted locally.
But to make it works, this comes with some specific configuration to be done.
UEFI partition does require to be formatted to FAT32 but has another requirement from GPT’s partition type perspective, the partition itself should be EF00 as well since the UEFI of some manufacturers may refuse to read the partition otherwise. On top of this, GRUB will not list the partition as well.
Currently on MAAS on a freshly deployed server, the UEFI partition is formatted as a linux partition type 8300, where it should be EF00 :
ubuntu@node:~$ sudo sgdisk /dev/sda -p
Disk /dev/sda: 11721045168 sectors, 5.5 TiB
Model: ST6000NM0115-1YZ
Sector size (logical/physical): 512/4096 bytes
…
Total free space is 13421 sectors (6.6 MiB)Number Start (sector) End (sector) Size Code Name
1 2048 1951743 952.0 MiB 8300
2 1951744 3901439 952.0 MiB 8300
3 3901440 11721033727 5.5 TiB 8300
Solution from MAAS
It would be great if MAAS were to configure the UEFI/ESP partition appropriately to EF00 or at least if we had a way to precise the partition type. Then on top of this to be able to create another EF00 partition on other disks and then have GRUB to be enabled on all ESP partition.
Subiquity
Below can be found a configuration example from subiquity about to precise a partition’s type to EF00 and then enable it for Grub installation (Thanks to Yoshi Kadokawa for this info)
storage:
…
- device: vda
id: boot_efi_part
size: 512MB
type: partition
flag: boot
grub_device: true
wipe: superblock
partition_type: EF00
- device: vdb
id: backup_boot_efi_part
size: 512MB
type: partition
flag: boot
grub_device: true
wipe: superblock
partition_type: EF00
Workaround
For now, I have prepared a workaround to be applied after deploying a server for some customers, with the help of gdisk/sgdisk to change the partition type properly to EF00, and by reconfiguring GRUB to enable multi(here the OS drives are sda and sdb) :
change the partition 1 of sda and sdb to EF00 instead of 8300
sudo sgdisk /dev/sda -t 1:EF00
sudo sgdisk /dev/sdb -t 1:EF00
(optional) if not done, format the secondary partition to vfat
sudo mkfs.vfat /dev/sdb1
(optional) mount the /boot/efi with “nofail” to not block the boot if the primary disk disappears (LP#2024869)
sudo sed -E ‘s/vfat(\s+)defaults/vfat\1defaults,nofail/’ -i ./fstab
reconfigure grub and enable multiple partition updates
sugo dpkg-reconfigure grub-efi-amd64
