On Tue, Mar 29, 2016 at 07:50:27PM -0500, Mario_Limonciello@Dell.com wrote:
> I was briefly discussing this with Steve McIntyre and wanted to bring
> it to a wider discussion. Currently users need to make a selection at
> installation time whether to install in UEFI mode or in Legacy mode.
In fact pre-installation, because it depends on how they told the
firmware to boot the installer. I'd expect modern systems to have
defaults that lead to UEFI mode, and for this to predominantly be an
issue on older systems, which means that we need to give more weight to
considerations that apply to older systems.
> If they installed in legacy mode and later discovered that their
> system supported extra features in UEFI mode (For example firmware
> updates) they are penalized and need to redo the installation in order
> to switch modes.
>
> I'd like to propose changing this and by default install both legacy
> and UEFI bootloaders on architectures that support both regardless of
> which mode the system is running in at installation.
I'm pretty wary about this because it seems likely to exacerbate the
already far too common problems where people end up booting from a GRUB
installation they don't realise they're booting from, and then at some
point in the future something changes so that some subset of the
installed GRUB instances don't get updated properly and then everything
explodes mysteriously. (Usually I find out about this when I upload
GRUB and then get dozens of bug reports that are in fact due to some bug
in the installer from years back that's now next to impossible to track
down.) Being able to say that UEFI installations just don't need to
worry about this class of problems is a significant benefit.
> Making this change has a few obvious implications:
> * The installation disk would always be formatted GPT.
On the whole I think this is a good direction to go as it's a much
better partition table type, but a lot of BIOSes object to this in
practice unless the disk is very specifically and delicately formatted.
parted allows setting the necessary flag ("pmbr_boot"), but I don't
believe that partman has support for it as yet, and it violates the UEFI
specification so it's possible that doing this unconditionally would
cause problems later.
> * An ESP would always be created.
And, I think, also a BIOS Boot Partition, which starts feeling like a
lot of overhead on modern systems.
> * If the user is in legacy at installation time, it's not possible to
> create an EFI boot entry since EFI runtime services aren't present.
> The removable media fallback path (\efi\boot\boot$ARCH.efi) will need
> to be used to boot the system at this point and at some point create a
> "debian" NVRAM boot entry
Indeed, and this is exactly the scenario you specifically mentioned
being interested in. But this is another way that the system can work
after the initial installation but then be broken by later updates
because we change the boot path, which to my mind is much worse than not
working after the initial installation because the user has put more
effort into their system by that point.
> I'm not aware of any modern systems that are unable to boot a GPT
> partitioned disk. If there are systems like this in the wild, it
> would be worthwhile to leave support to install in MBR mode when doing
> an expert install so that people can still use them.
Remember that very many Debian installations happen on systems that are
already partitioned and frequently already have other operating systems
on them. In those cases we're stuck with the partition table type
that's already in use.
So, I'm very unconvinced about the plan to have more than one boot
loader instance think that it's responsible for booting the computer. I
think that's likely to lead to difficult-to-diagnose problems down the
line. How about a compromise? If we could at least get to the point
where we install systems with GPT and an ESP where we can even if we
aren't going to install grub-efi-amd64, then it would at least be
reasonably straightforward to switch mode by just installing
grub-efi-amd64 and removing grub-pc; you wouldn't need to redo the
installation.
That would give most of the benefits you're looking for, albeit at the
cost of a bit of documentation, without needing to break the "only one
installed boot loader thinks that it owns the system boot process" rule.
--
Colin Watson [cjwatson@debian.org]