The unfortunate configuration choice Grub2 makes in UEFI configurations
When I talked about my new home machine, I mentioned that I wasn't even trying to use UEFI on it after my experiences with my work machine, fundamentally because Grub2's UEFI setup makes an unfortunate configuration choice. Today I'm going to talk about what that choice is and why it's an unfortunate one, at least for people like me (and for people with servers).
Put simply, it's that the UEFI Grub2 requires you to put grub.cfg
in the EFI system partition. On the one hand, this is a reasonable
choice, and probably one that simplifies Grub's life. In a UEFI
environment, the EFI system partition exists and is easily accessible
through (U)EFI services, so you have a natural place to put everything
else that Grub2 needs, including both its additional modules and
grub.cfg. In a traditional non-UEFI environment, grub2 needs to
do some magic to be able to load your grub.cfg from whatever sort
of filesystem and RAID setup and so on your /boot is in; the
actual mechanisms of that are relatively impressive and more than
a bit complex (cf). UEFI makes life much
simpler.
On the other hand, grub.cfg is the one piece of your Grub2
configuration that changes frequently, because it gets updated every
time you add a kernel, remove a kernel, or modify kernel command
line arguments. This is an issue for me and for people with servers,
because the EFI system partition can't be part of a RAID mirror.
If you want to be able to boot from a second disk if your primary
disk fails, you need a duplicate copy of your EFI system partition,
and because grub.cfg changes frequently, you need to keep this
up to date on a frequent basis. Otherwise, not only will you perhaps
be booting from an older (but functional) version of Grub2 that you
didn't update, you'll probably be trying to boot kernels that don't
even exist any more (perhaps with wrong or missing kernel arguments).
You'll probably be able to boot your system in the end, but it's not
likely to be easy or automatic.
Life would be a lot easier and better here if you could configure
Grub2 to load your real grub.cfg from your (non-EFI) /boot.
You could use software RAID, LVM, and any filesystem normally
supported by Grub2. People with mirrored system disks would still
have all of the good stuff that you get with them in a non-EFI
configuration (although every so often you'd need to remember to
update the stuff in your EFI system partition on the second disk).
My guess is that the easiest way to add this to Grub2 would be to
give Grub2 some way of including additional files in grub.cfg.
With this, you'd still have a stub grub.cfg in the EFI system
partition (which Grub2 could load with UEFI services just like
today), and this stub would specify everything else. It would know
the UUID of the filesystem with your /boot in it and also what
additional RAID or LVM UUIDs it needed to look for and start in
order to find it, just as a non-EFI Grub2 knows those details today
(cf), but these wouldn't change very often
so your EFI system partition grub.cfg would stay mostly unchanging.
Of course this Grub2 configuration choice isn't important unless you have mirrored system disks. If your system disk is unmirrored, an unmirrored EFI system partition creates no additional problems and the current UEFI Grub2 design is fine. Since this probably describes most systems using UEFI today, I don't expect UEFI Grub2 to change any time soon. Probably it will only start to change when servers become UEFI-only and people running them discover that their mirrored, redundant system disks actually aren't any more because of this.
Comments on this page:
|
|