Ok, EFI + GPT is the way to go (until Coreboot takes over lol)... So, there MUST be a way to add "/boot/efi" on top of a raid1, right?!

Hey guys!

I finally decided to let the BIOS go… And the MBR too! RIP :smile:

So, I’m now using EFI and GPT, but, Grub is still around.

Maybe EFI Stub will be next (year by default with 20.04?) and bye bye Grub too.

I’m surprised about how hard is to build a simple Linux RAID1 for “/boot/efi” on top of two identical disks.

Right now, I made the move to EFI+GPT but, I have to do the following (ugly workaround) to be able to boot with my two SSDs under the new scheme:

After first boot (of a physical SuperMicro Machine deployed with Ubuntu 18.04 by MaaS):

umount /boot/efi
dd if=/dev/sda1 of=/dev/sdb1
grub-install --recheck /dev/sdb
mount /dev/sda1 /boot/efi

This way, I can finally boot with two disks when using EFI+GPT but, this can’t be a final solution for the next ~10 years… lol

NOTE: I guess that I can just copy files between the 2 EFI vfat partitions, instead of using dd and duplicating the file system UUID (which sounds bad).

I still have a very simple GPT partition scheme, as follows:

/dev/sda:
1 MiB Free Space at the beginning
256 MiB for /boot/efi @ /dev/sda1
240 GiB for /dev/sda1 @ /dev/md0 as device 1
1 MiB Free Space at the end

/dev/sdb:
1 MiB Free Space at the beginning
256 MiB for /boot/efi-2 @ /dev/sdb1
240 GiB for /dev/sdb1 @ /dev/md0 as device 2
1 MiB Free Space at the end

So, “/dev/md0” is for my ext4 root file system.

I was googling about “boot efi mdmad” and I found out that, with “mdadm --metadata=0.9 (or maybe 1.0)”, it’s possible to have the “/boot/efi” on top of Linux RAID1! Like “/dev/md0 for /boot/efi” and then, “/dev/md1 for /”.

However, I also was reading somewhere that there might be things that will eventually, write things directly to the partition without Linux Raid being loaded, then, it will cause problems to sync when Linux boots up. Not sure about how to replicate this in a lab.

I also read that the “EFI guys” decided to leave the redundancy completely to the hardware vendors! Sure, with raid1 via hardware, the “/boot/efi” will end up on a raid1 anyway BUT, again, there must be a way to do this via software!

I would not mind to have something like “update-grub” being able to manage “/boot/efi-1 @ /dev/sda1” and “/boot/efi-2 @ /dev/sdb1”!

What are you guys doing to solve this?! Not making the move to EFI / GPT? lol

What I found about the topic on the Interwebs:

Might be a good idea to try to implement the above idea, using this:

http://caribou.kamikamamak.com/2015/06/26/custom-partitioning-with-maas-and-curtin-2/

https://outflux.net/blog/archives/2018/04/19/uefi-booting-and-raid1/

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815569

This ZFS using the WHOLE disk looks crazy! I’m actually surprised that this system even booted in my gaming PC! There is no “/boot/efi”, no “biosgrub”:

https://github.com/zfsonlinux/pkg-zfs/wiki/HOWTO-install-Ubuntu-18.04-to-a-Whole-Disk-Native-ZFS-Root-Filesystem-using-Ubiquity-GUI-installer

Well, since I moved to EFI+GPT, why not get rid of Grub, mdadm, ext4, and move to a ZFS root! These days, two things that I’m interested, MaaS and ZFS, likes GPT (Also EFI “likes” GPT)!