On 7/20/2016 3:34 PM, Chris Murphy wrote:
On Sat, Jul 16, 2016 at 3:57 PM, John Andersen <jsamyth@gmail.com> wrote:
Building a new mini-server on a Gigabyte Motherboard (GA-J1900N-D3V)that has both Legacy and UEFI support. Will maybe have software raid mirrored drives, two network interfaces, and handle mail and firewall/routing.
OK small problem because you want to do mirrored drives:
UEFI puts the bootloader on a FAT32 volume called the EFI System partition. The problem is that other than firmware RAID, there is no way right now to properly keep the ESP on all member drives in sync as bootloader configuration stuff changes.
What *should* be true, and someone ought to check since I'm too lazy to do it right now:
- Each ESP should be created on each selected device for installation automatically (I think it's perverse to ask the user to create bootloader volumes)
- Each ESP should be populated with all necessary bootloader files such as shim and grubx64.efi.
- Each ESP should have a static, immutable, grub.cfg whose sole purpose is to find the "real" grub.cfg. It can do this by using mduuid= to find and assemble the RAID, and then search for a volume UUID to find an ext4 or XFS file system, where the grub.cfg is found. On Btrfs, GRUB understands raid levels 0, 1 and 10 by the Btrfs volume UUID, nothing special is needed to find the real grub.cfg. That 2nd grub.cfg is the one that's modified whenever bootloader configuration changes happen like kernel additions/deletions. That way there is a single real grub.cfg, which is replicated by software RAID, no tricks. And it means we don't need fancy ways to keep every grub.cfg on the ESP modified.
This is the way Ubuntu does it, last time I checked. It is not the way Fedora does it on UEFI, there it's broken because the real grub.cfg only exists on the ESP and it is never sycned.
- Do away with this idiocy of persistently mounting the EFI system partition. It shouldn't be mounted let alone at /boot/efi. No other modern OS keeps the bootloader volume mounted all the time. There's no good reason it should be done on Linux either.
Anyway, depending on whether opensuse on UEFI puts the grub.cfg, determines if this works out of the box or not. I suspect openSUSE does this per upstream GRUB, where grub.cfg is always at /boot/grub (or /boot/grub2 depending on distro specific naming) rather than on the ESP.
Note for systemd-boot/gummiboot users, upstream considers the only supportable way to do RAID booting is with proprietary firmware RAID, which is rather annoying. I'd really rather see the various file system GRUB modules put into EFI file system wrappers, so any EFI boot loader (really it's a boot manager but...) can just understand any file system that GRUB already supports. And GRUB, as overly complicated as it can be, is pretty badass when it comes to recognizing almost anything: it'll even find grub.cfg, the kernel, and initrams, on a *degraded* raid6, so long as the firmware recognizes all the remaining drives in the pre-boot environment. It's pretty remarkable how well supported these things are.
Not really related to the UEFI part, but the mirroring part, if you want something that's stable and mature, pick mdadm RAID, or as a 2nd option LVM RAID. Don't do Btrfs RAID and expect it to work degraded for rootfs, because it doesn't. That work isn't done yet, and while your data is safe, you will not be able to boot without a lot of esoteric knowledge.
Thanks Chris. You'd be surprised how hard it is to dig up this sort of information. I've been running mdadm Raid since the 90s, although often I have used an additional device to boot from (since booting from mdadm was problematic in those early days.) I might just stick with Legacy ad nobody has made a convincing case that I have anything to gain by doing it over. Thx. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org