Simultaneous EFI and Legacy bootloader installation

[Mario Limonciello]

Thanks for the comments.

On 03/30/2016 06:11 AM, Colin Watson wrote:
> On Tue, Mar 29, 2016 at 07:50:27PM -0500, Mario_Limonciello at 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.
As Jared was mentioning to me the other day, there is unfortunately a
mentality in the server world of not installing the OS in UEFI yet and
leave the CSM enabled.  The best way to allow for that mentality to
break is to allow an easy way for an admin to switch to UEFI mode
without re-installation.
 
>> 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.
Yes, this will only help people wiling to reformat their disk.  I think
if Debian can lead the way in switching to GPT by default it can be a
role model for other distributions to make this change as well. 
>
> 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.
>
To me this is an acceptable compromise. 

IIRC there is a debconf question about installing to the removable path
when you install EFI GRUB2.  What are the defaults for this? 
Would you consider making the default yes if you identify they are
running in legacy mode when you install the EFI GRUB2 (to do this
bootloader switch).