Hi On Friday 25 July 2014, Julian Andres Klode wrote: > On Fri, Jul 25, 2014 at 04:29:02AM +0200, Stefan Lippers-Hollmann wrote: [...] > > It would be nice if gummiboot would support installing its EFI loader > > to multiple EFI system partitions in order to gain failsafe support for > > RAID setups under UEFI. The attached patch allows (optionally) > > configuring multiple targets via GUMMIBOOT_EFI. > > I understand what you're trying to do, but my plan was to drop options, > not add some more. To be precise: Upstream only supports a single ESP > in both gummiboot and systemd. systemd provides a script called > kernel-install for installing kernels. I want to switch to that script. > (and that script is really primitive, and only supports configuring > the kernel cmdline or reading it from /proc/cmdline). > > Upstream mounts /boot/efi at /boot, so there's not much chance to > get support for multiple ESPs there. > > I'm not sure what I should do now.
I'm not married to any particular implementation (nor even bootloader),
my goal is merely to provide fallback bootoptions for UEFI systems in
a RAID-like fashion.
When booting in BIOS mode (CSM emulation), the situation is rather
simple. grub-pc has the option to embed its stage1/ stage1.5 between
(MSDOS-) partition table and the start of the first partition (or the
BIOS Boot partition/ 0xef02 for GPT respectively) of all installed
harddisks (via debconf selection of potential target disks).
Accordingly redundancy is provided for both the bootsector (stage 1/
stage 1.5) on each individual disk and the rootfs, /boot/ respectively,
on a RAID1 volume.
When booting in native UEFI mode, the situation is unfortunately a lot
more difficult.
- real hardware RAID, this might actually work if the hardware RAID
controller completely abstracts its RAID functionality from the UEFI
firmware and provides transparent support for UEFI and grub, so that
the EFI system partition (0xef00) is actually part of the RAID
volume.
Lacking a full-hardware RAID controller, I have not tested this.
- fake RAID/ BIOS assisted software RAID (e.g. dmraid/ Intel ISW).
While the UEFI firmware might, or might not - depending on the
actual firmware implementation, recognize an EFI system partition
(0xef00), at least wheezy's grub was not able to cope with a
sandy-bridge era Intel ISW fake RAID, neither via the ordinary
installation means, nor fully manually.
- Linux software RAID (mdadm), putting the EFI system partition on
top of a mdadm volume is not possible, as no mainboard with UEFI
firmware implementation recognizes this as a valid ESP.
The only alternative I've seen so far (ignoring the real hardware RAID
controller, which both busts the budget and introduce a strong hardware
dependency on the controller hardware), is putting a full EFI system
partition on each harddisk and the rootfs on RAID1. Given that the UEFI
specification allows specifying multiple boot entries and usually
manages to fall back transparently, if the primary boot entry is
missing, this appears to be a nice workaround.
grub-efi unfortunately does not directly support this scenario (at
least not the current maintainer scripts in unstable. While it should
be possible to add support for this in a similar as in my suggested
patch for gummiboot, its maintainer scripts are considerably more
complex - although it should still be possible. Another added
complexity in case of grub2 is the split between stage1 (or the EFI
binary) and the on-disk modules (/boot/grub/), which don't offer any
ABI stability, making it essential to keep /boot/grub/ and
/boot/efi/EFI/debian/grubx64.efi in perfect sync - which is not
possible via a simple hook provided by the local admin and requires
full-blown integration into grub-efi-amd64's maintainer scripts
instead.
Looking at gummiboot, I see several advantages over grub-efi for this
particular situation (although it's certainly interesting to make grub2
compatible to the mdadm RAID1 scenario as well):
- the maintainer scripts and kernel hooks are simple enough to allow
this feature addition easily.
- gummiboot essentially only needs a single EFI binary, without the
risk of multiple components on multiple disks get out of sync.
- in addition to its own native EFI binary at
\EFI\gummiboot\gummibootx64.efi, it -optionally- also covers
\EFI\Boot\bootx64.efi, which increases robustness quite a bit (of
six different mainboard, each from different vendors, only one
manages to remember boot entries and -order after a firmware upgrade
all others reverted to a blank boot list/ -order; offering a
\EFI\Boot\bootx64.efi binary helps a lot in this case; grub-efi does
not support this (at least not in its current form in Debian)).
- Using vmlinuz and initrd.img as bootloader makes mounting the rootfs
from non-standard block devices, like mdadm, a lot easier - actually
this would even allow booting from RAID5, RAID6 or even RAID0 or
other "strangely" stacked varitions (I've tested this with
gummiboot; grub2 would need native filesystem drivers for these -
which are less likely to support these variations).
I certainly recognize the appeal to standardise on a common
install-kernel implementation, although the current version as part
of systemd 208 indeed seems to be rather limiting - while gummiboot's
kernel hooks still have an attractive simpilicty and offer easy
extensibility. Likewise I fear dropping configuration options from
/etc/default/gummiboot might be problematic, e.g. trying to detect
the rootfs might be a bit too much for a simple script (be it systemd's
install-kernel or gummiboot's own kernel hooks). grub2 uses its quite
advanced grub-probe binary, but without something like this, trying
to guess the root=<rootfs> parameter will fail in quite a few corner
cases without options to override this, e.g:
lvm2: /dev/vg-efi/debian64 is perfectly valid in fstab - and
determine_root() extracts this verbatim, but initramfs(-tools) cannot
find the logical volume under this name, it needs the alternative
encoding as /dev/mapper/vg--efi-debian64 instead. I assume this to
be a similar problem for mdadm or the various layering possibilities
for cryptoloop or LUKS.
I'd be interested in different options to provide this kind of
boot redundancy along RAID1 (or better) and am willing to try or
provide different implementations for this functionality. It might
be interesting to involve Debian's grub2 maintainer or debian-boot
for this as well.
Thanks a lot for maintaining gummiboot, I'm quite impressed about its
simple, but quite mighty approach of provding a convenient efi
chainloader.
Regards
Stefan Lippers-Hollmann
signature.asc
Description: This is a digitally signed message part.
