Making Anaconda do hybrid BIOS+UEFI setups for legacy BIOS installs

[Neal Gompa]

Hey all,

As y'all may know, there was the rather contentious discussion around
deprecating/removing legacy BIOS support (which was ultimately
rejected). As part of that discussion, a more incremental path to
deprecating BIOS boot was identified. The first step of that is to
move to legacy BIOS installations to GPT partitioning[1][2].

Following that, I'd like to adjust Anaconda to install a hybrid
BIOS+UEFI boot setup for BIOS systems, similar to what I did for
Fedora Cloud[3]. However, I'm not really sure how to implement that
and would like some guidance on how to pull it off.

Thanks in advance and best regards,
Neal

[1]: https://fedoraproject.org/wiki/Changes/GPTforBIOSbyDefault
[2]: https://github.com/rhinstaller/anaconda/pull/4104
[3]: https://fedoraproject.org/wiki/Changes/FedoraCloudHybridBoot

--
真実はいつも一つ！/ Always, there's only one truth!

[Chris Murphy]

I inserted a comment in the PR,
https://github.com/rhinstaller/anaconda/pull/4104#issuecomment-1127824824

On second thought it's probably better discussed here. I'm generally
inclined to support less than more by combining things as much as
possible. So I'm wondering about a disklabel and bootloader policy
that in effect is GPT+BIOSBoot+EFI System partitions, with both
bootloaders configured at installation time no matter the firmware
type during installation. There's already one consumer for this,
Fedora Cloud edition images (both qcow2 and raw).

Maybe it doesn't really simplify anything for the non-cloud case? We'd
need to boot systems in BIOS, do an installation, test the
installation in BIOS and UEFI mode boot. And boot systems in UEFI, do
an installation, and test the installation in BIOS and UEFI boot. We
do this already but I wonder if it's overall less complex for Anaconda
going forward? And reduces the chance of installation failure or the
boot following installation?

--
Chris

[Jiri Konecny]

Hi Chris,

honestly, it looks to me like a hack which is required for the cloud 
images but shouldn't be used out of that. I don't like the solution 
much, it makes everything much more complicated especially for the 
"mbr/bios" and similar formats. I'm more inclined for the simplified 
current solution.

Also I'm thinking if it would be really that helpful. Users usually 
don't change on the installed system between UEFI and BIOS boot, do they?

Adding bootloader dev for the heads-up about this change and the discussion.

Best Regards,
Jirka

Dne 16. 05. 22 v 17:55 Chris Murphy napsal(a):
> I inserted a comment in the PR,
> https://github.com/rhinstaller/anaconda/pull/4104#issuecomment-1127824824
>
> On second thought it's probably better discussed here. I'm generally
> inclined to support less than more by combining things as much as
> possible. So I'm wondering about a disklabel and bootloader policy
> that in effect is GPT+BIOSBoot+EFI System partitions, with both
> bootloaders configured at installation time no matter the firmware
> type during installation. There's already one consumer for this,
> Fedora Cloud edition images (both qcow2 and raw).
>
> Maybe it doesn't really simplify anything for the non-cloud case? We'd
> need to boot systems in BIOS, do an installation, test the
> installation in BIOS and UEFI mode boot. And boot systems in UEFI, do
> an installation, and test the installation in BIOS and UEFI boot. We
> do this already but I wonder if it's overall less complex for Anaconda
> going forward? And reduces the chance of installation failure or the
> boot following installation?
>
> --
> Chris
> _______________________________________________
> Anaconda-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]...
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Neal Gompa]

On Wed, May 18, 2022 at 11:21 AM Jiri Konecny  wrote:
> Hi Chris,
>
> honestly, it looks to me like a hack which is required for the cloud
> images but shouldn't be used out of that. I don't like the solution
> much, it makes everything much more complicated especially for the
> "mbr/bios" and similar formats. I'm more inclined for the simplified
> current solution.
>
> Also I'm thinking if it would be really that helpful. Users usually
> don't change on the installed system between UEFI and BIOS boot, do they?
>
> Adding bootloader dev for the heads-up about this change and the discussion.

It does happen. Especially if there are problems in one mode vs the other.

But more importantly, this Change is designed as a step toward the
eventual removal of grub2-pc as a package. It may be in the future
that we'll have OpenCore or some other UEFI emulator for BIOS (similar
to what we do for a lot of ARM devices with u-boot), which allows for
the shipped GRUB codebase to be drastically simplified to just the
stuff for grub2-efi. Having legacy BIOS installs be hybrid BIOS+UEFI
would be very useful toward that goal.

I don't particularly want to add too many more partitioning modes. I'm
even a bit hesitant to change from inst.mbr to
inst.disklabel=(mbr|gpt) because the latter implies permanent support
of alternative disklabels. And frankly, I think we want to just get
down to GPT (and DASD for s390x) in the far future.

[Chris Murphy]

On Wed, May 18, 2022 at 11:21 AM Jiri Konecny  wrote:
> Hi Chris,
>
> honestly, it looks to me like a hack which is required for the cloud
> images but shouldn't be used out of that. I don't like the solution
> much, it makes everything much more complicated especially for the
> "mbr/bios" and similar formats. I'm more inclined for the simplified
> current solution.
>
> Also I'm thinking if it would be really that helpful. Users usually
> don't change on the installed system between UEFI and BIOS boot, do they?

It's mixed. Some do it inadvertently, including the case where USB
boots use one mode and internal drive boot uses the other mode. And
also the case where users go on a "push all the buttons" spree and
turn on legacy. And there's some population still of Windows 7 and
Vista era systems that are UEFI but default to BIOS, the idea was
you'd flip to UEFI once an OS could support it. But if you do a UEFI
installation and then merely reset to factor defaults, you get BIOS
boot. So for all these edge case reasons I'm thinking a while ago we
should have just done hybrid setups and focus on that as the one size
fits all.

Also, there's a ton of UEFI bugs still, and lots of hardware won't
ever get firmware updates again. Using CSM/BIOS mode is one way of
working around that, however suboptimal. I don't think flipping back
and forth is a feature or a good thing, it's mainly a fallback to
avoid a worse user experience.

[Robbie Harwood]

Chris Murphy  writes:
> On Wed, May 18, 2022 at 11:21 AM Jiri Konecny  wrote:
> > Hi Chris,
> >
> > honestly, it looks to me like a hack which is required for the cloud
> > images but shouldn't be used out of that. I don't like the solution
> > much, it makes everything much more complicated especially for the
> > "mbr/bios" and similar formats. I'm more inclined for the simplified
> > current solution.
> >
> > Also I'm thinking if it would be really that helpful. Users usually
> > don't change on the installed system between UEFI and BIOS boot, do they?
>
> It's mixed. Some do it inadvertently, including the case where USB
> boots use one mode and internal drive boot uses the other mode.  And
> also the case where users go on a "push all the buttons" spree and
> turn on legacy.

Well, it won't actually boot both ways unless you've installed
bootloaders for both paths - which we don't do for desktop/server use
cases, only cloud-style use cases.

(Also, on systems with legacy CSM, enabling the legacy boot path doesn't
typically turn off the non-legacy path - it just adds the legacy options
as additional boot targets (either after or before the non-legacy ones).)

Be well,
--Robbie

[Robbie Harwood]

Jiri Konecny  writes:
> Dne 16. 05. 22 v 17:55 Chris Murphy napsal(a):
> > I inserted a comment in the PR,
> > https://github.com/rhinstaller/anaconda/pull/4104#issuecomment-1127824824
> >
> > On second thought it's probably better discussed here. I'm generally
> > inclined to support less than more by combining things as much as
> > possible. So I'm wondering about a disklabel and bootloader policy
> > that in effect is GPT+BIOSBoot+EFI System partitions, with both
> > bootloaders configured at installation time no matter the firmware
> > type during installation. There's already one consumer for this,
> > Fedora Cloud edition images (both qcow2 and raw).
> >
> > Maybe it doesn't really simplify anything for the non-cloud case?
> > We'd need to boot systems in BIOS, do an installation, test the
> > installation in BIOS and UEFI mode boot. And boot systems in UEFI, do
> > an installation, and test the installation in BIOS and UEFI boot. We
> > do this already but I wonder if it's overall less complex for
> > Anaconda going forward? And reduces the chance of installation
> > failure or the boot following installation?
>
> Hi Chris,
>
> honestly, it looks to me like a hack which is required for the cloud 
> images but shouldn't be used out of that. I don't like the solution 
> much, it makes everything much more complicated especially for the 
> "mbr/bios" and similar formats. I'm more inclined for the simplified 
> current solution.
>
> Also I'm thinking if it would be really that helpful. Users usually 
> don't change on the installed system between UEFI and BIOS boot, do they?

Right.  Even in cloud images, while one has the capability to do either
initially, going back and forth isn't normal.  (Certainly it's not
something we test during development.)

While I don't want to spread FUD, I think this has been tried in the
past and didn't work well.  That doesn't mean don't do it, of course,
just that it'd need to be understood why it didn't work.

I don't expect anyone wants to support migrations UEFI to legacy, so
this really is about legacy to UEFI.  While I know that others on CC may
not agree, my personal opinion is that hardware that can't do UEFI by
default at this point is a corner case - which means I'm unconvinced
that the benefits of enabling such in new installs is worth the
complexity.
> Adding bootloader dev for the heads-up about this change and the
> discussion.

Cheers.  I expect we'll defer to whatever decision anaconda makes here.

Be well,
--Robbie