F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS

== Summary ==
Make UEFI a hardware requirement for new Fedora installations on
platforms that support it (x86_64).  Legacy BIOS support is not
removed, but new non-UEFI installation is not supported on those
platforms.  This is a first step toward eventually removing legacy
BIOS support entirely.

== Owner ==
* Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří
Konečný]], [[User:bcl| Brian C. Lane]]
* Email: rharwood(a)redhat.com


== Detailed Description ==
UEFI is defined by a versioned standard that can be tested and
certified against.  By contrast, every legacy BIOS is unique. Legacy
BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple)
and on its way out.  As it ages, maintainability has decreased, and
the status quo of maintaining both stacks in perpetuity is not viable
for those currently doing that work.

It is inevitable that legacy BIOS will be removed in a future release.
To ease this transition as best we can, there will be a period (of at
least one Fedora release) where it will be possible to boot using the
legacy BIOS codepaths, but new installations will not be possible.
While it would be easier for us to cut support off today, our hope is
that this compromise position will make for a smoother transition.
Additional support with issues during the transition would be
appreciated.

While this will eventually reduce workload for boot/installation
components (grub2 reduces surface area, syslinux goes away entirely,
anaconda reduces surface area), the reduction in support burden
extends much further into the stack - for instance, VESA support can
be removed from the distro.

Fedora already requires a 2GHz dual core CPU at minimum (and therefore
mandates that machines must have been made after 2006).  Like the
already accepted Fedora 37 change to retire ARMv7 support, the
hardware targeted tends to be rather underpowered by today’s
standards, and the world has moved on from it.  Intel stopped shipping
the last vestiges of BIOS support in 2020 (as have other vendors, and
Apple and Microsoft), so this is clearly the way things are heading -
and therefore aligns with Fedora’s “First” objective.

== Feedback ==
Dropping legacy BIOS was previously discussed (but not proposed) in 2020:
https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject...

Important, relevant points from that thread (yes, I reread the entire
thread) that have informed this change:

* Some machines are BIOS-only.  This change does not prevent their use
yet, but they are effectively deprecated.  grub2 (our default
bootloader) is already capable of both BIOS and UEFI booting.
* Drawing a clear year cutoff, let alone a detailed list of hardware
this change affects, is basically impossible.  This is unfortunate but
unlikely to ever change.
* There is no migration story from Legacy BIOS to UEFI -
repartitioning effectively mandates a reinstall.  As a result, we
don’t drop support for existing Legacy BIOS systems yet, just new
installations.
* There is no way to deprecate hardware without causing some amount of friction.
* While at the time AWS did not support UEFI booting, that is no
longer the case and they support UEFI today.

== Benefit to Fedora ==
UEFI is required for many desirable features, including applying
firmware updates (fwupd) and supporting SecureBoot.  As a standalone
change, it reduces support burden on everything involved in installing
Fedora, since there becomes only one way to do it per platform.
Finally, it simplifies our install/live media, since it too only has
to boot one way per arch.  Freedom Friends Features First - this is
that last one.

== Scope ==
* Proposal owners:
** bootloaders: No change (existing Legacy BIOS installations still supported).
** anaconda: No change (there could be only optional cleanups in the
code). However, it needs to be verified.
** Lorax: Code has already been written:
https://github.com/weldr/lorax/pull/1205

* Other developers:
** libvirt: UEFI works today, but is not the default.  UEFI-only
installation is needed for Windows 11, and per conversations, libvirt
is prepared for this change.
** Virtualbox: UEFI Fedora installs are working and per virtualbox
team, UEFI will be/is the default in 7.0+.
** The Hardware Overview page should be updated to mention the UEFI
requirement:
https://docs.fedoraproject.org/en-US/fedora/rawhide/release-notes/welcome...

* Release engineering: [https://pagure.io/releng/issue/10738 #Releng
issue 10738]

* Policies and guidelines: N/A (not needed for this Change)

* Trademark approval: N/A (not needed for this Change)

* Alignment with Objectives: N/A

== Upgrade/compatibility impact ==
Systems currently using Legacy BIOS for booting on x86_64 will
continue to do so.

However, this modifies the baseline Fedora requirements and some
hardware will no longer be supported for new installations.

== How To Test ==
UEFI installation has been supported for quite a while already, so
additional testing there should not be required.

== User Experience ==
Installs will continue to work on UEFI, and will not work on Legacy
BIOS.  Our install media is already UEFI-capable.

== Dependencies ==
None

== Contingency Plan ==
Leave things as they are.  Code continues to rot.  Community
assistance is required to continue the status quo.  Current owners
plan to orphan some packages regardless of whether the proposal is
accepted.

Another fallback option could be, if a Legacy BIOS SIG organizes, to
donate the relevant packages there and provide some initial mentoring.
Longer term, packages that cannot be wholly donated could be split,
though it is unclear whether the synchronization thereby required
would reduce the work for anyone.

* Contingency mechanism: Delay until next release.
* Contingency deadline: Beta freeze
* Blocks release? No

== Documentation ==
See release notes.

== Release Notes ==
Fedora 37 marks legacy BIOS installation as deprecated on x86_64 in
favor of UEFI.  While systems already using Legacy BIOS to boot are
still supported, new legacy BIOS installations on these architectures
are no longer possible.  Legacy BIOS support will be removed entirely
in a future Fedora.

(Additionally, the Hardware Overview page should be updated to mention
the UEFI requirement.)


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis

[Neal Gompa]

On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
>
>  == Summary ==
>  Make UEFI a hardware requirement for new Fedora installations on
>  platforms that support it (x86_64).  Legacy BIOS support is not
>  removed, but new non-UEFI installation is not supported on those
>  platforms.  This is a first step toward eventually removing legacy
>  BIOS support entirely.
>
>  == Owner ==
>  * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří
>  Konečný]], [[User:bcl| Brian C. Lane]]
>  * Email: rharwood(a)redhat.com
>
>
>  == Detailed Description ==
>  UEFI is defined by a versioned standard that can be tested and
>  certified against.  By contrast, every legacy BIOS is unique. Legacy
>  BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple)
>  and on its way out.  As it ages, maintainability has decreased, and
>  the status quo of maintaining both stacks in perpetuity is not viable
>  for those currently doing that work.
>
>  It is inevitable that legacy BIOS will be removed in a future release.
>  To ease this transition as best we can, there will be a period (of at
>  least one Fedora release) where it will be possible to boot using the
>  legacy BIOS codepaths, but new installations will not be possible.
>  While it would be easier for us to cut support off today, our hope is
>  that this compromise position will make for a smoother transition.
>  Additional support with issues during the transition would be
>  appreciated.
>
>  While this will eventually reduce workload for boot/installation
>  components (grub2 reduces surface area, syslinux goes away entirely,
>  anaconda reduces surface area), the reduction in support burden
>  extends much further into the stack - for instance, VESA support can
>  be removed from the distro.
>
>  Fedora already requires a 2GHz dual core CPU at minimum (and therefore
>  mandates that machines must have been made after 2006).  Like the
>  already accepted Fedora 37 change to retire ARMv7 support, the
>  hardware targeted tends to be rather underpowered by today’s
>  standards, and the world has moved on from it.  Intel stopped shipping
>  the last vestiges of BIOS support in 2020 (as have other vendors, and
>  Apple and Microsoft), so this is clearly the way things are heading -
>  and therefore aligns with Fedora’s “First” objective.
>
>  == Feedback ==
>  Dropping legacy BIOS was previously discussed (but not proposed) in 2020:
>
> https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject...
>
>  Important, relevant points from that thread (yes, I reread the entire
>  thread) that have informed this change:
>
>  * Some machines are BIOS-only.  This change does not prevent their use
>  yet, but they are effectively deprecated.  grub2 (our default
>  bootloader) is already capable of both BIOS and UEFI booting.
>  * Drawing a clear year cutoff, let alone a detailed list of hardware
>  this change affects, is basically impossible.  This is unfortunate but
>  unlikely to ever change.
>  * There is no migration story from Legacy BIOS to UEFI -
>  repartitioning effectively mandates a reinstall.  As a result, we
>  don’t drop support for existing Legacy BIOS systems yet, just new
>  installations.
>  * There is no way to deprecate hardware without causing some amount of friction.
>  * While at the time AWS did not support UEFI booting, that is no
>  longer the case and they support UEFI today.
>
>  == Benefit to Fedora ==
>  UEFI is required for many desirable features, including applying
>  firmware updates (fwupd) and supporting SecureBoot.  As a standalone
>  change, it reduces support burden on everything involved in installing
>  Fedora, since there becomes only one way to do it per platform.
>  Finally, it simplifies our install/live media, since it too only has
>  to boot one way per arch.  Freedom Friends Features First - this is
>  that last one.
>
>  == Scope ==
>  * Proposal owners:
>  ** bootloaders: No change (existing Legacy BIOS installations still supported).
>  ** anaconda: No change (there could be only optional cleanups in the
>  code). However, it needs to be verified.
>  ** Lorax: Code has already been written:
>  https://github.com/weldr/lorax/pull/1205
>  
This pull request primarily drops legacy BIOS support by dropping
syslinux/isolinux. We don't necessarily have to drop legacy BIOS
support there if we reuse GRUB there too. Other distributions
(openSUSE and Mageia, notably) both use GRUB for both BIOS and UEFI on
live media.

>  * Other developers:
>  ** libvirt: UEFI works today, but is not the default.  UEFI-only
>  installation is needed for Windows 11, and per conversations, libvirt
>  is prepared for this change.
>  ** Virtualbox: UEFI Fedora installs are working and per virtualbox
>  team, UEFI will be/is the default in 7.0+.
>  ** The Hardware Overview page should be updated to mention the UEFI
>  requirement:
> https://docs.fedoraproject.org/en-US/fedora/rawhide/release-notes/welcome...
>
>  * Release engineering: [https://pagure.io/releng/issue/10738 #Releng
>  issue 10738]
>
>  * Policies and guidelines: N/A (not needed for this Change)
>
>  * Trademark approval: N/A (not needed for this Change)
>
>  * Alignment with Objectives: N/A
>
>  == Upgrade/compatibility impact ==
>  Systems currently using Legacy BIOS for booting on x86_64 will
>  continue to do so.
>
>  However, this modifies the baseline Fedora requirements and some
>  hardware will no longer be supported for new installations.
>
>  == How To Test ==
>  UEFI installation has been supported for quite a while already, so
>  additional testing there should not be required.
>
>  == User Experience ==
>  Installs will continue to work on UEFI, and will not work on Legacy
>  BIOS.  Our install media is already UEFI-capable.
>
>  == Dependencies ==
>  None
>
>  == Contingency Plan ==
>  Leave things as they are.  Code continues to rot.  Community
>  assistance is required to continue the status quo.  Current owners
>  plan to orphan some packages regardless of whether the proposal is
>  accepted.
>
>  Another fallback option could be, if a Legacy BIOS SIG organizes, to
>  donate the relevant packages there and provide some initial mentoring.
>  Longer term, packages that cannot be wholly donated could be split,
>  though it is unclear whether the synchronization thereby required
>  would reduce the work for anyone.
>
>  * Contingency mechanism: Delay until next release.
>  * Contingency deadline: Beta freeze
>  * Blocks release? No
>
>  == Documentation ==
>  See release notes.
>
>  == Release Notes ==
>  Fedora 37 marks legacy BIOS installation as deprecated on x86_64 in
>  favor of UEFI.  While systems already using Legacy BIOS to boot are
>  still supported, new legacy BIOS installations on these architectures
>  are no longer possible.  Legacy BIOS support will be removed entirely
>  in a future Fedora.
>
>  (Additionally, the Hardware Overview page should be updated to mention
>  the UEFI requirement.)
>  
While I'm sympathetic to this Change, I think this is way too early to
do across the board. UEFI came onto the scene in the PC space in
2011~2012 with Windows 8, and even to this day, there are sufficiently
buggy hardware platforms that Linux does not boot in UEFI mode:
https://twitter.com/VKCsh/status/1511132132885815307

I even have one such machine, an HP desktop machine that came with
Windows 8. My current desktop PC has problems booting Linux UEFI as
well, though I've done "clever" things to work around that. I don't
expect most users to be able to deal with that. Server platforms were
*worse* as they were slower to offer UEFI. The first time I was able
to get a server with UEFI was in 2014.

And we've still failed to get ARM and RISC-V broadly on board with
UEFI (though that's irrelevant to this Change, even though ARM is
mentioned).

We also lack solutions for dealing with the NVIDIA driver in
UEFI+Secure Boot case. Are you planning to actually *fix* that now?
Because we still don't have a way to have kernel-only keyrings for
secure boot certificates to avoid importing them into the firmware.




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

[Peter Robinson]

On Tue, Apr 5, 2022 at 4:09 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  >
>  > https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
>  >
>  > == Summary ==
>  > Make UEFI a hardware requirement for new Fedora installations on
>  > platforms that support it (x86_64).  Legacy BIOS support is not
>  > removed, but new non-UEFI installation is not supported on those
>  > platforms.  This is a first step toward eventually removing legacy
>  > BIOS support entirely.
>  >
>  > == Owner ==
>  > * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří
>  > Konečný]], [[User:bcl| Brian C. Lane]]
>  > * Email: rharwood(a)redhat.com
>  >
>  >
>  > == Detailed Description ==
>  > UEFI is defined by a versioned standard that can be tested and
>  > certified against.  By contrast, every legacy BIOS is unique. Legacy
>  > BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple)
>  > and on its way out.  As it ages, maintainability has decreased, and
>  > the status quo of maintaining both stacks in perpetuity is not viable
>  > for those currently doing that work.
>  >
>  > It is inevitable that legacy BIOS will be removed in a future release.
>  > To ease this transition as best we can, there will be a period (of at
>  > least one Fedora release) where it will be possible to boot using the
>  > legacy BIOS codepaths, but new installations will not be possible.
>  > While it would be easier for us to cut support off today, our hope is
>  > that this compromise position will make for a smoother transition.
>  > Additional support with issues during the transition would be
>  > appreciated.
>  >
>  > While this will eventually reduce workload for boot/installation
>  > components (grub2 reduces surface area, syslinux goes away entirely,
>  > anaconda reduces surface area), the reduction in support burden
>  > extends much further into the stack - for instance, VESA support can
>  > be removed from the distro.
>  >
>  > Fedora already requires a 2GHz dual core CPU at minimum (and therefore
>  > mandates that machines must have been made after 2006).  Like the
>  > already accepted Fedora 37 change to retire ARMv7 support, the
>  > hardware targeted tends to be rather underpowered by today’s
>  > standards, and the world has moved on from it.  Intel stopped shipping
>  > the last vestiges of BIOS support in 2020 (as have other vendors, and
>  > Apple and Microsoft), so this is clearly the way things are heading -
>  > and therefore aligns with Fedora’s “First” objective.
>  >
>  > == Feedback ==
>  > Dropping legacy BIOS was previously discussed (but not proposed) in 2020:
>  >
> https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject...
>  >
>  > Important, relevant points from that thread (yes, I reread the entire
>  > thread) that have informed this change:
>  >
>  > * Some machines are BIOS-only.  This change does not prevent their use
>  > yet, but they are effectively deprecated.  grub2 (our default
>  > bootloader) is already capable of both BIOS and UEFI booting.
>  > * Drawing a clear year cutoff, let alone a detailed list of hardware
>  > this change affects, is basically impossible.  This is unfortunate but
>  > unlikely to ever change.
>  > * There is no migration story from Legacy BIOS to UEFI -
>  > repartitioning effectively mandates a reinstall.  As a result, we
>  > don’t drop support for existing Legacy BIOS systems yet, just new
>  > installations.
>  > * There is no way to deprecate hardware without causing some amount of friction.
>  > * While at the time AWS did not support UEFI booting, that is no
>  > longer the case and they support UEFI today.
>  >
>  > == Benefit to Fedora ==
>  > UEFI is required for many desirable features, including applying
>  > firmware updates (fwupd) and supporting SecureBoot.  As a standalone
>  > change, it reduces support burden on everything involved in installing
>  > Fedora, since there becomes only one way to do it per platform.
>  > Finally, it simplifies our install/live media, since it too only has
>  > to boot one way per arch.  Freedom Friends Features First - this is
>  > that last one.
>  >
>  > == Scope ==
>  > * Proposal owners:
>  > ** bootloaders: No change (existing Legacy BIOS installations still supported).
>  > ** anaconda: No change (there could be only optional cleanups in the
>  > code). However, it needs to be verified.
>  > ** Lorax: Code has already been written:
>  > https://github.com/weldr/lorax/pull/1205
>  >
>
>  This pull request primarily drops legacy BIOS support by dropping
>  syslinux/isolinux. We don't necessarily have to drop legacy BIOS
>  support there if we reuse GRUB there too. Other distributions
>  (openSUSE and Mageia, notably) both use GRUB for both BIOS and UEFI on
>  live media.
>
>  > * Other developers:
>  > ** libvirt: UEFI works today, but is not the default.  UEFI-only
>  > installation is needed for Windows 11, and per conversations, libvirt
>  > is prepared for this change.
>  > ** Virtualbox: UEFI Fedora installs are working and per virtualbox
>  > team, UEFI will be/is the default in 7.0+.
>  > ** The Hardware Overview page should be updated to mention the UEFI
>  > requirement:
> https://docs.fedoraproject.org/en-US/fedora/rawhide/release-notes/welcome...
>  >
>  > * Release engineering: [https://pagure.io/releng/issue/10738 #Releng
>  > issue 10738]
>  >
>  > * Policies and guidelines: N/A (not needed for this Change)
>  >
>  > * Trademark approval: N/A (not needed for this Change)
>  >
>  > * Alignment with Objectives: N/A
>  >
>  > == Upgrade/compatibility impact ==
>  > Systems currently using Legacy BIOS for booting on x86_64 will
>  > continue to do so.
>  >
>  > However, this modifies the baseline Fedora requirements and some
>  > hardware will no longer be supported for new installations.
>  >
>  > == How To Test ==
>  > UEFI installation has been supported for quite a while already, so
>  > additional testing there should not be required.
>  >
>  > == User Experience ==
>  > Installs will continue to work on UEFI, and will not work on Legacy
>  > BIOS.  Our install media is already UEFI-capable.
>  >
>  > == Dependencies ==
>  > None
>  >
>  > == Contingency Plan ==
>  > Leave things as they are.  Code continues to rot.  Community
>  > assistance is required to continue the status quo.  Current owners
>  > plan to orphan some packages regardless of whether the proposal is
>  > accepted.
>  >
>  > Another fallback option could be, if a Legacy BIOS SIG organizes, to
>  > donate the relevant packages there and provide some initial mentoring.
>  > Longer term, packages that cannot be wholly donated could be split,
>  > though it is unclear whether the synchronization thereby required
>  > would reduce the work for anyone.
>  >
>  > * Contingency mechanism: Delay until next release.
>  > * Contingency deadline: Beta freeze
>  > * Blocks release? No
>  >
>  > == Documentation ==
>  > See release notes.
>  >
>  > == Release Notes ==
>  > Fedora 37 marks legacy BIOS installation as deprecated on x86_64 in
>  > favor of UEFI.  While systems already using Legacy BIOS to boot are
>  > still supported, new legacy BIOS installations on these architectures
>  > are no longer possible.  Legacy BIOS support will be removed entirely
>  > in a future Fedora.
>  >
>  > (Additionally, the Hardware Overview page should be updated to mention
>  > the UEFI requirement.)
>  >
>
>  While I'm sympathetic to this Change, I think this is way too early to
>  do across the board. UEFI came onto the scene in the PC space in
>  2011~2012 with Windows 8, and even to this day, there are sufficiently
>  buggy hardware platforms that Linux does not boot in UEFI mode:
>  https://twitter.com/VKCsh/status/1511132132885815307
>
>  I even have one such machine, an HP desktop machine that came with
>  Windows 8. My current desktop PC has problems booting Linux UEFI as
>  well, though I've done "clever" things to work around that. I don't
>  expect most users to be able to deal with that. Server platforms were
>  *worse* as they were slower to offer UEFI. The first time I was able
>  to get a server with UEFI was in 2014.
>
>  And we've still failed to get ARM and RISC-V broadly on board with
>  UEFI (though that's irrelevant to this Change, even though ARM is
>  mentioned). 
In Fedora for Arm we don't support anything but UEFI for arm., on
aarch64 we've only ever supported UEFI. While you can use other
methods they're hacks and aren't actively supported on Fedora, even
ARMv7 was moved by default to UEFI back in F-33 or 34.

So from that PoV your comment on arm in the connection to Fedora is irreverent.

>  We also lack solutions for dealing with the NVIDIA driver in
>  UEFI+Secure Boot case. Are you planning to actually *fix* that now?
>  Because we still don't have a way to have kernel-only keyrings for
>  secure boot certificates to avoid importing them into the firmware. 
This is out of context here because you can disable Secure Boot but
still use UEFI to make that work. You're trying to link to different
problems together.

[Marc Pervaz Boocha]

On Tue, 2022-04-05 at 10:52 -0400, Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
>  
>  Important, relevant points from that thread (yes, I reread the entire
>  thread) that have informed this change:
>  
>  * Some machines are BIOS-only.  This change does not prevent their
>  use
>  yet, but they are effectively deprecated.  grub2 (our default
>  bootloader) is already capable of both BIOS and UEFI booting.
>  * Drawing a clear year cutoff, let alone a detailed list of hardware
>  this change affects, is basically impossible.  This is unfortunate
>  but
>  unlikely to ever change.
>  * There is no migration story from Legacy BIOS to UEFI -
>  repartitioning effectively mandates a reinstall.  As a result, we
>  don’t drop support for existing Legacy BIOS systems yet, just new
>  installations.
>  * There is no way to deprecate hardware without causing some amount
>  of friction.
>  * While at the time AWS did not support UEFI booting, that is no
>  longer the case and they support UEFI today.
>   
Even though aws supports UEFI, many vps providers do not(Vultr and
Linode are some examples). But having a soft corner for Systemd-boot
and UEFI in general, I think there could be a middle ground. I believe
most BIOSes can boot GPT formated disk although there are few that can
not and I believe windows never supported this config. But since most
of the remaining consumers which real need this configs are VPSes which
generaly do not dual boot with windows. Also we can drop support for
all bios only bootloader as grub is good enough here.
If there is a way to push these companies to to switch to UEFI based VM
, that should be done. But removing all other bios config except for
bios + grub + gpt could be a fesible starting point.

[Neal Gompa]

On Tue, Apr 5, 2022 at 11:26 AM Peter Robinson <pbrobinson(a)gmail.com&gt; wrote:
>  On Tue, Apr 5, 2022 at 4:09 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  >
>  > On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  > >
>  > > https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
>  > >
>  > > == Summary ==
>  > > Make UEFI a hardware requirement for new Fedora installations on
>  > > platforms that support it (x86_64).  Legacy BIOS support is not
>  > > removed, but new non-UEFI installation is not supported on those
>  > > platforms.  This is a first step toward eventually removing legacy
>  > > BIOS support entirely.
>  > >
>  > > == Owner ==
>  > > * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří
>  > > Konečný]], [[User:bcl| Brian C. Lane]]
>  > > * Email: rharwood(a)redhat.com
>  > >
>  > >
>  > > == Detailed Description ==
>  > > UEFI is defined by a versioned standard that can be tested and
>  > > certified against.  By contrast, every legacy BIOS is unique. Legacy
>  > > BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple)
>  > > and on its way out.  As it ages, maintainability has decreased, and
>  > > the status quo of maintaining both stacks in perpetuity is not viable
>  > > for those currently doing that work.
>  > >
>  > > It is inevitable that legacy BIOS will be removed in a future release.
>  > > To ease this transition as best we can, there will be a period (of at
>  > > least one Fedora release) where it will be possible to boot using the
>  > > legacy BIOS codepaths, but new installations will not be possible.
>  > > While it would be easier for us to cut support off today, our hope is
>  > > that this compromise position will make for a smoother transition.
>  > > Additional support with issues during the transition would be
>  > > appreciated.
>  > >
>  > > While this will eventually reduce workload for boot/installation
>  > > components (grub2 reduces surface area, syslinux goes away entirely,
>  > > anaconda reduces surface area), the reduction in support burden
>  > > extends much further into the stack - for instance, VESA support can
>  > > be removed from the distro.
>  > >
>  > > Fedora already requires a 2GHz dual core CPU at minimum (and therefore
>  > > mandates that machines must have been made after 2006).  Like the
>  > > already accepted Fedora 37 change to retire ARMv7 support, the
>  > > hardware targeted tends to be rather underpowered by today’s
>  > > standards, and the world has moved on from it.  Intel stopped shipping
>  > > the last vestiges of BIOS support in 2020 (as have other vendors, and
>  > > Apple and Microsoft), so this is clearly the way things are heading -
>  > > and therefore aligns with Fedora’s “First” objective.
>  > >
>  > > == Feedback ==
>  > > Dropping legacy BIOS was previously discussed (but not proposed) in 2020:
>  > >
> https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject...
>  > >
>  > > Important, relevant points from that thread (yes, I reread the entire
>  > > thread) that have informed this change:
>  > >
>  > > * Some machines are BIOS-only.  This change does not prevent their use
>  > > yet, but they are effectively deprecated.  grub2 (our default
>  > > bootloader) is already capable of both BIOS and UEFI booting.
>  > > * Drawing a clear year cutoff, let alone a detailed list of hardware
>  > > this change affects, is basically impossible.  This is unfortunate but
>  > > unlikely to ever change.
>  > > * There is no migration story from Legacy BIOS to UEFI -
>  > > repartitioning effectively mandates a reinstall.  As a result, we
>  > > don’t drop support for existing Legacy BIOS systems yet, just new
>  > > installations.
>  > > * There is no way to deprecate hardware without causing some amount of
> friction.
>  > > * While at the time AWS did not support UEFI booting, that is no
>  > > longer the case and they support UEFI today.
>  > >
>  > > == Benefit to Fedora ==
>  > > UEFI is required for many desirable features, including applying
>  > > firmware updates (fwupd) and supporting SecureBoot.  As a standalone
>  > > change, it reduces support burden on everything involved in installing
>  > > Fedora, since there becomes only one way to do it per platform.
>  > > Finally, it simplifies our install/live media, since it too only has
>  > > to boot one way per arch.  Freedom Friends Features First - this is
>  > > that last one.
>  > >
>  > > == Scope ==
>  > > * Proposal owners:
>  > > ** bootloaders: No change (existing Legacy BIOS installations still
> supported).
>  > > ** anaconda: No change (there could be only optional cleanups in the
>  > > code). However, it needs to be verified.
>  > > ** Lorax: Code has already been written:
>  > > https://github.com/weldr/lorax/pull/1205
>  > >
>  >
>  > This pull request primarily drops legacy BIOS support by dropping
>  > syslinux/isolinux. We don't necessarily have to drop legacy BIOS
>  > support there if we reuse GRUB there too. Other distributions
>  > (openSUSE and Mageia, notably) both use GRUB for both BIOS and UEFI on
>  > live media.
>  >
>  > > * Other developers:
>  > > ** libvirt: UEFI works today, but is not the default.  UEFI-only
>  > > installation is needed for Windows 11, and per conversations, libvirt
>  > > is prepared for this change.
>  > > ** Virtualbox: UEFI Fedora installs are working and per virtualbox
>  > > team, UEFI will be/is the default in 7.0+.
>  > > ** The Hardware Overview page should be updated to mention the UEFI
>  > > requirement:
> https://docs.fedoraproject.org/en-US/fedora/rawhide/release-notes/welcome...
>  > >
>  > > * Release engineering: [https://pagure.io/releng/issue/10738 #Releng
>  > > issue 10738]
>  > >
>  > > * Policies and guidelines: N/A (not needed for this Change)
>  > >
>  > > * Trademark approval: N/A (not needed for this Change)
>  > >
>  > > * Alignment with Objectives: N/A
>  > >
>  > > == Upgrade/compatibility impact ==
>  > > Systems currently using Legacy BIOS for booting on x86_64 will
>  > > continue to do so.
>  > >
>  > > However, this modifies the baseline Fedora requirements and some
>  > > hardware will no longer be supported for new installations.
>  > >
>  > > == How To Test ==
>  > > UEFI installation has been supported for quite a while already, so
>  > > additional testing there should not be required.
>  > >
>  > > == User Experience ==
>  > > Installs will continue to work on UEFI, and will not work on Legacy
>  > > BIOS.  Our install media is already UEFI-capable.
>  > >
>  > > == Dependencies ==
>  > > None
>  > >
>  > > == Contingency Plan ==
>  > > Leave things as they are.  Code continues to rot.  Community
>  > > assistance is required to continue the status quo.  Current owners
>  > > plan to orphan some packages regardless of whether the proposal is
>  > > accepted.
>  > >
>  > > Another fallback option could be, if a Legacy BIOS SIG organizes, to
>  > > donate the relevant packages there and provide some initial mentoring.
>  > > Longer term, packages that cannot be wholly donated could be split,
>  > > though it is unclear whether the synchronization thereby required
>  > > would reduce the work for anyone.
>  > >
>  > > * Contingency mechanism: Delay until next release.
>  > > * Contingency deadline: Beta freeze
>  > > * Blocks release? No
>  > >
>  > > == Documentation ==
>  > > See release notes.
>  > >
>  > > == Release Notes ==
>  > > Fedora 37 marks legacy BIOS installation as deprecated on x86_64 in
>  > > favor of UEFI.  While systems already using Legacy BIOS to boot are
>  > > still supported, new legacy BIOS installations on these architectures
>  > > are no longer possible.  Legacy BIOS support will be removed entirely
>  > > in a future Fedora.
>  > >
>  > > (Additionally, the Hardware Overview page should be updated to mention
>  > > the UEFI requirement.)
>  > >
>  >
>  > While I'm sympathetic to this Change, I think this is way too early to
>  > do across the board. UEFI came onto the scene in the PC space in
>  > 2011~2012 with Windows 8, and even to this day, there are sufficiently
>  > buggy hardware platforms that Linux does not boot in UEFI mode:
>  > https://twitter.com/VKCsh/status/1511132132885815307
>  >
>  > I even have one such machine, an HP desktop machine that came with
>  > Windows 8. My current desktop PC has problems booting Linux UEFI as
>  > well, though I've done "clever" things to work around that. I
> don't
>  > expect most users to be able to deal with that. Server platforms were
>  > *worse* as they were slower to offer UEFI. The first time I was able
>  > to get a server with UEFI was in 2014.
>  >
>  > And we've still failed to get ARM and RISC-V broadly on board with
>  > UEFI (though that's irrelevant to this Change, even though ARM is
>  > mentioned).
>
>  In Fedora for Arm we don't support anything but UEFI for arm., on
>  aarch64 we've only ever supported UEFI. While you can use other
>  methods they're hacks and aren't actively supported on Fedora, even
>  ARMv7 was moved by default to UEFI back in F-33 or 34.
>
>  So from that PoV your comment on arm in the connection to Fedora is irreverent.
>  
Then why even bother mentioning it in the Change?

>  > We also lack solutions for dealing with the NVIDIA driver in
>  > UEFI+Secure Boot case. Are you planning to actually *fix* that now?
>  > Because we still don't have a way to have kernel-only keyrings for
>  > secure boot certificates to avoid importing them into the firmware.
>
>  This is out of context here because you can disable Secure Boot but
>  still use UEFI to make that work. You're trying to link to different
>  problems together. 
It is easier to tell people to boot the media in BIOS mode in some
cases than it is to figure out how to turn off Secure Boot.

You're right that these are different problems, but I've also seen
very little appetite for reducing the suffering of Fedora Linux users
on UEFI Secure Boot with the *most common issue* we have: an NVIDIA
driver that doesn't do anything because of the lockdown feature. If
you're planning to say that UEFI is the only way to boot, then that
means you need to be prepared to accept that our UEFI experience is
*worse* than our BIOS one right now, and someone needs to take
ownership to improve it.

By virtue of how boot stuff is handled in Fedora, the community is
incapable of working on it. Those packages are the most locked down in
the entire distribution (for not entirely bad reasons), but the
consequence is that there's a very distinct ownership there that
doesn't exist for the rest of the distribution.

We also still have problems today with UEFI that get very little love:
https://bugzilla.redhat.com/show_bug.cgi?id=1955416

Fundamentally, this Change is premature unless there's a fundamental
decision that there's going to be more activity to solve these
problems. You're saying that this will reduce maintenance burden, but
virtually every boot bug I've seen for the last few Fedora releases
have been around UEFI, *not* BIOS. And it's a very real struggle to
get UEFI bugs fixed.


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

[Florian Weimer]

* Peter Robinson:

>  This is out of context here because you can disable Secure Boot but
>  still use UEFI to make that work. You're trying to link to different
>  problems together. 
I think there's firmware out there which enables Secure Boot
unconditionally in UEFI mode, but still has CSM support.

Thanks,
Florian

[Robbie Harwood]

Neal Gompa <ngompa13(a)gmail.com&gt; writes:

>  And we've still failed to get ARM and RISC-V broadly on board
> with
>  UEFI 
This statement is not correct.  ARM in Fedora is UEFI-only, and we were
both in the Plumbers conversation around RISC-V's booting.

>  We also lack solutions for dealing with the NVIDIA driver in
>  UEFI+Secure Boot case. Are you planning to actually *fix* that now?
>  Because we still don't have a way to have kernel-only keyrings for
>  secure boot certificates to avoid importing them into the firmware. 
Users wishing to use NVIDIA hardware have the following options:

- Use nouveau (free, open source, cool)
- Sign their own copy of the proprietary driver (involves messing with
  certificates, so not appropriate for all users)
- Disable Secure Boot (note that this is still UEFI)

The NVIDIA driver is proprietary, so of course it's not going to get
signed.

Be well,
--Robbie

[Michael Catanzaro]

On Tue, Apr 5 2022 at 11:56:07 AM -0400, Robbie Harwood 
<rharwood(a)redhat.com&gt; wrote:
>  Users wishing to use NVIDIA hardware have the following options:
>  
>  - Use nouveau (free, open source, cool)
>  - Sign their own copy of the proprietary driver (involves messing with
>    certificates, so not appropriate for all users)
>  - Disable Secure Boot (note that this is still UEFI)
>  
>  The NVIDIA driver is proprietary, so of course it's not going to get
>  signed. 
The user experience requirement is: user searches for NVIDIA in GNOME 
Software and clicks Install. No further action should be necessary. We 
didn't make the NVIDIA driver available from the graphical installer 
with the intention that arcane workarounds would be required to use it.

Michael

[David Duncan]

>  On Apr 5, 2022, at 8:08 AM, Neal Gompa <ngompa13(a)gmail.com&gt;
> wrote:
>  
>  On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
> > 
> > https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
> > 
> > == Summary ==
> > Make UEFI a hardware requirement for new Fedora installations on
> > platforms that support it (x86_64).  Legacy BIOS support is not
> > removed, but new non-UEFI installation is not supported on those
> > platforms.  This is a first step toward eventually removing legacy
> > BIOS support entire
> > 
> > == Owner ==
> > * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří
> > Konečný]], [[User:bcl| Brian C. Lane]]
> > * Email: rharwood(a)redhat.com
> > 
> > 
> > == Detailed Description ==
> > UEFI is defined by a versioned standard that can be tested and
> > certified against.  By contrast, every legacy BIOS is unique. Legacy
> > BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple)
> > and on its way out.  As it ages, maintainability has decreased, and
> > the status quo of maintaining both stacks in perpetuity is not viable
> > for those currently doing that work.
> > 
> > It is inevitable that legacy BIOS will be removed in a future release.
> > To ease this transition as best we can, there will be a period (of at
> > least one Fedora release) where it will be possible to boot using the
> > legacy BIOS codepaths, but new installations will not be possible.
> > While it would be easier for us to cut support off today, our hope is
> > that this compromise position will make for a smoother transition.
> > Additional support with issues during the transition would be
> > appreciated.
> > 
> > While this will eventually reduce workload for boot/installation
> > components (grub2 reduces surface area, syslinux goes away entirely,
> > anaconda reduces surface area), the reduction in support burden
> > extends much further into the stack - for instance, VESA support can
> > be removed from the distro.
> > 
> > Fedora already requires a 2GHz dual core CPU at minimum (and therefore
> > mandates that machines must have been made after 2006).  Like the
> > already accepted Fedora 37 change to retire ARMv7 support, the
> > hardware targeted tends to be rather underpowered by today’s
> > standards, and the world has moved on from it.  Intel stopped shipping
> > the last vestiges of BIOS support in 2020 (as have other vendors, and
> > Apple and Microsoft), so this is clearly the way things are heading -
> > and therefore aligns with Fedora’s “First” objective.
> > 
> > == Feedback ==
> > Dropping legacy BIOS was previously discussed (but not proposed) in 2020:
> >
> https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject...
> > 
> > Important, relevant points from that thread (yes, I reread the entire
> > thread) that have informed this change:
> > 
> > * Some machines are BIOS-only.  This change does not prevent their use
> > yet, but they are effectively deprecated.  grub2 (our default
> > bootloader) is already capable of both BIOS and UEFI booting.
> > * Drawing a clear year cutoff, let alone a detailed list of hardware
> > this change affects, is basically impossible.  This is unfortunate but
> > unlikely to ever change.
> > * There is no migration story from Legacy BIOS to UEFI -
> > repartitioning effectively mandates a reinstall.  As a result, we
> > don’t drop support for existing Legacy BIOS systems yet, just new
> > installations.
> > * There is no way to deprecate hardware without causing some amount of friction.
> > * While at the time AWS did not support UEFI booting, that is no
> > longer the case and they support UEFI today.
> > 
> > == Benefit to Fedora ==
> > UEFI is required for many desirable features, including applying
> > firmware updates (fwupd) and supporting SecureBoot.  As a standalone
> > change, it reduces support burden on everything involved in installing
> > Fedora, since there becomes only one way to do it per platform.
> > Finally, it simplifies our install/live media, since it too only has
> > to boot one way per arch.  Freedom Friends Features First - this is
> > that last one.
> > 
> > == Scope ==
> > * Proposal owners:
> > ** bootloaders: No change (existing Legacy BIOS installations still supported).
> > ** anaconda: No change (there could be only optional cleanups in the
> > code). However, it needs to be verified.
> > ** Lorax: Code has already been written:
> > https://github.com/weldr/lorax/pull/1205
> > 
>  
>  This pull request primarily drops legacy BIOS support by dropping
>  syslinux/isolinux. We don't necessarily have to drop legacy BIOS
>  support there if we reuse GRUB there too. Other distributions
>  (openSUSE and Mageia, notably) both use GRUB for both BIOS and UEFI on
>  live media.
>  
> > * Other developers:
> > ** libvirt: UEFI works today, but is not the default.  UEFI-only
> > installation is needed for Windows 11, and per conversations, libvirt
> > is prepared for this change.
> > ** Virtualbox: UEFI Fedora installs are working and per virtualbox
> > team, UEFI will be/is the default in 7.0+.
> > ** The Hardware Overview page should be updated to mention the UEFI
> > requirement:
> https://docs.fedoraproject.org/en-US/fedora/rawhide/release-notes/welcome...
> > 
> > * Release engineering: [https://pagure.io/releng/issue/10738 #Releng
> > issue 10738]
> > 
> > * Policies and guidelines: N/A (not needed for this Change)
> > 
> > * Trademark approval: N/A (not needed for this Change)
> > 
> > * Alignment with Objectives: N/A
> > 
> > == Upgrade/compatibility impact ==
> > Systems currently using Legacy BIOS for booting on x86_64 will
> > continue to do so.
> > 
> > However, this modifies the baseline Fedora requirements and some
> > hardware will no longer be supported for new installations.
> > 
> > == How To Test ==
> > UEFI installation has been supported for quite a while already, so
> > additional testing there should not be required.
> > 
> > == User Experience ==
> > Installs will continue to work on UEFI, and will not work on Legacy
> > BIOS.  Our install media is already UEFI-capable.
> > 
> > == Dependencies ==
> > None
> > 
> > == Contingency Plan ==
> > Leave things as they are.  Code continues to rot.  Community
> > assistance is required to continue the status quo.  Current owners
> > plan to orphan some packages regardless of whether the proposal is
> > accepted.
> > 
> > Another fallback option could be, if a Legacy BIOS SIG organizes, to
> > donate the relevant packages there and provide some initial mentoring.
> > Longer term, packages that cannot be wholly donated could be split,
> > though it is unclear whether the synchronization thereby required
> > would reduce the work for anyone.
> > 
> > * Contingency mechanism: Delay until next release.
> > * Contingency deadline: Beta freeze
> > * Blocks release? No
> > 
> > == Documentation ==
> > See release notes.
> > 
> > == Release Notes ==
> > Fedora 37 marks legacy BIOS installation as deprecated on x86_64 in
> > favor of UEFI.  While systems already using Legacy BIOS to boot are
> > still supported, new legacy BIOS installations on these architectures
> > are no longer possible.  Legacy BIOS support will be removed entirely
> > in a future Fedora.
> > 
> > (Additionally, the Hardware Overview page should be updated to mention
> > the UEFI requirement.)
> > 
>  
>  While I'm sympathetic to this Change, I think this is way too early to
>  do across the board. UEFI came onto the scene in the PC space in
>  2011~2012 with Windows 8, and even to this day, there are sufficiently
>  buggy hardware platforms that Linux does not boot in UEFI mode:
>  https://twitter.com/VKCsh/status/1511132132885815307
>  
>  I even have one such machine, an HP desktop machine that came with
>  Windows 8. My current desktop PC has problems booting Linux UEFI as
>  well, though I've done "clever" things to work around that. I don't
>  expect most users to be able to deal with that. Server platforms were
>  *worse* as they were slower to offer UEFI. The first time I was able
>  to get a server with UEFI was in 2014.
>  
>  And we've still failed to get ARM and RISC-V broadly on board with
>  UEFI (though that's irrelevant to this Change, even though ARM is
>  mentioned).
>  
>  We also lack solutions for dealing with the NVIDIA driver in
>  UEFI+Secure Boot case. Are you planning to actually *fix* that now?
>  Because we still don't have a way to have kernel-only keyrings for
>  secure boot certificates to avoid importing them into the firmware.
>   
For similar reasons, I agree with Neal. There are a number of Amazon EC2 instance types
that would be left out of the next generation. I think it would be better to identify the
usage in some way and create a general awareness that it is being removed prior to
outright removing it. The deprecation period is important IMO.

[Jared Dominguez]

On Tue, Apr 5, 2022, 11:15 Neal Gompa <ngompa13(a)gmail.com&gt; wrote:

>  On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton <bcotton(a)redhat.com&gt;
> wrote:
>  >
>  > https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
>  >
>  > == Summary ==
>  > Make UEFI a hardware requirement for new Fedora installations on
>  > platforms that support it (x86_64).  Legacy BIOS support is not
>  > removed, but new non-UEFI installation is not supported on those
>  > platforms.  This is a first step toward eventually removing legacy
>  > BIOS support entirely.
>  >
>  > == Owner ==
>  > * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří
>  > Konečný]], [[User:bcl| Brian C. Lane]]
>  > * Email: rharwood(a)redhat.com
>  >
>  >
>  > == Detailed Description ==
>  > UEFI is defined by a versioned standard that can be tested and
>  > certified against.  By contrast, every legacy BIOS is unique. Legacy
>  > BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple)
>  > and on its way out.  As it ages, maintainability has decreased, and
>  > the status quo of maintaining both stacks in perpetuity is not viable
>  > for those currently doing that work.
>  >
>  > It is inevitable that legacy BIOS will be removed in a future release.
>  > To ease this transition as best we can, there will be a period (of at
>  > least one Fedora release) where it will be possible to boot using the
>  > legacy BIOS codepaths, but new installations will not be possible.
>  > While it would be easier for us to cut support off today, our hope is
>  > that this compromise position will make for a smoother transition.
>  > Additional support with issues during the transition would be
>  > appreciated.
>  >
>  > While this will eventually reduce workload for boot/installation
>  > components (grub2 reduces surface area, syslinux goes away entirely,
>  > anaconda reduces surface area), the reduction in support burden
>  > extends much further into the stack - for instance, VESA support can
>  > be removed from the distro.
>  >
>  > Fedora already requires a 2GHz dual core CPU at minimum (and therefore
>  > mandates that machines must have been made after 2006).  Like the
>  > already accepted Fedora 37 change to retire ARMv7 support, the
>  > hardware targeted tends to be rather underpowered by today’s
>  > standards, and the world has moved on from it.  Intel stopped shipping
>  > the last vestiges of BIOS support in 2020 (as have other vendors, and
>  > Apple and Microsoft), so this is clearly the way things are heading -
>  > and therefore aligns with Fedora’s “First” objective.
>  >
>  > == Feedback ==
>  > Dropping legacy BIOS was previously discussed (but not proposed) in 2020:
>  >
>
> https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject...
>  >
>  > Important, relevant points from that thread (yes, I reread the entire
>  > thread) that have informed this change:
>  >
>  > * Some machines are BIOS-only.  This change does not prevent their use
>  > yet, but they are effectively deprecated.  grub2 (our default
>  > bootloader) is already capable of both BIOS and UEFI booting.
>  > * Drawing a clear year cutoff, let alone a detailed list of hardware
>  > this change affects, is basically impossible.  This is unfortunate but
>  > unlikely to ever change.
>  > * There is no migration story from Legacy BIOS to UEFI -
>  > repartitioning effectively mandates a reinstall.  As a result, we
>  > don’t drop support for existing Legacy BIOS systems yet, just new
>  > installations.
>  > * There is no way to deprecate hardware without causing some amount of
>  friction.
>  > * While at the time AWS did not support UEFI booting, that is no
>  > longer the case and they support UEFI today.
>  >
>  > == Benefit to Fedora ==
>  > UEFI is required for many desirable features, including applying
>  > firmware updates (fwupd) and supporting SecureBoot.  As a standalone
>  > change, it reduces support burden on everything involved in installing
>  > Fedora, since there becomes only one way to do it per platform.
>  > Finally, it simplifies our install/live media, since it too only has
>  > to boot one way per arch.  Freedom Friends Features First - this is
>  > that last one.
>  >
>  > == Scope ==
>  > * Proposal owners:
>  > ** bootloaders: No change (existing Legacy BIOS installations still
>  supported).
>  > ** anaconda: No change (there could be only optional cleanups in the
>  > code). However, it needs to be verified.
>  > ** Lorax: Code has already been written:
>  > https://github.com/weldr/lorax/pull/1205
>  >
>
>  This pull request primarily drops legacy BIOS support by dropping
>  syslinux/isolinux. We don't necessarily have to drop legacy BIOS
>  support there if we reuse GRUB there too. Other distributions
>  (openSUSE and Mageia, notably) both use GRUB for both BIOS and UEFI on
>  live media.
>
>  > * Other developers:
>  > ** libvirt: UEFI works today, but is not the default.  UEFI-only
>  > installation is needed for Windows 11, and per conversations, libvirt
>  > is prepared for this change.
>  > ** Virtualbox: UEFI Fedora installs are working and per virtualbox
>  > team, UEFI will be/is the default in 7.0+.
>  > ** The Hardware Overview page should be updated to mention the UEFI
>  > requirement:
>
> https://docs.fedoraproject.org/en-US/fedora/rawhide/release-notes/welcome...
>  >
>  > * Release engineering: [https://pagure.io/releng/issue/10738 #Releng
>  > issue 10738]
>  >
>  > * Policies and guidelines: N/A (not needed for this Change)
>  >
>  > * Trademark approval: N/A (not needed for this Change)
>  >
>  > * Alignment with Objectives: N/A
>  >
>  > == Upgrade/compatibility impact ==
>  > Systems currently using Legacy BIOS for booting on x86_64 will
>  > continue to do so.
>  >
>  > However, this modifies the baseline Fedora requirements and some
>  > hardware will no longer be supported for new installations.
>  >
>  > == How To Test ==
>  > UEFI installation has been supported for quite a while already, so
>  > additional testing there should not be required.
>  >
>  > == User Experience ==
>  > Installs will continue to work on UEFI, and will not work on Legacy
>  > BIOS.  Our install media is already UEFI-capable.
>  >
>  > == Dependencies ==
>  > None
>  >
>  > == Contingency Plan ==
>  > Leave things as they are.  Code continues to rot.  Community
>  > assistance is required to continue the status quo.  Current owners
>  > plan to orphan some packages regardless of whether the proposal is
>  > accepted.
>  >
>  > Another fallback option could be, if a Legacy BIOS SIG organizes, to
>  > donate the relevant packages there and provide some initial mentoring.
>  > Longer term, packages that cannot be wholly donated could be split,
>  > though it is unclear whether the synchronization thereby required
>  > would reduce the work for anyone.
>  >
>  > * Contingency mechanism: Delay until next release.
>  > * Contingency deadline: Beta freeze
>  > * Blocks release? No
>  >
>  > == Documentation ==
>  > See release notes.
>  >
>  > == Release Notes ==
>  > Fedora 37 marks legacy BIOS installation as deprecated on x86_64 in
>  > favor of UEFI.  While systems already using Legacy BIOS to boot are
>  > still supported, new legacy BIOS installations on these architectures
>  > are no longer possible.  Legacy BIOS support will be removed entirely
>  > in a future Fedora.
>  >
>  > (Additionally, the Hardware Overview page should be updated to mention
>  > the UEFI requirement.)
>  >
>
>  While I'm sympathetic to this Change, I think this is way too early to
>  do across the board. UEFI came onto the scene in the PC space in
>  2011~2012 with Windows 8, and even to this day, there are sufficiently
>  buggy hardware platforms that Linux does not boot in UEFI mode:
>  https://twitter.com/VKCsh/status/1511132132885815307 

Those platforms boot Windows with UEFI. If there are outstanding bugs,
we're looking at Linux bugs that are being worked around.

I even have one such machine, an HP desktop machine that came with
>  Windows 8. My current desktop PC has problems booting Linux UEFI as
>  well, though I've done "clever" things to work around that. I don't
>  expect most users to be able to deal with that. Server platforms were
>  *worse* as they were slower to offer UEFI. The first time I was able
>  to get a server with UEFI was in 2014.
>  
The Dell PowerEdge R710, which was their flagship two socket server
launched in 2009, supported UEFI. Even if there were some bugs, I remember
it booted in UEFI mode quite fine with several Linux distro back in
2011-2012, because I was at Dell on their server OS team debugging issues
that came up with that platform then.

And we've still failed to get ARM and RISC-V broadly on board with
>  UEFI (though that's irrelevant to this Change, even though ARM
> is
>  mentioned).
>
>  We also lack solutions for dealing with the NVIDIA driver in
>  UEFI+Secure Boot case. Are you planning to actually *fix* that now?
>  Because we still don't have a way to have kernel-only keyrings for
>  secure boot certificates to avoid importing them into the firmware. 

Secure Boot is a different matter from UEFI. UEFI provides a lot more than
just that feature. Let's not derail this proposal with that.

--
>  真実はいつも一つ！/ Always, there's only one truth!
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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
>

[Marc Pervaz Boocha]

On Tue, 2022-04-05 at 09:33 -0700, David Duncan wrote:
>  
>  
>  > On Apr 5, 2022, at 8:08 AM, Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  > 
>  > On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton <bcotton(a)redhat.com&gt;
>  > wrote:
>  > > 
>  > > https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
>  > > 
>  > > == Summary ==
>  > > Make UEFI a hardware requirement for new Fedora installations on
>  > > platforms that support it (x86_64).  Legacy BIOS support is not
>  > > removed, but new non-UEFI installation is not supported on those
>  > > platforms.  This is a first step toward eventually removing
>  > > legacy
>  > > BIOS support entire
>  > > 
>  > > == Owner ==
>  > > * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří
>  > > Konečný]], [[User:bcl| Brian C. Lane]]
>  > > * Email: rharwood(a)redhat.com
>  > > 
>  > > 
>  > > == Detailed Description ==
>  > > UEFI is defined by a versioned standard that can be tested and
>  > > certified against.  By contrast, every legacy BIOS is unique.
>  > > Legacy
>  > > BIOS is widely considered deprecated (Intel, AMD, Microsoft,
>  > > Apple)
>  > > and on its way out.  As it ages, maintainability has decreased,
>  > > and
>  > > the status quo of maintaining both stacks in perpetuity is not
>  > > viable
>  > > for those currently doing that work.
>  > > 
>  > > It is inevitable that legacy BIOS will be removed in a future
>  > > release.
>  > > To ease this transition as best we can, there will be a period
>  > > (of at
>  > > least one Fedora release) where it will be possible to boot using
>  > > the
>  > > legacy BIOS codepaths, but new installations will not be
>  > > possible.
>  > > While it would be easier for us to cut support off today, our
>  > > hope is
>  > > that this compromise position will make for a smoother
>  > > transition.
>  > > Additional support with issues during the transition would be
>  > > appreciated.
>  > > 
>  > > While this will eventually reduce workload for boot/installation
>  > > components (grub2 reduces surface area, syslinux goes away
>  > > entirely,
>  > > anaconda reduces surface area), the reduction in support burden
>  > > extends much further into the stack - for instance, VESA support
>  > > can
>  > > be removed from the distro.
>  > > 
>  > > Fedora already requires a 2GHz dual core CPU at minimum (and
>  > > therefore
>  > > mandates that machines must have been made after 2006).  Like the
>  > > already accepted Fedora 37 change to retire ARMv7 support, the
>  > > hardware targeted tends to be rather underpowered by today’s
>  > > standards, and the world has moved on from it.  Intel stopped
>  > > shipping
>  > > the last vestiges of BIOS support in 2020 (as have other vendors,
>  > > and
>  > > Apple and Microsoft), so this is clearly the way things are
>  > > heading -
>  > > and therefore aligns with Fedora’s “First” objective.
>  > > 
>  > > == Feedback ==
>  > > Dropping legacy BIOS was previously discussed (but not proposed)
>  > > in 2020:
>  > >
> https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject...
>  > > 
>  > > Important, relevant points from that thread (yes, I reread the
>  > > entire
>  > > thread) that have informed this change:
>  > > 
>  > > * Some machines are BIOS-only.  This change does not prevent
>  > > their use
>  > > yet, but they are effectively deprecated.  grub2 (our default
>  > > bootloader) is already capable of both BIOS and UEFI booting.
>  > > * Drawing a clear year cutoff, let alone a detailed list of
>  > > hardware
>  > > this change affects, is basically impossible.  This is
>  > > unfortunate but
>  > > unlikely to ever change.
>  > > * There is no migration story from Legacy BIOS to UEFI -
>  > > repartitioning effectively mandates a reinstall.  As a result, we
>  > > don’t drop support for existing Legacy BIOS systems yet, just new
>  > > installations.
>  > > * There is no way to deprecate hardware without causing some
>  > > amount of friction.
>  > > * While at the time AWS did not support UEFI booting, that is no
>  > > longer the case and they support UEFI today.
>  > > 
>  > > == Benefit to Fedora ==
>  > > UEFI is required for many desirable features, including applying
>  > > firmware updates (fwupd) and supporting SecureBoot.  As a
>  > > standalone
>  > > change, it reduces support burden on everything involved in
>  > > installing
>  > > Fedora, since there becomes only one way to do it per platform.
>  > > Finally, it simplifies our install/live media, since it too only
>  > > has
>  > > to boot one way per arch.  Freedom Friends Features First - this
>  > > is
>  > > that last one.
>  > > 
>  > > == Scope ==
>  > > * Proposal owners:
>  > > ** bootloaders: No change (existing Legacy BIOS installations
>  > > still supported).
>  > > ** anaconda: No change (there could be only optional cleanups in
>  > > the
>  > > code). However, it needs to be verified.
>  > > ** Lorax: Code has already been written:
>  > > https://github.com/weldr/lorax/pull/1205
>  > > 
>  > 
>  > This pull request primarily drops legacy BIOS support by dropping
>  > syslinux/isolinux. We don't necessarily have to drop legacy BIOS
>  > support there if we reuse GRUB there too. Other distributions
>  > (openSUSE and Mageia, notably) both use GRUB for both BIOS and UEFI
>  > on
>  > live media.
>  > 
>  > > * Other developers:
>  > > ** libvirt: UEFI works today, but is not the default.  UEFI-only
>  > > installation is needed for Windows 11, and per conversations,
>  > > libvirt
>  > > is prepared for this change.
>  > > ** Virtualbox: UEFI Fedora installs are working and per
>  > > virtualbox
>  > > team, UEFI will be/is the default in 7.0+.
>  > > ** The Hardware Overview page should be updated to mention the
>  > > UEFI
>  > > requirement:
>  > >
> https://docs.fedoraproject.org/en-US/fedora/rawhide/release-notes/welcome...
>  > > 
>  > > * Release engineering:
>  > > [https://pagure.io/releng/issue/10738 #Releng
>  > > issue 10738]
>  > > 
>  > > * Policies and guidelines: N/A (not needed for this Change)
>  > > 
>  > > * Trademark approval: N/A (not needed for this Change)
>  > > 
>  > > * Alignment with Objectives: N/A
>  > > 
>  > > == Upgrade/compatibility impact ==
>  > > Systems currently using Legacy BIOS for booting on x86_64 will
>  > > continue to do so.
>  > > 
>  > > However, this modifies the baseline Fedora requirements and some
>  > > hardware will no longer be supported for new installations.
>  > > 
>  > > == How To Test ==
>  > > UEFI installation has been supported for quite a while already,
>  > > so
>  > > additional testing there should not be required.
>  > > 
>  > > == User Experience ==
>  > > Installs will continue to work on UEFI, and will not work on
>  > > Legacy
>  > > BIOS.  Our install media is already UEFI-capable.
>  > > 
>  > > == Dependencies ==
>  > > None
>  > > 
>  > > == Contingency Plan ==
>  > > Leave things as they are.  Code continues to rot.  Community
>  > > assistance is required to continue the status quo.  Current
>  > > owners
>  > > plan to orphan some packages regardless of whether the proposal
>  > > is
>  > > accepted.
>  > > 
>  > > Another fallback option could be, if a Legacy BIOS SIG organizes,
>  > > to
>  > > donate the relevant packages there and provide some initial
>  > > mentoring.
>  > > Longer term, packages that cannot be wholly donated could be
>  > > split,
>  > > though it is unclear whether the synchronization thereby required
>  > > would reduce the work for anyone.
>  > > 
>  > > * Contingency mechanism: Delay until next release.
>  > > * Contingency deadline: Beta freeze
>  > > * Blocks release? No
>  > > 
>  > > == Documentation ==
>  > > See release notes.
>  > > 
>  > > == Release Notes ==
>  > > Fedora 37 marks legacy BIOS installation as deprecated on x86_64
>  > > in
>  > > favor of UEFI.  While systems already using Legacy BIOS to boot
>  > > are
>  > > still supported, new legacy BIOS installations on these
>  > > architectures
>  > > are no longer possible.  Legacy BIOS support will be removed
>  > > entirely
>  > > in a future Fedora.
>  > > 
>  > > (Additionally, the Hardware Overview page should be updated to
>  > > mention
>  > > the UEFI requirement.)
>  > > 
>  > 
>  > While I'm sympathetic to this Change, I think this is way too early
>  > to
>  > do across the board. UEFI came onto the scene in the PC space in
>  > 2011~2012 with Windows 8, and even to this day, there are
>  > sufficiently
>  > buggy hardware platforms that Linux does not boot in UEFI mode:
>  > https://twitter.com/VKCsh/status/1511132132885815307
>  > 
>  > I even have one such machine, an HP desktop machine that came with
>  > Windows 8. My current desktop PC has problems booting Linux UEFI as
>  > well, though I've done "clever" things to work around that. I
> don't
>  > expect most users to be able to deal with that. Server platforms
>  > were
>  > *worse* as they were slower to offer UEFI. The first time I was
>  > able
>  > to get a server with UEFI was in 2014.
>  > 
>  > And we've still failed to get ARM and RISC-V broadly on board with
>  > UEFI (though that's irrelevant to this Change, even though ARM is
>  > mentioned).
>  > 
>  > We also lack solutions for dealing with the NVIDIA driver in
>  > UEFI+Secure Boot case. Are you planning to actually *fix* that now?
>  > Because we still don't have a way to have kernel-only keyrings for
>  > secure boot certificates to avoid importing them into the firmware.
>  > 
>  
>  For similar reasons, I agree with Neal. There are a number of Amazon
>  EC2 instance types that would be left out of the next generation. I
>  think it would be better to identify the usage in some way and create
>  a general awareness that it is being removed prior to outright
>  removing it. The deprecation period is important IMO.  
Yes definately. Alot of other cloud companies don't have the option. I
suggest atleast a couple of years.A little inconvinence may give the
required push. Maybe only support installation from the everthing iso
so those users get that inconvinence?

>  
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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

[Robbie Harwood]

Neal Gompa <ngompa13(a)gmail.com&gt; writes:

>  By virtue of how boot stuff is handled in Fedora, the community is
>  incapable of working on it. 
Not true.  Not at all true.

src.fedoraproject.org permits anyone, *anyone* to send PRs to fix issues
in the boot stack, or any other package.  Even without it, bugzilla
doesn't lock down people helping troubleshoot, write patches, work with
upstreams, etc..

Just because you can't build an official version of the package doesn't
mean you can't help work on it.

>  Fundamentally, this Change is premature unless there's a
> fundamental
>  decision that there's going to be more activity to solve these
>  problems. You're saying that this will reduce maintenance burden, but
>  virtually every boot bug I've seen for the last few Fedora releases
>  have been around UEFI, *not* BIOS. And it's a very real struggle to
>  get UEFI bugs fixed. 
So you've heard that we're overloaded, and you know that UEFI is the
direction the world is heading.  Your solution to this is... what, stick
our heads in the sand and ignore that?  Just do legacy?  We already have
UEFI-only platforms (see also: the mention of ARM you're belaboring), so
that's obviously not going to fly, even if we were willing to, which
we're not.

Be well,
--Robbie

[Robbie Harwood]

David Duncan <davdunc(a)gmail.com&gt; writes:

>  For similar reasons, I agree with Neal. There are a number of Amazon
>  EC2 instance types that would be left out of the next generation. I
>  think it would be better to identify the usage in some way and create
>  a general awareness that it is being removed prior to outright
>  removing it. The deprecation period is important IMO. 
(Just to be clear here: this change is proposing a deprecation, not a
removal.)

Be well,
--Robbie

[Chris Adams]

Once upon a time, Robbie Harwood <rharwood(a)redhat.com&gt; said:
>  (Just to be clear here: this change is proposing a deprecation, not
> a
>  removal.) 
No, the change proposes making it impossible to install Fedora on BIOS.
That's not a deprecation.
-- 
Chris Adams <linux(a)cmadams.net&gt;

[Ralf Corsépius]

Am 05.04.22 um 16:52 schrieb Ben Cotton:
>  https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
>  
>  == Summary ==
>  Make UEFI a hardware requirement for new Fedora installations on
>  platforms that support it (x86_64).  Legacy BIOS support is not
>  removed, but new non-UEFI installation is not supported on those
>  platforms.  This is a first step toward eventually removing legacy
>  BIOS support entirely. 
Short, but hard and clear answer: No.

Ralf

[Tom Hughes]

On 05/04/2022 15:52, Ben Cotton wrote:

>  * There is no migration story from Legacy BIOS to UEFI -
>  repartitioning effectively mandates a reinstall.  As a result, we
>  don’t drop support for existing Legacy BIOS systems yet, just new
>  installations. 
This is where I have a problem with this, the fact that there is
no upgrade path - virtually my entire installed base of Fedora is
running legacy BIOS and not being able to upgrade them will be
something of a headache.

Is it actually true though? You need to be able to find some space
for an EFI partition but assuming that can be done is there some
other reason you can't migrate from BIOS to UEFI booting?

Tom

-- 
Tom Hughes (tom(a)compton.nu)
http://compton.nu/

[Neal Gompa]

On Tue, Apr 5, 2022 at 1:31 PM Tom Hughes via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  On 05/04/2022 15:52, Ben Cotton wrote:
>
>  > * There is no migration story from Legacy BIOS to UEFI -
>  > repartitioning effectively mandates a reinstall.  As a result, we
>  > don’t drop support for existing Legacy BIOS systems yet, just new
>  > installations.
>
>  This is where I have a problem with this, the fact that there is
>  no upgrade path - virtually my entire installed base of Fedora is
>  running legacy BIOS and not being able to upgrade them will be
>  something of a headache.
>
>  Is it actually true though? You need to be able to find some space
>  for an EFI partition but assuming that can be done is there some
>  other reason you can't migrate from BIOS to UEFI booting?
>  
In Fedora Linux default partitioning for all but Server, it is
possible to reconfigure existing systems to UEFI. Fedora Server is
screwed because they use XFS and you cannot shrink an XFS volume.

Fedora < 33 used ext4 by default, and you can do offline shrink and
open up space for an ESP. In Fedora >= 33, ext4 is still used for
/boot and you can resize that. Alternatively, the Btrfs / can be
resized while the system is running to make room for an ESP.

It wouldn't be difficult to provide a tool to make the conversion
possible as long as you didn't use XFS.

Fedora Cloud 35+ is configured in hybrid mode, so you can seamlessly
switch between BIOS and UEFI.

Fedora Server users *must* fully reinstall, because there's no way to
make space for an ESP and reconfigure things.






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

[Tom Hughes]

On 05/04/2022 18:38, Neal Gompa wrote:
>  On Tue, Apr 5, 2022 at 1:31 PM Tom Hughes via devel
>  <devel(a)lists.fedoraproject.org&gt; wrote:
> >
> > On 05/04/2022 15:52, Ben Cotton wrote:
> >
> >> * There is no migration story from Legacy BIOS to UEFI -
> >> repartitioning effectively mandates a reinstall.  As a result, we
> >> don’t drop support for existing Legacy BIOS systems yet, just new
> >> installations.
> >
> > This is where I have a problem with this, the fact that there is
> > no upgrade path - virtually my entire installed base of Fedora is
> > running legacy BIOS and not being able to upgrade them will be
> > something of a headache.
> >
> > Is it actually true though? You need to be able to find some space
> > for an EFI partition but assuming that can be done is there some
> > other reason you can't migrate from BIOS to UEFI booting?
>  
>  In Fedora Linux default partitioning for all but Server, it is
>  possible to reconfigure existing systems to UEFI. Fedora Server is
>  screwed because they use XFS and you cannot shrink an XFS volume.
>  
>  Fedora < 33 used ext4 by default, and you can do offline shrink and
>  open up space for an ESP. In Fedora >= 33, ext4 is still used for
>  /boot and you can resize that. Alternatively, the Btrfs / can be
>  resized while the system is running to make room for an ESP. 
I generally do my own partitioning rather than using the
default, and all my systems are ext4 so sounds like it's not
necessarily impossible.

I'm actually looking at stealing swap on some of them, or
just growing disks for VMs.

Tom

-- 
Tom Hughes (tom(a)compton.nu)
http://compton.nu/

[Richard Shaw]

On Tue, Apr 5, 2022 at 12:31 PM Tom Hughes via devel <
devel(a)lists.fedoraproject.org&gt; wrote:

>  On 05/04/2022 15:52, Ben Cotton wrote:
>
>  > * There is no migration story from Legacy BIOS to UEFI -
>  > repartitioning effectively mandates a reinstall.  As a result, we
>  > don’t drop support for existing Legacy BIOS systems yet, just new
>  > installations.
>
>  This is where I have a problem with this, the fact that there is
>  no upgrade path - virtually my entire installed base of Fedora is
>  running legacy BIOS and not being able to upgrade them will be
>  something of a headache.
>
>  Is it actually true though? You need to be able to find some space
>  for an EFI partition but assuming that can be done is there some
>  other reason you can't migrate from BIOS to UEFI booting?
>  
I actually did it manually several releases ago when I got a new computer
that supported EFI but kept the same OS drive.

I'm not going to lie, it was VERY painful and took me a while to figure
everything out, a lot of googling and trying stuff. It wasn't for the faint
of heart.

Thanks,
Richard

[Gregory Bartholomew]

On Tue, Apr 5, 2022 at 12:39 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:

>  Fedora Server users *must* fully reinstall, because there's no
> way to
>  make space for an ESP and reconfigure things.
>  
I haven't done a "default" Fedora Server installation in a long time, so
I'm not sure how they are laid out. But I seem to remember /boot being a
separate partition for a long time (it used to be required because some
older BOISs couldn't read beyond a certain sector on the disk). Could not
/boot be converted to the ESP (i.e. reformatted with FAT32) on such systems?

[Neal Gompa]

On Tue, Apr 5, 2022 at 1:46 PM Tom Hughes <tom(a)compton.nu&gt; wrote:
>  On 05/04/2022 18:38, Neal Gompa wrote:
>  > On Tue, Apr 5, 2022 at 1:31 PM Tom Hughes via devel
>  > <devel(a)lists.fedoraproject.org&gt; wrote:
>  >>
>  >> On 05/04/2022 15:52, Ben Cotton wrote:
>  >>
>  >>> * There is no migration story from Legacy BIOS to UEFI -
>  >>> repartitioning effectively mandates a reinstall.  As a result, we
>  >>> don’t drop support for existing Legacy BIOS systems yet, just new
>  >>> installations.
>  >>
>  >> This is where I have a problem with this, the fact that there is
>  >> no upgrade path - virtually my entire installed base of Fedora is
>  >> running legacy BIOS and not being able to upgrade them will be
>  >> something of a headache.
>  >>
>  >> Is it actually true though? You need to be able to find some space
>  >> for an EFI partition but assuming that can be done is there some
>  >> other reason you can't migrate from BIOS to UEFI booting?
>  >
>  > In Fedora Linux default partitioning for all but Server, it is
>  > possible to reconfigure existing systems to UEFI. Fedora Server is
>  > screwed because they use XFS and you cannot shrink an XFS volume.
>  >
>  > Fedora < 33 used ext4 by default, and you can do offline shrink and
>  > open up space for an ESP. In Fedora >= 33, ext4 is still used for
>  > /boot and you can resize that. Alternatively, the Btrfs / can be
>  > resized while the system is running to make room for an ESP.
>
>  I generally do my own partitioning rather than using the
>  default, and all my systems are ext4 so sounds like it's not
>  necessarily impossible.
>
>  I'm actually looking at stealing swap on some of them, or
>  just growing disks for VMs.
>  
If you have a swap partition, that's the easiest place to steal from, indeed!



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

[Peter Boy]

>  Am 05.04.2022 um 16:52 schrieb Ben Cotton
> <bcotton(a)redhat.com&gt;:
>  
>  https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
>  
>  == Summary ==
>  Make UEFI a hardware requirement for new Fedora installations on
>  platforms that support it (x86_64).  Legacy BIOS support is not
>  removed, but new non-UEFI installation is not supported on those
>  platforms.  This is a first step toward eventually removing legacy
>  BIOS support entirely.
>   
From the Fedora Server Working Group's point of view, I am absolutely against this
change (namely to drop new BIOS-boot installations). There are a large number of data
centers with rental hardware (e.g. hetzner.com) or co-location that (still) require bios
boot even for newer servers. I don't know the reasons, probably due to their support
and management infrastructure. I suppose this will change in the future, but foreseeably
not for the next 5 - x years. 

In any case, we would force all users of that environment to switch away from Fedora
Server to another distribution. I’m wondering, do we really want to do that?

And likewise, we must not make it unnecessarily difficult for users to use this (old)
path. We are not a reform school.

And I also don't understand why we should give up a hallmark of free Linux, namely to
support old, but still good usable hardware (unlike commercial system, not only Windows
but also e.g. RHEL).


Peter






(And to my chagrin, I myself would be affected and forced to leave Fedora and immediately
start to move our servers to another distro when this change is accepted.)

[Neal Gompa]

On Tue, Apr 5, 2022 at 1:47 PM Gregory Bartholomew
<gregory.lee.bartholomew(a)gmail.com&gt; wrote:
>  On Tue, Apr 5, 2022 at 12:39 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
> >
> > Fedora Server users *must* fully reinstall, because there's no way to
> > make space for an ESP and reconfigure things.
>
>
>  I haven't done a "default" Fedora Server installation in a long time, so
> I'm not sure how they are laid out. But I seem to remember /boot being a separate
> partition for a long time (it used to be required because some older BOISs couldn't
> read beyond a certain sector on the disk). Could not /boot be converted to the ESP (i.e.
> reformatted with FAT32) on such systems? 
We do /boot/efi (ESP for EFI blobs) + /boot (everything else). The ESP
can be extremely tiny because of it. Fedora Server /boot is XFS, so
non-shrinkable.



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

[Robbie Harwood]

Tom Hughes via devel <devel(a)lists.fedoraproject.org&gt; writes:

>  On 05/04/2022 15:52, Ben Cotton wrote:
>
> > * There is no migration story from Legacy BIOS to UEFI -
> > repartitioning effectively mandates a reinstall.  As a result, we
> > don’t drop support for existing Legacy BIOS systems yet, just new
> > installations.
>
>  This is where I have a problem with this, the fact that there is
>  no upgrade path - virtually my entire installed base of Fedora is
>  running legacy BIOS and not being able to upgrade them will be
>  something of a headache. 
Yup.  That's why there's a deprecation window here.

>  Is it actually true though? You need to be able to find some space
>  for an EFI partition but assuming that can be done is there some
>  other reason you can't migrate from BIOS to UEFI booting? 
Right, you need the EFI partition (EFI System Partition, or ESP).  I
don't remember what we default those to these days - I usually make
about 600M, but I need it larger for testing stuff.  The partition
scheme also needs to be GPT, not MBR.  Once that's all set, the EFI
grub2 packages need to be installed, but that's the easy part :)

Repartitioning in the general case is very involved.  If the system is
using an encrypted LVM, that's two more layers to worry about.  The
dm-crypt area would need to shrink, which means the LVM needs to shrink,
which means the filesystems on it need to shrink (and importantly, not
all of them can).  That doesn't even touch dual-boot scenarios, where
our filesysem support is less good than for Linux native cases.

To restate that: I think very determined, patient users can make it work
in some cases.  But I don't think we can expect that to work for
everyone, especially without friendly tooling to accomplish it.

Be well,
--Robbie

[Tom Hughes]

On 05/04/2022 18:51, Robbie Harwood wrote:

>  Right, you need the EFI partition (EFI System Partition, or ESP).  I
>  don't remember what we default those to these days - I usually make
>  about 600M, but I need it larger for testing stuff.  The partition
>  scheme also needs to be GPT, not MBR.  Once that's all set, the EFI
>  grub2 packages need to be installed, but that's the easy part :) 
I actually checked that on wikipedia because I wondered if it
had to be GPT and it seemed to say MBR was supported?

https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Disk_...

Tom

-- 
Tom Hughes (tom(a)compton.nu)
http://compton.nu/

[Robbie Harwood]

Peter Boy <pboy(a)uni-bremen.de&gt; writes:

>  And I also don't understand why we should give up a hallmark of
> free
>  Linux, namely to support old, but still good usable hardware (unlike
>  commercial system, not only Windows but also e.g. RHEL). 
Developers are free to support whatever systems they like.  If someone
wants to support systems, they'll be supported; if not, they won't.
There's no law that says Linux MUST keep supporting hardware forever.
See also: armv7 removal, i386/i686 removal, ppc removal, m68k removal,
...

Be well,
--Robbie

[Robbie Harwood]

Gregory Bartholomew <gregory.lee.bartholomew(a)gmail.com&gt; writes:

>  But I seem to remember /boot being a separate partition for a long
>  time (it used to be required because some older BOISs couldn't read
>  beyond a certain sector on the disk). Could not /boot be converted to
>  the ESP (i.e. reformatted with FAT32) on such systems? 
Only if there's somewhere else for /boot to reside.  If e.g., / is
encrypted, we're not prepared out of the box to handle that.  A
determined user could probably make it work, but it's again niche.

Be well,
--Robbie

[Peter Boy]

>  Am 05.04.2022 um 19:38 schrieb Neal Gompa
> <ngompa13(a)gmail.com&gt;:
>  
>  Fedora Server is
>  screwed because they use XFS and you cannot shrink an XFS volume. 

Server is not screwed because of XFS, according to the change, an existing installation
can still use bios boot. That is not a Problem. (And you could easily relocate logical
volumes and adjust the physical volume without a complete reinstallation, although only
offline)

Instead, the change will „screw“ Server because some data center require bios boot.

[Robbie Harwood]

Tom Hughes <tom(a)compton.nu&gt; writes:

>  On 05/04/2022 18:51, Robbie Harwood wrote:
>
> > Right, you need the EFI partition (EFI System Partition, or ESP).  I
> > don't remember what we default those to these days - I usually make
> > about 600M, but I need it larger for testing stuff.  The partition
> > scheme also needs to be GPT, not MBR.  Once that's all set, the EFI
> > grub2 packages need to be installed, but that's the easy part :)
>
>  I actually checked that on wikipedia because I wondered if it
>  had to be GPT and it seemed to say MBR was supported?
>
>
> https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Disk_...
That may work, but what's important is that it's not close to as
well-tested - Windows binds UEFI support to needing GPT.  (Also, the
2.2T limitation on MBR makes GPT very attractive.)

Be well,
--Robbie

[Peter Boy]

>  Am 05.04.2022 um 19:57 schrieb Robbie Harwood
> <rharwood(a)redhat.com&gt;:
>  
>  Peter Boy <pboy(a)uni-bremen.de&gt; writes:
>  
> > And I also don't understand why we should give up a hallmark of free
> > Linux, namely to support old, but still good usable hardware (unlike
> > commercial system, not only Windows but also e.g. RHEL).
>  
>  Developers are free to support whatever systems they like.  If someone
>  wants to support systems, they'll be supported; if not, they won't.
>  There's no law that says Linux MUST keep supporting hardware forever.
>  See also: armv7 removal, i386/i686 removal, ppc removal, m68k removal, 
I =don’t= say must! I ask if that is wise!


Of course, Fedora is free to discontinue support for bios boot, and may we have to because
of lack of manpower. Users will then move away from Fedora to somewhere else, Suse or
Debian. And certainly no new users will switch to Fedora because we no longer support BIOS
boot and it's so cool.


Peter

[Jason L Tibbitts III]

> >>>> Ben Cotton <bcotton(a)redhat.com&gt; writes: 
>  == Make UEFI a hardware requirement for new Fedora installations on
>  platforms that support it (x86_64). 
My problem here is that I have real, useful hardware which has always
run Fedora that I would like to continue using.  But it's just old
enough (purchased in 2011) and doesn't support UEFI at all.  These
machines are repurposed computational servers and work perfectly well to
do things like provide some public Fedora mirrors.

>  Like the already accepted Fedora 37 change to retire ARMv7 support,
>  the hardware targeted tends to be rather underpowered by today’s
>  standards, and the world has moved on from it. 
I know there is this tendency to dismiss anything that's old as useless,
and 20 years ago, a decade-old machine wasn't something you probably
wanted to use.  But the rate of progress has slowed down, and a Xeon
X5670 with 96GB of memory and a pile of disk just isn't a piece of
garbage.  I know I'll have to toss it out eventually, but I'd hope to do
that when it either fails or is actually no longer useful.

I understand that this isn't going to be how the primary user experience
is directed.  I can deal with having to jump through hoops to get a
machine installed.  But it would be kind of sad if my alternatives are
to use another distro or toss the stuff in the trash.  (There would be a
certain irony in not being able to run Fedora to provide a Fedora
mirror.)

For those who might be curious, the systems are Supermicro 6026TT-HTRF
machines with four nodes in 2U.  I have three, so twelve machines in
total.  The machines have X8DTT-HF+ motherboards.  I actually have older
hardware than that around and still in use (all Supermicro), but oddly
some of it actually has an EFI option.

 - J<

[PGNet Dev]

>  So you've heard that we're overloaded, and you know that UEFI
> is the
>  direction the world is heading. 
Well, so is (was?) 'IPv6' ...

>  Your solution to this is... what, stick
>  our heads in the sand and ignore that?  Just do legacy?  We already have
>  UEFI-only platforms (see also: the mention of ARM you're belaboring), so
>  that's obviously not going to fly, even if we were willing to, which
>  we're not. 
There are enough, different plots of sand for different folks to stick their heads into. 
To my read, noone's suggested ignoring the future -- rather the suggestions appear to
be to NOT ignore reality.

Curious, has anyone from @redhat or @fedora though to actually communicate with any of the
'big' hosting providers, to perhaps coordinate/influence/compromise/plan?

I'd bet AWS, DigitalOcean & Linode/Akamai -- among this biggest hosting providers
where 'new installs' would be happening on their VPSs -- would be quite interested
in making sure that THEIR customers had smooth install/migration options for
Redhat/Centos*/Fedora variants.

I know my _own_ solution to UEFI-install only if those^ providers don't support it;
I'm guessing not everyone will have the same goals/approach.

[Gregory Bartholomew]

On Tue, Apr 5, 2022 at 1:17 PM Jason L Tibbitts III <j(a)tib.bs&gt; wrote:

>  For those who might be curious, the systems are Supermicro 6026TT-HTRF
>  machines with four nodes in 2U.  I have three, so twelve machines in
>  total.  The machines have X8DTT-HF+ motherboards.  I actually have older
>  hardware than that around and still in use (all Supermicro), but oddly
>  some of it actually has an EFI option.
>
>  
Check out this beauty that I still run.

# cat /etc/redhat-release
Fedora release 34 (Thirty Four)
# dmidecode
# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 2.3 present.
87 structures occupying 3232 bytes.
Table at 0x000F9920.

Handle 0xDA00, DMI type 218, 11 bytes
OEM-specific Type
   Header and Data:
      DA 0B 00 DA B2 00 17 00 0E 20 00

Handle 0x0000, DMI type 0, 20 bytes
BIOS Information
   Vendor: Dell Computer Corporation
   Version: A07
   Release Date: 04/25/2008
   Address: 0xF0000
   Runtime Size: 64 kB
   ROM Size: 1 MB
   Characteristics:
      ISA is supported
      PCI is supported
      PNP is supported
      BIOS is upgradeable
      BIOS shadowing is allowed
      ESCD support is available
      Boot from CD is supported
      Selectable boot is supported
      EDD is supported
      Japanese floppy for Toshiba 1.2 MB is supported (int 13h)
      5.25"/360 kB floppy services are supported (int 13h)
      5.25"/1.2 MB floppy services are supported (int 13h)
      3.5"/720 kB floppy services are supported (int 13h)
      Print screen service is supported (int 5h)
      8042 keyboard services are supported (int 9h)
      Serial services are supported (int 14h)
      Printer services are supported (int 17h)
      CGA/mono video services are supported (int 10h)
      ACPI is supported
      USB legacy is supported
      LS-120 boot is supported
      BIOS boot specification is supported
      Function key-initiated network boot is supported

But I don't really expect Fedora Linux to support something that old. I
fully understand that I may have to jump through some manual hoops to keep
it running at this point. In fact, I do. I have this system customized to
boot using syslinux with BLS support.

[Robbie Harwood]

PGNet Dev <pgnet.dev(a)gmail.com&gt; writes:

>  Curious, has anyone from @redhat or @fedora though to actually
>  communicate with any of the 'big' hosting providers, to perhaps
>  coordinate/influence/compromise/plan?
>
>  I'd bet AWS, DigitalOcean & Linode/Akamai -- among this biggest
>  hosting providers where 'new installs' would be happening on their
>  VPSs -- would be quite interested in making sure that THEIR customers
>  had smooth install/migration options for Redhat/Centos*/Fedora
>  variants.
>
>  I know my _own_ solution to UEFI-install only if those^ providers
>  don't support it; I'm guessing not everyone will have the same
>  goals/approach. 
Any VPS that supports Windows 11 needs to support UEFI-only already.  In
particular, the top 3 (AWS, Azure, Google Cloud) are all UEFI-capable.

(Akamai is, to my knowledge, not a provider of VPSs.)

Be well,
--Robbie

[PGNet Dev]

>  (Akamai is, to my knowledge, not a provider of VPSs.) 
https://www.linode.com/press-release/akamai-to-acquire-linode/

[Neal Gompa]

On Tue, Apr 5, 2022 at 2:36 PM Robbie Harwood <rharwood(a)redhat.com&gt; wrote:
>  PGNet Dev <pgnet.dev(a)gmail.com&gt; writes:
>
>  > Curious, has anyone from @redhat or @fedora though to actually
>  > communicate with any of the 'big' hosting providers, to perhaps
>  > coordinate/influence/compromise/plan?
>  >
>  > I'd bet AWS, DigitalOcean & Linode/Akamai -- among this biggest
>  > hosting providers where 'new installs' would be happening on their
>  > VPSs -- would be quite interested in making sure that THEIR customers
>  > had smooth install/migration options for Redhat/Centos*/Fedora
>  > variants.
>  >
>  > I know my _own_ solution to UEFI-install only if those^ providers
>  > don't support it; I'm guessing not everyone will have the same
>  > goals/approach.
>
>  Any VPS that supports Windows 11 needs to support UEFI-only already.  In
>  particular, the top 3 (AWS, Azure, Google Cloud) are all UEFI-capable.
>
>  (Akamai is, to my knowledge, not a provider of VPSs.)
>  
Akamai owns Linode, which is a prominent VPS that focuses on Linux
(Linode is a contraction meaning "Linux Node").

DigitalOcean similarly is Linux centric and so Windows doesn't matter.

Most web hosting providers and VPSes are Linux-centric and so Windows
doesn't matter.



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

[Demi Marie Obenour]

On 4/5/22 12:29, Michael Catanzaro wrote:
>  On Tue, Apr 5 2022 at 11:56:07 AM -0400, Robbie Harwood 
>  <rharwood(a)redhat.com&gt; wrote:
> > Users wishing to use NVIDIA hardware have the following options:
> >
> > - Use nouveau (free, open source, cool)
> > - Sign their own copy of the proprietary driver (involves messing with
> >   certificates, so not appropriate for all users)
> > - Disable Secure Boot (note that this is still UEFI)
> >
> > The NVIDIA driver is proprietary, so of course it's not going to get
> > signed.
>  
>  The user experience requirement is: user searches for NVIDIA in GNOME 
>  Software and clicks Install. No further action should be necessary. We 
>  didn't make the NVIDIA driver available from the graphical installer 
>  with the intention that arcane workarounds would be required to use it.
>  
>  Michael 
Bingo.  None of the three options Robbie suggested are reasonable for
non-technical users.

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[PGNet Dev]

>  Akamai owns Linode, which is a prominent VPS that focuses on Linux
>  (Linode is a contraction meaning "Linux Node"). 
+1

>  DigitalOcean similarly is Linux centric and so Windows doesn't
> matter. 
+1

>  Most web hosting providers and VPSes are Linux-centric and so
> Windows
>  doesn't matter. 
+1


Ironic that Windows11 compat is being floated as any kind of rationale here.

[Demi Marie Obenour]

On 4/5/22 13:38, Neal Gompa wrote:
>  On Tue, Apr 5, 2022 at 1:31 PM Tom Hughes via devel
>  <devel(a)lists.fedoraproject.org&gt; wrote:
> >
> > On 05/04/2022 15:52, Ben Cotton wrote:
> >
> >> * There is no migration story from Legacy BIOS to UEFI -
> >> repartitioning effectively mandates a reinstall.  As a result, we
> >> don’t drop support for existing Legacy BIOS systems yet, just new
> >> installations.
> >
> > This is where I have a problem with this, the fact that there is
> > no upgrade path - virtually my entire installed base of Fedora is
> > running legacy BIOS and not being able to upgrade them will be
> > something of a headache.
> >
> > Is it actually true though? You need to be able to find some space
> > for an EFI partition but assuming that can be done is there some
> > other reason you can't migrate from BIOS to UEFI booting?
> >
>  
>  In Fedora Linux default partitioning for all but Server, it is
>  possible to reconfigure existing systems to UEFI. Fedora Server is
>  screwed because they use XFS and you cannot shrink an XFS volume. 
Time to get the XFS developers to support shrinking?

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[Neal Gompa]

On Tue, Apr 5, 2022 at 3:06 PM Demi Marie Obenour <demiobenour(a)gmail.com&gt; wrote:
>  On 4/5/22 13:38, Neal Gompa wrote:
>  > On Tue, Apr 5, 2022 at 1:31 PM Tom Hughes via devel
>  > <devel(a)lists.fedoraproject.org&gt; wrote:
>  >>
>  >> On 05/04/2022 15:52, Ben Cotton wrote:
>  >>
>  >>> * There is no migration story from Legacy BIOS to UEFI -
>  >>> repartitioning effectively mandates a reinstall.  As a result, we
>  >>> don’t drop support for existing Legacy BIOS systems yet, just new
>  >>> installations.
>  >>
>  >> This is where I have a problem with this, the fact that there is
>  >> no upgrade path - virtually my entire installed base of Fedora is
>  >> running legacy BIOS and not being able to upgrade them will be
>  >> something of a headache.
>  >>
>  >> Is it actually true though? You need to be able to find some space
>  >> for an EFI partition but assuming that can be done is there some
>  >> other reason you can't migrate from BIOS to UEFI booting?
>  >>
>  >
>  > In Fedora Linux default partitioning for all but Server, it is
>  > possible to reconfigure existing systems to UEFI. Fedora Server is
>  > screwed because they use XFS and you cannot shrink an XFS volume.
>
>  Time to get the XFS developers to support shrinking?
>  
That's not likely to happen anytime soon. That said, up until Fedora
Linux 33, a swap partition was created by default too. You can shrink
that and reuse some of that space to create an ESP outside of the
LVM+XFS setup. As I was reminded earlier in this thread, swap is a
good chopping block to work with.



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

[Demi Marie Obenour]

On 4/5/22 15:09, Neal Gompa wrote:
>  On Tue, Apr 5, 2022 at 3:06 PM Demi Marie Obenour
> <demiobenour(a)gmail.com&gt; wrote:
> >
> > On 4/5/22 13:38, Neal Gompa wrote:
> >> On Tue, Apr 5, 2022 at 1:31 PM Tom Hughes via devel
> >> <devel(a)lists.fedoraproject.org&gt; wrote:
> >>>
> >>> On 05/04/2022 15:52, Ben Cotton wrote:
> >>>
> >>>> * There is no migration story from Legacy BIOS to UEFI -
> >>>> repartitioning effectively mandates a reinstall.  As a result, we
> >>>> don’t drop support for existing Legacy BIOS systems yet, just new
> >>>> installations.
> >>>
> >>> This is where I have a problem with this, the fact that there is
> >>> no upgrade path - virtually my entire installed base of Fedora is
> >>> running legacy BIOS and not being able to upgrade them will be
> >>> something of a headache.
> >>>
> >>> Is it actually true though? You need to be able to find some space
> >>> for an EFI partition but assuming that can be done is there some
> >>> other reason you can't migrate from BIOS to UEFI booting?
> >>>
> >>
> >> In Fedora Linux default partitioning for all but Server, it is
> >> possible to reconfigure existing systems to UEFI. Fedora Server is
> >> screwed because they use XFS and you cannot shrink an XFS volume.
> >
> > Time to get the XFS developers to support shrinking?
> >
>  
>  That's not likely to happen anytime soon. 
Is this because of lack of demand from paying RHEL customers?

>  That said, up until Fedora
>  Linux 33, a swap partition was created by default too. You can shrink
>  that and reuse some of that space to create an ESP outside of the
>  LVM+XFS setup. As I was reminded earlier in this thread, swap is a
>  good chopping block to work with. 
Yeah, you can use a swap file instead.  Also LVM thin volumes may be
getting shrinking support.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[Adam Jackson]

On Tue, Apr 5, 2022 at 3:15 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:

>  We also lack solutions for dealing with the NVIDIA driver in
>  UEFI+Secure Boot case. Are you planning to actually *fix* that now?
>  Because we still don't have a way to have kernel-only keyrings for
>  secure boot certificates to avoid importing them into the firmware. 
Couple of thoughts, here:

1 - This is a non sequitur to the question of removing BIOS support,
because Secure Boot is not a BIOS feature, so nobody relying on Secure
Boot today would stand to lose anything.

2 - How is this our problem to solve? NVIDIA are the ones with the
private source code.

3 - Your complaint describes solution: import NVIDIA's signing key
into your firmware. If you want both Secure Boot and nvidia.ko so
badly, then you as the consumer need to tell your platform to trust
what NVIDIA signs. If that's a burden, again, see point 2 about who
exactly is making your life hard here. Remedies there might include
some UI streamlining around mokutil, or getting nvidia and nouveau to
use the same (open) kernel driver so the question just goes away.

- ajax

[Adam Jackson]

On Tue, Apr 5, 2022 at 11:18 AM Ben Cotton <bcotton(a)redhat.com&gt; wrote:

>  While this will eventually reduce workload for boot/installation
>  components (grub2 reduces surface area, syslinux goes away entirely,
>  anaconda reduces surface area), the reduction in support burden
>  extends much further into the stack - for instance, VESA support can
>  be removed from the distro. 
I'm flattered, but I intend to drop vesa in F37 regardless of the
outcome of this particular change. The only supported way to get to
graphics with vesa is to use Xorg, and we sincerely want to be out of
the business of maintaining Xorg the hardware server. (We'll need an X
server forever, Xwayland isn't going away, don't misread me here.)

And frankly at this point if you seriously want to use vesa it's
because you're trying to like reverse engineer some obscure card's
VBIOS, and if you're doing that you're probably building your own X
server anyway, I know I would be. Its use as an emergency driver on
physical GPUs is negligible, we have native drivers for virtually
everything made in the last 20 years. Its use as an emergency driver
in virtual machines is more statistically significant, maybe, but even
there we usually have a drm driver these days, and where we don't we
can probably club it into bochs_drm since that's the only rom anyone
bothers to use for that.

- ajax

[Sebastian Crane]

I frequently use BIOS-only machines which don't have a UEFI boot option
- and one of those machines is indeed running Fedora! Certainly, I
understand that there are better ways of booting systems now, but for
the time being BIOS is still very important.

If the installation media can not install onto BIOS-only machines yet
all the bootloader stages support BIOS, then there will be an awkward
stage where some existing Fedora installations can be upgraded, but if
anything goes wrong it'd be impossible to reinstall them! The lack of a
BIOS installer as a fallback would make running Fedora on BIOS-only
machines risky enough that it seems to me as no better than removing
support entirely. Could I missing something here?

Also, one thing that I would be greatly reassured by is a date for
removal of BIOS support entirely. This would at least give confidence
that is worth installing Fedora on these machines for use in a limited,
but known, duration, rather than looking at alternative distributions
now.

[Neal Gompa]

On Tue, Apr 5, 2022 at 3:38 PM Adam Jackson <ajax(a)redhat.com&gt; wrote:
>  On Tue, Apr 5, 2022 at 3:15 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>
>  > We also lack solutions for dealing with the NVIDIA driver in
>  > UEFI+Secure Boot case. Are you planning to actually *fix* that now?
>  > Because we still don't have a way to have kernel-only keyrings for
>  > secure boot certificates to avoid importing them into the firmware.
>
>  Couple of thoughts, here:
>
>  1 - This is a non sequitur to the question of removing BIOS support,
>  because Secure Boot is not a BIOS feature, so nobody relying on Secure
>  Boot today would stand to lose anything.
>
>  2 - How is this our problem to solve? NVIDIA are the ones with the
>  private source code.
>  
It's our problem because the problem isn't specific to NVIDIA, it's
specific to how people compile and load kernel modules of their own.
We should not require loading keys into firmware for user built kernel
modules. An OS-level module should be trustable at the OS kernel
level.

Thus, it should be: MS cert -> shim -> Fedora cert -> grub -> kernel
-> user cert -> user kmod.

>  3 - Your complaint describes solution: import NVIDIA's signing
> key
>  into your firmware. If you want both Secure Boot and nvidia.ko so
>  badly, then you as the consumer need to tell your platform to trust
>  what NVIDIA signs. If that's a burden, again, see point 2 about who
>  exactly is making your life hard here. Remedies there might include
>  some UI streamlining around mokutil, or getting nvidia and nouveau to
>  use the same (open) kernel driver so the question just goes away.
>  
This problem also makes life miserable for people working with third
party open source kernel modules too. As a live streamer, for example,
I need to use v4l2loopback, which will never exist in mainline because
v4l2 maintainers don't like it at all.

Broad non-Mac hardware only became available after Windows 8 / Windows
Server 2012 R2. Yes, some hardware existed a few years before, but it
was not broadly available before 2013. We didn't discontinue i686 in
Fedora until Fedora Linux 31, which was over 15 years after the first
x86_64 system. The user experience with x86_64 was immeasurably better
than i686 at that point in time.

We do not have a better experience with UEFI *right now*. I know of
plenty of people intentionally choosing BIOS because the user
experience is better, even though it's older/bad technology. Because
using BIOS means kmods work. Because using BIOS means hibernate works.
Because using BIOS means they can get an equivalent experience
leveraging their hardware that they can get on Windows today with
UEFI. Maybe none of you proposing this Change use these things, but
I'm telling you these things matter.

And the amount of resistance to improving UEFI experience for hardware
is amazingly awful. The workstation working group has tried to figure
out ways to improve the experience, only to be simultaneously stymied
by the UEFI firmware management tools and unwillingness by anyone
involved to even consider that we should make this better.

I will *not* force people to deal with importing keys into firmware.
It's brittle, buggy, and often completely broken on motherboards. Many
of those UEFI implementations are extremely buggy and terrible. I've
dealt with a lot of it as part of my job over the years and it leads
to a terrible user experience for Linux users.

If you are making UEFI the only way people boot, ***fix*** the
experience. If you're not committed to that, then you're causing more
pain for no gain.




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

[David Airlie]

On Wed, Apr 6, 2022 at 1:18 AM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
>
>  == Summary ==
>  Make UEFI a hardware requirement for new Fedora installations on
>  platforms that support it (x86_64).  Legacy BIOS support is not
>  removed, but new non-UEFI installation is not supported on those
>  platforms.  This is a first step toward eventually removing legacy
>  BIOS support entirely.
>
>  == Owner ==
>  * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří
>  Konečný]], [[User:bcl| Brian C. Lane]]
>  * Email: rharwood(a)redhat.com
>
>
>  == Detailed Description ==
>  UEFI is defined by a versioned standard that can be tested and
>  certified against.  By contrast, every legacy BIOS is unique. Legacy
>  BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple)
>  and on its way out.  As it ages, maintainability has decreased, and
>  the status quo of maintaining both stacks in perpetuity is not viable
>  for those currently doing that work.
>
>  It is inevitable that legacy BIOS will be removed in a future release.
>  To ease this transition as best we can, there will be a period (of at
>  least one Fedora release) where it will be possible to boot using the
>  legacy BIOS codepaths, but new installations will not be possible.
>  While it would be easier for us to cut support off today, our hope is
>  that this compromise position will make for a smoother transition.
>  Additional support with issues during the transition would be
>  appreciated.
>  

Just a personal frustration here, I recently worked on a project to
rewrite the mesa driver for a range of intel GPUs from gen4->gen7, we
ship it in Fedora 35 as the default driver on those GPUs.

It was of great benefit to me and the community that I could use
Fedora for developing this sort of feature, and have a place to roll
it out for validation. This change would invalidate a wide range of
the machines I wrote this on from being used.

I have a fully operational 965G desktop machine that runs f35, a
mostly operational 965GM HP laptop with busted fan, and a GM45 in a
Thinkpad W500 machine that are all pre-UEFI but still can run fedora.
I've got one Ironlake HP laptop that has UEFI but only if I hand pick
the boot file since its UEFI implementation has a bunch of BIOS
warnings around it saying not to enable it for normal use. The T440s I
have doesn't seem to be installed in UEFI mode and that likely means I
need to nuke it and start again.

This would mean for future projects I'd probably have to consider
moving off Fedora would definitely count as a major pita for me, I
also cleanly installed all these machines with F35 as I didn't want
the behaviour of updating from f31 to f33 to f35 etc.

Dave.

[Adam Jackson]

On Tue, Apr 5, 2022 at 4:01 PM Sebastian Crane <seabass-labrax(a)gmx.com&gt; wrote:

>  If the installation media can not install onto BIOS-only machines
> yet
>  all the bootloader stages support BIOS, then there will be an awkward
>  stage where some existing Fedora installations can be upgraded, but if
>  anything goes wrong it'd be impossible to reinstall them! The lack of a
>  BIOS installer as a fallback would make running Fedora on BIOS-only
>  machines risky enough that it seems to me as no better than removing
>  support entirely. Could I missing something here? 
If I were interested in keeping BIOS machines installable, I'd
probably just rebuild the F36 installer every so often, pointing it at
newer repos by default each time. Long term that might be a little
weird - if the installed system stops knowing about BIOS partition
tables you might end up with a machine unable to inspect its own disk
layout from like gnome-disks - but...

- ajax

[Chris Murphy]

On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton <bcotton(a)redhat.com&gt; wrote:

>  Fedora already requires a 2GHz dual core CPU at minimum (and
> therefore
>  mandates that machines must have been made after 2006). 
Where do we require this? I see only one location for such minimums:

https://getfedora.org/en/workstation/download/

* Fedora requires a minimum of 20GB disk, 2GB RAM, to install and run
successfully. Double those amounts is recommended.

Should this be modified to better communicate the actual minimums? I
like the idea of making this less ambiguous: e.g. CPU release date 4th
quarter 2006 or later; or a list of CPU features?


>  * Drawing a clear year cutoff, let alone a detailed list of hardware
>  this change affects, is basically impossible.  This is unfortunate but
>  unlikely to ever change. 
OK I'm confused now.


>  * There is no migration story from Legacy BIOS to UEFI -
>  repartitioning effectively mandates a reinstall.  As a result, we
>  don’t drop support for existing Legacy BIOS systems yet, just new
>  installations. 
OK let's set aside the case of native UEFI with CSM enabled legacy
BIOS. That's plainly (a) change the settings, and (b) reinstall.

But this leaves out native BIOS systems entirely, for new
installations. How is this not removing BIOS support entirely if users
can only do upgrades, but not clean installs on BIOS systems?

I think an intermediate step is necessary. One possible idea is to
stop creating hybrid ISO images. Instead make separate GPT only images
for non-optical (typically USB stick) booting, and consider one or
more images for the optical boot case using strictly conforming ISO
9660 or UDF? Again stop making universal media with all the weird (but
awesome) hacks, and multiple bootloaders.

Fedora Cloud edition's base images now have GPT partition scheme
(only) with both BIOS and UEFI bootloaders and partitions. We can
create spec compliant (no funny business) images, reducing the overall
complexity as an intermediate step before fully dropping BIOS. Instead
of using ISOLINUX as the BIOS bootloader, just use GRUB for both, just
as Cloud edition is today.


-- 
Chris Murphy

[Robbie Harwood]

Chris Murphy <lists(a)colorremedies.com&gt; writes:

>  On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton <bcotton(a)redhat.com&gt;
> wrote:
>
> > Fedora already requires a 2GHz dual core CPU at minimum (and therefore
> > mandates that machines must have been made after 2006).
>
>  Where do we require this? I see only one location for such minimums:
>
>  https://getfedora.org/en/workstation/download/ 
https://docs.fedoraproject.org/en-US/fedora/rawhide/release-notes/welcome...

Be well,
--Robbie

[Chris Murphy]

On Tue, Apr 5, 2022 at 9:56 AM Florian Weimer <fweimer(a)redhat.com&gt; wrote:
>  * Peter Robinson:
>
>  > This is out of context here because you can disable Secure Boot but
>  > still use UEFI to make that work. You're trying to link to different
>  > problems together.
>
>  I think there's firmware out there which enables Secure Boot
>  unconditionally in UEFI mode, but still has CSM support. 
The UEFI spec makes CSM and Secure Boot mutually exclusive. CSM
enabled renders Secure Boot impossible. So I'm not sure how the
firmware can simultaneously enforce Secure Boot, but then permit the
loading of non-compliant bootloaders. That'd seem to be a Secure Boot
break worthy of a firmware update. In particular if it's also possible
to invoke CSM boot via NVRAM variables.

-- 
Chris Murphy

[Neal Gompa]

On Tue, Apr 5, 2022 at 4:28 PM Chris Murphy <lists(a)colorremedies.com&gt; wrote:
>  On Tue, Apr 5, 2022 at 9:56 AM Florian Weimer <fweimer(a)redhat.com&gt; wrote:
>  >
>  > * Peter Robinson:
>  >
>  > > This is out of context here because you can disable Secure Boot but
>  > > still use UEFI to make that work. You're trying to link to different
>  > > problems together.
>  >
>  > I think there's firmware out there which enables Secure Boot
>  > unconditionally in UEFI mode, but still has CSM support.
>
>  The UEFI spec makes CSM and Secure Boot mutually exclusive. CSM
>  enabled renders Secure Boot impossible. So I'm not sure how the
>  firmware can simultaneously enforce Secure Boot, but then permit the
>  loading of non-compliant bootloaders. That'd seem to be a Secure Boot
>  break worthy of a firmware update. In particular if it's also possible
>  to invoke CSM boot via NVRAM variables.
>  
Many boards offered this capability, even though it violates the
standard. It's one of the reasons why Intel demanded PC makers stop
supporting CSM at all.



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

[Chris Murphy]

On Tue, Apr 5, 2022 at 11:31 AM Tom Hughes via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  On 05/04/2022 15:52, Ben Cotton wrote:
>
>  > * There is no migration story from Legacy BIOS to UEFI -
>  > repartitioning effectively mandates a reinstall.  As a result, we
>  > don’t drop support for existing Legacy BIOS systems yet, just new
>  > installations.
>
>  This is where I have a problem with this, the fact that there is
>  no upgrade path - virtually my entire installed base of Fedora is
>  running legacy BIOS and not being able to upgrade them will be
>  something of a headache.
>
>  Is it actually true though? You need to be able to find some space
>  for an EFI partition but assuming that can be done is there some
>  other reason you can't migrate from BIOS to UEFI booting? 
a. There's no way to automate the switch from CSM/BIOS to UEFI. The
user must interact with the firmware setup directly to make the switch
happen.
b. It's not immediately obvious that the migration worked, from a
user's perspective. They need to run efiboormgr and know what's
expected.

Fedora Cloud edition base images are dual BIOS and UEFI boot, using
GPT partition scheme. It is possible to do this. But Cloud has a much
narrower set of virtualized firmwares to deal with, and getting bugs
fixed is pretty likely. Whereas any bugs discovered in hardware's
firmware is unlikely to get fixed anytime soon.

The biggest though is likely lack of resources. It'd amount to
foisting this arrangement onto users and come what may.

-- 
Chris Murphy

[Chris Murphy]

On Tue, Apr 5, 2022 at 11:47 AM Gregory Bartholomew
<gregory.lee.bartholomew(a)gmail.com&gt; wrote:
>  On Tue, Apr 5, 2022 at 12:39 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
> >
> > Fedora Server users *must* fully reinstall, because there's no way to
> > make space for an ESP and reconfigure things.
>
>
>  I haven't done a "default" Fedora Server installation in a long time, so
> I'm not sure how they are laid out. But I seem to remember /boot being a separate
> partition for a long time (it used to be required because some older BOISs couldn't
> read beyond a certain sector on the disk). Could not /boot be converted to the ESP (i.e.
> reformatted with FAT32) on such systems? 
No. It would need to be reformatted as FAT to be firmware readable.
And thus this is an irreversible modification. There will be lengthy
periods of time that are simply not crash safe. So the risk is
probably unacceptably high that the user ends up abandoned on a
deserted island, in which case it's better to just steer them toward
the well understood and document process of reprovisioning (clean
install time). Yes it's tedious, but it's well understood and very
reliable, and that counts for more than convenience in QA terms.


-- 
Chris Murphy

[Jared Dominguez]

On Tue, Apr 5, 2022 at 4:10 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:

>  On Tue, Apr 5, 2022 at 3:38 PM Adam Jackson <ajax(a)redhat.com&gt;
> wrote:
>  >
>  > On Tue, Apr 5, 2022 at 3:15 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  >
>  > > We also lack solutions for dealing with the NVIDIA driver in
>  > > UEFI+Secure Boot case. Are you planning to actually *fix* that now?
>  > > Because we still don't have a way to have kernel-only keyrings for
>  > > secure boot certificates to avoid importing them into the firmware.
>  >
>  > Couple of thoughts, here:
>  >
>  > 1 - This is a non sequitur to the question of removing BIOS support,
>  > because Secure Boot is not a BIOS feature, so nobody relying on Secure
>  > Boot today would stand to lose anything.
>  >
>  > 2 - How is this our problem to solve? NVIDIA are the ones with the
>  > private source code.
>  >
>
>  It's our problem because the problem isn't specific to NVIDIA, it's
>  specific to how people compile and load kernel modules of their own.
>  We should not require loading keys into firmware for user built kernel
>  modules. An OS-level module should be trustable at the OS kernel
>  level.
>
>  Thus, it should be: MS cert -> shim -> Fedora cert -> grub -> kernel
>  -> user cert -> user kmod.
>
>  > 3 - Your complaint describes solution: import NVIDIA's signing key
>  > into your firmware. If you want both Secure Boot and nvidia.ko so
>  > badly, then you as the consumer need to tell your platform to trust
>  > what NVIDIA signs. If that's a burden, again, see point 2 about who
>  > exactly is making your life hard here. Remedies there might include
>  > some UI streamlining around mokutil, or getting nvidia and nouveau to
>  > use the same (open) kernel driver so the question just goes away.
>  >
>
>  This problem also makes life miserable for people working with third
>  party open source kernel modules too. As a live streamer, for example,
>  I need to use v4l2loopback, which will never exist in mainline because
>  v4l2 maintainers don't like it at all.
>
>  Broad non-Mac hardware only became available after Windows 8 / Windows
>  Server 2012 R2. Yes, some hardware existed a few years before, but it
>  was not broadly available before 2013. We didn't discontinue i686 in
>  Fedora until Fedora Linux 31, which was over 15 years after the first
>  x86_64 system. The user experience with x86_64 was immeasurably better
>  than i686 at that point in time.
>  
The security of UEFI systems is immeasurably better. Standardized firmware
updates, support for modern secure TPMs, OS protection from firmware (SMM
mitigations), HTTP(S) boot support, largely shared and open sourced
firmware codebases that aren't a pile of assembly code, and a lot of other
features are UEFI-only.


>  We do not have a better experience with UEFI *right now*. I know of
>  plenty of people intentionally choosing BIOS because the user
>  experience is better, even though it's older/bad technology. Because
>  using BIOS means kmods work. Because using BIOS means hibernate works.
>  Because using BIOS means they can get an equivalent experience
>  leveraging their hardware that they can get on Windows today with
>  UEFI. Maybe none of you proposing this Change use these things, but
>  I'm telling you these things matter.
>  
This is really vague, especially considering that the amount of
official hardware support for Linux outside the top 3 OEMs is dicey anyway.
Additionally, lots of vendors are treating legacy boot as unsupported (or
"supported" but only for Linux, i.e. not really tested), so the same
argument could be made the other way.


>  And the amount of resistance to improving UEFI experience for
> hardware
>  is amazingly awful. The workstation working group has tried to figure
>  out ways to improve the experience, only to be simultaneously stymied
>  by the UEFI firmware management tools and unwillingness by anyone
>  involved to even consider that we should make this better.
>  
Which tools? What specific efforts have been stymied? How is any of this
specific to UEFI versus trying to deal with things that aren't supported by
someone?


>  I will *not* force people to deal with importing keys into firmware.
>  It's brittle, buggy, and often completely broken on motherboards. Many
>  of those UEFI implementations are extremely buggy and terrible. I've
>  dealt with a lot of it as part of my job over the years and it leads
>  to a terrible user experience for Linux users.
>  
In general, all of the stuff about Secure Boot and signing is really
tangential. This change proposal is about reducing maintenance burden
because we already know that pretending to continue to support legacy x86
boot is problematic. As stated in the change proposal, "Community
assistance is required to continue the status quo. Current owners plan to
orphan some packages regardless of whether the proposal is accepted."

By the way, VMware also deprecated legacy x86 boot support:
https://kb.vmware.com/s/article/84233


>  If you are making UEFI the only way people boot, ***fix*** the
>  experience. If you're not committed to that, then you're causing more
>  pain for no gain.
>  
This comment seems misguided, since improving the experience on UEFI
systems is precisely what Red Hat's bootloader team* is most focused on.

Not stated in this proposal, but continuing to support legacy x86 boot also
serves to allow OEMs, IBVs and users from avoiding fixing and reporting
issues that should have been fixed a long time ago because there is a
mostly palatable workaround.

*(NB: a team I manage)

--
>  真実はいつも一つ！/ Always, there's only one truth!
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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
>  

-- 
Jared Dominguez (he/him)
Software Engineering Manager
New Platform Technologies Enablement team
RHEL Workstation Engineering

If I am emailing outside of business hours (mine or yours), it is my choice
and does not mean I expect you to respond today.

[Gary Buhrmaster]

On Tue, Apr 5, 2022 at 5:46 PM Richard Shaw <hobbes1069(a)gmail.com&gt; wrote:
>  On Tue, Apr 5, 2022 at 12:31 PM Tom Hughes via devel
> <devel(a)lists.fedoraproject.org&gt; wrote: 
==
> > Is it actually true though? You need to be able to find some
> space
> > for an EFI partition but assuming that can be done is there some
> > other reason you can't migrate from BIOS to UEFI booting?
>
>
>  I actually did it manually several releases ago when I got a new computer that supported
> EFI but kept the same OS drive.
>
>  I'm not going to lie, it was VERY painful and took me a while to figure everything
> out, a lot of googling and trying stuff. It wasn't for the faint of heart. 
I did it a few years ago when I decided to
(finally) convert a ~9 year old (at the time,
~11 year old now) PC from BIOS to (U)EFI
(initially my belief was that Linux support
for (U)EFI was not as mature as it is now,
which is why I choose to stay in BIOS mode).
However, I had thought ahead all those
years ago, and partitioned using GPT and
had reserved both a BIOS boot partition
(which was suggested somewhere during
that period) and a EFI system partition, so
I did not have to deal with extensive
re-partitioning steps.

As I recall it was not all *that* hard[0],
although I agree it was not at all well
described (and because I was paranoid
I had built (and tested) a USB emergency
boot drive just in case, although I did
not end up needing it (probably because
I had it)).

I will agree that there are enough edge
cases that for all practical purposes one
should likely recommend reinstall most
of the time (after the two+ tested backups
one should make, of course).

btw, since the time I did so, a red behatted
individual described the steps they used at
https://www.redhat.com/sysadmin/bios-uefi
which is clearly a proof by example it can
be done.  Sometimes.

Gary


[0] It is always possible that I have
suppressed all the painful memories
as a survival technique.

[Gregory Bartholomew]

On Tue, Apr 5, 2022 at 3:51 PM Chris Murphy <lists(a)colorremedies.com&gt; wrote:

>  On Tue, Apr 5, 2022 at 11:47 AM Gregory Bartholomew
>  <gregory.lee.bartholomew(a)gmail.com&gt; wrote:
>
>  > I haven't done a "default" Fedora Server installation in a long time,
> so
>  I'm not sure how they are laid out. But I seem to remember /boot being a
>  separate partition for a long time (it used to be required because some
>  older BOISs couldn't read beyond a certain sector on the disk). Could not
>  /boot be converted to the ESP (i.e. reformatted with FAT32) on such systems?
>
>  No. It would need to be reformatted as FAT to be firmware readable.
>  And thus this is an irreversible modification. There will be lengthy
>  periods of time that are simply not crash safe. So the risk is
>  probably unacceptably high that the user ends up abandoned on a
>  deserted island, in which case it's better to just steer them toward
>  the well understood and document process of reprovisioning (clean
>  install time). Yes it's tedious, but it's well understood and very
>  reliable, and that counts for more than convenience in QA terms.
>  
I get where you are coming from. But I might have an idea about how at
least the "There will be lengthy
periods of time that are simply not crash safe" problem could be addressed.

What if upgrades from BIOS to UEFI mode *had* to be done from an
installation DVD/Thumb drive? Then there is a guaranteed way that the
system can be booted (otherwise the user would not have been able to
initiate the automated upgrade). Additionally, the upgrade process could
make a dd backup of the previous /boot partition (and the 440-byte boot
sector) before reformatting it. In the worst-case scenario, the backup of
the BIOS bootsector and partition could be restored. But another option the
user could have if they so chose would be to leave the installation media
connected to the computer such that it would provide the legacy boot chain
if the UEFI upgrade didn't fully work for whatever reason. I'm guessing
that if a user is willing to put up with running such old hardware that it
doesn't support UEFI, they might also be OK with going *really* old-school
and having to boot the system off an external media (e.g. leave the CD in
the drive bay or leave the thumb drive plugged into the back of the machine
for the remainder of its life)? Presumably the installation media could be
configured to default to chain-loading the /boot/loader/entries file if one
exists that is equal to or newer than the kernel of the installation disc?

This is just an idea that I'm throwing out there. I'm not even sure how
much I care for it myself.

[Chris Murphy]

On Tue, Apr 5, 2022 at 3:42 PM Gregory Bartholomew
<gregory.lee.bartholomew(a)gmail.com&gt; wrote:
>  On Tue, Apr 5, 2022 at 3:51 PM Chris Murphy <lists(a)colorremedies.com&gt; wrote:
> >
> > On Tue, Apr 5, 2022 at 11:47 AM Gregory Bartholomew
> > <gregory.lee.bartholomew(a)gmail.com&gt; wrote:
> >
> > > I haven't done a "default" Fedora Server installation in a long
> time, so I'm not sure how they are laid out. But I seem to remember /boot being a
> separate partition for a long time (it used to be required because some older BOISs
> couldn't read beyond a certain sector on the disk). Could not /boot be converted to
> the ESP (i.e. reformatted with FAT32) on such systems?
> >
> > No. It would need to be reformatted as FAT to be firmware readable.
> > And thus this is an irreversible modification. There will be lengthy
> > periods of time that are simply not crash safe. So the risk is
> > probably unacceptably high that the user ends up abandoned on a
> > deserted island, in which case it's better to just steer them toward
> > the well understood and document process of reprovisioning (clean
> > install time). Yes it's tedious, but it's well understood and very
> > reliable, and that counts for more than convenience in QA terms.
>
>
>  I get where you are coming from. But I might have an idea about how at least the
> "There will be lengthy
>  periods of time that are simply not crash safe" problem could be addressed.
>
>  What if upgrades from BIOS to UEFI mode *had* to be done from an installation DVD/Thumb
> drive? 
Doesn't matter, it still wouldn't be crash safe on its own. You'd have
to design an upgrade utility that uses a journal such that any
interruption can be resumed where it left off. Only that journal would
know the actual state of the system at each step of the migration.
That's a lot of work and pretty much out of scope.

> Then there is a guaranteed way that the system can be booted
> (otherwise the user would not have been able to initiate the automated upgrade). 
But without a journal it wouldn't be resumable or reversible. Since
none of our installation media are writable out of the box, we'd also
have to redesign one that does.

>  Additionally, the upgrade process could make a dd backup of the
> previous /boot partition (and the 440-byte boot sector) before reformatting it. In the
> worst-case scenario, the backup of the BIOS bootsector and partition could be restored.
Only if the upgrade utility is designed to do such a restoration, the
current upgrade service knows nothing about that. This is non-trivial
work. And users can just upgrade. How will they even know about
migration or what the benefits are? There's insufficient incentive to
do the migration, even if they were aware of it. I think it'd be a lot
of effort for very few users.

The problem is that BIOS systems cannot have new installations
performed on them. This makes the proposal a removal of support, not a
deprecation. Deprecation is an expression of disapproval, it shouldn't
have a direct impact on users. It's notice that this will (soon)
involve an impact on users.


-- 
Chris Murphy

[Demi Marie Obenour]

On 4/5/22 15:58, Adam Jackson wrote:
>  On Tue, Apr 5, 2022 at 11:18 AM Ben Cotton <bcotton(a)redhat.com&gt;
> wrote:
>  
> > While this will eventually reduce workload for boot/installation
> > components (grub2 reduces surface area, syslinux goes away entirely,
> > anaconda reduces surface area), the reduction in support burden
> > extends much further into the stack - for instance, VESA support can
> > be removed from the distro.
>  
>  I'm flattered, but I intend to drop vesa in F37 regardless of the
>  outcome of this particular change. The only supported way to get to
>  graphics with vesa is to use Xorg, and we sincerely want to be out of
>  the business of maintaining Xorg the hardware server. (We'll need an X
>  server forever, Xwayland isn't going away, don't misread me here.) 
Does that mean that F37 will only have an Xwayland package, not an
Xorg package?  And does it mean that XFCE support is being deprecated?
Qubes OS relies on the latter.

>  And frankly at this point if you seriously want to use vesa it's
>  because you're trying to like reverse engineer some obscure card's
>  VBIOS, and if you're doing that you're probably building your own X
>  server anyway, I know I would be. Its use as an emergency driver on
>  physical GPUs is negligible, we have native drivers for virtually
>  everything made in the last 20 years. Its use as an emergency driver
>  in virtual machines is more statistically significant, maybe, but even
>  there we usually have a drm driver these days, and where we don't we
>  can probably club it into bochs_drm since that's the only rom anyone
>  bothers to use for that. 
Do we have DRM drivers for the UEFI framebuffer and the standard
QEMU-emulated graphics?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[Kevin Kofler]

Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
>  
>  == Summary ==
>  Make UEFI a hardware requirement for new Fedora installations on
>  platforms that support it (x86_64).  Legacy BIOS support is not
>  removed, but new non-UEFI installation is not supported on those
>  platforms.  This is a first step toward eventually removing legacy
>  BIOS support entirely.
>  
>  == Owner ==
>  * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří
>  Konečný]], [[User:bcl| Brian C. Lane]]
>  * Email: rharwood(a)redhat.com 
Considering that this will desupport my notebook that runs Fedora just fine, 
and that I am not alone with this issue judging from the other comments, I 
am totally opposed to this change.

>  == Detailed Description ==
>  UEFI is defined by a versioned standard that can be tested and
>  certified against.  By contrast, every legacy BIOS is unique. Legacy
>  BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple)
>  and on its way out.  As it ages, maintainability has decreased, and
>  the status quo of maintaining both stacks in perpetuity is not viable
>  for those currently doing that work. 
I do not see what is there to maintain given that it is legacy technology 
that does not change anymore.

>  It is inevitable that legacy BIOS will be removed in a future
> release. 
Hence, I do not see the inevitability at all!

>  To ease this transition as best we can, there will be a period (of
> at
>  least one Fedora release) where it will be possible to boot using the
>  legacy BIOS codepaths, but new installations will not be possible.
>  While it would be easier for us to cut support off today, our hope is
>  that this compromise position will make for a smoother transition.
>  Additional support with issues during the transition would be
>  appreciated. 
As others have pointed out, that broken "compromise" means that corrupt 
installations, hard disk failures, etc. can no longer be recovered on those 
machines. So it does not solve the problem at all. And I disagree with the 
ultimate goal of the transition (complete desupport of legacy BIOS) to begin 
with.

By the way, if you just drop support from Anaconda, that does not preclude 
installing Fedora on those systems using Calamares.

>  While this will eventually reduce workload for boot/installation
>  components (grub2 reduces surface area, syslinux goes away entirely,
>  anaconda reduces surface area), the reduction in support burden
>  extends much further into the stack - for instance, VESA support can
>  be removed from the distro. 
That (dropping VESA), too, will desupport a whole class of perfectly working 
hardware, though it should not affect me personally.

>  Fedora already requires a 2GHz dual core CPU at minimum (and
> therefore
>  mandates that machines must have been made after 2006). 
My notebook has a 2.4 GHz Core 2 Duo T7700, so it fits that requirement. 
(But Fedora probably actually runs on even lower-powered machines. After 
all, the PinePhone, on which Fedora is known to run, has a 1.2 GHz aarch64 
CPU (with 4 cores).) Still, the notebook does not support UEFI.

>  Like the already accepted Fedora 37 change to retire ARMv7 support,
>  the hardware targeted tends to be rather underpowered by today’s
>  standards, and the world has moved on from it. 
The difference is, Fedora on ARM has always been a niche thing, so dropping 
ARMv7 affects far fewer users than dropping support for some x86_64 
machines. (Also note that the change was not about dropping a subset of 
aarch64 machines, only 32-bit was dropped, years after that happened for 
x86.) And also, performance-wise, my Core 2 Duo notebook is probably faster 
than most of those 32-bit ARMv7 devices.

>  Intel stopped shipping the last vestiges of BIOS support in 2020 (as
> have
>  other vendors, and Apple and Microsoft), so this is clearly the way things
>  are heading - and therefore aligns with Fedora’s “First” objective. 
"First" was never meant to be a synonym for planned obsolescence of 
hardware. It means being first to offer the latest and greatest software, 
nothing more.

>  * There is no way to deprecate hardware without causing some amount
> of
>  friction. 
Indeed. So do not do that then.

>  Current owners plan to orphan some packages regardless of whether
> the
>  proposal is accepted. 
And that is completely unacceptable blackmailing.

        Kevin Kofler

[Rahul Sundaram]

Hi

On Tue, Apr 5, 2022 at 6:59 PM Kevin Kofler  wrote:

>  > Current owners plan to orphan some packages regardless of whether the
>  > proposal is accepted.
>
>  And that is completely unacceptable blackmailing.
>  
Blackmail is always conditional.  Stating openly that someone is going to
do something unconditionally is just disclosure.

Rahul

[Chris Murphy]

On Tue, Apr 5, 2022 at 3:08 PM Jared Dominguez <jaredz(a)redhat.com&gt; wrote:

>  The security of UEFI systems is immeasurably better. Standardized
> firmware updates, support for modern secure TPMs, OS protection from firmware (SMM
> mitigations), HTTP(S) boot support, largely shared and open sourced firmware codebases
> that aren't a pile of assembly code, and a lot of other features are UEFI-only.
When users have a suboptimal experience by default, it makes Fedora
look bad. We can't have security concerns overriding all other
concerns. But it's really pernicious to simultaneously say security is
important, but we're also not going to sign proprietary drivers. This
highly incentivizes the user to disable Secure Boot because that's so
much easier than users signing kernel modules and enrolling keys with
the firmware, and therefore makes the user *less safe*.


> > And the amount of resistance to improving UEFI experience for
> hardware
> > is amazingly awful. The workstation working group has tried to figure
> > out ways to improve the experience, only to be simultaneously stymied
> > by the UEFI firmware management tools and unwillingness by anyone
> > involved to even consider that we should make this better.
>
>
>  Which tools? What specific efforts have been stymied? How is any of this specific to UEFI
> versus trying to deal with things that aren't supported by someone? 
Namely, Fedora signing NVIDIA's proprietary driver.

Apple and Microsoft signing NVIDIA's proprietary driver doesn't at all
indicate Apple and Microsoft trust the driver itself. It is trusting
the providence of the blob, in order to achieve an overall safer
ecosystem for their users.

We either want users with NVIDIA hardware to be inside the Secure Boot
fold or we don't. I want them in the fold *despite* the driver that
needs signing is proprietary. That's a better user experience across
the board, including the security messaging is made consistent. The
existing policy serves no good at all and is double talk. If we really
care about security more than ideological worry, we'd sign the driver.


-- 
Chris Murphy

[Andre Robatino]

Those figures are recommended minimums, not requirements. I have a single core F35 machine
which works fine.

[Jared Dominguez]

On Tue, Apr 5, 2022 at 7:39 PM Chris Murphy <lists(a)colorremedies.com&gt; wrote:

>  On Tue, Apr 5, 2022 at 3:08 PM Jared Dominguez
> <jaredz(a)redhat.com&gt; wrote:
>
>  > The security of UEFI systems is immeasurably better. Standardized
>  firmware updates, support for modern secure TPMs, OS protection from
>  firmware (SMM mitigations), HTTP(S) boot support, largely shared and open
>  sourced firmware codebases that aren't a pile of assembly code, and a lot
>  of other features are UEFI-only.
>
>  When users have a suboptimal experience by default, it makes Fedora
>  look bad. We can't have security concerns overriding all other
>  concerns. But it's really pernicious to simultaneously say security is
>  important, but we're also not going to sign proprietary drivers. This
>  highly incentivizes the user to disable Secure Boot because that's so
>  much easier than users signing kernel modules and enrolling keys with
>  the firmware, and therefore makes the user *less safe*.
>  
Understandable concern. Secure Boot is still a different topic from UEFI
(and many of the features provided by UEFI, including those impacting
security), and UEFI can be utilized even without Secure Boot. Nonetheless,
several folks have been exploring options to be able to support Nvidia's
driver in Fedora.


>  >> And the amount of resistance to improving UEFI experience
> for hardware
>  >> is amazingly awful. The workstation working group has tried to figure
>  >> out ways to improve the experience, only to be simultaneously stymied
>  >> by the UEFI firmware management tools and unwillingness by anyone
>  >> involved to even consider that we should make this better.
>  >
>  >
>  > Which tools? What specific efforts have been stymied? How is any of this
>  specific to UEFI versus trying to deal with things that aren't supported by
>  someone?
>
>  Namely, Fedora signing NVIDIA's proprietary driver.
>
>  Apple and Microsoft signing NVIDIA's proprietary driver doesn't at all
>  indicate Apple and Microsoft trust the driver itself. It is trusting
>  the providence of the blob, in order to achieve an overall safer
>  ecosystem for their users.
>  
Apple and Microsoft are held to different license terms in their operating
systems than we are.


>  We either want users with NVIDIA hardware to be inside the Secure
> Boot
>  fold or we don't. I want them in the fold *despite* the driver that
>  needs signing is proprietary. That's a better user experience across
>  the board, including the security messaging is made consistent. The
>  existing policy serves no good at all and is double talk. If we really
>  care about security more than ideological worry, we'd sign the driver.
>
>
>  --
>  Chris Murphy
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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
>  

-- 
Jared Dominguez (he/him)
Software Engineering Manager
New Platform Technologies Enablement team
RHEL Workstation Engineering

[Chris Murphy]

On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  Legacy BIOS support is not
>  removed, but new non-UEFI installation is not supported on those
>  platforms.  This is a first step toward eventually removing legacy
>  BIOS support entirely. 
What is the distinction between "support is not removed" and "removing
support entirely"?  i.e. what are the additional steps for entirely
removing support? And what's the approximate time frame for it?

"Support is not removed" seems incongruent with "new installations are
not supported." What continues to be supported? Will grub-pc still be
built and updated? Will grub2-install still work on BIOS systems?

> syslinux goes away entirely 
If the installation media used BIOS GRUB, syslinux could still go
away. What consideration has occurred to switch from syslinux to BIOS
GRUB for installation media? Is BIOS GRUB being deprecated? Or is it
being discontinued in Fedora?

If security vulnerabilities in BIOS GRUB are discovered, and
grub2-install doesn't apply the most recently available fixes, I
consider this an unsupported configuration. We can't say "support is
not removed" while removing the ability to apply security fixes to the
embedded bootloader.

>  * Some machines are BIOS-only.  This change does not prevent their
> use
>  yet, but they are effectively deprecated.  grub2 (our default
>  bootloader) is already capable of both BIOS and UEFI booting. 
This is inconsistent with the previous language "new non-UEFI
installation is not supported". Clearly the change prevents their use
if new clean installations on them aren't possible.


>  However, this modifies the baseline Fedora requirements and some
>  hardware will no longer be supported for new installations. 
This is removal of support. No mere deprecation.


>  Installs will continue to work on UEFI, and will not work on Legacy
>  BIOS. 
Again, removal of support. The change does prevent their use for new
clean installations.


-- 
Chris Murphy

[Jared Dominguez]

On Tue, Apr 5, 2022 at 8:51 PM Chris Murphy <lists(a)colorremedies.com&gt; wrote:

>  On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton <bcotton(a)redhat.com&gt;
> wrote:
>  > Legacy BIOS support is not
>  > removed, but new non-UEFI installation is not supported on those
>  > platforms.  This is a first step toward eventually removing legacy
>  > BIOS support entirely.
>
>  What is the distinction between "support is not removed" and "removing
>  support entirely"?  i.e. what are the additional steps for entirely
>  removing support? And what's the approximate time frame for it?
>
>  "Support is not removed" seems incongruent with "new installations are
>  not supported." What continues to be supported? Will grub-pc still be
>  built and updated? Will grub2-install still work on BIOS systems?
>
>  >syslinux goes away entirely
>
>  If the installation media used BIOS GRUB, syslinux could still go
>  away. What consideration has occurred to switch from syslinux to BIOS
>  GRUB for installation media? Is BIOS GRUB being deprecated? Or is it
>  being discontinued in Fedora?
>
>  If security vulnerabilities in BIOS GRUB are discovered, and
>  grub2-install doesn't apply the most recently available fixes, I
>  consider this an unsupported configuration. We can't say "support is
>  not removed" while removing the ability to apply security fixes to the
>  embedded bootloader.
>
>  > * Some machines are BIOS-only.  This change does not prevent their use
>  > yet, but they are effectively deprecated.  grub2 (our default
>  > bootloader) is already capable of both BIOS and UEFI booting.
>
>  This is inconsistent with the previous language "new non-UEFI
>  installation is not supported". Clearly the change prevents their use
>  if new clean installations on them aren't possible.
>
>
>  > However, this modifies the baseline Fedora requirements and some
>  > hardware will no longer be supported for new installations.
>
>  This is removal of support. No mere deprecation.
>
>
>  > Installs will continue to work on UEFI, and will not work on Legacy
>  > BIOS.
>
>  Again, removal of support. The change does prevent their use for new
>  clean installations.
>  
A less phased approach was considered when we were working on the change
proposal and would actually be more desirable from a development point of
view, but a more generous approach seemed more palatable since it'd give
people more time to handle transition.


>  --
>  Chris Murphy
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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
>  

-- 
Jared Dominguez (he/him)
Software Engineering Manager
New Platform Technologies Enablement team
RHEL Workstation Engineering

If I am emailing outside of business hours (mine or yours), it is my choice
and does not mean I expect you to respond today.

[Demi Marie Obenour]

On 4/5/22 19:38, Chris Murphy wrote:
>  On Tue, Apr 5, 2022 at 3:08 PM Jared Dominguez
> <jaredz(a)redhat.com&gt; wrote:
>  
> > The security of UEFI systems is immeasurably better. Standardized firmware updates,
> support for modern secure TPMs, OS protection from firmware (SMM mitigations), HTTP(S)
> boot support, largely shared and open sourced firmware codebases that aren't a pile of
> assembly code, and a lot of other features are UEFI-only.
>  
>  When users have a suboptimal experience by default, it makes Fedora
>  look bad. We can't have security concerns overriding all other
>  concerns. But it's really pernicious to simultaneously say security is
>  important, but we're also not going to sign proprietary drivers. This
>  highly incentivizes the user to disable Secure Boot because that's so
>  much easier than users signing kernel modules and enrolling keys with
>  the firmware, and therefore makes the user *less safe*.
>  
>  
> >> And the amount of resistance to improving UEFI experience for hardware
> >> is amazingly awful. The workstation working group has tried to figure
> >> out ways to improve the experience, only to be simultaneously stymied
> >> by the UEFI firmware management tools and unwillingness by anyone
> >> involved to even consider that we should make this better.
> >
> >
> > Which tools? What specific efforts have been stymied? How is any of this specific to
> UEFI versus trying to deal with things that aren't supported by someone?
>  
>  Namely, Fedora signing NVIDIA's proprietary driver.
>  
>  Apple and Microsoft signing NVIDIA's proprietary driver doesn't at all
>  indicate Apple and Microsoft trust the driver itself. It is trusting
>  the providence of the blob, in order to achieve an overall safer
>  ecosystem for their users.
>  
>  We either want users with NVIDIA hardware to be inside the Secure Boot
>  fold or we don't. I want them in the fold *despite* the driver that
>  needs signing is proprietary. That's a better user experience across
>  the board, including the security messaging is made consistent. The
>  existing policy serves no good at all and is double talk. If we really
>  care about security more than ideological worry, we'd sign the driver. 
I agree with this.  Sign the driver.

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[Chris Murphy]

On Tue, Apr 5, 2022 at 6:55 PM Jared Dominguez <jaredz(a)redhat.com&gt; wrote:
>  On Tue, Apr 5, 2022 at 8:51 PM Chris Murphy <lists(a)colorremedies.com&gt; wrote:
> >
> > On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
> > > Legacy BIOS support is not
> > > removed, but new non-UEFI installation is not supported on those
> > > platforms.  This is a first step toward eventually removing legacy
> > > BIOS support entirely.
> >
> > What is the distinction between "support is not removed" and
> "removing
> > support entirely"?  i.e. what are the additional steps for entirely
> > removing support? And what's the approximate time frame for it?
> >
> > "Support is not removed" seems incongruent with "new installations
> are
> > not supported." What continues to be supported? Will grub-pc still be
> > built and updated? Will grub2-install still work on BIOS systems?
> >
> > >syslinux goes away entirely
> >
> > If the installation media used BIOS GRUB, syslinux could still go
> > away. What consideration has occurred to switch from syslinux to BIOS
> > GRUB for installation media? Is BIOS GRUB being deprecated? Or is it
> > being discontinued in Fedora?
> >
> > If security vulnerabilities in BIOS GRUB are discovered, and
> > grub2-install doesn't apply the most recently available fixes, I
> > consider this an unsupported configuration. We can't say "support is
> > not removed" while removing the ability to apply security fixes to the
> > embedded bootloader.
> >
> > > * Some machines are BIOS-only.  This change does not prevent their use
> > > yet, but they are effectively deprecated.  grub2 (our default
> > > bootloader) is already capable of both BIOS and UEFI booting.
> >
> > This is inconsistent with the previous language "new non-UEFI
> > installation is not supported". Clearly the change prevents their use
> > if new clean installations on them aren't possible.
> >
> >
> > > However, this modifies the baseline Fedora requirements and some
> > > hardware will no longer be supported for new installations.
> >
> > This is removal of support. No mere deprecation.
> >
> >
> > > Installs will continue to work on UEFI, and will not work on Legacy
> > > BIOS.
> >
> > Again, removal of support. The change does prevent their use for new
> > clean installations.
>
>
>  A less phased approach was considered when we were working on the change proposal and
> would actually be more desirable from a development point of view, but a more generous
> approach seemed more palatable since it'd give people more time to handle transition.
This generosity doesn't answer any of the questions I've asked, or
address the inconsistent language I've noted.

What is less phased in than what's being proposed? There are advocates
of planned obsolescence of BIOS systems, with a soft landing, I'm one
of them. But this is not anything like what I've imagined. It's not a
plan, it's a notification. And it's a very hard landing, significant
removal of support is actually in this proposal, not merely
deprecation. It leaves essentially no time to plan alternatives.



-- 
Chris Murphy

[Demi Marie Obenour]

On 4/5/22 16:09, Neal Gompa wrote:
>  On Tue, Apr 5, 2022 at 3:38 PM Adam Jackson <ajax(a)redhat.com&gt;
> wrote:
> >
> > On Tue, Apr 5, 2022 at 3:15 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
> >
> >> We also lack solutions for dealing with the NVIDIA driver in
> >> UEFI+Secure Boot case. Are you planning to actually *fix* that now?
> >> Because we still don't have a way to have kernel-only keyrings for
> >> secure boot certificates to avoid importing them into the firmware.
> >
> > Couple of thoughts, here:
> >
> > 1 - This is a non sequitur to the question of removing BIOS support,
> > because Secure Boot is not a BIOS feature, so nobody relying on Secure
> > Boot today would stand to lose anything.
> >
> > 2 - How is this our problem to solve? NVIDIA are the ones with the
> > private source code.
> >
>  
>  It's our problem because the problem isn't specific to NVIDIA, it's
>  specific to how people compile and load kernel modules of their own.
>  We should not require loading keys into firmware for user built kernel
>  modules. An OS-level module should be trustable at the OS kernel
>  level.
>  
>  Thus, it should be: MS cert -> shim -> Fedora cert -> grub -> kernel
>  -> user cert -> user kmod.
>  
> > 3 - Your complaint describes solution: import NVIDIA's signing key
> > into your firmware. If you want both Secure Boot and nvidia.ko so
> > badly, then you as the consumer need to tell your platform to trust
> > what NVIDIA signs. If that's a burden, again, see point 2 about who
> > exactly is making your life hard here. Remedies there might include
> > some UI streamlining around mokutil, or getting nvidia and nouveau to
> > use the same (open) kernel driver so the question just goes away.
> >
>  
>  This problem also makes life miserable for people working with third
>  party open source kernel modules too. As a live streamer, for example,
>  I need to use v4l2loopback, which will never exist in mainline because
>  v4l2 maintainers don't like it at all. 
Are you sure about that?  There is probably a better place to talk
about this, but Qubes OS also will be needing v4l2loopback soon (for
Qubes Video Companion) and so I have a strong interest in getting it
upstreamed.

>  Broad non-Mac hardware only became available after Windows 8 /
> Windows
>  Server 2012 R2. Yes, some hardware existed a few years before, but it
>  was not broadly available before 2013. We didn't discontinue i686 in
>  Fedora until Fedora Linux 31, which was over 15 years after the first
>  x86_64 system. The user experience with x86_64 was immeasurably better
>  than i686 at that point in time.
>  
>  We do not have a better experience with UEFI *right now*. I know of
>  plenty of people intentionally choosing BIOS because the user
>  experience is better, even though it's older/bad technology. Because
>  using BIOS means kmods work. Because using BIOS means hibernate works.
>  Because using BIOS means they can get an equivalent experience
>  leveraging their hardware that they can get on Windows today with
>  UEFI. Maybe none of you proposing this Change use these things, but
>  I'm telling you these things matter. 
And this ignores the case of virtualized systems, where the EFI System
Partition is purely wasted space.

>  And the amount of resistance to improving UEFI experience for
> hardware
>  is amazingly awful. The workstation working group has tried to figure
>  out ways to improve the experience, only to be simultaneously stymied
>  by the UEFI firmware management tools and unwillingness by anyone
>  involved to even consider that we should make this better.
>  
>  I will *not* force people to deal with importing keys into firmware.
>  It's brittle, buggy, and often completely broken on motherboards. Many
>  of those UEFI implementations are extremely buggy and terrible. I've
>  dealt with a lot of it as part of my job over the years and it leads
>  to a terrible user experience for Linux users. 
And even if it worked great on all platforms, **users should not need
to do it**.

Because let’s face it: If you have unrestricted root access, getting
kernel access is almost certainly going to be possible.  If nothing
else, just boot into Windows and take advantage of any one of the admin
⇒ kernel privilege escalations known on that platform.  For secure
boot to actually be more than security theater, it needs to disallow
insecure OSs (such as Windows) from booting.  Secure boot on Android
does that.  Secure boot on PCs does not, at least with the default
list of trusted bootloaders.

Qubes OS (which has security as its very reason for existing) does
*not* use secure boot right now, and while support for secure boot
would be nice, it is *not* the top priority right now.  Measured boot,
combined with disk encryption keys tied to these measurements, provides
much more security in practice.  If the attacker is at the point
where they can tamper with the bootloader of a running system with the
disks unlocked, they have already won.  If this is an offline attack,
measured boot is a much more effective mitigation.

>  If you are making UEFI the only way people boot, ***fix*** the
>  experience. If you're not committed to that, then you're causing more
>  pain for no gain. 
Bingo.


-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[Neal Gompa]

On Tue, Apr 5, 2022 at 8:59 PM Demi Marie Obenour <demiobenour(a)gmail.com&gt; wrote:
>  On 4/5/22 19:38, Chris Murphy wrote:
>  > On Tue, Apr 5, 2022 at 3:08 PM Jared Dominguez <jaredz(a)redhat.com&gt; wrote:
>  >
>  >> The security of UEFI systems is immeasurably better. Standardized firmware
> updates, support for modern secure TPMs, OS protection from firmware (SMM mitigations),
> HTTP(S) boot support, largely shared and open sourced firmware codebases that aren't a
> pile of assembly code, and a lot of other features are UEFI-only.
>  >
>  > When users have a suboptimal experience by default, it makes Fedora
>  > look bad. We can't have security concerns overriding all other
>  > concerns. But it's really pernicious to simultaneously say security is
>  > important, but we're also not going to sign proprietary drivers. This
>  > highly incentivizes the user to disable Secure Boot because that's so
>  > much easier than users signing kernel modules and enrolling keys with
>  > the firmware, and therefore makes the user *less safe*.
>  >
>  >
>  >>> And the amount of resistance to improving UEFI experience for hardware
>  >>> is amazingly awful. The workstation working group has tried to figure
>  >>> out ways to improve the experience, only to be simultaneously stymied
>  >>> by the UEFI firmware management tools and unwillingness by anyone
>  >>> involved to even consider that we should make this better.
>  >>
>  >>
>  >> Which tools? What specific efforts have been stymied? How is any of this
> specific to UEFI versus trying to deal with things that aren't supported by someone?
>  >
>  > Namely, Fedora signing NVIDIA's proprietary driver.
>  >
>  > Apple and Microsoft signing NVIDIA's proprietary driver doesn't at all
>  > indicate Apple and Microsoft trust the driver itself. It is trusting
>  > the providence of the blob, in order to achieve an overall safer
>  > ecosystem for their users.
>  >
>  > We either want users with NVIDIA hardware to be inside the Secure Boot
>  > fold or we don't. I want them in the fold *despite* the driver that
>  > needs signing is proprietary. That's a better user experience across
>  > the board, including the security messaging is made consistent. The
>  > existing policy serves no good at all and is double talk. If we really
>  > care about security more than ideological worry, we'd sign the driver.
>
>  I agree with this.  Sign the driver.
>  
My preference would be to somehow get NVIDIA to offer GPU
documentation and firmware blobs so nouveau could be further
developed. But it seems like nobody is trying to get them to do that
anymore, so I don't know what else we can do anymore.



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

[Chris Murphy]

>  On 4/5/22 19:38, Chris Murphy wrote: 
>  > Apple and Microsoft signing NVIDIA's proprietary driver
> doesn't at all
>  > indicate Apple and Microsoft trust the driver itself. It is trusting
>  > the providence of the blob, in order to achieve an overall safer
>  > ecosystem for their users. 
s/providence/provenance/

I'd like to blame this on autocorrect...


-- 
Chris Murphy

[Neal Gompa]

On Tue, Apr 5, 2022 at 9:07 PM Demi Marie Obenour <demiobenour(a)gmail.com&gt; wrote:
>  On 4/5/22 16:09, Neal Gompa wrote:
>  > On Tue, Apr 5, 2022 at 3:38 PM Adam Jackson <ajax(a)redhat.com&gt; wrote:
>  >>
>  >> On Tue, Apr 5, 2022 at 3:15 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  >>
>  >>> We also lack solutions for dealing with the NVIDIA driver in
>  >>> UEFI+Secure Boot case. Are you planning to actually *fix* that now?
>  >>> Because we still don't have a way to have kernel-only keyrings for
>  >>> secure boot certificates to avoid importing them into the firmware.
>  >>
>  >> Couple of thoughts, here:
>  >>
>  >> 1 - This is a non sequitur to the question of removing BIOS support,
>  >> because Secure Boot is not a BIOS feature, so nobody relying on Secure
>  >> Boot today would stand to lose anything.
>  >>
>  >> 2 - How is this our problem to solve? NVIDIA are the ones with the
>  >> private source code.
>  >>
>  >
>  > It's our problem because the problem isn't specific to NVIDIA, it's
>  > specific to how people compile and load kernel modules of their own.
>  > We should not require loading keys into firmware for user built kernel
>  > modules. An OS-level module should be trustable at the OS kernel
>  > level.
>  >
>  > Thus, it should be: MS cert -> shim -> Fedora cert -> grub -> kernel
>  > -> user cert -> user kmod.
>  >
>  >> 3 - Your complaint describes solution: import NVIDIA's signing key
>  >> into your firmware. If you want both Secure Boot and nvidia.ko so
>  >> badly, then you as the consumer need to tell your platform to trust
>  >> what NVIDIA signs. If that's a burden, again, see point 2 about who
>  >> exactly is making your life hard here. Remedies there might include
>  >> some UI streamlining around mokutil, or getting nvidia and nouveau to
>  >> use the same (open) kernel driver so the question just goes away.
>  >>
>  >
>  > This problem also makes life miserable for people working with third
>  > party open source kernel modules too. As a live streamer, for example,
>  > I need to use v4l2loopback, which will never exist in mainline because
>  > v4l2 maintainers don't like it at all.
>
>  Are you sure about that?  There is probably a better place to talk
>  about this, but Qubes OS also will be needing v4l2loopback soon (for
>  Qubes Video Companion) and so I have a strong interest in getting it
>  upstreamed.
>  
Yes. Last I heard, V4L2 folks think it'd be used to bypass making a
real camera driver for the kernel. That's pretty much why it's not
there.

You may be able to accomplish a good portion of it with PipeWire's
camera API, but you'll probably want to ask in the PipeWire Matrix
room about that: https://matrix.to/#/#pipewire:matrix.org

>  > Broad non-Mac hardware only became available after Windows 8 /
> Windows
>  > Server 2012 R2. Yes, some hardware existed a few years before, but it
>  > was not broadly available before 2013. We didn't discontinue i686 in
>  > Fedora until Fedora Linux 31, which was over 15 years after the first
>  > x86_64 system. The user experience with x86_64 was immeasurably better
>  > than i686 at that point in time.
>  >
>  > We do not have a better experience with UEFI *right now*. I know of
>  > plenty of people intentionally choosing BIOS because the user
>  > experience is better, even though it's older/bad technology. Because
>  > using BIOS means kmods work. Because using BIOS means hibernate works.
>  > Because using BIOS means they can get an equivalent experience
>  > leveraging their hardware that they can get on Windows today with
>  > UEFI. Maybe none of you proposing this Change use these things, but
>  > I'm telling you these things matter.
>
>  And this ignores the case of virtualized systems, where the EFI System
>  Partition is purely wasted space.
>  
The partition can be fairly small if it just contains EFI blobs, but I
think we give a fairly large one by default.

>  > And the amount of resistance to improving UEFI experience for
> hardware
>  > is amazingly awful. The workstation working group has tried to figure
>  > out ways to improve the experience, only to be simultaneously stymied
>  > by the UEFI firmware management tools and unwillingness by anyone
>  > involved to even consider that we should make this better.
>  >
>  > I will *not* force people to deal with importing keys into firmware.
>  > It's brittle, buggy, and often completely broken on motherboards. Many
>  > of those UEFI implementations are extremely buggy and terrible. I've
>  > dealt with a lot of it as part of my job over the years and it leads
>  > to a terrible user experience for Linux users.
>
>  And even if it worked great on all platforms, **users should not need
>  to do it**.
>
>  Because let’s face it: If you have unrestricted root access, getting
>  kernel access is almost certainly going to be possible.  If nothing
>  else, just boot into Windows and take advantage of any one of the admin
>  ⇒ kernel privilege escalations known on that platform.  For secure
>  boot to actually be more than security theater, it needs to disallow
>  insecure OSs (such as Windows) from booting.  Secure boot on Android
>  does that.  Secure boot on PCs does not, at least with the default
>  list of trusted bootloaders.
>
>  Qubes OS (which has security as its very reason for existing) does
>  *not* use secure boot right now, and while support for secure boot
>  would be nice, it is *not* the top priority right now.  Measured boot,
>  combined with disk encryption keys tied to these measurements, provides
>  much more security in practice.  If the attacker is at the point
>  where they can tamper with the bootloader of a running system with the
>  disks unlocked, they have already won.  If this is an offline attack,
>  measured boot is a much more effective mitigation.
>
>  > If you are making UEFI the only way people boot, ***fix*** the
>  > experience. If you're not committed to that, then you're causing more
>  > pain for no gain.
>
>  Bingo.
>  
Indeed.



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

[Gary Buhrmaster]

On Wed, Apr 6, 2022 at 12:59 AM Demi Marie Obenour
<demiobenour(a)gmail.com&gt; wrote:
>  On 4/5/22 19:38, Chris Murphy wrote:
>  > We either want users with NVIDIA hardware to be inside the Secure Boot
>  > fold or we don't. I want them in the fold *despite* the driver that
>  > needs signing is proprietary. That's a better user experience across
>  > the board, including the security messaging is made consistent. The
>  > existing policy serves no good at all and is double talk. If we really
>  > care about security more than ideological worry, we'd sign the driver.
>
>  I agree with this.  Sign the driver. 
Nvidia has their driver signed for their
Windows drivers.  That they choose
not to do so for Linux is their right,
even if some wish they did.

It should be noted that while many
might wish nvidia chose a different
way, that is completely orthogonal
to bios vs uefi.

[majid hussain]

hi,
could someone kindly tell me if my toshiba l750 machine has EFI support?
i'm blind and efi/bios screens are in accessible.




Majid

> Sent: Wednesday, April 06, 2022 at 6:03 am
> From: "Gary Buhrmaster" <gary.buhrmaster(a)gmail.com&gt;
> To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org&gt;
> Subject: Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
>
> On Wed, Apr 6, 2022 at 12:59 AM Demi Marie Obenour
> <demiobenour(a)gmail.com&gt; wrote:
> >
> > On 4/5/22 19:38, Chris Murphy wrote:
> > > We either want users with NVIDIA hardware to be inside the Secure Boot
> > > fold or we don't. I want them in the fold *despite* the driver that
> > > needs signing is proprietary. That's a better user experience across
> > > the board, including the security messaging is made consistent. The
> > > existing policy serves no good at all and is double talk. If we really
> > > care about security more than ideological worry, we'd sign the driver.
> >
> > I agree with this.  Sign the driver.
>
> Nvidia has their driver signed for their
> Windows drivers.  That they choose
> not to do so for Linux is their right,
> even if some wish they did.
>
> It should be noted that while many
> might wish nvidia chose a different
> way, that is completely orthogonal
> to bios vs uefi.
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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

[laolux laolux]

I have no strong opinion on this, and not much say anyways, but I thought I could share my
little piece of info.
My currently one and only computer is a 2012 MSI GE60 0ND, with a core i7-3630QM, 16GB RAM
and retrofitted with a SSD.
So I would say fast enough for using Fedora. At least according to notebookcheck.com the
CPU is supposed to be faster than a rather recent Core i3-1110G4, which is still being
used in new notebooks in 2022.
Unfortunately it only supports legacy BIOS, and not UEFI.
Thus I do not like the wording of the change proposal.

>  Fedora already requires a 2GHz dual core CPU at minimum (and
> therefore
>  mandates that machines must have been made after 2006).  Like the
>  already accepted Fedora 37 change to retire ARMv7 support, the
>  hardware targeted tends to be rather underpowered by today’s
>  standards, and the world has moved on from it.  Intel stopped shipping
>  the last vestiges of BIOS support in 2020 (as have other vendors, and
>  Apple and Microsoft), so this is clearly the way things are heading -
>  and therefore aligns with Fedora’s “First” objective. 
This seems to imply that only rather old and weak hardware would be affected, when clearly
the cutoff is (at maximum) only 10 years back.
Please don't get me wrong, I am perfectly fine about Fedora dropping "old"
hardware, and I am willing to throw away my still working notebook, producing a little bit
electronic waste when the time comes. But I think one should be more open and explicit
about it.

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 05 April 2022 at 16:52, Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
>  
>  == Summary ==
>  Make UEFI a hardware requirement for new Fedora installations on
>  platforms that support it (x86_64).  Legacy BIOS support is not
>  removed, but new non-UEFI installation is not supported on those
>  platforms.  This is a first step toward eventually removing legacy
>  BIOS support entirely. 
How is making new installs (and thus re-installs) not removing support
entirely? The summary is misleading.

>  == Owner ==
>  * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří
>  Konečný]], [[User:bcl| Brian C. Lane]]
>  * Email: rharwood(a)redhat.com
>  
>  
>  == Detailed Description ==
>  UEFI is defined by a versioned standard that can be tested and
>  certified against.  By contrast, every legacy BIOS is unique. Legacy
>  BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple)
>  and on its way out.  As it ages, maintainability has decreased, and
>  the status quo of maintaining both stacks in perpetuity is not viable
>  for those currently doing that work. 
Have you tried getting more people involved?

>  It is inevitable that legacy BIOS will be removed in a future
> release. 
Future release of what and why is it inevitable?

>  To ease this transition as best we can, there will be a period (of
> at
>  least one Fedora release) where it will be possible to boot using the
>  legacy BIOS codepaths, but new installations will not be possible. 
Which is effectively removing support entirely.

>  While it would be easier for us to cut support off today, our hope
> is
>  that this compromise position will make for a smoother transition. 
I don't see how this is a compromise.

>  Additional support with issues during the transition would be
>  appreciated.
>  
>  While this will eventually reduce workload for boot/installation
>  components (grub2 reduces surface area, syslinux goes away entirely, 
You could switch from syslinux to grub for installation media as well.

>  anaconda reduces surface area), the reduction in support burden
>  extends much further into the stack - for instance, VESA support can
>  be removed from the distro. 
>  Fedora already requires a 2GHz dual core CPU at minimum (and
> therefore
>  mandates that machines must have been made after 2006). 
It's not a hard requirement. Fedora runs just fine on slower hardware.
I have an x86_64 1.66GHz Atom machine from 2010 which is still perfectly
serviceable as a router, just as it was 12 years ago. I expanded its
memory, replaced hard drives, and it's still running. It's BIOS-only.
I would not appreciate having to throw it away because of this change.
I already had to say goodbye to a couple of Atom-based netbooks that
were x86 32-bit but still in working condition because Fedora stopped
supporting this arch.

>  Like the already accepted Fedora 37 change to retire ARMv7 support,
>  the hardware targeted tends to be rather underpowered by today’s
>  standards, and the world has moved on from it. 
ARMv7 retirement is irrelevant to this change, but "the world" hasn't
moved on from it except maybe for your part of the world. Please stop
generalizing.

>  Intel stopped shipping the last vestiges of BIOS support in 2020 (as
>  have other vendors, and Apple and Microsoft), so this is clearly the
>  way things are heading - and therefore aligns with Fedora’s “First”
>  objective. 
I've always understood Fedora's "First" foundation to be "First to
implement new features/standards", not "First to stop supporting legacy
stuff".

If 2020 is the year when no new machines are built with BIOS then give
it at least another 10 years for the old hardware to die out.

>  == Feedback ==
>  Dropping legacy BIOS was previously discussed (but not proposed) in 2020:
>
> https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject...
>  
>  Important, relevant points from that thread (yes, I reread the entire
>  thread) that have informed this change:
>  
>  * Some machines are BIOS-only.  This change does not prevent their use
>  yet, but they are effectively deprecated.  grub2 (our default
>  bootloader) is already capable of both BIOS and UEFI booting.
>  * Drawing a clear year cutoff, let alone a detailed list of hardware
>  this change affects, is basically impossible.  This is unfortunate but
>  unlikely to ever change.
>  * There is no migration story from Legacy BIOS to UEFI -
>  repartitioning effectively mandates a reinstall.  As a result, we
>  don’t drop support for existing Legacy BIOS systems yet, just new
>  installations.
>  * There is no way to deprecate hardware without causing some amount of friction.
>  * While at the time AWS did not support UEFI booting, that is no
>  longer the case and they support UEFI today. 
All these points are valid (with the exception of migration, which is
possible, but difficult). However, I'd argue that now is too early to
remove BIOS installation support. This could be revisited in a couple of
years, but right now the feedback you're receiving is overwhelmingly
negative.

>  == Benefit to Fedora ==
>  UEFI is required for many desirable features, including applying
>  firmware updates (fwupd) and supporting SecureBoot.  As a standalone
>  change, it reduces support burden on everything involved in installing
>  Fedora, since there becomes only one way to do it per platform.
>  Finally, it simplifies our install/live media, since it too only has
>  to boot one way per arch.  Freedom Friends Features First - this is
>  that last one. 
This change fails to uphold three out of four Fedora foundations and
even the fourth one is questionable in this case. I can understand the
benefit of reducing maintenance burden, but don't pretend it's to uphold
Fedora foundations.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Neal Gompa]

On Wed, Apr 6, 2022 at 12:04 AM Gary Buhrmaster
<gary.buhrmaster(a)gmail.com&gt; wrote:
>  On Wed, Apr 6, 2022 at 12:59 AM Demi Marie Obenour
>  <demiobenour(a)gmail.com&gt; wrote:
>  >
>  > On 4/5/22 19:38, Chris Murphy wrote:
>  > > We either want users with NVIDIA hardware to be inside the Secure Boot
>  > > fold or we don't. I want them in the fold *despite* the driver that
>  > > needs signing is proprietary. That's a better user experience across
>  > > the board, including the security messaging is made consistent. The
>  > > existing policy serves no good at all and is double talk. If we really
>  > > care about security more than ideological worry, we'd sign the driver.
>  >
>  > I agree with this.  Sign the driver.
>
>  Nvidia has their driver signed for their
>  Windows drivers.  That they choose
>  not to do so for Linux is their right,
>  even if some wish they did.
>
>  It should be noted that while many
>  might wish nvidia chose a different
>  way, that is completely orthogonal
>  to bios vs uefi. 
Linux, like Windows, requires the distribution vendor to sign modules
for automatic trust. There are a number of complicated issues that
make it difficult for us to sign this particular driver, though.
Notably, NVIDIA themselves acknowledges that it infringes on the GPL
to redistribute built kernel module blobs of nvidia.ko[1], so that means
any method of signing it needs to be done locally, which means we
*need* the local signing path to be improved.

[1]: https://imgur.com/LUCQ3WW




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

[Richard Hughes]

On Wed, 6 Apr 2022 at 11:20, Dominik 'Rathann' Mierzejewski
<dominik(a)greysector.net&gt; wrote:
>  > and on its way out.  As it ages, maintainability has decreased,
> and
>  > the status quo of maintaining both stacks in perpetuity is not viable
>  > for those currently doing that work.
>  Have you tried getting more people involved? 
I don't think that's how Open Source works. Realistically the way I
see this playing out is that the people responsible for maintaining
the legacy boot stack will retire the packages, some well meaning
community people take them over, then everything breaks in an
unexpected way before a Fedora release for some technical reason and
the new package maintainers have no idea how to fix the underlying
issue. Then Fedora QA needs to decide if the legacy boot failure is
actually release blocking. I'm happy to be proved wrong, but asking
someone "have you tried getting more people involved" is neither
helpful nor realistic.

Richard

[John Boero]

I can fully understand why this would be done.  As per the original discussion when Peter
Robinson mentioned a Spin to deprecate BIOS, would anybody else be interested in helping
with a Spin for legacy BIOS support?  I agree with the e-waste comments and it seems a
shame to trash some perfectly viable kiosks or old IoT which gave new life to old kit.  I
just got done knocking Windows 11 for deprecating support for fairly new hardware but now
realize Fedora is doing something similar (though not as drastic).  Is a spin worth
exploring?  Volunteers welcome.

[Neal Gompa]

On Wed, Apr 6, 2022 at 7:14 AM John Boero <boeroboy(a)gmail.com&gt; wrote:
>  I can fully understand why this would be done.  As per the original discussion when Peter
> Robinson mentioned a Spin to deprecate BIOS, would anybody else be interested in helping
> with a Spin for legacy BIOS support?  I agree with the e-waste comments and it seems a
> shame to trash some perfectly viable kiosks or old IoT which gave new life to old kit.  I
> just got done knocking Windows 11 for deprecating support for fairly new hardware but now
> realize Fedora is doing something similar (though not as drastic).  Is a spin worth
> exploring?  Volunteers welcome. 
The pull request to delete the code for BIOS support in lorax means
that we can't produce media with BIOS support at all once that's
merged. They've tied dropping syslinux to dropping BIOS support
entirely. It is also unclear that they'd take a contribution to rewire
lorax to produce media with BIOS support using GRUB like we do for
UEFI.



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

[Vitaly Zaitsev]

On 05/04/2022 16:52, Ben Cotton wrote:
>  Make UEFI a hardware requirement for new Fedora installations on
>  platforms that support it (x86_64).  Legacy BIOS support is not
>  removed, but new non-UEFI installation is not supported on those
>  platforms.  This is a first step toward eventually removing legacy
>  BIOS support entirely. 
+1. Then we can finally deprecate and drop GRUB2 and switch to systemd-boot.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Neal Gompa]

On Wed, Apr 6, 2022 at 7:30 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  On 05/04/2022 16:52, Ben Cotton wrote:
>  > Make UEFI a hardware requirement for new Fedora installations on
>  > platforms that support it (x86_64).  Legacy BIOS support is not
>  > removed, but new non-UEFI installation is not supported on those
>  > platforms.  This is a first step toward eventually removing legacy
>  > BIOS support entirely.
>
>  +1. Then we can finally deprecate and drop GRUB2 and switch to systemd-boot.
>  
Irrespective of this change, I would flat-out oppose moving to
sd-boot. In any case, you can't use sd-boot for live media.

If we were going to move to pure EFI boot manager, I'd rather use one
that has a decent user experience and not a barebones crappy one.




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

[Vít Ondruch]

Dne 05. 04. 22 v 17:08 Neal Gompa napsal(a):
>  On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton <bcotton(a)redhat.com&gt;
> wrote:
> > https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
> >
> > == Summary ==
> > Make UEFI a hardware requirement for new Fedora installations on
> > platforms that support it (x86_64).  Legacy BIOS support is not
> > removed, but new non-UEFI installation is not supported on those
> > platforms.  This is a first step toward eventually removing legacy
> > BIOS support entirely.
> >
> > == Owner ==
> > * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří
> > Konečný]], [[User:bcl| Brian C. Lane]]
> > * Email: rharwood(a)redhat.com
> >
> >
> > == Detailed Description ==
> > UEFI is defined by a versioned standard that can be tested and
> > certified against.  By contrast, every legacy BIOS is unique. Legacy
> > BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple)
> > and on its way out.  As it ages, maintainability has decreased, and
> > the status quo of maintaining both stacks in perpetuity is not viable
> > for those currently doing that work.
> >
> > It is inevitable that legacy BIOS will be removed in a future release.
> > To ease this transition as best we can, there will be a period (of at
> > least one Fedora release) where it will be possible to boot using the
> > legacy BIOS codepaths, but new installations will not be possible.
> > While it would be easier for us to cut support off today, our hope is
> > that this compromise position will make for a smoother transition.
> > Additional support with issues during the transition would be
> > appreciated.
> >
> > While this will eventually reduce workload for boot/installation
> > components (grub2 reduces surface area, syslinux goes away entirely,
> > anaconda reduces surface area), the reduction in support burden
> > extends much further into the stack - for instance, VESA support can
> > be removed from the distro.
> >
> > Fedora already requires a 2GHz dual core CPU at minimum (and therefore
> > mandates that machines must have been made after 2006).  Like the
> > already accepted Fedora 37 change to retire ARMv7 support, the
> > hardware targeted tends to be rather underpowered by today’s
> > standards, and the world has moved on from it.  Intel stopped shipping
> > the last vestiges of BIOS support in 2020 (as have other vendors, and
> > Apple and Microsoft), so this is clearly the way things are heading -
> > and therefore aligns with Fedora’s “First” objective.
> >
> > == Feedback ==
> > Dropping legacy BIOS was previously discussed (but not proposed) in 2020:
> >
> https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject...
> >
> > Important, relevant points from that thread (yes, I reread the entire
> > thread) that have informed this change:
> >
> > * Some machines are BIOS-only.  This change does not prevent their use
> > yet, but they are effectively deprecated.  grub2 (our default
> > bootloader) is already capable of both BIOS and UEFI booting.
> > * Drawing a clear year cutoff, let alone a detailed list of hardware
> > this change affects, is basically impossible.  This is unfortunate but
> > unlikely to ever change.
> > * There is no migration story from Legacy BIOS to UEFI -
> > repartitioning effectively mandates a reinstall.  As a result, we
> > don’t drop support for existing Legacy BIOS systems yet, just new
> > installations.
> > * There is no way to deprecate hardware without causing some amount of friction.
> > * While at the time AWS did not support UEFI booting, that is no
> > longer the case and they support UEFI today.
> >
> > == Benefit to Fedora ==
> > UEFI is required for many desirable features, including applying
> > firmware updates (fwupd) and supporting SecureBoot.  As a standalone
> > change, it reduces support burden on everything involved in installing
> > Fedora, since there becomes only one way to do it per platform.
> > Finally, it simplifies our install/live media, since it too only has
> > to boot one way per arch.  Freedom Friends Features First - this is
> > that last one.
> >
> > == Scope ==
> > * Proposal owners:
> > ** bootloaders: No change (existing Legacy BIOS installations still supported).
> > ** anaconda: No change (there could be only optional cleanups in the
> > code). However, it needs to be verified.
> > ** Lorax: Code has already been written:
> > https://github.com/weldr/lorax/pull/1205
> >
>  This pull request primarily drops legacy BIOS support by dropping
>  syslinux/isolinux. We don't necessarily have to drop legacy BIOS
>  support there if we reuse GRUB there too. Other distributions
>  (openSUSE and Mageia, notably) both use GRUB for both BIOS and UEFI on
>  live media.
>
> > * Other developers:
> > ** libvirt: UEFI works today, but is not the default.  UEFI-only
> > installation is needed for Windows 11, and per conversations, libvirt
> > is prepared for this change.
> > ** Virtualbox: UEFI Fedora installs are working and per virtualbox
> > team, UEFI will be/is the default in 7.0+.
> > ** The Hardware Overview page should be updated to mention the UEFI
> > requirement:
> https://docs.fedoraproject.org/en-US/fedora/rawhide/release-notes/welcome...
> >
> > * Release engineering: [https://pagure.io/releng/issue/10738 #Releng
> > issue 10738]
> >
> > * Policies and guidelines: N/A (not needed for this Change)
> >
> > * Trademark approval: N/A (not needed for this Change)
> >
> > * Alignment with Objectives: N/A
> >
> > == Upgrade/compatibility impact ==
> > Systems currently using Legacy BIOS for booting on x86_64 will
> > continue to do so.
> >
> > However, this modifies the baseline Fedora requirements and some
> > hardware will no longer be supported for new installations.
> >
> > == How To Test ==
> > UEFI installation has been supported for quite a while already, so
> > additional testing there should not be required.
> >
> > == User Experience ==
> > Installs will continue to work on UEFI, and will not work on Legacy
> > BIOS.  Our install media is already UEFI-capable.
> >
> > == Dependencies ==
> > None
> >
> > == Contingency Plan ==
> > Leave things as they are.  Code continues to rot.  Community
> > assistance is required to continue the status quo.  Current owners
> > plan to orphan some packages regardless of whether the proposal is
> > accepted.
> >
> > Another fallback option could be, if a Legacy BIOS SIG organizes, to
> > donate the relevant packages there and provide some initial mentoring.
> > Longer term, packages that cannot be wholly donated could be split,
> > though it is unclear whether the synchronization thereby required
> > would reduce the work for anyone.
> >
> > * Contingency mechanism: Delay until next release.
> > * Contingency deadline: Beta freeze
> > * Blocks release? No
> >
> > == Documentation ==
> > See release notes.
> >
> > == Release Notes ==
> > Fedora 37 marks legacy BIOS installation as deprecated on x86_64 in
> > favor of UEFI.  While systems already using Legacy BIOS to boot are
> > still supported, new legacy BIOS installations on these architectures
> > are no longer possible.  Legacy BIOS support will be removed entirely
> > in a future Fedora.
> >
> > (Additionally, the Hardware Overview page should be updated to mention
> > the UEFI requirement.)
> >
>  While I'm sympathetic to this Change, I think this is way too early to
>  do across the board. UEFI came onto the scene in the PC space in
>  2011~2012 with Windows 8, and even to this day, there are sufficiently
>  buggy hardware platforms that Linux does not boot in UEFI mode:
>  https://twitter.com/VKCsh/status/1511132132885815307
>
>  I even have one such machine, an HP desktop machine that came with
>  Windows 8. My current desktop PC has problems booting Linux UEFI as
>  well, though I've done "clever" things to work around that. I don't
>  expect most users to be able to deal with that. Server platforms were
>  *worse* as they were slower to offer UEFI. The first time I was able
>  to get a server with UEFI was in 2014.
>  

Maybe I don't correctly understand the "Legacy BIOS support is not 
removed, but new non-UEFI installation is not supported on those 
platforms." quoted from the the change description, but if you have your 
system installed, it should keep working. You just keep updating. IOW as 
long as you don't reinstall the system, you are fine and you don't have 
to be concerned.

If you really have a need to reinstall such machine, you'll take the F36 
image and upgrade to F37+ and you should still be good.


Vít


>  And we've still failed to get ARM and RISC-V broadly on board
> with
>  UEFI (though that's irrelevant to this Change, even though ARM is
>  mentioned).
>
>  We also lack solutions for dealing with the NVIDIA driver in
>  UEFI+Secure Boot case. Are you planning to actually *fix* that now?
>  Because we still don't have a way to have kernel-only keyrings for
>  secure boot certificates to avoid importing them into the firmware.
>
>
>
>
>  --
>  真実はいつも一つ！/ Always, there's only one truth!
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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
>

[Ben Beasley]

Indeed, HP (now HPE) first introduced UEFI support to their ProLiant 
servers in the Gen8 series, which I believe was around 2013. While I 
think the previous G7 servers have reached the end of their support 
lifecycle (but are probably still happily running in some places), UEFI 
has indeed been supported on some vendors’ server hardware for less than 
ten years.

I also manage a desktop for a family member based on an AMD Phenom II X4 
CPU and ASUS M4A88T-V EVO/USB3 motherboard. It was built at the very end 
of 2010 with new upper-mid-range hardware, so it’s a bit over ten years 
old. It doesn’t support UEFI. On the other hand, it’s a 3.4 GHz 
quad-core platform and still extremely usable.

Until 2021, my primary computer was a circa-2007 desktop that did not 
support UEFI. Again, with a Q6600 (2.4 GHz quad-core CPU) and a modern 
SSD, it was more than usable. I elected to replace rather than repair it 
after a power supply failure.

I can’t say I oppose this Change, because I can’t do anything to 
mitigate the underlying reasons that it appears to be necessary. Still, 
I agree that it will impact much newer and “better” hardware than some 
people might have expected.

On 4/6/22 04:06, laolux laolux via devel wrote:
> I have no strong opinion on this, and not much say anyways, but I thought I could
share my little piece of info.
> My currently one and only computer is a 2012 MSI GE60 0ND, with a core i7-3630QM,
16GB RAM and retrofitted with a SSD.
> So I would say fast enough for using Fedora. At least according to notebookcheck.com
the CPU is supposed to be faster than a rather recent Core i3-1110G4, which is still being
used in new notebooks in 2022.
> Unfortunately it only supports legacy BIOS, and not UEFI.
> Thus I do not like the wording of the change proposal.
>
>> Fedora already requires a 2GHz dual core CPU at minimum (and therefore
>> mandates that machines must have been made after 2006).  Like the
>> already accepted Fedora 37 change to retire ARMv7 support, the
>> hardware targeted tends to be rather underpowered by today’s
>> standards, and the world has moved on from it.  Intel stopped shipping
>> the last vestiges of BIOS support in 2020 (as have other vendors, and
>> Apple and Microsoft), so this is clearly the way things are heading -
>> and therefore aligns with Fedora’s “First” objective.
> This seems to imply that only rather old and weak hardware would be affected, when
clearly the cutoff is (at maximum) only 10 years back.
> Please don't get me wrong, I am perfectly fine about Fedora dropping
"old" hardware, and I am willing to throw away my still working notebook,
producing a little bit electronic waste when the time comes. But I think one should be
more open and explicit about it.
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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

[PGNet Dev]

On 4/6/22 8:03 AM, Vít Ondruch wrote:
>  If you really have a need to reinstall such machine, you'll take
> the F36 image and upgrade to F37+ and you should still be good. 
With 100s - 1000s of of affected machines -- real & virtual -- still in operation,
with usable lifetimes of years-to-come,
from a planner's perspective, given the choice of that^ risk vs moving to a different
distro where there's a more realistic sunset, curious ...
... what do ppl here think will be the choice (about continued use of RH/Centos/Fedora)?

best for developers != (necessarily) best for customers/users.

[Josh Boyer]

On Wed, Apr 6, 2022 at 7:08 AM Richard Hughes <hughsient(a)gmail.com&gt; wrote:
>  On Wed, 6 Apr 2022 at 11:20, Dominik 'Rathann' Mierzejewski
>  <dominik(a)greysector.net&gt; wrote:
>  > > and on its way out.  As it ages, maintainability has decreased, and
>  > > the status quo of maintaining both stacks in perpetuity is not viable
>  > > for those currently doing that work.
>  > Have you tried getting more people involved?
>
>  I don't think that's how Open Source works. Realistically the way I
>  see this playing out is that the people responsible for maintaining
>  the legacy boot stack will retire the packages, some well meaning
>  community people take them over, then everything breaks in an
>  unexpected way before a Fedora release for some technical reason and
>  the new package maintainers have no idea how to fix the underlying
>  issue. Then Fedora QA needs to decide if the legacy boot failure is
>  actually release blocking. I'm happy to be proved wrong, but asking
>  someone "have you tried getting more people involved" is neither
>  helpful nor realistic. 
I agree 100%.  I think this is actually getting to the crux of the
issue, which is that while we have a lot of people that want BIOS
support to continue, we effectively have nobody that wants to do the
work to make it happen.  We saw this with i686 installations and
kernels, and I suspect the same will happen here.  Even if Fedora QA
decided it was release blocking, if there's nobody to do the work what
does that actually mean?  Fedora doesn't release indefinitely?

The one positive thing that comes from this is that it will create an
opportunity for people to learn about a new tech stack to scratch
their own itch.  That doesn't mean it will be successful in the end,
but the community has always surprised me in many ways.  It could lead
to a Fedora Remix or Spin, for example.

josh

[Neal Gompa]

On Wed, Apr 6, 2022 at 8:04 AM Vít Ondruch <vondruch(a)redhat.com&gt; wrote:
>  Dne 05. 04. 22 v 17:08 Neal Gompa napsal(a):
>  > On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  >> https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
>  >>
>  >> == Summary ==
>  >> Make UEFI a hardware requirement for new Fedora installations on
>  >> platforms that support it (x86_64).  Legacy BIOS support is not
>  >> removed, but new non-UEFI installation is not supported on those
>  >> platforms.  This is a first step toward eventually removing legacy
>  >> BIOS support entirely.
>  >>
>  >> == Owner ==
>  >> * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří
>  >> Konečný]], [[User:bcl| Brian C. Lane]]
>  >> * Email: rharwood(a)redhat.com
>  >>
>  >>
>  >> == Detailed Description ==
>  >> UEFI is defined by a versioned standard that can be tested and
>  >> certified against.  By contrast, every legacy BIOS is unique. Legacy
>  >> BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple)
>  >> and on its way out.  As it ages, maintainability has decreased, and
>  >> the status quo of maintaining both stacks in perpetuity is not viable
>  >> for those currently doing that work.
>  >>
>  >> It is inevitable that legacy BIOS will be removed in a future release.
>  >> To ease this transition as best we can, there will be a period (of at
>  >> least one Fedora release) where it will be possible to boot using the
>  >> legacy BIOS codepaths, but new installations will not be possible.
>  >> While it would be easier for us to cut support off today, our hope is
>  >> that this compromise position will make for a smoother transition.
>  >> Additional support with issues during the transition would be
>  >> appreciated.
>  >>
>  >> While this will eventually reduce workload for boot/installation
>  >> components (grub2 reduces surface area, syslinux goes away entirely,
>  >> anaconda reduces surface area), the reduction in support burden
>  >> extends much further into the stack - for instance, VESA support can
>  >> be removed from the distro.
>  >>
>  >> Fedora already requires a 2GHz dual core CPU at minimum (and therefore
>  >> mandates that machines must have been made after 2006).  Like the
>  >> already accepted Fedora 37 change to retire ARMv7 support, the
>  >> hardware targeted tends to be rather underpowered by today’s
>  >> standards, and the world has moved on from it.  Intel stopped shipping
>  >> the last vestiges of BIOS support in 2020 (as have other vendors, and
>  >> Apple and Microsoft), so this is clearly the way things are heading -
>  >> and therefore aligns with Fedora’s “First” objective.
>  >>
>  >> == Feedback ==
>  >> Dropping legacy BIOS was previously discussed (but not proposed) in 2020:
>  >>
> https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject...
>  >>
>  >> Important, relevant points from that thread (yes, I reread the entire
>  >> thread) that have informed this change:
>  >>
>  >> * Some machines are BIOS-only.  This change does not prevent their use
>  >> yet, but they are effectively deprecated.  grub2 (our default
>  >> bootloader) is already capable of both BIOS and UEFI booting.
>  >> * Drawing a clear year cutoff, let alone a detailed list of hardware
>  >> this change affects, is basically impossible.  This is unfortunate but
>  >> unlikely to ever change.
>  >> * There is no migration story from Legacy BIOS to UEFI -
>  >> repartitioning effectively mandates a reinstall.  As a result, we
>  >> don’t drop support for existing Legacy BIOS systems yet, just new
>  >> installations.
>  >> * There is no way to deprecate hardware without causing some amount of
> friction.
>  >> * While at the time AWS did not support UEFI booting, that is no
>  >> longer the case and they support UEFI today.
>  >>
>  >> == Benefit to Fedora ==
>  >> UEFI is required for many desirable features, including applying
>  >> firmware updates (fwupd) and supporting SecureBoot.  As a standalone
>  >> change, it reduces support burden on everything involved in installing
>  >> Fedora, since there becomes only one way to do it per platform.
>  >> Finally, it simplifies our install/live media, since it too only has
>  >> to boot one way per arch.  Freedom Friends Features First - this is
>  >> that last one.
>  >>
>  >> == Scope ==
>  >> * Proposal owners:
>  >> ** bootloaders: No change (existing Legacy BIOS installations still supported).
>  >> ** anaconda: No change (there could be only optional cleanups in the
>  >> code). However, it needs to be verified.
>  >> ** Lorax: Code has already been written:
>  >> https://github.com/weldr/lorax/pull/1205
>  >>
>  > This pull request primarily drops legacy BIOS support by dropping
>  > syslinux/isolinux. We don't necessarily have to drop legacy BIOS
>  > support there if we reuse GRUB there too. Other distributions
>  > (openSUSE and Mageia, notably) both use GRUB for both BIOS and UEFI on
>  > live media.
>  >
>  >> * Other developers:
>  >> ** libvirt: UEFI works today, but is not the default.  UEFI-only
>  >> installation is needed for Windows 11, and per conversations, libvirt
>  >> is prepared for this change.
>  >> ** Virtualbox: UEFI Fedora installs are working and per virtualbox
>  >> team, UEFI will be/is the default in 7.0+.
>  >> ** The Hardware Overview page should be updated to mention the UEFI
>  >> requirement:
> https://docs.fedoraproject.org/en-US/fedora/rawhide/release-notes/welcome...
>  >>
>  >> * Release engineering: [https://pagure.io/releng/issue/10738 #Releng
>  >> issue 10738]
>  >>
>  >> * Policies and guidelines: N/A (not needed for this Change)
>  >>
>  >> * Trademark approval: N/A (not needed for this Change)
>  >>
>  >> * Alignment with Objectives: N/A
>  >>
>  >> == Upgrade/compatibility impact ==
>  >> Systems currently using Legacy BIOS for booting on x86_64 will
>  >> continue to do so.
>  >>
>  >> However, this modifies the baseline Fedora requirements and some
>  >> hardware will no longer be supported for new installations.
>  >>
>  >> == How To Test ==
>  >> UEFI installation has been supported for quite a while already, so
>  >> additional testing there should not be required.
>  >>
>  >> == User Experience ==
>  >> Installs will continue to work on UEFI, and will not work on Legacy
>  >> BIOS.  Our install media is already UEFI-capable.
>  >>
>  >> == Dependencies ==
>  >> None
>  >>
>  >> == Contingency Plan ==
>  >> Leave things as they are.  Code continues to rot.  Community
>  >> assistance is required to continue the status quo.  Current owners
>  >> plan to orphan some packages regardless of whether the proposal is
>  >> accepted.
>  >>
>  >> Another fallback option could be, if a Legacy BIOS SIG organizes, to
>  >> donate the relevant packages there and provide some initial mentoring.
>  >> Longer term, packages that cannot be wholly donated could be split,
>  >> though it is unclear whether the synchronization thereby required
>  >> would reduce the work for anyone.
>  >>
>  >> * Contingency mechanism: Delay until next release.
>  >> * Contingency deadline: Beta freeze
>  >> * Blocks release? No
>  >>
>  >> == Documentation ==
>  >> See release notes.
>  >>
>  >> == Release Notes ==
>  >> Fedora 37 marks legacy BIOS installation as deprecated on x86_64 in
>  >> favor of UEFI.  While systems already using Legacy BIOS to boot are
>  >> still supported, new legacy BIOS installations on these architectures
>  >> are no longer possible.  Legacy BIOS support will be removed entirely
>  >> in a future Fedora.
>  >>
>  >> (Additionally, the Hardware Overview page should be updated to mention
>  >> the UEFI requirement.)
>  >>
>  > While I'm sympathetic to this Change, I think this is way too early to
>  > do across the board. UEFI came onto the scene in the PC space in
>  > 2011~2012 with Windows 8, and even to this day, there are sufficiently
>  > buggy hardware platforms that Linux does not boot in UEFI mode:
>  > https://twitter.com/VKCsh/status/1511132132885815307
>  >
>  > I even have one such machine, an HP desktop machine that came with
>  > Windows 8. My current desktop PC has problems booting Linux UEFI as
>  > well, though I've done "clever" things to work around that. I
> don't
>  > expect most users to be able to deal with that. Server platforms were
>  > *worse* as they were slower to offer UEFI. The first time I was able
>  > to get a server with UEFI was in 2014.
>
>
>  Maybe I don't correctly understand the "Legacy BIOS support is not
>  removed, but new non-UEFI installation is not supported on those
>  platforms." quoted from the the change description, but if you have your
>  system installed, it should keep working. You just keep updating. IOW as
>  long as you don't reinstall the system, you are fine and you don't have
>  to be concerned.
>
>  If you really have a need to reinstall such machine, you'll take the F36
>  image and upgrade to F37+ and you should still be good.
>  
This is not a deprecation change, this is effectively a removal
change. By removing the packages and the tooling support for legacy
BIOS, it makes several scenarios (including recovery) harder.
Moreover, it puts the burden on people to figure out if their hardware
can boot and install Fedora when we clearly haven't reached a critical
mass yet for doing so, like we did when we finally removed the i686
kernel build.

I'm personally a fan of using UEFI instead of BIOS. Heck, I
implemented support for UEFI in Fedora's cloud images when other
people told me it was not possible, while preserving BIOS support.
I've been trying to figure out the roadmap for BIOS deprecation for a
year now, and the reason *I* didn't propose a Change yet is because I
have not sufficiently determined that it was reasonable to do so.

I'm particularly upset about this Change because it feels like a
hostage change where the proposal owners blithely ignore what we're
saying as unimportant or irrelevant and abuse our principles to do
things that are clearly against what the community feels is right.

I have been trying in the background for years to try to figure out
solutions for usability problems in Fedora Linux on UEFI because *I
want our experience to be good there*. But it's extremely hard when:

1. Bugs and feature requests around UEFI related features are ignored
2. The packages are locked down so there is no way for the community to help
3. At various times, people have explicitly said "patches NOT welcome"

I'm angry because we're doing this without any real thought around the
consequences for the user experience, and we should not do that as a
premier Linux distribution.


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

[Gary Buhrmaster]

On Wed, Apr 6, 2022 at 1:16 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  On Tue, Apr 5, 2022 at 9:07 PM Demi Marie Obenour <demiobenour(a)gmail.com&gt; wrote:
>  >
>  > On 4/5/22 16:09, Neal Gompa wrote: 
>  > > This problem also makes life miserable for people working
> with third
>  > > party open source kernel modules too. As a live streamer, for example,
>  > > I need to use v4l2loopback, which will never exist in mainline because
>  > > v4l2 maintainers don't like it at all. 
>  > Are you sure about that?  There is probably a better place to
> talk
>  > about this, but Qubes OS also will be needing v4l2loopback soon (for
>  > Qubes Video Companion) and so I have a strong interest in getting it
>  > upstreamed.
>  >
>
>  Yes. Last I heard, V4L2 folks think it'd be used to bypass making a
>  real camera driver for the kernel. That's pretty much why it's not
>  there. 
Well, I think it was mostly one person, but as
they are the primary maintainer for the subsystem
that opinion carries some weight (although it
should be noted that another co/sub-maintainer
has been somewhat more interested in getting
v4l2loopback upstreamed).  However, last I knew,
there was still some significant work to be
completed on the driver in order to meet current
kernel and subsystem standards before it could
be reconsidered for inclusion.  Those that want
to see the driver upstreamed should likely
contribute to those changes.

[PGNet Dev]

I'm shutting up now, because this comment from ngompa is, IMO, very well/thoroughly
said.
thx Neal!

On 4/6/22 8:16 AM, Neal Gompa wrote:
> > If you really have a need to reinstall such machine, you'll
> take the F36
> > image and upgrade to F37+ and you should still be good.
> >
>  
>  This is not a deprecation change, this is effectively a removal
>  change. By removing the packages and the tooling support for legacy
>  BIOS, it makes several scenarios (including recovery) harder.
>  Moreover, it puts the burden on people to figure out if their hardware
>  can boot and install Fedora when we clearly haven't reached a critical
>  mass yet for doing so, like we did when we finally removed the i686
>  kernel build.
>  
>  I'm personally a fan of using UEFI instead of BIOS. Heck, I
>  implemented support for UEFI in Fedora's cloud images when other
>  people told me it was not possible, while preserving BIOS support.
>  I've been trying to figure out the roadmap for BIOS deprecation for a
>  year now, and the reason *I* didn't propose a Change yet is because I
>  have not sufficiently determined that it was reasonable to do so.
>  
>  I'm particularly upset about this Change because it feels like a
>  hostage change where the proposal owners blithely ignore what we're
>  saying as unimportant or irrelevant and abuse our principles to do
>  things that are clearly against what the community feels is right.
>  
>  I have been trying in the background for years to try to figure out
>  solutions for usability problems in Fedora Linux on UEFI because *I
>  want our experience to be good there*. But it's extremely hard when:
>  
>  1. Bugs and feature requests around UEFI related features are ignored
>  2. The packages are locked down so there is no way for the community to help
>  3. At various times, people have explicitly said "patches NOT welcome"
>  
>  I'm angry because we're doing this without any real thought around the
>  consequences for the user experience, and we should not do that as a
>  premier Linux distribution.

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 06 April 2022 at 13:07, Richard Hughes wrote:
>  On Wed, 6 Apr 2022 at 11:20, Dominik 'Rathann' Mierzejewski
>  <dominik(a)greysector.net&gt; wrote:
>  > > and on its way out.  As it ages, maintainability has decreased, and
>  > > the status quo of maintaining both stacks in perpetuity is not viable
>  > > for those currently doing that work.
>  > Have you tried getting more people involved?
>  
>  I don't think that's how Open Source works. Realistically the way I
>  see this playing out is that the people responsible for maintaining
>  the legacy boot stack will retire the packages, 
I thought they would be orphaned, if anything. Retiring seems rather
hostile to the people who still need those packages (which are those,
by the way?).

>  some well meaning
>  community people take them over, then everything breaks in an
>  unexpected way before a Fedora release for some technical reason and 
If this change is accepted, then BIOS-based installations will break
and will have to be removed from release blocking criteria because
anaconda will simply not support that use case anymore. That's how I
understand the impact although this is not explicitly written in the
change proposal.

>  the new package maintainers have no idea how to fix the underlying
>  issue. Then Fedora QA needs to decide if the legacy boot failure is
>  actually release blocking. I'm happy to be proved wrong, but asking
>  someone "have you tried getting more people involved" is neither
>  helpful nor realistic. 
It's helpful to show the change proponents attitude. As a way of "asking
more people to get involved", I'd expect a list of packages the change
proponents no longer whish to maintain and a date when they will orphan
them, since they've stated they're going to do that anyway. Without such
list it's difficult to assess the scope of the work required to maintain
the affected software stack. I don't see any such details in the change
proposal.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Gary Buhrmaster]

On Wed, Apr 6, 2022 at 12:15 PM Josh Boyer <jwboyer(a)fedoraproject.org&gt; wrote:

>  I agree 100%.  I think this is actually getting to the crux of the
>  issue, which is that while we have a lot of people that want BIOS
>  support to continue, we effectively have nobody that wants to do the
>  work to make it happen. 
In a previous thread about bios support, there
was a discussion about (a mythical) someone
resurrecting DUET to provide a transition path.

To the best of my knowledge, no one stepped
up to do that work[0].

Gary


[0] Quite honestly, given that DUET was removed
upstream, I would have thought looking instead
at Clover (which is still supported) would be a
better option, but better only in some theoretical
sense, as there was no one to do that work
either.

[JT]

On Wed, Apr 6, 2022 at 4:06 AM laolux laolux via devel <
devel(a)lists.fedoraproject.org&gt; wrote:

>  I have no strong opinion on this, and not much say anyways, but I
> thought
>  I could share my little piece of info.
>  My currently one and only computer is a 2012 MSI GE60 0ND, with a core
>  i7-3630QM, 16GB RAM and retrofitted with a SSD.
>  So I would say fast enough for using Fedora. At least according to
>  notebookcheck.com the CPU is supposed to be faster than a rather recent
>  Core i3-1110G4, which is still being used in new notebooks in 2022.
>  Unfortunately it only supports legacy BIOS, and not UEFI.
>  Thus I do not like the wording of the change proposal.
>
>  > Fedora already requires a 2GHz dual core CPU at minimum (and therefore
>  > mandates that machines must have been made after 2006).  Like the
>  > already accepted Fedora 37 change to retire ARMv7 support, the
>  > hardware targeted tends to be rather underpowered by today’s
>  > standards, and the world has moved on from it.  Intel stopped shipping
>  > the last vestiges of BIOS support in 2020 (as have other vendors, and
>  > Apple and Microsoft), so this is clearly the way things are heading -
>  > and therefore aligns with Fedora’s “First” objective.
>
>  This seems to imply that only rather old and weak hardware would be
>  affected, when clearly the cutoff is (at maximum) only 10 years back.
>  Please don't get me wrong, I am perfectly fine about Fedora dropping "old"
>  hardware, and I am willing to throw away my still working notebook,
>  producing a little bit electronic waste when the time comes. But I think
>  one should be more open and explicit about it.
>
>  
At the risk of being 'that guy' it's worth pointing out that not
everyone
lives in a 1st world country and has access to cheap powerful hardware.  I
have good friends in Namibia and Cote d'Ivoire who are still using Fedora
on Core2Duo systems from pre 2010, because the machines are still perfectly
functional and do what they need them to do.
I realize some will have the attitude of "they can just not upgrade and
keep using their old Fedora versions".  Ok, that's a possible solution,
except that Fedora versions get EOL'd pretty quickly, so we'd basically be
taking the stance of 'buy new hardware if you want updates'.

Fedora has made a big deal about being considered a "Digital Public Good";
and we are right to be proud of that.  But if we're going to be proud of
that, let's not also decide to screw over areas that are not as
economically strong as where most of us are lucky enough to live.  It's
kind of arrogant of us to expect that everyone who uses Fedora is
financially able to go out and replace their hardware all the time even
when there's nothing wrong with it.
Are we only making Fedora for those with lots of spare money or is Fedora
for everyone?
/end being that guy

[David Both]

I live in a 1st world country and have lots of new computers that this
change would not affect. However I still have some older computers that
fall outside the UEFI range and use only BIOS. I would still like to
keep these computers running and up to date so that they are secure and
have the most recent fixes. I also know many people who only have access
to 2nd or 3rd hand computers.

I do have a strong opinion and I say that it is too early to drop BIOS
support. There will probably be BIOS-only computers out there for years.
And one of the things I tell people when getting them to try Linux is
that it can extend the useful lives of those really old computers.

Thanks for considering my opinion.

-- 


*********************************************************
David P. Both, RHCE
He/Him/His
*********************************************************
www.both.org - My personal web site
www.Linux-Databook.info - Home of the DataBook for Linux
DataBook is a Registered Trademark of David Both
*********************************************************
The value of any software lies in its usefulness
not in its price.

— Linus Torvalds
*********************************************************

On Wed, 6 Apr 2022, JT wrote:

> Date: Wed, 6 Apr 2022 08:50:18
> From: JT <jt(a)obs-sec.com&gt;
> Reply-To: Development discussions related to Fedora
>     <devel(a)lists.fedoraproject.org&gt;
> To: Development discussions related to Fedora <devel(a)lists.fedoraproject.org&gt;
> Cc: laolux laolux <laolux(a)rocketmail.com&gt;
> Subject: Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
> 
> On Wed, Apr 6, 2022 at 4:06 AM laolux laolux via devel <
> devel(a)lists.fedoraproject.org&gt; wrote:
>
>> I have no strong opinion on this, and not much say anyways, but I thought
>> I could share my little piece of info.
>> My currently one and only computer is a 2012 MSI GE60 0ND, with a core
>> i7-3630QM, 16GB RAM and retrofitted with a SSD.
>> So I would say fast enough for using Fedora. At least according to
>> notebookcheck.com the CPU is supposed to be faster than a rather recent
>> Core i3-1110G4, which is still being used in new notebooks in 2022.
>> Unfortunately it only supports legacy BIOS, and not UEFI.
>> Thus I do not like the wording of the change proposal.
>>
>>> Fedora already requires a 2GHz dual core CPU at minimum (and therefore
>>> mandates that machines must have been made after 2006).  Like the
>>> already accepted Fedora 37 change to retire ARMv7 support, the
>>> hardware targeted tends to be rather underpowered by today’s
>>> standards, and the world has moved on from it.  Intel stopped shipping
>>> the last vestiges of BIOS support in 2020 (as have other vendors, and
>>> Apple and Microsoft), so this is clearly the way things are heading -
>>> and therefore aligns with Fedora’s “First” objective.
>>
>> This seems to imply that only rather old and weak hardware would be
>> affected, when clearly the cutoff is (at maximum) only 10 years back.
>> Please don't get me wrong, I am perfectly fine about Fedora dropping
"old"
>> hardware, and I am willing to throw away my still working notebook,
>> producing a little bit electronic waste when the time comes. But I think
>> one should be more open and explicit about it.
>>
>>
> At the risk of being 'that guy' it's worth pointing out that not
everyone
> lives in a 1st world country and has access to cheap powerful hardware.  I
> have good friends in Namibia and Cote d'Ivoire who are still using Fedora
> on Core2Duo systems from pre 2010, because the machines are still perfectly
> functional and do what they need them to do.
> I realize some will have the attitude of "they can just not upgrade and
> keep using their old Fedora versions".  Ok, that's a possible solution,
> except that Fedora versions get EOL'd pretty quickly, so we'd basically be
> taking the stance of 'buy new hardware if you want updates'.
>
> Fedora has made a big deal about being considered a "Digital Public Good";
> and we are right to be proud of that.  But if we're going to be proud of
> that, let's not also decide to screw over areas that are not as
> economically strong as where most of us are lucky enough to live.  It's
> kind of arrogant of us to expect that everyone who uses Fedora is
> financially able to go out and replace their hardware all the time even
> when there's nothing wrong with it.
> Are we only making Fedora for those with lots of spare money or is Fedora
> for everyone?
> /end being that guy
>

[John Boero]

There are other ways to create bootable media, right?  Does everything need to be
Koji+Lorax?

[Alberto Abrao]

F

On 2022-04-06 07:16, Neal Gompa wrote:
>  Moreover, it puts the burden on people to figure out if their
> hardware
>  can boot and install Fedora when we clearly haven't reached a critical
>  mass yet for doing so, like we did when we finally removed the i686
>  kernel build. 
All points by Neal were valid, and I second his post.

Also, let me state that many machines who'd be UEFI capable on paper are 
*not*: in my experience, many early UEFI machines (2009 up to 2014) have 
a very buggy implementation, to the point of being unusable and/or a 
terrible experience.

I run Fedora on a wide variety of machines, including old hardware that 
is plenty capable spec-wise, yet not feasible for UEFI boot.

If we consider Fedora Server, it gets even worse. I have a couple of 
Dual-Socket Nehalem-era Xeon boards in service. Both run Fedora. One is 
not UEFI capable at all, the other is very buggy when using it. My newer 
servers are not as powerful as these two, although they are UEFI capable.

This is to say that age alone does not tell the whole story. This change 
would leave behind a LOT of serviceable hardware even by today's standards.

Ironically, Fedora is one of the distributions out there that allows me 
to extract the most out of older hardware. It would be a terrible loss 
to have to move to a different one, but it's hard to reason purchasing 
new hardware - especially right now, with pandemic-related supply issues 
still ongoing - to keep up with this change.


Kind regards,
Alberto

[Hans de Goede]

Hi,

<to be clear I'm replying on a personal title here, not on
 behalf of my employer (Red Hat)>

On 4/5/22 16:52, Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS 
<snip>

>  Fedora already requires a 2GHz dual core CPU at minimum (and
> therefore
>  mandates that machines must have been made after 2006). 
But machines made between 2006-2012 generally did not have
EFI support, anf for example at home I still have several
machines from that era which are BIOS only in active use:

1. My daughter's workstation is an i5-2400 with 8G RAM, this
is a 3.1 GHz base-freq quad-core processor very easily
matching Fedora's minimal requirements. Currently running
Fedora 35 just fine. Making it impossible to keep using this
in the future is just causing unnecessary ewaste for no good
reason IMHO.

2. My wife's workstation is a Core 2 Duo E6600 2.4 Ghz dual
core machine with 4G RAM, which also still works fine for
what she uses it for.

3. The living room laptop is another Core 2 Duo machine with
4G RAM.

Looking specifically at fixed PCs and not laptops this
proposal would (eventually) turn 2/5 PCs in my home
unusable, which really is unacceptable IMHO.

Also note that all these machines use somewhat older Intel
integrated graphics. As he has already mentioned on this
this thread, Dave Airlie has just spend a lot of time on 
making sure those iGPU-s will work with a gallium driver
so that the classic mesa code can be removed and it seems
rather silly to drop support for this hw after just investing
a significant chunk of time to breathe new live into their
GPU support.

So a big -1 from me for this proposal as it stand.

###

But I do completely understand that there is a workload issue
for the bootloader team and the proposal also mentions:

>  == Contingency Plan ==
>  Leave things as they are.  Code continues to rot.  Community
>  assistance is required to continue the status quo.  Current owners
>  plan to orphan some packages regardless of whether the proposal is
>  accepted. 
If the current owners no longer want to support some packages
which are only necessary for legacy BIOS support, then orphaning
these seems completely reasonable to me.

Maybe you can provide a list of these pkgs before hand so that
people can already volunteer as co-maintainers now and then
when they are orphaned, instead of orphaning them they can
be directly handed over (using the "give away" button) to the
new maintainers ?

>  Another fallback option could be, if a Legacy BIOS SIG organizes, to
>  donate the relevant packages there and provide some initial mentoring. 
I believe that that is a great idea, I hereby volunteer to
try and setup such a SIG. If anyone reading this is interested
in joining such a SIG please drop me an email.

I realize that there have been similar attempts around keeping
32 bit x86 alive and that those have failed, but I believe that
this is different for a number of reasons:

1. i686 support required making sure that *all* of Fedora kept
working on i686, the problem was not just the kernel breaking
sometimes, but also that huge projects like libreoffice would
no longer start on i686 (at least on some of my machines).

Legacy BIOS boot support is basically only about the image-creation
tools + the bootloader. As various people have mentioned in the
thread BIOS support is still very much a thing in data-centers,
so I expect the upstream kernel community to keep the kernel
working with this for at least a couple of years. Where as both
the kernel + many userspace apps were breaking on i686.

2. I personally basically gave up on i686 support also because
there was very little 32 bit only x86 hw around remaining in
active use when it was dropped. And what was still on active
use was getting close to unusable from a performance pov.
Where as here we are talking about up to 2nd and 3th gen
core i5 / i7 machines which are still quite performant.

Esp. the 2nd gen core machines (Sandy Bridge) are still
quite popular and lots of people have hung on to desktops
with those because the CPU performance increase in generations
after SNB have been rather underwhelming.

>  Longer term, packages that cannot be wholly donated could be split,
>  though it is unclear whether the synchronization thereby required
>  would reduce the work for anyone. 
I've been thinking about how this could be done for grub; also
because of the issue that the EFI builds of grub need to be
signed with Fedora's secure boot keys, which means only a few
people can do grub2 builds atm.

One option which I think we should consider is sticking with
a single downstream git fork (until we have managed to get
everything we need upstream), so stick with:

https://github.com/rhboot/grub2/

As the Source0 provider for the packages and then next to:

https://src.fedoraproject.org/rpms/grub2

Add a:

https://src.fedoraproject.org/rpms/grub2-bios

And moving the build of all sub-packages which are
only necessary for BIOS support to the second src.rpm.

This way the Legacy BIOS SIG could maintain
the grub2-bios src.rpm (and binary pkgs it builds).
The SIG _must_ then of course still submit pull-reqs to:
https://github.com/rhboot/grub2/ for any changes.

But in case of e.g. a beta blocking BIOS only bug they
could solve that with a patch in the src.rpm and kickof
a build right away without blocking on the bootloader
team and thus without causing a spike in
work-pressure/load for the bootloader team.

And then once the pull-req is merged (possibly
a revised version of it) the next build of
the grub2-bios src.rpm can pull in the new Source0
and drop its local changes (IOW grub2-bios _must_
not become a separate fork).

Regards,

Hans

[Neal Gompa]

On Wed, Apr 6, 2022 at 10:18 AM Hans de Goede <hdegoede(a)redhat.com&gt; wrote:
>  Hi,
>
>  <to be clear I'm replying on a personal title here, not on
>   behalf of my employer (Red Hat)>
>
>  On 4/5/22 16:52, Ben Cotton wrote:
>  > https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
>
>  <snip>
>
>  > Fedora already requires a 2GHz dual core CPU at minimum (and therefore
>  > mandates that machines must have been made after 2006).
>
>  But machines made between 2006-2012 generally did not have
>  EFI support, anf for example at home I still have several
>  machines from that era which are BIOS only in active use:
>
>  1. My daughter's workstation is an i5-2400 with 8G RAM, this
>  is a 3.1 GHz base-freq quad-core processor very easily
>  matching Fedora's minimal requirements. Currently running
>  Fedora 35 just fine. Making it impossible to keep using this
>  in the future is just causing unnecessary ewaste for no good
>  reason IMHO.
>
>  2. My wife's workstation is a Core 2 Duo E6600 2.4 Ghz dual
>  core machine with 4G RAM, which also still works fine for
>  what she uses it for.
>
>  3. The living room laptop is another Core 2 Duo machine with
>  4G RAM.
>
>  Looking specifically at fixed PCs and not laptops this
>  proposal would (eventually) turn 2/5 PCs in my home
>  unusable, which really is unacceptable IMHO.
>
>  Also note that all these machines use somewhat older Intel
>  integrated graphics. As he has already mentioned on this
>  this thread, Dave Airlie has just spend a lot of time on
>  making sure those iGPU-s will work with a gallium driver
>  so that the classic mesa code can be removed and it seems
>  rather silly to drop support for this hw after just investing
>  a significant chunk of time to breathe new live into their
>  GPU support.
>
>  So a big -1 from me for this proposal as it stand.
>
>  ###
>
>  But I do completely understand that there is a workload issue
>  for the bootloader team and the proposal also mentions:
>
>  > == Contingency Plan ==
>  > Leave things as they are.  Code continues to rot.  Community
>  > assistance is required to continue the status quo.  Current owners
>  > plan to orphan some packages regardless of whether the proposal is
>  > accepted.
>
>  If the current owners no longer want to support some packages
>  which are only necessary for legacy BIOS support, then orphaning
>  these seems completely reasonable to me.
>
>  Maybe you can provide a list of these pkgs before hand so that
>  people can already volunteer as co-maintainers now and then
>  when they are orphaned, instead of orphaning them they can
>  be directly handed over (using the "give away" button) to the
>  new maintainers ?
>
>  > Another fallback option could be, if a Legacy BIOS SIG organizes, to
>  > donate the relevant packages there and provide some initial mentoring.
>
>  I believe that that is a great idea, I hereby volunteer to
>  try and setup such a SIG. If anyone reading this is interested
>  in joining such a SIG please drop me an email.
>
>  I realize that there have been similar attempts around keeping
>  32 bit x86 alive and that those have failed, but I believe that
>  this is different for a number of reasons:
>
>  1. i686 support required making sure that *all* of Fedora kept
>  working on i686, the problem was not just the kernel breaking
>  sometimes, but also that huge projects like libreoffice would
>  no longer start on i686 (at least on some of my machines).
>
>  Legacy BIOS boot support is basically only about the image-creation
>  tools + the bootloader. As various people have mentioned in the
>  thread BIOS support is still very much a thing in data-centers,
>  so I expect the upstream kernel community to keep the kernel
>  working with this for at least a couple of years. Where as both
>  the kernel + many userspace apps were breaking on i686.
>
>  2. I personally basically gave up on i686 support also because
>  there was very little 32 bit only x86 hw around remaining in
>  active use when it was dropped. And what was still on active
>  use was getting close to unusable from a performance pov.
>  Where as here we are talking about up to 2nd and 3th gen
>  core i5 / i7 machines which are still quite performant.
>
>  Esp. the 2nd gen core machines (Sandy Bridge) are still
>  quite popular and lots of people have hung on to desktops
>  with those because the CPU performance increase in generations
>  after SNB have been rather underwhelming.
>
>  > Longer term, packages that cannot be wholly donated could be split,
>  > though it is unclear whether the synchronization thereby required
>  > would reduce the work for anyone.
>
>  I've been thinking about how this could be done for grub; also
>  because of the issue that the EFI builds of grub need to be
>  signed with Fedora's secure boot keys, which means only a few
>  people can do grub2 builds atm.
>
>  One option which I think we should consider is sticking with
>  a single downstream git fork (until we have managed to get
>  everything we need upstream), so stick with:
>
>  https://github.com/rhboot/grub2/
>
>  As the Source0 provider for the packages and then next to:
>
>  https://src.fedoraproject.org/rpms/grub2
>
>  Add a:
>
>  https://src.fedoraproject.org/rpms/grub2-bios
>
>  And moving the build of all sub-packages which are
>  only necessary for BIOS support to the second src.rpm.
>
>  This way the Legacy BIOS SIG could maintain
>  the grub2-bios src.rpm (and binary pkgs it builds).
>  The SIG _must_ then of course still submit pull-reqs to:
>  https://github.com/rhboot/grub2/ for any changes.
>
>  But in case of e.g. a beta blocking BIOS only bug they
>  could solve that with a patch in the src.rpm and kickof
>  a build right away without blocking on the bootloader
>  team and thus without causing a spike in
>  work-pressure/load for the bootloader team.
>
>  And then once the pull-req is merged (possibly
>  a revised version of it) the next build of
>  the grub2-bios src.rpm can pull in the new Source0
>  and drop its local changes (IOW grub2-bios _must_
>  not become a separate fork).
>  
Constructively speaking, I would prefer to drop syslinux regardless,
and porting lorax templates to use GRUB for BIOS boot for live media
instead of syslinux as other distributions have done would drastically
reduce the burden of things. Syslinux is a special burden in itself
and I'd rather have it gone.

KIWI (the tool that openSUSE uses to produce live media) uses GRUB by
default for BIOS live media. I've been looking at dropping syslinux
support from livecd-tools for a while, too.



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

[Chris Adams]

Once upon a time, Alberto Abrao <alberto(a)abrao.net&gt; said:
>  Also, let me state that many machines who'd be UEFI capable on
> paper
>  are *not*: in my experience, many early UEFI machines (2009 up to
>  2014) have a very buggy implementation, to the point of being
>  unusable and/or a terrible experience. 
One add to that: just because a system has UEFI doesn't mean it supports
all the same boot methods equally.  I do a lot of network installs, and
early UEFI systems I tried had broken PXE support (not sure when this
may have changed, as I then didn't try for a while).

Setting up a UEFI PXE boot server is (in my experience) more
complicated.  UEFI also supports HTTP boot, which is an improvement (the
sooner TFTP can die the better), but it's not a widespread (or at least,
sometimes not as easy to call).

-- 
Chris Adams <linux(a)cmadams.net&gt;

[Robbie Harwood]

majid hussain <mhussaincov93(a)gmx.com&gt; writes:

>  hi,
>  could someone kindly tell me if my toshiba l750 machine has EFI support?
>  i'm blind and efi/bios screens are in accessible. 
Easiest is probably to do:

ls /sys/firmware/efi

This tells you whether the machine booted using UEFI.  anaconda will set
up a UEFI-capable system if booted that way, unless partitioning is
overridden to prevent that.

If it didn't boot using UEFI today, that doesn't mean it can't (you
could check with a live image as well).  UEFI tends to be enabled on
machines made these days by default for Windows logo requirements, but
this is firmware land, and there are no absolutes.

Be well,
--Robbie

[Robbie Harwood]

Vít Ondruch <vondruch(a)redhat.com&gt; writes:

>  Maybe I don't correctly understand the "Legacy BIOS support
> is not 
>  removed, but new non-UEFI installation is not supported on those 
>  platforms." quoted from the the change description, but if you have your 
>  system installed, it should keep working. You just keep updating. IOW as 
>  long as you don't reinstall the system, you are fine and you don't have 
>  to be concerned. 
Just for clarity, this is indeed a correct reading of the intent of the
change.

If there's wording that clarified here, I'm happy to adopt suggestions -
my intent is not to confuse :)

Be well,
--Robbie

[Robbie Harwood]

Neal Gompa <ngompa13(a)gmail.com&gt; writes:

>  This is not a deprecation change, this is effectively a removal
>  change. By removing the packages and the tooling support for legacy
>  BIOS, it makes several scenarios (including recovery) harder.
>  Moreover, it puts the burden on people to figure out if their hardware
>  can boot and install Fedora when we clearly haven't reached a critical
>  mass yet for doing so, like we did when we finally removed the i686
>  kernel build. 
I've stated in the change that the intent is to eventually remove legacy
entirely - so there's no sleight of hand here.  The rest is a semantic
issue which I don't care to argue.

>  2. The packages are locked down so there is no way for the community
> to help 
I've replied to this when you said it before, but no, this is
misinformation, and I'd appreciate if you stop spreading it.

Bootloader packages are available for PRs, same as every other package
in the distro.  Our bugzilla issues are as open as any other package in
the distro.

Quite simply, being able to make official builds isn't a requirement to
help with any package in the distro, bootloader or otherwise.  And to
peek behind the curtain a bit, running `fedpkg build` is not even close
to the hardest or most time-consuming part of working on bootloader
packages.

>  3. At various times, people have explicitly said "patches NOT
> welcome" 
I see no evidence of this having happened, and it's definitely not
something I've said.

Be well,
--Robbie

[Björn Persson]

laolux laolux via devel wrote:
>  I am willing to throw away my still working notebook, producing a
> little bit electronic waste when the time comes. 
I'm not. It remains to be seen how long Fedora will continue to work on
my ten-year-old laptop, but when the time comes I will not trash it and
buy a new one. Unless the hardware breaks first, I'll install some other
distribution when the laptop is no longer welcome in Fedora. I'll
probably go with Debian, which is usually good with not quite brand new
hardware. This may reduce my ability and motivation to contribute to
Fedora.

I use this laptop to develop and test performance measurement tools. It
handles build jobs, testsuites and virtual machines just fine. The days
when a three-year-old computer was too slow to be useful are long gone.

Björn Persson

[Robbie Harwood]

"Andre Robatino" <robatino(a)fedoraproject.org&gt; writes:

>  Those figures are recommended minimums, not requirements. I have a
>  single core F35 machine which works fine. 
It's important to note here that "works fine" isn't the same as
"is
supported".

My reading of that document is that if one goes below what's laid out in
"Minimum System Configuration", here be dragons, trouble may happen, and
to varying degrees, one is on their own.  And that those dangers are why
there's a "Recommended System Configuration" in the next section.

Be well,
--Robbie

[Björn Persson]

JT wrote:
>  I realize some will have the attitude of "they can just not
> upgrade and
>  keep using their old Fedora versions". 
That's obviously not a solution for any Internet-connected computer.
Even if you communicate only by moving files on USB sticks or
diskettes, it's still dangerous to let known security holes accumulate.

Björn Persson

[Neal Gompa]

On Wed, Apr 6, 2022 at 10:59 AM Robbie Harwood <rharwood(a)redhat.com&gt; wrote:
>  Neal Gompa <ngompa13(a)gmail.com&gt; writes:
>
>  > This is not a deprecation change, this is effectively a removal
>  > change. By removing the packages and the tooling support for legacy
>  > BIOS, it makes several scenarios (including recovery) harder.
>  > Moreover, it puts the burden on people to figure out if their hardware
>  > can boot and install Fedora when we clearly haven't reached a critical
>  > mass yet for doing so, like we did when we finally removed the i686
>  > kernel build.
>
>  I've stated in the change that the intent is to eventually remove legacy
>  entirely - so there's no sleight of hand here.  The rest is a semantic
>  issue which I don't care to argue.
>
>  > 2. The packages are locked down so there is no way for the community to help
>
>  I've replied to this when you said it before, but no, this is
>  misinformation, and I'd appreciate if you stop spreading it.
>
>  Bootloader packages are available for PRs, same as every other package
>  in the distro.  Our bugzilla issues are as open as any other package in
>  the distro.
>
>  Quite simply, being able to make official builds isn't a requirement to
>  help with any package in the distro, bootloader or otherwise.  And to
>  peek behind the curtain a bit, running `fedpkg build` is not even close
>  to the hardest or most time-consuming part of working on bootloader
>  packages.
>
>  > 3. At various times, people have explicitly said "patches NOT welcome"
>
>  I see no evidence of this having happened, and it's definitely not
>  something I've said. 
The grub2 package had pull requests disabled until last year. That's a
pretty obvious hammer to indicate patches are not welcome. That's why
I couldn't send PRs to add the protected.d files for grub and had to
wait for someone else to do it by filing a BZ.



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

[Robbie Harwood]

Chris Murphy <lists(a)colorremedies.com&gt; writes:

>  On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton <bcotton(a)redhat.com&gt;
> wrote:
>
> > Legacy BIOS support is not removed, but new non-UEFI installation is
> > not supported on those platforms.  This is a first step toward
> > eventually removing legacy BIOS support entirely.
>
>  What is the distinction between "support is not removed" and "removing
>  support entirely"?  i.e. what are the additional steps for entirely
>  removing support? 
A project decision that it's not supported, and to stop building the
bootloader packages for it entirely.

>  And what's the approximate time frame for it? 
Unclear.  Sooner would be better for us, but I know that's not
realistic.  At least a release, probably multiple.  Reasoned suggestions
(i.e., other than "never") would influence this.

>  "Support is not removed" seems incongruent with "new
> installations are
>  not supported." What continues to be supported? 
Existing installations.

>  Will grub-pc still be built and updated? 
Yes.

>  Will grub2-install still work on BIOS systems? 
Probably - I'm not about to sabotage it.  But it wouldn't be supported
for making new installations.  I'm aware that users comfortable doing
installs outside anaconda (or with customized anaconda) can circumvent
this, and I'm not interested in trying to stop them - that's an
adversarial relationship neither of us want.

> > syslinux goes away entirely
>
>  If the installation media used BIOS GRUB, syslinux could still go
>  away. What consideration has occurred to switch from syslinux to BIOS
>  GRUB for installation media? Is BIOS GRUB being deprecated? Or is it
>  being discontinued in Fedora? 
(I wasn't involved in the decision of what bootloader to use for legacy
live media and can't speak to it.)

>  If security vulnerabilities in BIOS GRUB are discovered, and
>  grub2-install doesn't apply the most recently available fixes, I
>  consider this an unsupported configuration. We can't say "support is
>  not removed" while removing the ability to apply security fixes to the
>  embedded bootloader. 
I don't think I understand this paragraph, but taking a guess: I don't
intend to break anything about existing installations, including
security update delivery.

>  This is removal of support. No mere deprecation. 
This is a semantic issue that I don't think it will be useful to argue.

Be well,
--Robbie

[Robbie Harwood]

Neal Gompa <ngompa13(a)gmail.com&gt; writes:

>  On Wed, Apr 6, 2022 at 7:14 AM John Boero <boeroboy(a)gmail.com&gt;
> wrote:
> >
> > I can fully understand why this would be done.  As per the original
> > discussion when Peter Robinson mentioned a Spin to deprecate BIOS,
> > would anybody else be interested in helping with a Spin for legacy
> > BIOS support?  I agree with the e-waste comments and it seems a shame
> > to trash some perfectly viable kiosks or old IoT which gave new life
> > to old kit.  I just got done knocking Windows 11 for deprecating
> > support for fairly new hardware but now realize Fedora is doing
> > something similar (though not as drastic).  Is a spin worth
> > exploring?  Volunteers welcome.
>
>  The pull request to delete the code for BIOS support in lorax means
>  that we can't produce media with BIOS support at all once that's
>  merged. They've tied dropping syslinux to dropping BIOS support
>  entirely. It is also unclear that they'd take a contribution to rewire
>  lorax to produce media with BIOS support using GRUB like we do for
>  UEFI. 
We're right here - you can just ask.

Brian's PR is to implement the change as written.  If the project
decided to go in the direction of a spin, that would be something other
than what the change proposes, and the PR wouldn't be appropriate.

Be well,
--Robbie

[stan]

On Wed, 6 Apr 2022 06:28:59 +0200
majid hussain <mhussaincov93(a)gmx.com&gt; wrote:

>  could someone kindly tell me if my toshiba l750 machine has EFI
>  support? i'm blind and efi/bios screens are in accessible. 
This question is better suited to the user list rather than
this thread, but if your laptop came with windows 8 or later,
it will have uefi support. Here is a link that explains how to get into
the bios if you want to have someone double check for you.

https://www.4winkey.com/computer-help/how-to-access-enter-bios-on-toshiba...

[Robbie Harwood]

Neal Gompa <ngompa13(a)gmail.com&gt; writes:

>  On Wed, Apr 6, 2022 at 10:59 AM Robbie Harwood
> <rharwood(a)redhat.com&gt; wrote:
> > Neal Gompa <ngompa13(a)gmail.com&gt; writes:
> >
> >> 3. At various times, people have explicitly said "patches NOT
> >> welcome"
> >
> > I see no evidence of this having happened, and it's definitely not
> > something I've said.
>
>  The grub2 package had pull requests disabled until last year. That's a
>  pretty obvious hammer to indicate patches are not welcome. That's why
>  I couldn't send PRs to add the protected.d files for grub and had to
>  wait for someone else to do it by filing a BZ. 
That change went in in 2020, so we're pushing two years ago.  The patch
was ultimately written by Javier as
8c2cf1c36843a2eb1e52c29f20ef4167463189ec.  While it's not the most
complex thing in the world, it's not trivial either.

The relevant bug was https://bugzilla.redhat.com/show_bug.cgi?id=1874541
which you filed.  You did not mention that sending PRs was broken, nor
did you provide a patch there, nor did you indicate willingness to
provide one.

To turn around after that and say, today, that the grub maintainers have
said "patches NOT welcome" seems more like an assumption of bad faith
than a reasonable characterization to me.

Be well,
--Robbie

[Robert Marcano]

On 4/5/22 10:52 AM, Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
>   
...
>  It is inevitable that legacy BIOS will be removed in a future
> release.
>  To ease this transition as best we can, there will be a period (of at
>  least one Fedora release) where it will be possible to boot using the
>  legacy BIOS codepaths, but new installations will not be possible.
>  While it would be easier for us to cut support off today, our hope is
>  that this compromise position will make for a smoother transition.
>  Additional support with issues during the transition would be
>  appreciated.
>   
Many people have already commented on having active and usable computers 
only supporting BIOS and not UEFI. You can count me on that list too. 
but I will really appreciate a clarification.

Is this change only related to install media support for booting with 
BIOS only? Would I be able to install newer Fedora releases using Legacy 
PXE on BIOS only machines?

[Jared Dominguez]

On Wed, Apr 6, 2022 at 8:20 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:

>  On Wed, Apr 6, 2022 at 8:04 AM Vít Ondruch
> <vondruch(a)redhat.com&gt; wrote:
>  >
>  >
>  > Dne 05. 04. 22 v 17:08 Neal Gompa napsal(a):
>  > > On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  > >> https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
>  > >>
>  > >> == Summary ==
>  > >> Make UEFI a hardware requirement for new Fedora installations on
>  > >> platforms that support it (x86_64).  Legacy BIOS support is not
>  > >> removed, but new non-UEFI installation is not supported on those
>  > >> platforms.  This is a first step toward eventually removing legacy
>  > >> BIOS support entirely.
>  > >>
>  > >> == Owner ==
>  > >> * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří
>  > >> Konečný]], [[User:bcl| Brian C. Lane]]
>  > >> * Email: rharwood(a)redhat.com
>  > >>
>  > >>
>  > >> == Detailed Description ==
>  > >> UEFI is defined by a versioned standard that can be tested and
>  > >> certified against.  By contrast, every legacy BIOS is unique. Legacy
>  > >> BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple)
>  > >> and on its way out.  As it ages, maintainability has decreased, and
>  > >> the status quo of maintaining both stacks in perpetuity is not viable
>  > >> for those currently doing that work.
>  > >>
>  > >> It is inevitable that legacy BIOS will be removed in a future release.
>  > >> To ease this transition as best we can, there will be a period (of at
>  > >> least one Fedora release) where it will be possible to boot using the
>  > >> legacy BIOS codepaths, but new installations will not be possible.
>  > >> While it would be easier for us to cut support off today, our hope is
>  > >> that this compromise position will make for a smoother transition.
>  > >> Additional support with issues during the transition would be
>  > >> appreciated.
>  > >>
>  > >> While this will eventually reduce workload for boot/installation
>  > >> components (grub2 reduces surface area, syslinux goes away entirely,
>  > >> anaconda reduces surface area), the reduction in support burden
>  > >> extends much further into the stack - for instance, VESA support can
>  > >> be removed from the distro.
>  > >>
>  > >> Fedora already requires a 2GHz dual core CPU at minimum (and therefore
>  > >> mandates that machines must have been made after 2006).  Like the
>  > >> already accepted Fedora 37 change to retire ARMv7 support, the
>  > >> hardware targeted tends to be rather underpowered by today’s
>  > >> standards, and the world has moved on from it.  Intel stopped shipping
>  > >> the last vestiges of BIOS support in 2020 (as have other vendors, and
>  > >> Apple and Microsoft), so this is clearly the way things are heading -
>  > >> and therefore aligns with Fedora’s “First” objective.
>  > >>
>  > >> == Feedback ==
>  > >> Dropping legacy BIOS was previously discussed (but not proposed) in
>  2020:
>  > >>
>
> https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject...
>  > >>
>  > >> Important, relevant points from that thread (yes, I reread the entire
>  > >> thread) that have informed this change:
>  > >>
>  > >> * Some machines are BIOS-only.  This change does not prevent their use
>  > >> yet, but they are effectively deprecated.  grub2 (our default
>  > >> bootloader) is already capable of both BIOS and UEFI booting.
>  > >> * Drawing a clear year cutoff, let alone a detailed list of hardware
>  > >> this change affects, is basically impossible.  This is unfortunate but
>  > >> unlikely to ever change.
>  > >> * There is no migration story from Legacy BIOS to UEFI -
>  > >> repartitioning effectively mandates a reinstall.  As a result, we
>  > >> don’t drop support for existing Legacy BIOS systems yet, just new
>  > >> installations.
>  > >> * There is no way to deprecate hardware without causing some amount
>  of friction.
>  > >> * While at the time AWS did not support UEFI booting, that is no
>  > >> longer the case and they support UEFI today.
>  > >>
>  > >> == Benefit to Fedora ==
>  > >> UEFI is required for many desirable features, including applying
>  > >> firmware updates (fwupd) and supporting SecureBoot.  As a standalone
>  > >> change, it reduces support burden on everything involved in installing
>  > >> Fedora, since there becomes only one way to do it per platform.
>  > >> Finally, it simplifies our install/live media, since it too only has
>  > >> to boot one way per arch.  Freedom Friends Features First - this is
>  > >> that last one.
>  > >>
>  > >> == Scope ==
>  > >> * Proposal owners:
>  > >> ** bootloaders: No change (existing Legacy BIOS installations still
>  supported).
>  > >> ** anaconda: No change (there could be only optional cleanups in the
>  > >> code). However, it needs to be verified.
>  > >> ** Lorax: Code has already been written:
>  > >> https://github.com/weldr/lorax/pull/1205
>  > >>
>  > > This pull request primarily drops legacy BIOS support by dropping
>  > > syslinux/isolinux. We don't necessarily have to drop legacy BIOS
>  > > support there if we reuse GRUB there too. Other distributions
>  > > (openSUSE and Mageia, notably) both use GRUB for both BIOS and UEFI on
>  > > live media.
>  > >
>  > >> * Other developers:
>  > >> ** libvirt: UEFI works today, but is not the default.  UEFI-only
>  > >> installation is needed for Windows 11, and per conversations, libvirt
>  > >> is prepared for this change.
>  > >> ** Virtualbox: UEFI Fedora installs are working and per virtualbox
>  > >> team, UEFI will be/is the default in 7.0+.
>  > >> ** The Hardware Overview page should be updated to mention the UEFI
>  > >> requirement:
>
> https://docs.fedoraproject.org/en-US/fedora/rawhide/release-notes/welcome...
>  > >>
>  > >> * Release engineering: [https://pagure.io/releng/issue/10738 #Releng
>  > >> issue 10738]
>  > >>
>  > >> * Policies and guidelines: N/A (not needed for this Change)
>  > >>
>  > >> * Trademark approval: N/A (not needed for this Change)
>  > >>
>  > >> * Alignment with Objectives: N/A
>  > >>
>  > >> == Upgrade/compatibility impact ==
>  > >> Systems currently using Legacy BIOS for booting on x86_64 will
>  > >> continue to do so.
>  > >>
>  > >> However, this modifies the baseline Fedora requirements and some
>  > >> hardware will no longer be supported for new installations.
>  > >>
>  > >> == How To Test ==
>  > >> UEFI installation has been supported for quite a while already, so
>  > >> additional testing there should not be required.
>  > >>
>  > >> == User Experience ==
>  > >> Installs will continue to work on UEFI, and will not work on Legacy
>  > >> BIOS.  Our install media is already UEFI-capable.
>  > >>
>  > >> == Dependencies ==
>  > >> None
>  > >>
>  > >> == Contingency Plan ==
>  > >> Leave things as they are.  Code continues to rot.  Community
>  > >> assistance is required to continue the status quo.  Current owners
>  > >> plan to orphan some packages regardless of whether the proposal is
>  > >> accepted.
>  > >>
>  > >> Another fallback option could be, if a Legacy BIOS SIG organizes, to
>  > >> donate the relevant packages there and provide some initial mentoring.
>  > >> Longer term, packages that cannot be wholly donated could be split,
>  > >> though it is unclear whether the synchronization thereby required
>  > >> would reduce the work for anyone.
>  > >>
>  > >> * Contingency mechanism: Delay until next release.
>  > >> * Contingency deadline: Beta freeze
>  > >> * Blocks release? No
>  > >>
>  > >> == Documentation ==
>  > >> See release notes.
>  > >>
>  > >> == Release Notes ==
>  > >> Fedora 37 marks legacy BIOS installation as deprecated on x86_64 in
>  > >> favor of UEFI.  While systems already using Legacy BIOS to boot are
>  > >> still supported, new legacy BIOS installations on these architectures
>  > >> are no longer possible.  Legacy BIOS support will be removed entirely
>  > >> in a future Fedora.
>  > >>
>  > >> (Additionally, the Hardware Overview page should be updated to mention
>  > >> the UEFI requirement.)
>  > >>
>  > > While I'm sympathetic to this Change, I think this is way too early to
>  > > do across the board. UEFI came onto the scene in the PC space in
>  > > 2011~2012 with Windows 8, and even to this day, there are sufficiently
>  > > buggy hardware platforms that Linux does not boot in UEFI mode:
>  > > https://twitter.com/VKCsh/status/1511132132885815307
>  > >
>  > > I even have one such machine, an HP desktop machine that came with
>  > > Windows 8. My current desktop PC has problems booting Linux UEFI as
>  > > well, though I've done "clever" things to work around that. I
> don't
>  > > expect most users to be able to deal with that. Server platforms were
>  > > *worse* as they were slower to offer UEFI. The first time I was able
>  > > to get a server with UEFI was in 2014.
>  >
>  >
>  > Maybe I don't correctly understand the "Legacy BIOS support is not
>  > removed, but new non-UEFI installation is not supported on those
>  > platforms." quoted from the the change description, but if you have your
>  > system installed, it should keep working. You just keep updating. IOW as
>  > long as you don't reinstall the system, you are fine and you don't have
>  > to be concerned.
>  >
>  > If you really have a need to reinstall such machine, you'll take the F36
>  > image and upgrade to F37+ and you should still be good.
>  >
>
>  This is not a deprecation change, this is effectively a removal
>  change. By removing the packages and the tooling support for legacy
>  BIOS, it makes several scenarios (including recovery) harder.
>  Moreover, it puts the burden on people to figure out if their hardware
>  can boot and install Fedora when we clearly haven't reached a critical
>  mass yet for doing so, like we did when we finally removed the i686
>  kernel build.
>
>  I'm personally a fan of using UEFI instead of BIOS. Heck, I
>  implemented support for UEFI in Fedora's cloud images when other
>  people told me it was not possible, while preserving BIOS support.
>  I've been trying to figure out the roadmap for BIOS deprecation for a
>  year now, and the reason *I* didn't propose a Change yet is because I
>  have not sufficiently determined that it was reasonable to do so.
>
>  I'm particularly upset about this Change because it feels like a
>  hostage change where the proposal owners blithely ignore what we're
>  saying as unimportant or irrelevant and abuse our principles to do
>  things that are clearly against what the community feels is right.
>  
This strikes me as a very negative view of what we're trying to do. We're
trying to figure out a timeline for deprecation and openly discuss, which
is why this change proposal is here now. Support for legacy x86 boot is
rapidly vanishing across the industry. Code is rotting in Fedora. The Red
Hat team doing the work in the bootloader space doesn't have capacity for
continuing support for legacy x86 boot anyway. We're attempting to
communicate boundaries and available commitment and work in the community
on a workable plan. This proposal includes a call for community assistance
if there's sufficient desire to maintain the status quo longer. You are
welcome to constructively help with that. Hearing accusations of folks, who
are operating on good faith, engaging in "abuse" and executing a "hostage
change" feels concerning to me.

I have been trying in the background for years to try to figure out
>  solutions for usability problems in Fedora Linux on UEFI because *I
>  want our experience to be good there*. But it's extremely hard when:
>
>  1. Bugs and feature requests around UEFI related features are ignored
>  
Per my reply to you yesterday, I would be grateful if you would list out
examples here. This is the second time I've heard this, and it's not
concrete enough for a constructive conversation on that topic.

2. The packages are locked down so there is no way for the community to help
>  3. At various times, people have explicitly said "patches NOT
> welcome"
>  
Robbie already responded to this, but I would like to add that if any of
this ever actually becomes true, I would like to know so that I can address
any such issue with this Red Hat team. From what I've seen, we very much
welcome community involvement. In fact, we are collaborating on a daily
basis with the bootloader community on grub2 and shim development.

I'm angry because we're doing this without any real thought around the
>  consequences for the user experience, and we should not do that as a
>  premier Linux distribution.
>
>
>  --
>  真実はいつも一つ！/ Always, there's only one truth!
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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
>  

-- 
Jared Dominguez (he/him)
Software Engineering Manager
New Platform Technologies Enablement team
RHEL Workstation Engineering

[Michael Catanzaro]

On Wed, Apr 6 2022 at 08:16:09 AM -0400, Neal Gompa 
<ngompa13(a)gmail.com&gt; wrote:
>  This is not a deprecation change, this is effectively a removal
>  change. By removing the packages and the tooling support for legacy
>  BIOS, it makes several scenarios (including recovery) harder.
>  Moreover, it puts the burden on people to figure out if their hardware
>  can boot and install Fedora when we clearly haven't reached a critical
>  mass yet for doing so, like we did when we finally removed the i686
>  kernel build. 
What scares me is we have no way to know how many users are using 
legacy BIOS vs. UEFI.

I used legacy BIOS until just a few months ago, when I found some 
obscure setting in my laptop's BIOS (don't remember what) and 
discovered that if set to a non-default value, suddenly UEFI would 
actually work. I actually had this laptop for just over five years 
before discovering that the UEFI support worked. I had previously 
assumed that it was broken.

I wonder if Ubuntu knows what percentage of their users are doing 
legacy BIOS vs. UEFI boot. Lacking any data from Fedora, data from 
another similar distro is going to be the closest proxy we can get for 
this info. I know Ubuntu has installation reports, but I don't know if 
they collect this data.

Michael

[Michael Catanzaro]

On Wed, Apr 6 2022 at 11:11:37 AM -0400, Neal Gompa 
<ngompa13(a)gmail.com&gt; wrote:
>  The grub2 package had pull requests disabled until last year.
> That's a
>  pretty obvious hammer to indicate patches are not welcome. That's why
>  I couldn't send PRs to add the protected.d files for grub and had to
>  wait for someone else to do it by filing a BZ. 
Woah, what happened here? Why would any Fedora package ever disable 
pull requests?

[Justin Forbes]

On Tue, Apr 5, 2022 at 6:39 PM Chris Murphy <lists(a)colorremedies.com&gt; wrote:
>  On Tue, Apr 5, 2022 at 3:08 PM Jared Dominguez <jaredz(a)redhat.com&gt; wrote:
>
>  > The security of UEFI systems is immeasurably better. Standardized firmware updates,
> support for modern secure TPMs, OS protection from firmware (SMM mitigations), HTTP(S)
> boot support, largely shared and open sourced firmware codebases that aren't a pile of
> assembly code, and a lot of other features are UEFI-only.
>
>  When users have a suboptimal experience by default, it makes Fedora
>  look bad. We can't have security concerns overriding all other
>  concerns. But it's really pernicious to simultaneously say security is
>  important, but we're also not going to sign proprietary drivers. This
>  highly incentivizes the user to disable Secure Boot because that's so
>  much easier than users signing kernel modules and enrolling keys with
>  the firmware, and therefore makes the user *less safe*.
>
>
>  >> And the amount of resistance to improving UEFI experience for hardware
>  >> is amazingly awful. The workstation working group has tried to figure
>  >> out ways to improve the experience, only to be simultaneously stymied
>  >> by the UEFI firmware management tools and unwillingness by anyone
>  >> involved to even consider that we should make this better.
>  >
>  >
>  > Which tools? What specific efforts have been stymied? How is any of this specific to
> UEFI versus trying to deal with things that aren't supported by someone?
>
>  Namely, Fedora signing NVIDIA's proprietary driver.
>
>  Apple and Microsoft signing NVIDIA's proprietary driver doesn't at all
>  indicate Apple and Microsoft trust the driver itself. It is trusting
>  the providence of the blob, in order to achieve an overall safer
>  ecosystem for their users.
>
>  We either want users with NVIDIA hardware to be inside the Secure Boot
>  fold or we don't. I want them in the fold *despite* the driver that
>  needs signing is proprietary. That's a better user experience across
>  the board, including the security messaging is made consistent. The
>  existing policy serves no good at all and is double talk. If we really
>  care about security more than ideological worry, we'd sign the driver. 
At the very least, it would require that Fedora have a separate key
that is trusted and not the same one used for shim/grub/kernel.  We
certainly aren't proposing that we use the standard Fedora keys to
sign a binary blob that runs in kernel space from a company who was
most recently hacked last month?

Justin

[Neal Gompa]

On Wed, Apr 6, 2022 at 12:23 PM Justin Forbes <jmforbes(a)linuxtx.org&gt; wrote:
>  On Tue, Apr 5, 2022 at 6:39 PM Chris Murphy <lists(a)colorremedies.com&gt; wrote:
>  >
>  > On Tue, Apr 5, 2022 at 3:08 PM Jared Dominguez <jaredz(a)redhat.com&gt; wrote:
>  >
>  > > The security of UEFI systems is immeasurably better. Standardized firmware
> updates, support for modern secure TPMs, OS protection from firmware (SMM mitigations),
> HTTP(S) boot support, largely shared and open sourced firmware codebases that aren't a
> pile of assembly code, and a lot of other features are UEFI-only.
>  >
>  > When users have a suboptimal experience by default, it makes Fedora
>  > look bad. We can't have security concerns overriding all other
>  > concerns. But it's really pernicious to simultaneously say security is
>  > important, but we're also not going to sign proprietary drivers. This
>  > highly incentivizes the user to disable Secure Boot because that's so
>  > much easier than users signing kernel modules and enrolling keys with
>  > the firmware, and therefore makes the user *less safe*.
>  >
>  >
>  > >> And the amount of resistance to improving UEFI experience for hardware
>  > >> is amazingly awful. The workstation working group has tried to figure
>  > >> out ways to improve the experience, only to be simultaneously stymied
>  > >> by the UEFI firmware management tools and unwillingness by anyone
>  > >> involved to even consider that we should make this better.
>  > >
>  > >
>  > > Which tools? What specific efforts have been stymied? How is any of this
> specific to UEFI versus trying to deal with things that aren't supported by someone?
>  >
>  > Namely, Fedora signing NVIDIA's proprietary driver.
>  >
>  > Apple and Microsoft signing NVIDIA's proprietary driver doesn't at all
>  > indicate Apple and Microsoft trust the driver itself. It is trusting
>  > the providence of the blob, in order to achieve an overall safer
>  > ecosystem for their users.
>  >
>  > We either want users with NVIDIA hardware to be inside the Secure Boot
>  > fold or we don't. I want them in the fold *despite* the driver that
>  > needs signing is proprietary. That's a better user experience across
>  > the board, including the security messaging is made consistent. The
>  > existing policy serves no good at all and is double talk. If we really
>  > care about security more than ideological worry, we'd sign the driver.
>
>  At the very least, it would require that Fedora have a separate key
>  that is trusted and not the same one used for shim/grub/kernel.  We
>  certainly aren't proposing that we use the standard Fedora keys to
>  sign a binary blob that runs in kernel space from a company who was
>  most recently hacked last month?
>  
I want a secondary key that we can use that's trusted only by the
kernel so that it's easy to revoke/rotate without forcing the whole
mess on everyone.

Having a keyring in the kernel that allows the kernel to trust
certificates without having to import them into firmware drastically
reduces the damage and improves the security of the system by making
it easier to manage trust in the first place.

The whole reason we sign shim with the Microsoft certificate and then
have shim trust our certificate for grub and the kernel is because we
recognize that making people fiddle with the firmware is a horribly
bad idea. That hasn't changed in 20 years. Shim changes very little,
and everything that uses the Fedora cert can change often without
involving the whole mess. I want that principle extended to kernel
modules too.




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

[Adam Jackson]

On Tue, Apr 5, 2022 at 6:51 PM Demi Marie Obenour <demiobenour(a)gmail.com&gt; wrote:

>  > I'm flattered, but I intend to drop vesa in F37 regardless
> of the
>  > outcome of this particular change. The only supported way to get to
>  > graphics with vesa is to use Xorg, and we sincerely want to be out of
>  > the business of maintaining Xorg the hardware server. (We'll need an X
>  > server forever, Xwayland isn't going away, don't misread me here.)
>
>  Does that mean that F37 will only have an Xwayland package, not an
>  Xorg package?  And does it mean that XFCE support is being deprecated?
>  Qubes OS relies on the latter. 
I chose my words carefully, I said "drop vesa" not "drop Xorg". It
means F37 will not have a vesa driver for the Xorg server to use. Xorg
will still be there for at least another release, probably several.

It's likely that the long term plan for preserving X11-only desktop
environments would be to run (say) weston such that its only client is
a fullscreen Xwayland, rather than Xorg driving the hardware directly.

>  > And frankly at this point if you seriously want to use vesa
> it's
>  > because you're trying to like reverse engineer some obscure card's
>  > VBIOS, and if you're doing that you're probably building your own X
>  > server anyway, I know I would be. Its use as an emergency driver on
>  > physical GPUs is negligible, we have native drivers for virtually
>  > everything made in the last 20 years. Its use as an emergency driver
>  > in virtual machines is more statistically significant, maybe, but even
>  > there we usually have a drm driver these days, and where we don't we
>  > can probably club it into bochs_drm since that's the only rom anyone
>  > bothers to use for that.
>
>  Do we have DRM drivers for the UEFI framebuffer and the standard
>  QEMU-emulated graphics? 
Yes.

- ajax

[Robbie Harwood]

Michael Catanzaro <mcatanzaro(a)gnome.org&gt; writes:

>  Woah, what happened here? Why would any Fedora package ever disable
>  pull requests? 
I suspect it was an accident.  I can't speak to why - if my
co-maintainers know, maybe they can - but it seems possible it got
toggled while someone was looking for something else in pagure settings.
It appears to just be a toggle in Project Options, so right next to web
hooks configuration or notification adjustment.

A (definitely out of scope) related question is, given this is something
we don't want to Fedora packages to do, whether src.fedoraproject.org
should just not expose the option at all.

Be well,
--Robbie

[Tom Hughes]

On 06/04/2022 15:36, Chris Adams wrote:

>  One add to that: just because a system has UEFI doesn't mean it
> supports
>  all the same boot methods equally.  I do a lot of network installs, and
>  early UEFI systems I tried had broken PXE support (not sure when this
>  may have changed, as I then didn't try for a while).
>  
>  Setting up a UEFI PXE boot server is (in my experience) more
>  complicated.  UEFI also supports HTTP boot, which is an improvement (the
>  sooner TFTP can die the better), but it's not a widespread (or at least,
>  sometimes not as easy to call). 
This is certainly why I have a lot of UEFI capable machines
using MBR boot because it's only recently that I got network
booting to work with UEFI and the install would install as MBR
if it was booted from a legacy network book.

Tom

-- 
Tom Hughes (tom(a)compton.nu)
http://compton.nu/

[Neal Gompa]

On Wed, Apr 6, 2022 at 11:50 AM Jared Dominguez <jaredz(a)redhat.com&gt; wrote:
>  On Wed, Apr 6, 2022 at 8:20 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
> >
> > On Wed, Apr 6, 2022 at 8:04 AM Vít Ondruch <vondruch(a)redhat.com&gt; wrote:
> > >
> > >
> > > Dne 05. 04. 22 v 17:08 Neal Gompa napsal(a):
> > > > On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton <bcotton(a)redhat.com&gt;
> wrote:
> > > >> https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
> > > >>
> > > >> == Summary ==
> > > >> Make UEFI a hardware requirement for new Fedora installations on
> > > >> platforms that support it (x86_64).  Legacy BIOS support is not
> > > >> removed, but new non-UEFI installation is not supported on those
> > > >> platforms.  This is a first step toward eventually removing legacy
> > > >> BIOS support entirely.
> > > >>
> > > >> == Owner ==
> > > >> * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří
> > > >> Konečný]], [[User:bcl| Brian C. Lane]]
> > > >> * Email: rharwood(a)redhat.com
> > > >>
> > > >>
> > > >> == Detailed Description ==
> > > >> UEFI is defined by a versioned standard that can be tested and
> > > >> certified against.  By contrast, every legacy BIOS is unique. Legacy
> > > >> BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple)
> > > >> and on its way out.  As it ages, maintainability has decreased, and
> > > >> the status quo of maintaining both stacks in perpetuity is not viable
> > > >> for those currently doing that work.
> > > >>
> > > >> It is inevitable that legacy BIOS will be removed in a future release.
> > > >> To ease this transition as best we can, there will be a period (of at
> > > >> least one Fedora release) where it will be possible to boot using the
> > > >> legacy BIOS codepaths, but new installations will not be possible.
> > > >> While it would be easier for us to cut support off today, our hope is
> > > >> that this compromise position will make for a smoother transition.
> > > >> Additional support with issues during the transition would be
> > > >> appreciated.
> > > >>
> > > >> While this will eventually reduce workload for boot/installation
> > > >> components (grub2 reduces surface area, syslinux goes away entirely,
> > > >> anaconda reduces surface area), the reduction in support burden
> > > >> extends much further into the stack - for instance, VESA support can
> > > >> be removed from the distro.
> > > >>
> > > >> Fedora already requires a 2GHz dual core CPU at minimum (and therefore
> > > >> mandates that machines must have been made after 2006).  Like the
> > > >> already accepted Fedora 37 change to retire ARMv7 support, the
> > > >> hardware targeted tends to be rather underpowered by today’s
> > > >> standards, and the world has moved on from it.  Intel stopped shipping
> > > >> the last vestiges of BIOS support in 2020 (as have other vendors, and
> > > >> Apple and Microsoft), so this is clearly the way things are heading -
> > > >> and therefore aligns with Fedora’s “First” objective.
> > > >>
> > > >> == Feedback ==
> > > >> Dropping legacy BIOS was previously discussed (but not proposed) in
> 2020:
> > > >>
> https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject...
> > > >>
> > > >> Important, relevant points from that thread (yes, I reread the entire
> > > >> thread) that have informed this change:
> > > >>
> > > >> * Some machines are BIOS-only.  This change does not prevent their use
> > > >> yet, but they are effectively deprecated.  grub2 (our default
> > > >> bootloader) is already capable of both BIOS and UEFI booting.
> > > >> * Drawing a clear year cutoff, let alone a detailed list of hardware
> > > >> this change affects, is basically impossible.  This is unfortunate but
> > > >> unlikely to ever change.
> > > >> * There is no migration story from Legacy BIOS to UEFI -
> > > >> repartitioning effectively mandates a reinstall.  As a result, we
> > > >> don’t drop support for existing Legacy BIOS systems yet, just new
> > > >> installations.
> > > >> * There is no way to deprecate hardware without causing some amount of
> friction.
> > > >> * While at the time AWS did not support UEFI booting, that is no
> > > >> longer the case and they support UEFI today.
> > > >>
> > > >> == Benefit to Fedora ==
> > > >> UEFI is required for many desirable features, including applying
> > > >> firmware updates (fwupd) and supporting SecureBoot.  As a standalone
> > > >> change, it reduces support burden on everything involved in installing
> > > >> Fedora, since there becomes only one way to do it per platform.
> > > >> Finally, it simplifies our install/live media, since it too only has
> > > >> to boot one way per arch.  Freedom Friends Features First - this is
> > > >> that last one.
> > > >>
> > > >> == Scope ==
> > > >> * Proposal owners:
> > > >> ** bootloaders: No change (existing Legacy BIOS installations still
> supported).
> > > >> ** anaconda: No change (there could be only optional cleanups in the
> > > >> code). However, it needs to be verified.
> > > >> ** Lorax: Code has already been written:
> > > >> https://github.com/weldr/lorax/pull/1205
> > > >>
> > > > This pull request primarily drops legacy BIOS support by dropping
> > > > syslinux/isolinux. We don't necessarily have to drop legacy BIOS
> > > > support there if we reuse GRUB there too. Other distributions
> > > > (openSUSE and Mageia, notably) both use GRUB for both BIOS and UEFI on
> > > > live media.
> > > >
> > > >> * Other developers:
> > > >> ** libvirt: UEFI works today, but is not the default.  UEFI-only
> > > >> installation is needed for Windows 11, and per conversations, libvirt
> > > >> is prepared for this change.
> > > >> ** Virtualbox: UEFI Fedora installs are working and per virtualbox
> > > >> team, UEFI will be/is the default in 7.0+.
> > > >> ** The Hardware Overview page should be updated to mention the UEFI
> > > >> requirement:
> https://docs.fedoraproject.org/en-US/fedora/rawhide/release-notes/welcome...
> > > >>
> > > >> * Release engineering: [https://pagure.io/releng/issue/10738 #Releng
> > > >> issue 10738]
> > > >>
> > > >> * Policies and guidelines: N/A (not needed for this Change)
> > > >>
> > > >> * Trademark approval: N/A (not needed for this Change)
> > > >>
> > > >> * Alignment with Objectives: N/A
> > > >>
> > > >> == Upgrade/compatibility impact ==
> > > >> Systems currently using Legacy BIOS for booting on x86_64 will
> > > >> continue to do so.
> > > >>
> > > >> However, this modifies the baseline Fedora requirements and some
> > > >> hardware will no longer be supported for new installations.
> > > >>
> > > >> == How To Test ==
> > > >> UEFI installation has been supported for quite a while already, so
> > > >> additional testing there should not be required.
> > > >>
> > > >> == User Experience ==
> > > >> Installs will continue to work on UEFI, and will not work on Legacy
> > > >> BIOS.  Our install media is already UEFI-capable.
> > > >>
> > > >> == Dependencies ==
> > > >> None
> > > >>
> > > >> == Contingency Plan ==
> > > >> Leave things as they are.  Code continues to rot.  Community
> > > >> assistance is required to continue the status quo.  Current owners
> > > >> plan to orphan some packages regardless of whether the proposal is
> > > >> accepted.
> > > >>
> > > >> Another fallback option could be, if a Legacy BIOS SIG organizes, to
> > > >> donate the relevant packages there and provide some initial mentoring.
> > > >> Longer term, packages that cannot be wholly donated could be split,
> > > >> though it is unclear whether the synchronization thereby required
> > > >> would reduce the work for anyone.
> > > >>
> > > >> * Contingency mechanism: Delay until next release.
> > > >> * Contingency deadline: Beta freeze
> > > >> * Blocks release? No
> > > >>
> > > >> == Documentation ==
> > > >> See release notes.
> > > >>
> > > >> == Release Notes ==
> > > >> Fedora 37 marks legacy BIOS installation as deprecated on x86_64 in
> > > >> favor of UEFI.  While systems already using Legacy BIOS to boot are
> > > >> still supported, new legacy BIOS installations on these architectures
> > > >> are no longer possible.  Legacy BIOS support will be removed entirely
> > > >> in a future Fedora.
> > > >>
> > > >> (Additionally, the Hardware Overview page should be updated to mention
> > > >> the UEFI requirement.)
> > > >>
> > > > While I'm sympathetic to this Change, I think this is way too early to
> > > > do across the board. UEFI came onto the scene in the PC space in
> > > > 2011~2012 with Windows 8, and even to this day, there are sufficiently
> > > > buggy hardware platforms that Linux does not boot in UEFI mode:
> > > > https://twitter.com/VKCsh/status/1511132132885815307
> > > >
> > > > I even have one such machine, an HP desktop machine that came with
> > > > Windows 8. My current desktop PC has problems booting Linux UEFI as
> > > > well, though I've done "clever" things to work around that. I
> don't
> > > > expect most users to be able to deal with that. Server platforms were
> > > > *worse* as they were slower to offer UEFI. The first time I was able
> > > > to get a server with UEFI was in 2014.
> > >
> > >
> > > Maybe I don't correctly understand the "Legacy BIOS support is not
> > > removed, but new non-UEFI installation is not supported on those
> > > platforms." quoted from the the change description, but if you have your
> > > system installed, it should keep working. You just keep updating. IOW as
> > > long as you don't reinstall the system, you are fine and you don't have
> > > to be concerned.
> > >
> > > If you really have a need to reinstall such machine, you'll take the F36
> > > image and upgrade to F37+ and you should still be good.
> > >
> >
> > This is not a deprecation change, this is effectively a removal
> > change. By removing the packages and the tooling support for legacy
> > BIOS, it makes several scenarios (including recovery) harder.
> > Moreover, it puts the burden on people to figure out if their hardware
> > can boot and install Fedora when we clearly haven't reached a critical
> > mass yet for doing so, like we did when we finally removed the i686
> > kernel build.
> >
> > I'm personally a fan of using UEFI instead of BIOS. Heck, I
> > implemented support for UEFI in Fedora's cloud images when other
> > people told me it was not possible, while preserving BIOS support.
> > I've been trying to figure out the roadmap for BIOS deprecation for a
> > year now, and the reason *I* didn't propose a Change yet is because I
> > have not sufficiently determined that it was reasonable to do so.
> >
> > I'm particularly upset about this Change because it feels like a
> > hostage change where the proposal owners blithely ignore what we're
> > saying as unimportant or irrelevant and abuse our principles to do
> > things that are clearly against what the community feels is right.
>
>
>  This strikes me as a very negative view of what we're trying to do. We're trying
> to figure out a timeline for deprecation and openly discuss, which is why this change
> proposal is here now. Support for legacy x86 boot is rapidly vanishing across the
> industry. Code is rotting in Fedora. The Red Hat team doing the work in the bootloader
> space doesn't have capacity for continuing support for legacy x86 boot anyway.
> We're attempting to communicate boundaries and available commitment and work in the
> community on a workable plan. This proposal includes a call for community assistance if
> there's sufficient desire to maintain the status quo longer. You are welcome to
> constructively help with that. Hearing accusations of folks, who are operating on good
> faith, engaging in "abuse" and executing a "hostage change" feels
> concerning to me.
>
> > I have been trying in the background for years to try to figure out
> > solutions for usability problems in Fedora Linux on UEFI because *I
> > want our experience to be good there*. But it's extremely hard when:
> >
> > 1. Bugs and feature requests around UEFI related features are ignored
>
>
>  Per my reply to you yesterday, I would be grateful if you would list out examples here.
> This is the second time I've heard this, and it's not concrete enough for a
> constructive conversation on that topic.
>  
This comes from years of trying to engage on improving the UEFI
situation in Fedora. To be perfectly clear: I don't want to maintain
the status quo. The status quo sucks.

The status quo is:

* UEFI is where everything is going in hardware
* Linux UEFI is a second-class experience to legacy boot
* No interest in making the UEFI-based environments better for users

We have a ton of nice things in UEFI environments when they work, as
long as we don't step out of the happy path. However, the majority of
Linux PC users *must* step out of the happy path to get their hardware
working for two cases:

* NVIDIA graphics
* Broadcom wireless

The former case is excessively common, and the latter case is fairly
common with HP and Dell machines as well as some smaller OEMs. I
literally helped someone this past week with both[1][2][3]. The
Workstation WG has been tracking both issues for years now[4][5]. This
situation is *worse* now because we have Fedora Linux preloaded on
computers, and OEMs basically have to disable Secure Boot to make
things "work". How's that for improving security?

On the cloud side, it's been very difficult to articulate any benefits
for supporting UEFI when the majority of the consumers of Fedora Cloud
don't have any pressing need to do it and things like hibernation and
snapshotting are non-functional. Last year, I changed Fedora Cloud to
hybrid boot[6] so that our image artifacts support both boot modes.
While GCP requires UEFI and Azure prefers it, AWS has very basic
support for UEFI and using UEFI causes you to lose some features that
exist only in BIOS mode. One of those is leveraging hibernation in the
cloud for spot instances[7]. Moving past the Big Three(tm), the actual
cloud providers that matter from a Fedora context are the smaller
outfits that principally serve Linux users. These are companies like
DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who
graciously do offer Fedora Linux in their platforms. All of their
virtualization platforms are BIOS only right now, and getting them to
switch requires them to uplift their platforms to support UEFI in the
first place. And again, when UEFI means things like VM snapshots and
cloud hibernation don't work, it's not very compelling.

You'd think that given how important this is for the Cloud that it
would have mattered for RHEL, but nope. These problems are not new.
They've existed since we supported UEFI Secure Boot, and given how
people have responded saying these issues are irrelevant to this
Change, it shows how out of sync with reality this Change is.

Frankly, I'm extremely frustrated and exhausted over the situation.

[1]: https://twitter.com/Det_Conan_Kudo/status/1508968025785049088
[2]: https://twitter.com/Det_Conan_Kudo/status/1508984123339202560
[3]: https://twitter.com/Det_Conan_Kudo/status/1511755879687012354
[4]: https://pagure.io/fedora-workstation/issue/155
[5]: https://pagure.io/fedora-workstation/issue/116
[6]: https://fedoraproject.org/wiki/Changes/FedoraCloudHybridBoot
[7]: https://lwn.net/Articles/821158/


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

[Michael Catanzaro]

On Wed, Apr 6 2022 at 01:57:00 PM -0400, Neal Gompa 
<ngompa13(a)gmail.com&gt; wrote:
>  Moving past the Big Three(tm), the actual
>  cloud providers that matter from a Fedora context are the smaller
>  outfits that principally serve Linux users. These are companies like
>  DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who
>  graciously do offer Fedora Linux in their platforms. All of their
>  virtualization platforms are BIOS only right now, and getting them to
>  switch requires them to uplift their platforms to support UEFI in the
>  first place. And again, when UEFI means things like VM snapshots and
>  cloud hibernation don't work, it's not very compelling. 
I suppose we should consider that all or most of these platforms are 
likely to drop Fedora as a supported option if we proceed with this 
change proposal.

[Florian Weimer]

* Adam Jackson:

>  2 - How is this our problem to solve? NVIDIA are the ones with the
>  private source code. 
Isn't it Fedora's decision to require kernel module signing when Secure
Boot is active?  So it's actually us who create the problem in the first
place?

Thanks,
Florian

[Jared Dominguez]

On Wed, Apr 6, 2022 at 2:26 PM Michael Catanzaro <mcatanzaro(a)gnome.org&gt;
wrote:

>  On Wed, Apr 6 2022 at 01:57:00 PM -0400, Neal Gompa
>  <ngompa13(a)gmail.com&gt; wrote:
>  > Moving past the Big Three(tm), the actual
>  > cloud providers that matter from a Fedora context are the smaller
>  > outfits that principally serve Linux users. These are companies like
>  > DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who
>  > graciously do offer Fedora Linux in their platforms. All of their
>  > virtualization platforms are BIOS only right now, and getting them to
>  > switch requires them to uplift their platforms to support UEFI in the
>  > first place. 

This seems like a strong assumption to me considering that aside from the
largest cloud providers (with whom Red Hat is directly working with on UEFI
boot features and bug reports), cloud providers are using off-the-shelf
hypervisors that support UEFI boot.


>  And again, when UEFI means things like VM snapshots and
>  
I've raised this within Red Hat's virtualization team.


>  > cloud hibernation don't work, it's not very compelling.
>  
AWS, for example has other situations in which this limitation exists:
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-hibernate-li...
But this is also something that can be fixed.


>  I suppose we should consider that all or most of these platforms are
>  likely to drop Fedora as a supported option if we proceed with this
>  change proposal.
>  
Why? VMware vSphere dropped legacy x86 boot support recently too. We
already know that Windows 11 requires UEFI. We (Red Hat) are actively
working with several cloud providers on UEFI-related features, some of
which are not possible with legacy x86 boot. I find it much more likely
that smaller cloud providers will update their software to support UEFI
rather than drop OS's that require it, at least if they want to remain
competitive.


>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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
>  

-- 
Jared Dominguez (he/him)
Software Engineering Manager
New Platform Technologies Enablement team
RHEL Workstation Engineering

[Demi Marie Obenour]

On 4/6/22 06:43, Neal Gompa wrote:
>  On Wed, Apr 6, 2022 at 12:04 AM Gary Buhrmaster
>  <gary.buhrmaster(a)gmail.com&gt; wrote:
> >
> > On Wed, Apr 6, 2022 at 12:59 AM Demi Marie Obenour
> > <demiobenour(a)gmail.com&gt; wrote:
> >>
> >> On 4/5/22 19:38, Chris Murphy wrote:
> >>> We either want users with NVIDIA hardware to be inside the Secure Boot
> >>> fold or we don't. I want them in the fold *despite* the driver that
> >>> needs signing is proprietary. That's a better user experience across
> >>> the board, including the security messaging is made consistent. The
> >>> existing policy serves no good at all and is double talk. If we really
> >>> care about security more than ideological worry, we'd sign the driver.
> >>
> >> I agree with this.  Sign the driver.
> >
> > Nvidia has their driver signed for their
> > Windows drivers.  That they choose
> > not to do so for Linux is their right,
> > even if some wish they did.
> >
> > It should be noted that while many
> > might wish nvidia chose a different
> > way, that is completely orthogonal
> > to bios vs uefi.
>  
>  Linux, like Windows, requires the distribution vendor to sign modules
>  for automatic trust. There are a number of complicated issues that
>  make it difficult for us to sign this particular driver, though.
>  Notably, NVIDIA themselves acknowledges that it infringes on the GPL
>  to redistribute built kernel module blobs of nvidia.ko[1], so that means
>  any method of signing it needs to be done locally, which means we
>  *need* the local signing path to be improved.
>  
>  [1]: https://imgur.com/LUCQ3WW 
Can we get NVIDIA to make the module build reproducible?  If so, we
could distribute a detached signature.

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[Neal Gompa]

On Wed, Apr 6, 2022 at 4:09 PM Demi Marie Obenour <demiobenour(a)gmail.com&gt; wrote:
>  On 4/6/22 06:43, Neal Gompa wrote:
>  > On Wed, Apr 6, 2022 at 12:04 AM Gary Buhrmaster
>  > <gary.buhrmaster(a)gmail.com&gt; wrote:
>  >>
>  >> On Wed, Apr 6, 2022 at 12:59 AM Demi Marie Obenour
>  >> <demiobenour(a)gmail.com&gt; wrote:
>  >>>
>  >>> On 4/5/22 19:38, Chris Murphy wrote:
>  >>>> We either want users with NVIDIA hardware to be inside the Secure Boot
>  >>>> fold or we don't. I want them in the fold *despite* the driver that
>  >>>> needs signing is proprietary. That's a better user experience
> across
>  >>>> the board, including the security messaging is made consistent. The
>  >>>> existing policy serves no good at all and is double talk. If we really
>  >>>> care about security more than ideological worry, we'd sign the
> driver.
>  >>>
>  >>> I agree with this.  Sign the driver.
>  >>
>  >> Nvidia has their driver signed for their
>  >> Windows drivers.  That they choose
>  >> not to do so for Linux is their right,
>  >> even if some wish they did.
>  >>
>  >> It should be noted that while many
>  >> might wish nvidia chose a different
>  >> way, that is completely orthogonal
>  >> to bios vs uefi.
>  >
>  > Linux, like Windows, requires the distribution vendor to sign modules
>  > for automatic trust. There are a number of complicated issues that
>  > make it difficult for us to sign this particular driver, though.
>  > Notably, NVIDIA themselves acknowledges that it infringes on the GPL
>  > to redistribute built kernel module blobs of nvidia.ko[1], so that means
>  > any method of signing it needs to be done locally, which means we
>  > *need* the local signing path to be improved.
>  >
>  > [1]: https://imgur.com/LUCQ3WW
>
>  Can we get NVIDIA to make the module build reproducible?  If so, we
>  could distribute a detached signature.
>  
Outside of RHEL (which they already do this for), it is not
technically feasible to do so. The mainline Linux kernel lacks a kABI
and symbol churn happens constantly. The modules have to be built
completely from source every time, dealing with kernel churn making
the resulting files different every time.



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

[Hans de Goede]

Hi,

On 4/6/22 16:23, Neal Gompa wrote:
>  On Wed, Apr 6, 2022 at 10:18 AM Hans de Goede
> <hdegoede(a)redhat.com&gt; wrote:
> >
> > Hi,
> >
> > <to be clear I'm replying on a personal title here, not on
> >  behalf of my employer (Red Hat)>
> >
> > On 4/5/22 16:52, Ben Cotton wrote:
> >> https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
> >
> > <snip>
> >
> >> Fedora already requires a 2GHz dual core CPU at minimum (and therefore
> >> mandates that machines must have been made after 2006).
> >
> > But machines made between 2006-2012 generally did not have
> > EFI support, anf for example at home I still have several
> > machines from that era which are BIOS only in active use:
> >
> > 1. My daughter's workstation is an i5-2400 with 8G RAM, this
> > is a 3.1 GHz base-freq quad-core processor very easily
> > matching Fedora's minimal requirements. Currently running
> > Fedora 35 just fine. Making it impossible to keep using this
> > in the future is just causing unnecessary ewaste for no good
> > reason IMHO.
> >
> > 2. My wife's workstation is a Core 2 Duo E6600 2.4 Ghz dual
> > core machine with 4G RAM, which also still works fine for
> > what she uses it for.
> >
> > 3. The living room laptop is another Core 2 Duo machine with
> > 4G RAM.
> >
> > Looking specifically at fixed PCs and not laptops this
> > proposal would (eventually) turn 2/5 PCs in my home
> > unusable, which really is unacceptable IMHO.
> >
> > Also note that all these machines use somewhat older Intel
> > integrated graphics. As he has already mentioned on this
> > this thread, Dave Airlie has just spend a lot of time on
> > making sure those iGPU-s will work with a gallium driver
> > so that the classic mesa code can be removed and it seems
> > rather silly to drop support for this hw after just investing
> > a significant chunk of time to breathe new live into their
> > GPU support.
> >
> > So a big -1 from me for this proposal as it stand.
> >
> > ###
> >
> > But I do completely understand that there is a workload issue
> > for the bootloader team and the proposal also mentions:
> >
> >> == Contingency Plan ==
> >> Leave things as they are.  Code continues to rot.  Community
> >> assistance is required to continue the status quo.  Current owners
> >> plan to orphan some packages regardless of whether the proposal is
> >> accepted.
> >
> > If the current owners no longer want to support some packages
> > which are only necessary for legacy BIOS support, then orphaning
> > these seems completely reasonable to me.
> >
> > Maybe you can provide a list of these pkgs before hand so that
> > people can already volunteer as co-maintainers now and then
> > when they are orphaned, instead of orphaning them they can
> > be directly handed over (using the "give away" button) to the
> > new maintainers ?
> >
> >> Another fallback option could be, if a Legacy BIOS SIG organizes, to
> >> donate the relevant packages there and provide some initial mentoring.
> >
> > I believe that that is a great idea, I hereby volunteer to
> > try and setup such a SIG. If anyone reading this is interested
> > in joining such a SIG please drop me an email.
> >
> > I realize that there have been similar attempts around keeping
> > 32 bit x86 alive and that those have failed, but I believe that
> > this is different for a number of reasons:
> >
> > 1. i686 support required making sure that *all* of Fedora kept
> > working on i686, the problem was not just the kernel breaking
> > sometimes, but also that huge projects like libreoffice would
> > no longer start on i686 (at least on some of my machines).
> >
> > Legacy BIOS boot support is basically only about the image-creation
> > tools + the bootloader. As various people have mentioned in the
> > thread BIOS support is still very much a thing in data-centers,
> > so I expect the upstream kernel community to keep the kernel
> > working with this for at least a couple of years. Where as both
> > the kernel + many userspace apps were breaking on i686.
> >
> > 2. I personally basically gave up on i686 support also because
> > there was very little 32 bit only x86 hw around remaining in
> > active use when it was dropped. And what was still on active
> > use was getting close to unusable from a performance pov.
> > Where as here we are talking about up to 2nd and 3th gen
> > core i5 / i7 machines which are still quite performant.
> >
> > Esp. the 2nd gen core machines (Sandy Bridge) are still
> > quite popular and lots of people have hung on to desktops
> > with those because the CPU performance increase in generations
> > after SNB have been rather underwhelming.
> >
> >> Longer term, packages that cannot be wholly donated could be split,
> >> though it is unclear whether the synchronization thereby required
> >> would reduce the work for anyone.
> >
> > I've been thinking about how this could be done for grub; also
> > because of the issue that the EFI builds of grub need to be
> > signed with Fedora's secure boot keys, which means only a few
> > people can do grub2 builds atm.
> >
> > One option which I think we should consider is sticking with
> > a single downstream git fork (until we have managed to get
> > everything we need upstream), so stick with:
> >
> > https://github.com/rhboot/grub2/
> >
> > As the Source0 provider for the packages and then next to:
> >
> > https://src.fedoraproject.org/rpms/grub2
> >
> > Add a:
> >
> > https://src.fedoraproject.org/rpms/grub2-bios
> >
> > And moving the build of all sub-packages which are
> > only necessary for BIOS support to the second src.rpm.
> >
> > This way the Legacy BIOS SIG could maintain
> > the grub2-bios src.rpm (and binary pkgs it builds).
> > The SIG _must_ then of course still submit pull-reqs to:
> > https://github.com/rhboot/grub2/ for any changes.
> >
> > But in case of e.g. a beta blocking BIOS only bug they
> > could solve that with a patch in the src.rpm and kickof
> > a build right away without blocking on the bootloader
> > team and thus without causing a spike in
> > work-pressure/load for the bootloader team.
> >
> > And then once the pull-req is merged (possibly
> > a revised version of it) the next build of
> > the grub2-bios src.rpm can pull in the new Source0
> > and drop its local changes (IOW grub2-bios _must_
> > not become a separate fork).
> >
>  
>  Constructively speaking, I would prefer to drop syslinux regardless,
>  and porting lorax templates to use GRUB for BIOS boot for live media
>  instead of syslinux as other distributions have done would drastically
>  reduce the burden of things. Syslinux is a special burden in itself
>  and I'd rather have it gone. 
I agree that it would be good if we don't need to maintain
both syslinux and grub, but that would require someone to
actually find the time to adjust lorax and then run a whole
bunch of tests after that to ensure the new way of doing
things will still work on most (legacy BIOS) hw.

Regards,

Hans

[Michael Catanzaro]

On Wed, Apr 6 2022 at 03:35:38 PM -0400, Jared Dominguez 
<jaredz(a)redhat.com&gt; wrote:
>  This seems like a strong assumption to me considering that aside from
>
>  the largest cloud providers (with whom Red Hat is directly working 
>  with on UEFI boot features and bug reports), cloud providers are 
>  using off-the-shelf hypervisors that support UEFI boot. 
I'm going to ask the proposal authors to at least mention this as a 
risk in the Feedback section of the change proposal. Maybe cloud 
providers will all see this as a good opportunity to enable UEFI on 
their platforms, and we'll be perfectly fine. I rather suspect it's not 
going to happen quite so smoothly, though....

[Javier Martinez Canillas]

On Wed, Apr 6, 2022 at 5:51 PM Jared Dominguez <jaredz(a)redhat.com&gt; wrote:

[snip]

>  Per my reply to you yesterday, I would be grateful if you would list out examples here.
> This is the second time I've heard this, and it's not concrete enough for a
> constructive conversation on that topic.
>
> > 2. The packages are locked down so there is no way for the community to help
> > 3. At various times, people have explicitly said "patches NOT welcome"
>
>
>  Robbie already responded to this, but I would like to add that if any of this ever
> actually becomes true, I would like to know so that I can address any such issue with this
> Red Hat team. From what I've seen, we very much welcome community involvement. In
> fact, we are collaborating on a daily basis with the bootloader community on grub2 and
> shim development.
>  
As Robbied said, I added the /etc/dnf/protected.d/grub2-*.conf to the
grub2 package after Neal filed that BZ and he also mentioned to me
back then that pull requests were disabled for the grub2 dist-git and
I re-enabled it after asking Peter if he was OK with that (and he told
me that sure go ahead).

BTW, Peter also did the same for shim and added
/etc/dnf/protected.d/shim.conf even though the dist-git for shim was
open at the time. So I don't see how grub2 dist-git not having pull
requests enabled (for whatever reasons) could be a blocker since a
change for shim wasn't proposed either. I mean, one could attach a
patch in the BZ, send an email to a maintainer, etc. Is not that PRs
in dist-git is not the only possible way to share a diff...

Anyway, I also personally never said "patches NOT welcome" to anyone.
It may be that I didn't have time to review/apply some proposed but
that's a different thing.

Best regards,
Javier

[Zbigniew Jędrzejewski-Szmek]

On Wed, Apr 06, 2022 at 11:02:17AM -0400, Robbie Harwood wrote:
>  "Andre Robatino" <robatino(a)fedoraproject.org&gt;
> writes:
>  
>  > Those figures are recommended minimums, not requirements. I have a
>  > single core F35 machine which works fine.
>  
>  It's important to note here that "works fine" isn't the same as
> "is
>  supported".
>  
>  My reading of that document is that if one goes below what's laid out in
>  "Minimum System Configuration", here be dragons, trouble may happen, and
>  to varying degrees, one is on their own.  And that those dangers are why
>  there's a "Recommended System Configuration" in the next section. 
I think that's reading too much into the "Recommended Config". In
particular
machines with less CPU will be completely usable — just slow. With RAM,
it's more complicated. But in particular with ZRAM we effectively trade
CPU cycles for more memory. So the details of when a machine stop being
"useful" depends immensly on the usecase. The *recommended* configuration
applies to a graphical boot and some typical desktop use. If you use sway or xfce
instead of gnome or kde, or you don't use firefox but e.g. just listen to music
on the machine, a machine with a fraction of recommended resources may be
just fine.

I think our users are smart: they will understand — and not complain —
that an old laptop with 2GB of RAM is not a video editing workstation.
Even if many developers personally have newer and beefier hardware, we
should keep in mind that there are geographical regions and non-developer
folks with more varied hardware.

Zbyszek

[Robbie Harwood]

Demi Marie Obenour <demiobenour(a)gmail.com&gt; writes:

>  On 4/5/22 12:29, Michael Catanzaro wrote:
> > On Tue, Apr 5 2022 at 11:56:07 AM -0400, Robbie Harwood 
> > <rharwood(a)redhat.com&gt; wrote:
> >> Users wishing to use NVIDIA hardware have the following options:
> >>
> >> - Use nouveau (free, open source, cool)
> >> - Sign their own copy of the proprietary driver (involves messing with
> >>   certificates, so not appropriate for all users)
> >> - Disable Secure Boot (note that this is still UEFI)
> >>
> >> The NVIDIA driver is proprietary, so of course it's not going to get
> >> signed.
> > 
> > The user experience requirement is: user searches for NVIDIA in GNOME
> > Software and clicks Install. No further action should be
> > necessary. We didn't make the NVIDIA driver available from the
> > graphical installer with the intention that arcane workarounds would
> > be required to use it.
>
>  Bingo.  None of the three options Robbie suggested are reasonable for
>  non-technical users. 
No, I don't think that's right.  It's been a bit since I've run nvidia
hardware, but I'm pretty sure using nouveau is the default.  It's less
powerful than the proprietary driver, but if it works out of the box,
it's really difficult to argue with that user experience.

Be well,
--Robbie

[Robbie Harwood]

Dominik 'Rathann' Mierzejewski <dominik(a)greysector.net&gt; writes:

>  On Wednesday, 06 April 2022 at 13:07, Richard Hughes wrote:
> > Dominik 'Rathann' Mierzejewski <dominik(a)greysector.net&gt; wrote:
> >
> >>> and on its way out.  As it ages, maintainability has decreased, and
> >>> the status quo of maintaining both stacks in perpetuity is not viable
> >>> for those currently doing that work.
> >>
> >> Have you tried getting more people involved?
> > 
> > I don't think that's how Open Source works. Realistically the way I
> > see this playing out is that the people responsible for maintaining
> > the legacy boot stack will retire the packages,
>
>  I thought they would be orphaned, if anything. Retiring seems rather
>  hostile to the people who still need those packages 
Assume good intent, please :)

I believe Richard's comment is about a hypothetical future, not what's
written in the change propsal in front of us.  I also don't think
Richard's point in any way hinges on the distinction between orphaning
and retiring.

>  (which are those, by the way?).
>
>  It's helpful to show the change proponents attitude. As a way of
>  "asking more people to get involved", I'd expect a list of packages
>  the change proponents no longer whish to maintain and a date when they
>  will orphan them, since they've stated they're going to do that
>  anyway. Without such list it's difficult to assess the scope of the
>  work required to maintain the affected software stack. I don't see any
>  such details in the change proposal. 
There's no list there because I don't believe that's a helpful way to
view the problem.  For instance, grub2 supports both legacy and UEFI
paths - so one can't cleanly say "this package supports one, this
package supports the other" like when trimming a dependency chain.
(This is especially true when thinking about bootloaders, which tend
toward being small operating systems unto themselves.)  It's more
realistic to consider use cases: legacy is a separate system bringup
path.  The work is the entire path, not a package.

(Lest I be accused of dodging the question: for me, the relevant
packages are parts of grub2 and all of syslinux.)

Be well,
--Robbie

[Robbie Harwood]

Demi Marie Obenour <demiobenour(a)gmail.com&gt; writes:

>  On 4/6/22 06:43, Neal Gompa wrote:
> > On Wed, Apr 6, 2022 at 12:04 AM Gary Buhrmaster
> > <gary.buhrmaster(a)gmail.com&gt; wrote:
> >>
> >> On Wed, Apr 6, 2022 at 12:59 AM Demi Marie Obenour
> >> <demiobenour(a)gmail.com&gt; wrote:
> >>>
> >>> On 4/5/22 19:38, Chris Murphy wrote:
> >>>> We either want users with NVIDIA hardware to be inside the Secure Boot
> >>>> fold or we don't. I want them in the fold *despite* the driver that
> >>>> needs signing is proprietary. That's a better user experience across
> >>>> the board, including the security messaging is made consistent. The
> >>>> existing policy serves no good at all and is double talk. If we really
> >>>> care about security more than ideological worry, we'd sign the
> driver.
> >>>
> >>> I agree with this.  Sign the driver.
> >>
> >> Nvidia has their driver signed for their
> >> Windows drivers.  That they choose
> >> not to do so for Linux is their right,
> >> even if some wish they did.
> >>
> >> It should be noted that while many
> >> might wish nvidia chose a different
> >> way, that is completely orthogonal
> >> to bios vs uefi.
> > 
> > Linux, like Windows, requires the distribution vendor to sign modules
> > for automatic trust. There are a number of complicated issues that
> > make it difficult for us to sign this particular driver, though.
> > Notably, NVIDIA themselves acknowledges that it infringes on the GPL
> > to redistribute built kernel module blobs of nvidia.ko[1], so that means
> > any method of signing it needs to be done locally, which means we
> > *need* the local signing path to be improved.
> > 
> > [1]: https://imgur.com/LUCQ3WW
>
>  Can we get NVIDIA to make the module build reproducible?  If so, we
>  could distribute a detached signature. 
nvidia's module is proprietary.

Be well,
--Robbie

[Demi Marie Obenour]

On 4/6/22 16:59, Robbie Harwood wrote:
>  Demi Marie Obenour <demiobenour(a)gmail.com&gt; writes:
>  
> > On 4/5/22 12:29, Michael Catanzaro wrote:
> >> On Tue, Apr 5 2022 at 11:56:07 AM -0400, Robbie Harwood 
> >> <rharwood(a)redhat.com&gt; wrote:
> >>> Users wishing to use NVIDIA hardware have the following options:
> >>>
> >>> - Use nouveau (free, open source, cool)
> >>> - Sign their own copy of the proprietary driver (involves messing with
> >>>   certificates, so not appropriate for all users)
> >>> - Disable Secure Boot (note that this is still UEFI)
> >>>
> >>> The NVIDIA driver is proprietary, so of course it's not going to get
> >>> signed.
> >>
> >> The user experience requirement is: user searches for NVIDIA in GNOME
> >> Software and clicks Install. No further action should be
> >> necessary. We didn't make the NVIDIA driver available from the
> >> graphical installer with the intention that arcane workarounds would
> >> be required to use it.
> >
> > Bingo.  None of the three options Robbie suggested are reasonable for
> > non-technical users.
>  
>  No, I don't think that's right.  It's been a bit since I've run nvidia
>  hardware, but I'm pretty sure using nouveau is the default.  It's less
>  powerful than the proprietary driver, but if it works out of the box,
>  it's really difficult to argue with that user experience. 
Nouveau does not support any graphics acceleration on Ampere, and its
performance is very poor on Maxwell and later.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[Robbie Harwood]

Demi Marie Obenour <demiobenour(a)gmail.com&gt; writes:

>  On 4/6/22 16:59, Robbie Harwood wrote:
> > Demi Marie Obenour <demiobenour(a)gmail.com&gt; writes:
> > 
> >> On 4/5/22 12:29, Michael Catanzaro wrote:
> >>> On Tue, Apr 5 2022 at 11:56:07 AM -0400, Robbie Harwood 
> >>> <rharwood(a)redhat.com&gt; wrote:
> >>>> Users wishing to use NVIDIA hardware have the following options:
> >>>>
> >>>> - Use nouveau (free, open source, cool)
> >>>> - Sign their own copy of the proprietary driver (involves messing with
> >>>>   certificates, so not appropriate for all users)
> >>>> - Disable Secure Boot (note that this is still UEFI)
> >>>>
> >>>> The NVIDIA driver is proprietary, so of course it's not going to get
> >>>> signed.
> >>>
> >>> The user experience requirement is: user searches for NVIDIA in GNOME
> >>> Software and clicks Install. No further action should be
> >>> necessary. We didn't make the NVIDIA driver available from the
> >>> graphical installer with the intention that arcane workarounds would
> >>> be required to use it.
> >>
> >> Bingo.  None of the three options Robbie suggested are reasonable for
> >> non-technical users.
> > 
> > No, I don't think that's right.  It's been a bit since I've run
> nvidia
> > hardware, but I'm pretty sure using nouveau is the default.  It's less
> > powerful than the proprietary driver, but if it works out of the box,
> > it's really difficult to argue with that user experience.
>
>  Nouveau does not support any graphics acceleration on Ampere, and its
>  performance is very poor on Maxwell and later. 
That may be true, but that has nothing to do with what non-technical
users are capable of doing to their systems.

Be well,
--Robbie

[Neal Gompa]

On Wed, Apr 6, 2022 at 5:37 PM Demi Marie Obenour <demiobenour(a)gmail.com&gt; wrote:
>  On 4/6/22 16:59, Robbie Harwood wrote:
>  > Demi Marie Obenour <demiobenour(a)gmail.com&gt; writes:
>  >
>  >> On 4/5/22 12:29, Michael Catanzaro wrote:
>  >>> On Tue, Apr 5 2022 at 11:56:07 AM -0400, Robbie Harwood
>  >>> <rharwood(a)redhat.com&gt; wrote:
>  >>>> Users wishing to use NVIDIA hardware have the following options:
>  >>>>
>  >>>> - Use nouveau (free, open source, cool)
>  >>>> - Sign their own copy of the proprietary driver (involves messing with
>  >>>>   certificates, so not appropriate for all users)
>  >>>> - Disable Secure Boot (note that this is still UEFI)
>  >>>>
>  >>>> The NVIDIA driver is proprietary, so of course it's not going to
> get
>  >>>> signed.
>  >>>
>  >>> The user experience requirement is: user searches for NVIDIA in GNOME
>  >>> Software and clicks Install. No further action should be
>  >>> necessary. We didn't make the NVIDIA driver available from the
>  >>> graphical installer with the intention that arcane workarounds would
>  >>> be required to use it.
>  >>
>  >> Bingo.  None of the three options Robbie suggested are reasonable for
>  >> non-technical users.
>  >
>  > No, I don't think that's right.  It's been a bit since I've run
> nvidia
>  > hardware, but I'm pretty sure using nouveau is the default.  It's less
>  > powerful than the proprietary driver, but if it works out of the box,
>  > it's really difficult to argue with that user experience.
>
>  Nouveau does not support any graphics acceleration on Ampere, and its
>  performance is very poor on Maxwell and later. 
Put more concretely in terms of user experience: nouveau causes
regular, random, immediate system freezes with RTX 20 series and RTX
30 series GPUs.

The only safe workaround is to force VGA/VESA mode until the NVIDIA
proprietary driver is installed.

I experienced this problem last week[1] and it's pretty consistent
across the board.

[1]: https://twitter.com/Det_Conan_Kudo/status/1508968025785049088




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

[Brian C. Lane]

On Tue, Apr 05, 2022 at 06:50:39PM -0600, Chris Murphy wrote:
>  On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton <bcotton(a)redhat.com&gt;
> wrote:
>  >syslinux goes away entirely
>  
>  If the installation media used BIOS GRUB, syslinux could still go
>  away. What consideration has occurred to switch from syslinux to BIOS
>  GRUB for installation media? Is BIOS GRUB being deprecated? Or is it
>  being discontinued in Fedora? 
A bit, long time time ago. I *think* wwoods and I discussed this at a
fudcon at one point but there were reasons not to do it. But since I can
no longer remember them I'll take a look again :)

But if Anaconda is going to drop BIOS installation support at some point
in the near future there really is no point in making the effort.

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart

[Neal Gompa]

On Wed, Apr 6, 2022 at 6:06 PM Brian C. Lane <bcl(a)redhat.com&gt; wrote:
>  On Tue, Apr 05, 2022 at 06:50:39PM -0600, Chris Murphy wrote:
>  > On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  > >syslinux goes away entirely
>  >
>  > If the installation media used BIOS GRUB, syslinux could still go
>  > away. What consideration has occurred to switch from syslinux to BIOS
>  > GRUB for installation media? Is BIOS GRUB being deprecated? Or is it
>  > being discontinued in Fedora?
>
>  A bit, long time time ago. I *think* wwoods and I discussed this at a
>  fudcon at one point but there were reasons not to do it. But since I can
>  no longer remember them I'll take a look again :)
>
>  But if Anaconda is going to drop BIOS installation support at some point
>  in the near future there really is no point in making the effort.
>  
It would be useful if we do indeed get a x86 BIOS SIG as Hans de Goede
proposed. I think Fedora Server and Fedora Cloud would be interested
in such a thing, given all the caveats right now with dropping BIOS
support for server-class hardware.


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

[Chris Murphy]

On Wed, Apr 6, 2022 at 10:23 AM Justin Forbes <jmforbes(a)linuxtx.org&gt; wrote:

>  > Apple and Microsoft signing NVIDIA's proprietary driver
> doesn't at all
>  > indicate Apple and Microsoft trust the driver itself. It is trusting
>  > the providence of the blob, in order to achieve an overall safer
>  > ecosystem for their users.
>  >
>  > We either want users with NVIDIA hardware to be inside the Secure Boot
>  > fold or we don't. I want them in the fold *despite* the driver that
>  > needs signing is proprietary. That's a better user experience across
>  > the board, including the security messaging is made consistent. The
>  > existing policy serves no good at all and is double talk. If we really
>  > care about security more than ideological worry, we'd sign the driver.
>
>  At the very least, it would require that Fedora have a separate key
>  that is trusted and not the same one used for shim/grub/kernel. 
If Fedora is going to sign it, rather than improving the local signing
experience, absolutely it should be signed with a separate key. The
design should assume a revocation is going to happen at some point.

>  We
>  certainly aren't proposing that we use the standard Fedora keys to
>  sign a binary blob that runs in kernel space from a company who was
>  most recently hacked last month? 
No way.

I don't think there's a mechanism for it, but I'd prefer Fedora sign
the 3rd party's key rather than their binary. Maybe it's a small
distinction at the end of the day.

-- 
Chris Murphy

[Justin Forbes]

On Wed, Apr 6, 2022 at 6:31 PM Chris Murphy <lists(a)colorremedies.com&gt; wrote:
>  On Wed, Apr 6, 2022 at 10:23 AM Justin Forbes <jmforbes(a)linuxtx.org&gt; wrote:
>
>  > > Apple and Microsoft signing NVIDIA's proprietary driver doesn't at all
>  > > indicate Apple and Microsoft trust the driver itself. It is trusting
>  > > the providence of the blob, in order to achieve an overall safer
>  > > ecosystem for their users.
>  > >
>  > > We either want users with NVIDIA hardware to be inside the Secure Boot
>  > > fold or we don't. I want them in the fold *despite* the driver that
>  > > needs signing is proprietary. That's a better user experience across
>  > > the board, including the security messaging is made consistent. The
>  > > existing policy serves no good at all and is double talk. If we really
>  > > care about security more than ideological worry, we'd sign the driver.
>  >
>  > At the very least, it would require that Fedora have a separate key
>  > that is trusted and not the same one used for shim/grub/kernel.
>
>  If Fedora is going to sign it, rather than improving the local signing
>  experience, absolutely it should be signed with a separate key. The
>  design should assume a revocation is going to happen at some point.
>
>  > We
>  > certainly aren't proposing that we use the standard Fedora keys to
>  > sign a binary blob that runs in kernel space from a company who was
>  > most recently hacked last month?
>
>  No way.
>
>  I don't think there's a mechanism for it, but I'd prefer Fedora sign
>  the 3rd party's key rather than their binary. Maybe it's a small
>  distinction at the end of the day. 

We have not set up an infrastructure for it, but in all honesty, there
is no technical reason that any 3rd party repository building and
packaging the driver could not have done such a thing a couple of
years ago.  The mechanism has been there, pesign can sign modules.
Now, asking Fedora to trust that key is a different issue, but users
have to reboot after installing the nvidia drivers anyway, so clicking
to accept the key isn't too much of a hurdle to jump through at that
point.

Justin

[Luya Tshimbalanga]

Reading the comments, it seems the overlooked word is “depreciated” 
meaning users will have time to properly transition their hardware.
It seems the proposal suggests an opportunity to revisit the boot-loader 
like the heavily downstream patched grub2 deeming too complex to 
maintain in long term. Additionally, this proposal gives time to explore 
alternative boot loader like  systemd-boot (mainly for x86-64 
architecture and useful for desktop and workstation) and  rEFi (?) to 
further reduce the code burden.

-- 
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer

[David Airlie]

On Thu, Apr 7, 2022 at 12:33 PM Luya Tshimbalanga
<luya(a)fedoraproject.org&gt; wrote:
>  Reading the comments, it seems the overlooked word is “depreciated” meaning users will
> have time to properly transition their hardware. 
Transition to what though, another distro?

moving to new hw won't help maintain things for older stuff.

I want to maintain one distro on the hw I maintain upstream drivers
for, this will stop me doing that with Fedora. I work for Red Hat, I
don't really want to move off Fedora, but having to keep Ubuntu and
Fedora mixtures would be a pita, and CentOS can't even build the newer
driver stacks without serious intervention.

Dave.

[Gerd Hoffmann]

  Hi,

>  On the cloud side, it's been very difficult to articulate any
> benefits
>  for supporting UEFI when the majority of the consumers of Fedora Cloud
>  don't have any pressing need to do it and things like hibernation and
>  snapshotting are non-functional. Last year, I changed Fedora Cloud to
>  hybrid boot[6] so that our image artifacts support both boot modes. 
Any chance for regular anaconda installs doing a hybrid boot setup too?

The installed systems will look pretty much the same (gpt with both
bios-boot and efi-esp partition) no matter how they where installed,
and it'll be trivial to switch from BIOS to UEFI without reinstalling
the system.

We can fade out some stuff already (mbr support), and painless switching
to UEFI for systems which where installed in BIOS mode for whatever
reason should also help UEFI adaption.

take care,
  Gerd

[Gerd Hoffmann]

On Wed, Apr 06, 2022 at 12:19:40PM +0200, Dominik 'Rathann' Mierzejewski wrote:
>  On Tuesday, 05 April 2022 at 16:52, Ben Cotton wrote:
>  > https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
>  > 
>  > == Summary ==
>  > Make UEFI a hardware requirement for new Fedora installations on
>  > platforms that support it (x86_64).  Legacy BIOS support is not
>  > removed, but new non-UEFI installation is not supported on those
>  > platforms.  This is a first step toward eventually removing legacy
>  > BIOS support entirely.
>  
>  How is making new installs (and thus re-installs) not removing support
>  entirely? The summary is misleading. 
It also opens up the question how we'll go QA bios support when you
can't install F37 in bios mode.

IMHO we should either drop support for BIOS, or continue full support
for BIOS (including installs).  Claiming BIOS still being supported
while you can't install the system in BIOS mode is bullshit IMHO.

I fully expect we will actually drop BIOS support at some point, the
world is clearly shifting towards UEFI.  Targeting F37 feels a bit
over-eager though.

take care,
  Gerd

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 05 April 2022 at 21:03, PGNet Dev wrote:
>  > Akamai owns Linode, which is a prominent VPS that focuses on
> Linux
>  > (Linode is a contraction meaning "Linux Node").
>  
>  +1
>  
>  > DigitalOcean similarly is Linux centric and so Windows doesn't matter.
>  
>  +1
>  
>  > Most web hosting providers and VPSes are Linux-centric and so Windows
>  > doesn't matter.
>  
>  +1
>  
>  
>  Ironic that Windows11 compat is being floated as any kind of rationale here. 
OVH is another big provider and they don't offer UEFI boot with their
VPS range. I've just confirmed it with their support.

Since one of my servers is hosted by OVH, I'd have to either migrate to
another hosting provider or migrate off Fedora. Which is ironic,
considering my involvement in Fedora.

As I said in another subthread, now is too early to drop BIOS
installation/boot support.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Samuel Sieb]

On 4/6/22 19:30, Luya Tshimbalanga wrote:
>  Reading the comments, it seems the overlooked word is “depreciated” 
>  meaning users will have time to properly transition their hardware. 
No, the problem is that saying it's "deprecated" is misleading.  If you 
can only upgrade a system and can't re-install it, then you've dropped 
support, not deprecated it.  "deprecated" means that it still works just 
as it always did, but with a warning that it will go away in the future.

[Lennart Poettering]

On Mi, 06.04.22 07:33, Neal Gompa (ngompa13(a)gmail.com) wrote:
>  Irrespective of this change, I would flat-out oppose moving to
>  sd-boot. In any case, you can't use sd-boot for live media.
>
>  If we were going to move to pure EFI boot manager, I'd rather use one
>  that has a decent user experience and not a barebones crappy one. 
OK, I'll bite.

What are you missing in sd-boot, specifically?

Also, why would a boot menu need a particularly fancy user experience?
It's a boot manager, not a web browser.

Do you think the user experience with grub was *good*? Turing complete
language? Scripts that generate scripts that generate scripts?

Lennart

--
Lennart Poettering, Berlin

[Leigh Scott]

>  On Wed, Apr 6, 2022 at 6:31 PM Chris Murphy
> <lists(a)colorremedies.com&gt; wrote:
>  
>  
>  We have not set up an infrastructure for it, but in all honesty, there
>  is no technical reason that any 3rd party repository building and
>  packaging the driver could not have done such a thing a couple of 
Rpmfusion doesn't provide compiled nvidia kernel modules.

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 06 April 2022 at 21:35, Jared Dominguez wrote:
>  On Wed, Apr 6, 2022 at 2:26 PM Michael Catanzaro
> <mcatanzaro(a)gnome.org&gt;
>  wrote:
>  
>  > On Wed, Apr 6 2022 at 01:57:00 PM -0400, Neal Gompa
>  > <ngompa13(a)gmail.com&gt; wrote:
>  > > Moving past the Big Three(tm), the actual
>  > > cloud providers that matter from a Fedora context are the smaller
>  > > outfits that principally serve Linux users. These are companies like
>  > > DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who
>  > > graciously do offer Fedora Linux in their platforms. All of their
>  > > virtualization platforms are BIOS only right now, and getting them to
>  > > switch requires them to uplift their platforms to support UEFI in the
>  > > first place.
>  
>  This seems like a strong assumption to me considering that aside from the
>  largest cloud providers (with whom Red Hat is directly working with on UEFI
>  boot features and bug reports), cloud providers are using off-the-shelf
>  hypervisors that support UEFI boot. 
OVH is not providing UEFI boot option at this time. I'd argue they are
a large hosting provider.

[...]
>  > I suppose we should consider that all or most of these platforms
> are
>  > likely to drop Fedora as a supported option if we proceed with this
>  > change proposal.
>  >
>  
>  Why? VMware vSphere dropped legacy x86 boot support recently too. We
>  already know that Windows 11 requires UEFI. We (Red Hat) are actively
>  working with several cloud providers on UEFI-related features, some of
>  which are not possible with legacy x86 boot. I find it much more likely
>  that smaller cloud providers will update their software to support UEFI
>  rather than drop OS's that require it, at least if they want to remain
>  competitive. 
Fedora doesn't have the market share to be able to compel such action.
I'm convinced the smaller providers will rather drop Fedora than
increase their maintenance burden of supporting both BIOS and UEFI.
After all, most Linux users use Ubuntu, which, to my knowledge, is
not removing or even deprecating BIOS support.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Dominik 'Rathann' Mierzejewski]

On Thursday, 07 April 2022 at 08:20, Gerd Hoffmann wrote:
>    Hi,
>  
>  > On the cloud side, it's been very difficult to articulate any benefits
>  > for supporting UEFI when the majority of the consumers of Fedora Cloud
>  > don't have any pressing need to do it and things like hibernation and
>  > snapshotting are non-functional. Last year, I changed Fedora Cloud to
>  > hybrid boot[6] so that our image artifacts support both boot modes.
>  
>  Any chance for regular anaconda installs doing a hybrid boot setup too?
>  
>  The installed systems will look pretty much the same (gpt with both
>  bios-boot and efi-esp partition) no matter how they where installed,
>  and it'll be trivial to switch from BIOS to UEFI without reinstalling
>  the system.
>  
>  We can fade out some stuff already (mbr support), and painless switching
>  to UEFI for systems which where installed in BIOS mode for whatever
>  reason should also help UEFI adaption. 
Now that'd be awesome and likely the best way forward, if feasible.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Florian Weimer]

* Chris Murphy:

>  On Tue, Apr 5, 2022 at 9:56 AM Florian Weimer
> <fweimer(a)redhat.com&gt; wrote:
> >
> > * Peter Robinson:
> >
> > > This is out of context here because you can disable Secure Boot but
> > > still use UEFI to make that work. You're trying to link to different
> > > problems together.
> >
> > I think there's firmware out there which enables Secure Boot
> > unconditionally in UEFI mode, but still has CSM support.
>
>  The UEFI spec makes CSM and Secure Boot mutually exclusive. CSM
>  enabled renders Secure Boot impossible. So I'm not sure how the
>  firmware can simultaneously enforce Secure Boot, but then permit the
>  loading of non-compliant bootloaders. 
I meant that without CSM, Secure Boot is always enabled.  I don't know
if Fedora UEFI installations work on such systems when CSM is enabled.

Thanks,
Florian

[Peter Boy]

>  Am 07.04.2022 um 00:25 schrieb Neal Gompa
> <ngompa13(a)gmail.com&gt;:
>  
>  It would be useful if we do indeed get a x86 BIOS SIG as Hans de Goede
>  proposed. I think Fedora Server and Fedora Cloud would be interested
>  in such a thing, given all the caveats right now with dropping BIOS
>  support for server-class hardware. 
As the soul who currently coordinates and moderates the work of the Server WG, I would be
very much in favor of such a SIG as a possible way out. If it's good enough, that is.

Just coming up with the idea of removing the (new) installation of such a central part
from one release to the next leaves me speechless. That's tens of thousands of devices
/ users affected and we don't even know how many tens of thousands. And then phrases
like "..will remove it anyway". What else is there to say?

I'm afraid just creating an x86 BIOS SIG is not sufficient anymore. We need a
completely different spirit in this area.

Don’t get me wrong. Lack of resources to maintain something is completely legitimate. But
I expect more open-mindedness and willingness for constructive alternatives. And none of
that is evident in the Change proposal, nor in the discussion here (by the change proposal
authors).

And it is OK for me to migrate to UEFI only in the long run. But not that way.

[Neal Gompa]

On Thu, Apr 7, 2022 at 2:20 AM Gerd Hoffmann <kraxel(a)redhat.com&gt; wrote:
>    Hi,
>
>  > On the cloud side, it's been very difficult to articulate any benefits
>  > for supporting UEFI when the majority of the consumers of Fedora Cloud
>  > don't have any pressing need to do it and things like hibernation and
>  > snapshotting are non-functional. Last year, I changed Fedora Cloud to
>  > hybrid boot[6] so that our image artifacts support both boot modes.
>
>  Any chance for regular anaconda installs doing a hybrid boot setup too?
>
>  The installed systems will look pretty much the same (gpt with both
>  bios-boot and efi-esp partition) no matter how they where installed,
>  and it'll be trivial to switch from BIOS to UEFI without reinstalling
>  the system.
>
>  We can fade out some stuff already (mbr support), and painless switching
>  to UEFI for systems which where installed in BIOS mode for whatever
>  reason should also help UEFI adaption.
>  
Anaconda can absolutely do it, after all, the cloud image build
currently runs Anaconda (!!!) to build the image.

In this scenario, grub2-pc, shim, and grub2-efi always get installed,
too. This became possible with the unified config introduced in Fedora
Linux 34.

The problem is that right now Anaconda has some hardwired assumptions
about what kind of bootloader and partitioning to request for all the
default partitioning modes. It shouldn't be difficult to fix, though.
Additionally, by switching to GPT by default for everything, we
probably want to replace inst.gpt with inst.mbr for forcing legacy
MBR.

If we did this now (in F37), we could then more easily fade out BIOS
support when the adoption curve is better off.




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

[Richard Hughes]

On Thu, 7 Apr 2022 at 09:43, Lennart Poettering <mzerqung(a)0pointer.de&gt; wrote:
>  Also, why would a boot menu need a particularly fancy user
> experience? 
Being honest, I think the simplicity of sd-boot is a feature, not a failure.

Richard.

[David Duncan]

>  On Apr 7, 2022, at 2:31 AM, Neal Gompa <ngompa13(a)gmail.com&gt;
> wrote:
>  
>  On Thu, Apr 7, 2022 at 2:20 AM Gerd Hoffmann <kraxel(a)redhat.com&gt; wrote:
> > 
> >  Hi,
> > 
> >> On the cloud side, it's been very difficult to articulate any benefits
> >> for supporting UEFI when the majority of the consumers of Fedora Cloud
> >> don't have any pressing need to do it and things like hibernation and
> >> snapshotting are non-functional. Last year, I changed Fedora Cloud to
> >> hybrid boot[6] so that our image artifacts support both boot modes.
> > 
> > Any chance for regular anaconda installs doing a hybrid boot setup too?
> > 
> > The installed systems will look pretty much the same (gpt with both
> > bios-boot and efi-esp partition) no matter how they where installed,
> > and it'll be trivial to switch from BIOS to UEFI without reinstalling
> > the system.
> > 
> > We can fade out some stuff already (mbr support), and painless switching
> > to UEFI for systems which where installed in BIOS mode for whatever
> > reason should also help UEFI adaption.
> > 
>  
>  Anaconda can absolutely do it, after all, the cloud image build
>  currently runs Anaconda (!!!) to build the image.
>  
>  In this scenario, grub2-pc, shim, and grub2-efi always get installed,
>  too. This became possible with the unified config introduced in Fedora
>  Linux 34.
>  
>  The problem is that right now Anaconda has some hardwired assumptions
>  about what kind of bootloader and partitioning to request for all the
>  default partitioning modes. It shouldn't be difficult to fix, though.
>  Additionally, by switching to GPT by default for everything, we
>  probably want to replace inst.gpt with inst.mbr for forcing legacy
>  MBR.
>  
>  If we did this now (in F37), we could then more easily fade out BIOS
>  support when the adoption curve is better off.
>   
And this is exactly what we need in my opinion. 

It sounds like there has been a great deal of thought put into what the developers can
manage on the supporting team, but it also appears that issues have prevented direct
contribution based on some sort of misconfiguration in the repository, though it sounds
like this is fixed as of this discussion. It still speaks to more than a year of
complication in contribution. Is Neal really the only one who was impacted by the
inability to submit a PR?  

I think that creating choice is the right response and that’s exactly why we created a
dually supported boot model in the cloud (soon-to-be-edition again) working group (thank
you Neal and Gerd). Choice is our best tool in the freedom toolkit. I have heard many say
that there is no rush to remove support for hardware that is in use by those of the
community that may not be capable of switching. I would like to see a period of joint
support in Fedora with the promise that the legacy-bios support will be removed when it no
longer serves the community, but not before that time is clear. It obviously does have an
end date consistent with F37 release. 

VMware’s deprecation does not set a date. It sets the promise of announcing a date at a
later time. I think we should follow suit. A future, as yet undetermined, Fedora release
will not have legacy-bios and we understand that it is expected to follow a concerted
effort to make moving to UEFI as easy as possible. If you have to fallback, there should
be an immediately available option like Gerd and Neal have implemented in their changes.

 In the meantime, this is obviously going to require a rally of community support. As a
community, we are going to have to limit the amount of explaining we need to do. To
loosely quote the agile manifesto: It is better to focus on working code than to focus on
comprehensive documentation. I see that as a directive to ship support for both boot
models in all editions for at the very least, one release and better to provide a minimum
of two. 

- David

[Vitaly Zaitsev]

On 05/04/2022 17:08, Neal Gompa wrote:
>  We also lack solutions for dealing with the NVIDIA driver in
>  UEFI+Secure Boot case. Are you planning to actually*fix*  that now? 
1. UEFI != UEFI Secure Boot.
2. akmods on Fedora 36+ can automatically sign all built kernel modules.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Vitaly Zaitsev]

On 05/04/2022 17:44, Neal Gompa wrote:
>  It is easier to tell people to boot the media in BIOS mode in some
>  cases than it is to figure out how to turn off Secure Boot. 
Legacy boot on modern hardware is a hack[1]. Some hardware manufactures 
even doesn't test CSM support.

[1]: https://www.rodsbooks.com/efi-bootloaders/csm-good-bad-ugly.html

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Vitaly Zaitsev]

On 07/04/2022 09:59, Dominik 'Rathann' Mierzejewski wrote:
>  OVH is another big provider and they don't offer UEFI boot with
> their
>  VPS range. I've just confirmed it with their support. 
You should contact their support first.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Vitaly Zaitsev]

On 05/04/2022 17:56, Robbie Harwood wrote:
>  - Use nouveau (free, open source, cool) 
No way. Broken for ages. Causes random hangs on my PC. Also can't work 
with modern NVIDIA cards without proprietary firmware installation.

>  - Sign their own copy of the proprietary driver (involves messing
> with
>    certificates, so not appropriate for all users) 
akmods can do everything automatically since Fedora 36. No documentation 
available yet.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Richard W.M. Jones]

On Tue, Apr 05, 2022 at 06:30:38PM +0100, Tom Hughes via devel wrote:
>  On 05/04/2022 15:52, Ben Cotton wrote:
>  
>  >* There is no migration story from Legacy BIOS to UEFI -
>  >repartitioning effectively mandates a reinstall.  As a result, we
>  >don’t drop support for existing Legacy BIOS systems yet, just new
>  >installations.
>  
>  This is where I have a problem with this, the fact that there is
>  no upgrade path - virtually my entire installed base of Fedora is
>  running legacy BIOS and not being able to upgrade them will be
>  something of a headache.
>  
>  Is it actually true though? You need to be able to find some space
>  for an EFI partition but assuming that can be done is there some
>  other reason you can't migrate from BIOS to UEFI booting? 
virt-v2v used to be able to do this.  We actually removed support
because it was very convoluted and difficult to maintain.  (Note the
support didn't cope with dm_crypt at all because it's not that common
inside VMs).

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

[Vitaly Zaitsev]

On 05/04/2022 18:29, Michael Catanzaro wrote:
>  The user experience requirement is: user searches for NVIDIA in GNOME
>
>  Software and clicks Install. No further action should be necessary. We 
>  didn't make the NVIDIA driver available from the graphical installer 
>  with the intention that arcane workarounds would be required to use it. 
Unattended installation is impossible because the user will need to 
create their own CA, add it to the trusted store in the UEFI BIOS 
settings, and then configure akmods.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Vitaly Zaitsev]

On 06/04/2022 22:59, Robbie Harwood wrote:
>  It's less
>  powerful than the proprietary driver, but if it works out of the box,
>  it's really difficult to argue with that user experience. 
It doesn't work on modern NVIDIA hardware at all without proprietary 
firmware installation.

On older hardware, it sometimes causes random system hangs. Reported 
this issue 4 years ago. Still not fixed.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Vitaly Zaitsev]

On 06/04/2022 23:44, Neal Gompa wrote:
>  Put more concretely in terms of user experience: nouveau causes
>  regular, random, immediate system freezes with RTX 20 series and RTX
>  30 series GPUs. 
Can confirm that. Also I can reproduce this on legacy GTX 780. Reported 
this issue 4 years ago. Not fixed yet.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Ian Pilcher]

On 4/7/22 03:43, Lennart Poettering wrote:
>  Do you think the user experience with grub was *good*? Turing
> complete
>  language? Scripts that generate scripts that generate scripts? 
Well said.

GRUB2 was actually the reason that I kept many of my UEFI-capable
systems booting in legacy mode for years (until switching to sd-boot).

-- 
========================================================================
Google                                      Where SkyNet meets Idiocracy
========================================================================

[Simo Sorce]

On Wed, 2022-04-06 at 21:03 -0500, Justin Forbes wrote:
>  On Wed, Apr 6, 2022 at 6:31 PM Chris Murphy
> <lists(a)colorremedies.com&gt; wrote:
>  > 
>  > On Wed, Apr 6, 2022 at 10:23 AM Justin Forbes <jmforbes(a)linuxtx.org&gt; wrote:
>  > 
>  > > > Apple and Microsoft signing NVIDIA's proprietary driver doesn't at
> all
>  > > > indicate Apple and Microsoft trust the driver itself. It is trusting
>  > > > the providence of the blob, in order to achieve an overall safer
>  > > > ecosystem for their users.
>  > > > 
>  > > > We either want users with NVIDIA hardware to be inside the Secure Boot
>  > > > fold or we don't. I want them in the fold *despite* the driver that
>  > > > needs signing is proprietary. That's a better user experience across
>  > > > the board, including the security messaging is made consistent. The
>  > > > existing policy serves no good at all and is double talk. If we really
>  > > > care about security more than ideological worry, we'd sign the
> driver.
>  > > 
>  > > At the very least, it would require that Fedora have a separate key
>  > > that is trusted and not the same one used for shim/grub/kernel.
>  > 
>  > If Fedora is going to sign it, rather than improving the local signing
>  > experience, absolutely it should be signed with a separate key. The
>  > design should assume a revocation is going to happen at some point.
>  > 
>  > > We
>  > > certainly aren't proposing that we use the standard Fedora keys to
>  > > sign a binary blob that runs in kernel space from a company who was
>  > > most recently hacked last month?
>  > 
>  > No way.
>  > 
>  > I don't think there's a mechanism for it, but I'd prefer Fedora sign
>  > the 3rd party's key rather than their binary. Maybe it's a small
>  > distinction at the end of the day.
>  
>  
>  We have not set up an infrastructure for it, but in all honesty, there
>  is no technical reason that any 3rd party repository building and
>  packaging the driver could not have done such a thing a couple of
>  years ago.  The mechanism has been there, pesign can sign modules.
>  Now, asking Fedora to trust that key is a different issue, but users
>  have to reboot after installing the nvidia drivers anyway, so clicking
>  to accept the key isn't too much of a hurdle to jump through at that
>  point. 
There is potentially an even easier solution.
Ideally dkms (or whatever) could simply generate a key, sign the module
and manage to get the public key in the right place so that the module
can be verified. But this is hard work I guess, and nobody cares about
Secure Boot enough to do it?

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

[Simo Sorce]

On Wed, 2022-04-06 at 19:30 -0700, Luya Tshimbalanga wrote:
>  Reading the comments, it seems the overlooked word is “depreciated” 
>  meaning users will have time to properly transition their hardware. 
The actual word is "deprecated", but I am pretty sure it applies to HW
that is also very depreciated at this point.

Sorry could not resist the pun :-)

>  It seems the proposal suggests an opportunity to revisit the
> boot-loader 
>  like the heavily downstream patched grub2 deeming too complex to 
>  maintain in long term. Additionally, this proposal gives time to explore 
>  alternative boot loader like  systemd-boot (mainly for x86-64 
>  architecture and useful for desktop and workstation) and  rEFi (?) to 
>  further reduce the code burden. 
-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

[Vitaly Zaitsev]

On 06/04/2022 01:38, Chris Murphy wrote:
>  Apple and Microsoft signing NVIDIA's proprietary driver
> doesn't at all
>  indicate Apple and Microsoft trust the driver itself. 
Both MacOS and Windows have stable as rock kernel API/ABI. Linux - 
don't. That's why you need to rebuild kernel modules after every kernel 
update (even after a patch release).

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Chris Adams]

Once upon a time, Simo Sorce <simo(a)redhat.com&gt; said:
>  Ideally dkms (or whatever) could simply generate a key, sign the
> module
>  and manage to get the public key in the right place so that the module
>  can be verified. 
That's not possible, is it?  I assume the user has to interact with the
firmware at some point to install a new key.  Otherwise, the whole thing
would be a waste of time.

-- 
Chris Adams <linux(a)cmadams.net&gt;

[Neal Gompa]

On Thu, Apr 7, 2022 at 9:20 AM Simo Sorce <simo(a)redhat.com&gt; wrote:
>  On Wed, 2022-04-06 at 21:03 -0500, Justin Forbes wrote:
>  > On Wed, Apr 6, 2022 at 6:31 PM Chris Murphy <lists(a)colorremedies.com&gt; wrote:
>  > >
>  > > On Wed, Apr 6, 2022 at 10:23 AM Justin Forbes <jmforbes(a)linuxtx.org&gt;
> wrote:
>  > >
>  > > > > Apple and Microsoft signing NVIDIA's proprietary driver
> doesn't at all
>  > > > > indicate Apple and Microsoft trust the driver itself. It is trusting
>  > > > > the providence of the blob, in order to achieve an overall safer
>  > > > > ecosystem for their users.
>  > > > >
>  > > > > We either want users with NVIDIA hardware to be inside the Secure
> Boot
>  > > > > fold or we don't. I want them in the fold *despite* the driver
> that
>  > > > > needs signing is proprietary. That's a better user experience
> across
>  > > > > the board, including the security messaging is made consistent. The
>  > > > > existing policy serves no good at all and is double talk. If we
> really
>  > > > > care about security more than ideological worry, we'd sign the
> driver.
>  > > >
>  > > > At the very least, it would require that Fedora have a separate key
>  > > > that is trusted and not the same one used for shim/grub/kernel.
>  > >
>  > > If Fedora is going to sign it, rather than improving the local signing
>  > > experience, absolutely it should be signed with a separate key. The
>  > > design should assume a revocation is going to happen at some point.
>  > >
>  > > > We
>  > > > certainly aren't proposing that we use the standard Fedora keys to
>  > > > sign a binary blob that runs in kernel space from a company who was
>  > > > most recently hacked last month?
>  > >
>  > > No way.
>  > >
>  > > I don't think there's a mechanism for it, but I'd prefer Fedora
> sign
>  > > the 3rd party's key rather than their binary. Maybe it's a small
>  > > distinction at the end of the day.
>  >
>  >
>  > We have not set up an infrastructure for it, but in all honesty, there
>  > is no technical reason that any 3rd party repository building and
>  > packaging the driver could not have done such a thing a couple of
>  > years ago.  The mechanism has been there, pesign can sign modules.
>  > Now, asking Fedora to trust that key is a different issue, but users
>  > have to reboot after installing the nvidia drivers anyway, so clicking
>  > to accept the key isn't too much of a hurdle to jump through at that
>  > point.
>
>  There is potentially an even easier solution.
>  Ideally dkms (or whatever) could simply generate a key, sign the module
>  and manage to get the public key in the right place so that the module
>  can be verified. But this is hard work I guess, and nobody cares about
>  Secure Boot enough to do it?
>  
This has been done for a while. However, there are issues.

The lack of ability to manage it in a non-interactive fashion, or even
fully from the desktop UX because of having to deal with firmware key
storage is a huge problem. But even if you get past that, there are
problems where there isn't enough memory on the firmware flash storage
for another key. This is one of the reasons why the SBAT strategy was
devised for Secure Boot: running out of space for certs in firmware is
a very real problem that people want to avoid.

This is why an OS-level keyring for these things is needed: it allows
us to scope it to the operating system (like Windows does), allows
unique keys to be easily managed, and makes it easy to rotate them
without worrying about causing problems.







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

[Vitaly Zaitsev]

On 06/04/2022 02:59, Demi Marie Obenour wrote:
>  I agree with this.  Sign the driver. 
/NVIDIA driver maintainer here/

We can't sign the driver, because we're building RPMS with kernel 
modules on end user machines with akmods.

Akmods can now automatically sign built kernel modules, but you will 
need to create your own CA and add its public key to the trusted store.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Neal Gompa]

On Thu, Apr 7, 2022 at 9:27 AM Chris Adams <linux(a)cmadams.net&gt; wrote:
>  Once upon a time, Simo Sorce <simo(a)redhat.com&gt; said:
>  > Ideally dkms (or whatever) could simply generate a key, sign the module
>  > and manage to get the public key in the right place so that the module
>  > can be verified.
>
>  That's not possible, is it?  I assume the user has to interact with the
>  firmware at some point to install a new key.  Otherwise, the whole thing
>  would be a waste of time.
>  
Yes. DKMS can be told to sign with a key, but the key needs to exist
first and be set up in firmware. Automating it requires moving it out
of firmware scope and putting it exclusively at the operating system
level. This is what Windows has for managing trust for kernel drivers.


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

[Vitaly Zaitsev]

On 06/04/2022 06:03, Gary Buhrmaster wrote:
>  That they choose
>  not to do so for Linux is their right,
>  even if some wish they did. 
Because it is impossible. The Linux kernel doesn't have a stable 
API/ABI. You need to rebuild kernel modules after every kernel update.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Vitaly Zaitsev]

On 06/04/2022 22:37, Javier Martinez Canillas wrote:
>  As Robbied said, I added the /etc/dnf/protected.d/grub2-*.conf to
> the
>  grub2 
I don't like that. Users should be able to remove grub2 and switch to 
systemd-boot.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Vitaly Zaitsev]

On 05/04/2022 19:30, Tom Hughes via devel wrote:
>  This is where I have a problem with this, the fact that there is
>  no upgrade path - virtually my entire installed base of Fedora is
>  running legacy BIOS and not being able to upgrade them will be
>  something of a headache. 
If you want to switch from legacy boot to UEFI, you need to do the 
following:
1. Switch from MBR (msdos) to GPT.
2. Create ESP (FAT32 by default) partition.
3. Move data.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Vitaly Zaitsev]

On 07/04/2022 10:43, Lennart Poettering wrote:
>  Do you think the user experience with grub was*good*? Turing
> complete
>  language? Scripts that generate scripts that generate scripts? 
+1. Current GRUB2 is a collection of hacks. Even the upstream abandoned 
it, and it currently maintained mainly in downstream.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Jared Dominguez]

On Thu, Apr 7, 2022 at 4:51 AM Dominik 'Rathann' Mierzejewski <
dominik(a)greysector.net&gt; wrote:

>  On Wednesday, 06 April 2022 at 21:35, Jared Dominguez wrote:
>  > On Wed, Apr 6, 2022 at 2:26 PM Michael Catanzaro <mcatanzaro(a)gnome.org&gt;
>  > wrote:
>  >
>  > > On Wed, Apr 6 2022 at 01:57:00 PM -0400, Neal Gompa
>  > > <ngompa13(a)gmail.com&gt; wrote:
>  > > > Moving past the Big Three(tm), the actual
>  > > > cloud providers that matter from a Fedora context are the smaller
>  > > > outfits that principally serve Linux users. These are companies like
>  > > > DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who
>  > > > graciously do offer Fedora Linux in their platforms. All of their
>  > > > virtualization platforms are BIOS only right now, and getting them to
>  > > > switch requires them to uplift their platforms to support UEFI in the
>  > > > first place.
>  >
>  > This seems like a strong assumption to me considering that aside from the
>  > largest cloud providers (with whom Red Hat is directly working with on
>  UEFI
>  > boot features and bug reports), cloud providers are using off-the-shelf
>  > hypervisors that support UEFI boot.
>
>  OVH is not providing UEFI boot option at this time. I'd argue they are
>  a large hosting provider.
>  
Looks like they are using vSphere, which supports UEFI VMs. The same is
true for KVM, Xen and bhyve, so it's more about what feature set cloud
providers using these hypervisors are choosing to turn on.


>  [...]
>  > > I suppose we should consider that all or most of these platforms are
>  > > likely to drop Fedora as a supported option if we proceed with this
>  > > change proposal.
>  > >
>  >
>  > Why? VMware vSphere dropped legacy x86 boot support recently too. We
>  > already know that Windows 11 requires UEFI. We (Red Hat) are actively
>  > working with several cloud providers on UEFI-related features, some of
>  > which are not possible with legacy x86 boot. I find it much more likely
>  > that smaller cloud providers will update their software to support UEFI
>  > rather than drop OS's that require it, at least if they want to remain
>  > competitive.
>
>  Fedora doesn't have the market share to be able to compel such action.
>  I'm convinced the smaller providers will rather drop Fedora than
>  increase their maintenance burden of supporting both BIOS and UEFI.
>  After all, most Linux users use Ubuntu, which, to my knowledge, is
>  not removing or even deprecating BIOS support.
>
>  Regards,
>  Dominik
>  --
>  Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
>  There should be a science of discontent. People need hard times and
>  oppression to develop psychic muscles.
>          -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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
>  

-- 
Jared Dominguez (he/him)
Software Engineering Manager
New Platform Technologies Enablement team
RHEL Workstation Engineering

If I am emailing outside of business hours (mine or yours), it is my choice
and does not mean I expect you to respond today.

[Zbigniew Jędrzejewski-Szmek]

On Thu, Apr 07, 2022 at 10:58:29AM +0200, Peter Boy wrote:
>  
>  
>  > Am 07.04.2022 um 00:25 schrieb Neal Gompa <ngompa13(a)gmail.com&gt;:
>  > 
>  > It would be useful if we do indeed get a x86 BIOS SIG as Hans de Goede
>  > proposed. I think Fedora Server and Fedora Cloud would be interested
>  > in such a thing, given all the caveats right now with dropping BIOS
>  > support for server-class hardware.
>  
>  As the soul who currently coordinates and moderates the work of the Server WG, I would be
> very much in favor of such a SIG as a possible way out. If it's good enough, that is.
>  
>  Just coming up with the idea of removing the (new) installation of such a central part
> from one release to the next leaves me speechless. That's tens of thousands of devices
> / users affected and we don't even know how many tens of thousands. And then phrases
> like "..will remove it anyway". What else is there to say?
>  
>  I'm afraid just creating an x86 BIOS SIG is not sufficient anymore. We need a
> completely different spirit in this area.
>  
>  Don’t get me wrong. Lack of resources to maintain something is completely legitimate. But
> I expect more open-mindedness and willingness for constructive alternatives. And none of
> that is evident in the Change proposal, nor in the discussion here (by the change proposal
> authors).
>  
>  And it is OK for me to migrate to UEFI only in the long run. But not that way. 
This summarizes my feelings about the proposal very well.

We should look to the Xorg → Wayland transition for inspiration:
it's long, it's messy, it requires a lot of effort from people doing
the work, and it's still not finished. Those are the downsides. But
the big upside is that we're not leaving users who need Xorg in the
ditch.

A similar pattern should be followed here: encourage users to switch,
fix bugs so that $new is better than $old in all cases we care about,
iterate until the number of users on $old is negligible,
*then* announce that $old is not supported, but keep it working,
and only after that start cutting off parts of $old.

The proposed plan seems to be to jump to the last two steps before the
middle parts have been done. Based on the examples posted to this
thread, it'd leave our users and developers with 10%–30% of hardware
unsupported by the next installer. It also depends on changes that are
only *planned* in external projects like VirtualBox and libvirt.

Sorry, but the plan needs to be inverted to at least make sure that
the UEFI works for all the cloud providers and virtualization software
in a testable way, and then switch to UEFI as the default in as many
places as possible. Then we can talk about dropping support for BIOS,
taking into account how many users are still left with BIOS-only
hardware.

Zbyszek

[Chris Adams]

Once upon a time, Jared Dominguez <jaredz(a)redhat.com&gt; said:
>  Looks like they are using vSphere, which supports UEFI VMs. The same
> is
>  true for KVM, Xen and bhyve, so it's more about what feature set cloud
>  providers using these hypervisors are choosing to turn on. 
In a way, this is similar to "your router supports IPv6, why don't you
just turn it on?":

- version considerations: when did $HYPERVISOR start supporting UEFI?
  what versions may still be running in some parts of infrastructure?

- "support" vs. "really support": just because something says it
  "supports UEFI" doesn't mean it works right; large-scale hosters need
  to do lots of testing of all their supported systems and setups to see
  how they actually react

- internal tooling: just because a hoster is using KVM for example
  doesn't mean they just install the vendor software and go; they have
  their own internal management systems built on top, calling vendor
  APIs to do things

- presentation: adding user-facing options should always be carefully
  considered, especially when they are "change this option and your VM
  possibly won't boot" type (so more support tickets)

That all combines to lots of effort to support UEFI booting.  When
there's little demand, and little obvious gain up front, low-overhead
providers aren't going to put that high on the priority list.

-- 
Chris Adams <linux(a)cmadams.net&gt;

[Lennart Poettering]

On Di, 05.04.22 17:38, Chris Murphy (lists(a)colorremedies.com) wrote:

>  When users have a suboptimal experience by default, it makes Fedora
>  look bad. We can't have security concerns overriding all other
>  concerns. But it's really pernicious to simultaneously say security is
>  important, but we're also not going to sign proprietary drivers. This
>  highly incentivizes the user to disable Secure Boot because that's so
>  much easier than users signing kernel modules and enrolling keys with
>  the firmware, and therefore makes the user *less safe*. 
Let me stress one thing though: Fedora *has* *no* working SecureBoot
implementation. The initrd is not authenticated. It has no signatures,
nothing.

By disabling SecureBoot you effectively lose exactly nothing in terms
of security right now.

What good is a trusted boot loader or kernel if it then goes on
loading an initrd that is not authenticated, super easy to modify (I
mean, seriously, any idiot script kiddie can unpack a cpio, add some
shell script and pack it up again, replacing the original one) – and
it's the component that actually reads your FDE LUKS password.

I mean, let's not pretend unsigned drivers were a big issue for
security right now. They are now, we have much much much wider gaping
holes in our stack.

Lennart

--
Lennart Poettering, Berlin

[Neal Gompa]

On Thu, Apr 7, 2022 at 10:03 AM Jared Dominguez <jaredz(a)redhat.com&gt; wrote:
>  On Thu, Apr 7, 2022 at 4:51 AM Dominik 'Rathann' Mierzejewski
> <dominik(a)greysector.net&gt; wrote:
> >
> > On Wednesday, 06 April 2022 at 21:35, Jared Dominguez wrote:
> > > On Wed, Apr 6, 2022 at 2:26 PM Michael Catanzaro <mcatanzaro(a)gnome.org&gt;
> > > wrote:
> > >
> > > > On Wed, Apr 6 2022 at 01:57:00 PM -0400, Neal Gompa
> > > > <ngompa13(a)gmail.com&gt; wrote:
> > > > > Moving past the Big Three(tm), the actual
> > > > > cloud providers that matter from a Fedora context are the smaller
> > > > > outfits that principally serve Linux users. These are companies like
> > > > > DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who
> > > > > graciously do offer Fedora Linux in their platforms. All of their
> > > > > virtualization platforms are BIOS only right now, and getting them to
> > > > > switch requires them to uplift their platforms to support UEFI in the
> > > > > first place.
> > >
> > > This seems like a strong assumption to me considering that aside from the
> > > largest cloud providers (with whom Red Hat is directly working with on UEFI
> > > boot features and bug reports), cloud providers are using off-the-shelf
> > > hypervisors that support UEFI boot.
> >
> > OVH is not providing UEFI boot option at this time. I'd argue they are
> > a large hosting provider.
>
>
>  Looks like they are using vSphere, which supports UEFI VMs. The same is true for KVM, Xen
> and bhyve, so it's more about what feature set cloud providers using these hypervisors
> are choosing to turn on.
>  
OVHcloud is OpenStack based:
https://www.theregister.com/2019/04/29/ovh_adds_bare_metal_fighters_to_it...

However, OpenStack's UEFI support is seemingly broken. For example,
the OpenStack deployment I use at work fail to boot UEFI VMs when I
set the appropriate flags, which have existed since OpenStack Mitaka
(we're testing on Ussuri right now). According to internal research,
it *may* be fixed in an upcoming OpenStack release, but no one is
sure...



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

[Richard W.M. Jones]

On Wed, Apr 06, 2022 at 12:38:40PM +0000, Gary Buhrmaster wrote:
>  On Wed, Apr 6, 2022 at 12:15 PM Josh Boyer
> <jwboyer(a)fedoraproject.org&gt; wrote:
>  
>  > I agree 100%.  I think this is actually getting to the crux of the
>  > issue, which is that while we have a lot of people that want BIOS
>  > support to continue, we effectively have nobody that wants to do the
>  > work to make it happen.
>  
>  In a previous thread about bios support, there
>  was a discussion about (a mythical) someone
>  resurrecting DUET to provide a transition path.
>  
>  To the best of my knowledge, no one stepped
>  up to do that work[0].
>  
>  Gary
>  
>  
>  [0] Quite honestly, given that DUET was removed
>  upstream, I would have thought looking instead
>  at Clover (which is still supported) would be a
>  better option, but better only in some theoretical
>  sense, as there was no one to do that work
>  either. 
I was wondering about whether this was possible (booting UEFI from
BIOS) too.  For reference, DUET is described here:

https://rodsbooks.com/bios2uefi/

Clover is described here:

https://github.com/CloverHackyColor/CloverBootloader

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

[Jared Dominguez]

On Thu, Apr 7, 2022 at 10:36 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:

>  On Thu, Apr 7, 2022 at 10:03 AM Jared Dominguez
> <jaredz(a)redhat.com&gt; wrote:
>  >
>  >
>  >
>  > On Thu, Apr 7, 2022 at 4:51 AM Dominik 'Rathann' Mierzejewski <
>  dominik(a)greysector.net&gt; wrote:
>  >>
>  >> On Wednesday, 06 April 2022 at 21:35, Jared Dominguez wrote:
>  >> > On Wed, Apr 6, 2022 at 2:26 PM Michael Catanzaro <
>  mcatanzaro(a)gnome.org&gt;
>  >> > wrote:
>  >> >
>  >> > > On Wed, Apr 6 2022 at 01:57:00 PM -0400, Neal Gompa
>  >> > > <ngompa13(a)gmail.com&gt; wrote:
>  >> > > > Moving past the Big Three(tm), the actual
>  >> > > > cloud providers that matter from a Fedora context are the
> smaller
>  >> > > > outfits that principally serve Linux users. These are companies
>  like
>  >> > > > DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who
>  >> > > > graciously do offer Fedora Linux in their platforms. All of
> their
>  >> > > > virtualization platforms are BIOS only right now, and getting
>  them to
>  >> > > > switch requires them to uplift their platforms to support UEFI
> in
>  the
>  >> > > > first place.
>  >> >
>  >> > This seems like a strong assumption to me considering that aside from
>  the
>  >> > largest cloud providers (with whom Red Hat is directly working with
>  on UEFI
>  >> > boot features and bug reports), cloud providers are using
>  off-the-shelf
>  >> > hypervisors that support UEFI boot.
>  >>
>  >> OVH is not providing UEFI boot option at this time. I'd argue they are
>  >> a large hosting provider.
>  >
>  >
>  > Looks like they are using vSphere, which supports UEFI VMs. The same is
>  true for KVM, Xen and bhyve, so it's more about what feature set cloud
>  providers using these hypervisors are choosing to turn on.
>  >
>
>  OVHcloud is OpenStack based:
>
>
> https://www.theregister.com/2019/04/29/ovh_adds_bare_metal_fighters_to_it...
>
>  However, OpenStack's UEFI support is seemingly broken. For example,
>  the OpenStack deployment I use at work fail to boot UEFI VMs when I
>  set the appropriate flags, which have existed since OpenStack Mitaka
>  (we're testing on Ussuri right now). According to internal research,
>  it *may* be fixed in an upcoming OpenStack release, but no one is
>  sure...
>  
From what I've found, it looks like they use both. Anyway, Red Hat has
customers using UEFI with OpenStack, which I'm aware of from seeing bug
reports which we fix. Have you reported the bugs that you've seen?


>  --
>  真実はいつも一つ！/ Always, there's only one truth!
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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
>  

-- 
Jared Dominguez (he/him)
Software Engineering Manager
New Platform Technologies Enablement team
RHEL Workstation Engineering

If I am emailing outside of business hours (mine or yours), it is my choice
and does not mean I expect you to respond today.

[Robert Marcano]

On 4/7/22 10:28 AM, Lennart Poettering wrote:
>  On Di, 05.04.22 17:38, Chris Murphy (lists(a)colorremedies.com) wrote:
>  
> > When users have a suboptimal experience by default, it makes Fedora
> > look bad. We can't have security concerns overriding all other
> > concerns. But it's really pernicious to simultaneously say security is
> > important, but we're also not going to sign proprietary drivers. This
> > highly incentivizes the user to disable Secure Boot because that's so
> > much easier than users signing kernel modules and enrolling keys with
> > the firmware, and therefore makes the user *less safe*.
>  
>  Let me stress one thing though: Fedora *has* *no* working SecureBoot
>  implementation. The initrd is not authenticated. It has no signatures,
>  nothing. 

Couldn't the other Fedora change about adding file signatures to the RPM 
installed files be used to close this hole?. Enabling some policy at 
boot that disallows execution on code not signed that is inside the 
initrd. I think all code copied to the initrd must come from Fedora 
packages, maybe the only exception are third party kernel modules.

Note: It appears cpio doesn't support extended attributes [1]

[1] https://bugzilla.redhat.com/show_bug.cgi?id=771926

>  
>  By disabling SecureBoot you effectively lose exactly nothing in terms
>  of security right now.
>  
>  What good is a trusted boot loader or kernel if it then goes on
>  loading an initrd that is not authenticated, super easy to modify (I
>  mean, seriously, any idiot script kiddie can unpack a cpio, add some
>  shell script and pack it up again, replacing the original one) – and
>  it's the component that actually reads your FDE LUKS password.
>  
>  I mean, let's not pretend unsigned drivers were a big issue for
>  security right now. They are now, we have much much much wider gaping
>  holes in our stack.
>  
>  Lennart
>  
>  --
>  Lennart Poettering, Berlin
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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

[Jared Dominguez]

On Thu, Apr 7, 2022 at 4:58 AM Peter Boy <pboy(a)uni-bremen.de&gt; wrote:

>  > Am 07.04.2022 um 00:25 schrieb Neal Gompa <ngompa13(a)gmail.com&gt;:
>  >
>  > It would be useful if we do indeed get a x86 BIOS SIG as Hans de Goede
>  > proposed. I think Fedora Server and Fedora Cloud would be interested
>  > in such a thing, given all the caveats right now with dropping BIOS
>  > support for server-class hardware.
>
>  As the soul who currently coordinates and moderates the work of the Server
>  WG, I would be very much in favor of such a SIG as a possible way out. If
>  it's good enough, that is.
>
>  Just coming up with the idea of removing the (new) installation of such a
>  central part from one release to the next leaves me speechless. That's tens
>  of thousands of devices / users affected and we don't even know how many
>  tens of thousands. And then phrases like "..will remove it anyway". What
>  else is there to say?
>
>  I'm afraid just creating an x86 BIOS SIG is not sufficient anymore. We
>  need a completely different spirit in this area.
>
>  Don’t get me wrong. Lack of resources to maintain something is completely
>  legitimate. But I expect more open-mindedness and willingness for
>  constructive alternatives. And none of that is evident in the Change
>  proposal, nor in the discussion here (by the change proposal authors).
>  
This is a proposal. Nothing has changed yet. The choice is now whether to
go forward with it or come together with a cohesive alternative, including
one of the two listed in the proposal. But we need a solution that accounts
for the existing maintainers not having capacity to continue maintaining
legacy code. I've seen responses from Robbie and Brian (and myself) that
are correcting false statements or following up on questions and nothing
that indicates to me close-mindedness or unwillingness for constructive
alternatives.


>  And it is OK for me to migrate to UEFI only in the long run. But not
> that
>  way.
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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
>  

-- 
Jared Dominguez (he/him)
Software Engineering Manager
New Platform Technologies Enablement team
RHEL Workstation Engineering

If I am emailing outside of business hours (mine or yours), it is my choice
and does not mean I expect you to respond today.

[Zbigniew Jędrzejewski-Szmek]

On Wed, Apr 06, 2022 at 10:47:30AM -0400, Robbie Harwood wrote:
>  majid hussain <mhussaincov93(a)gmx.com&gt; writes:
>  
>  > hi,
>  > could someone kindly tell me if my toshiba l750 machine has EFI support?
>  > i'm blind and efi/bios screens are in accessible. 
Based on a web query, it most likely has EFI support, but it also
supports BIOS-compat (CSM?).

>  Easiest is probably to do:
>  
>  ls /sys/firmware/efi
>  
>  This tells you whether the machine booted using UEFI.  anaconda will set
>  up a UEFI-capable system if booted that way, unless partitioning is
>  overridden to prevent that.
>  
>  If it didn't boot using UEFI today, that doesn't mean it can't (you
>  could check with a live image as well).  UEFI tends to be enabled on
>  machines made these days by default for Windows logo requirements, but
>  this is firmware land, and there are no absolutes. 
Changing UEFI setting in the firmware is a big problem. We know that
a) it can only be done by tweaking settings in the firmware interface
which looks different on every machine, b) users find it very hard in
general, and c) for blind users it's virtually impossible.

So even if a machine has UEFI, if it is currently in BIOS-compat mode,
to some extent it's like if it didn't have UEFI.

Zbyszek

[Lennart Poettering]

On Do, 07.04.22 10:53, Fedora Development ML (devel(a)lists.fedoraproject.org) wrote:

>  On 4/7/22 10:28 AM, Lennart Poettering wrote:
>  > On Di, 05.04.22 17:38, Chris Murphy (lists(a)colorremedies.com) wrote:
>  >
>  > > When users have a suboptimal experience by default, it makes Fedora
>  > > look bad. We can't have security concerns overriding all other
>  > > concerns. But it's really pernicious to simultaneously say security is
>  > > important, but we're also not going to sign proprietary drivers. This
>  > > highly incentivizes the user to disable Secure Boot because that's so
>  > > much easier than users signing kernel modules and enrolling keys with
>  > > the firmware, and therefore makes the user *less safe*.
>  >
>  > Let me stress one thing though: Fedora *has* *no* working SecureBoot
>  > implementation. The initrd is not authenticated. It has no signatures,
>  > nothing.
>
>
>  Couldn't the other Fedora change about adding file signatures to the RPM
>  installed files be used to close this hole?. Enabling some policy at boot
>  that disallows execution on code not signed that is inside the initrd. I
>  think all code copied to the initrd must come from Fedora packages, maybe
>  the only exception are third party kernel modules. 
You need to sign the whole thing, and figure out what to do about
configuration so that you can still configure the thing but also
authenticate it so that you know it is in order.

Lennart

--
Lennart Poettering, Berlin

[Chris Adams]

Once upon a time, Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl&gt; said:
>  Changing UEFI setting in the firmware is a big problem. We know that
>  a) it can only be done by tweaking settings in the firmware interface
>  which looks different on every machine, b) users find it very hard in
>  general, and c) for blind users it's virtually impossible. 
Yeah, even as a highly-knowledgeable person, I've had to dig around to
find it in some systems.

One thing I really like about Dell PowerEdge servers and OMSA is the
ability to change firmware settings from within Linux with omconfig.  I
really wish UEFI would include a standard mechanism for that, with all
the "normal" options standardized.

-- 
Chris Adams <linux(a)cmadams.net&gt;

[Jared Dominguez]

On Thu, Apr 7, 2022 at 11:09 AM Zbigniew Jędrzejewski-Szmek <
zbyszek(a)in.waw.pl&gt; wrote:

>  On Wed, Apr 06, 2022 at 10:47:30AM -0400, Robbie Harwood wrote:
>  > majid hussain <mhussaincov93(a)gmx.com&gt; writes:
>  >
>  > > hi,
>  > > could someone kindly tell me if my toshiba l750 machine has EFI
>  support?
>  > > i'm blind and efi/bios screens are in accessible.
>
>  Based on a web query, it most likely has EFI support, but it also
>  supports BIOS-compat (CSM?).
>
>  > Easiest is probably to do:
>  >
>  > ls /sys/firmware/efi
>  >
>  > This tells you whether the machine booted using UEFI.  anaconda will set
>  > up a UEFI-capable system if booted that way, unless partitioning is
>  > overridden to prevent that.
>  >
>  > If it didn't boot using UEFI today, that doesn't mean it can't (you
>  > could check with a live image as well).  UEFI tends to be enabled on
>  > machines made these days by default for Windows logo requirements, but
>  > this is firmware land, and there are no absolutes.
>
>  Changing UEFI setting in the firmware is a big problem. We know that
>  a) it can only be done by tweaking settings in the firmware interface
>  which looks different on every machine, b) users find it very hard in
>  general, and c) for blind users it's virtually impossible.
>
>  So even if a machine has UEFI, if it is currently in BIOS-compat mode,
>  to some extent it's like if it didn't have UEFI.
>  
Microsoft has required since Windows 8 (released in 2012) that any systems
that are certified with Windows must ship with UEFI by default, so in those
cases, the user would have had to manually change BIOS settings in the
first place. Alternatively, the person manually chose Windows 7 instead
(while that was still an option), built a system out of parts that didn't
get certified for Windows (rare), or found a small vendor to sell them
hardware that's not Windows certified and/or came with Linux. Having been
one of the folks who started Project Sputnik, I know that Dell, which was
one of the few companies shipping Linux in 2012, very quickly switched to
UEFI booting for Linux because of the advantages. So I would think that the
number of cases where a user doesn't know how to change to UEFI booting are
limited.


>  Zbyszek
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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
>  

-- 
Jared Dominguez (he/him)
Software Engineering Manager
New Platform Technologies Enablement team
RHEL Workstation Engineering

If I am emailing outside of business hours (mine or yours), it is my choice
and does not mean I expect you to respond today.

[Robbie Harwood]

Vitaly Zaitsev via devel <devel(a)lists.fedoraproject.org&gt; writes:

>  On 07/04/2022 10:43, Lennart Poettering wrote:
> > Do you think the user experience with grub was*good*? Turing complete
> > language? Scripts that generate scripts that generate scripts?
>
>  +1. Current GRUB2 is a collection of hacks. Even the upstream abandoned 
>  it, and it currently maintained mainly in downstream. 
This is not reflective of the current state of affairs.

While we do maintain a large set of patches downstream, due to upstream
being inactive for a while, today upstream is alive and very much not
abandoned:

https://www.gnu.org/software/grub/
https://lists.gnu.org/archive/html/grub-devel/

Last release was June; plenty of commits since then.  I regularly
communicate with dkiper (who is the maintainer these days).

Be well,
--Robbie

[Robbie Harwood]

Robert Marcano via devel <devel(a)lists.fedoraproject.org&gt; writes:

>  Is this change only related to install media support for booting with
>
>  BIOS only? Would I be able to install newer Fedora releases using Legacy 
>  PXE on BIOS only machines? 
The intent is to indicate that new legacy installations are not
supported, regardless of how one gets there.  Mechanically, there are
few ways to actually *prevent* these installations[1] - rather, we send
a message that this is on its way out (i.e., deprecated) and that it's
time for users to consider migrating their setups.

So the direct answer is: yes, probably, if you're willing to work at it
hard enough.  But it wouldn't be supported.

Be well,
--Robbie

1: Even if I wanted to, which I don't, it's not that hard to re-enable
   anything we might turn off just by doing local builds.

[Robbie Harwood]

Michael Catanzaro <mcatanzaro(a)gnome.org&gt; writes:

>  On Wed, Apr 6 2022 at 03:35:38 PM -0400, Jared Dominguez 
>  <jaredz(a)redhat.com&gt; wrote:
> > This seems like a strong assumption to me considering that aside from 
> > the largest cloud providers (with whom Red Hat is directly working 
> > with on UEFI boot features and bug reports), cloud providers are 
> > using off-the-shelf hypervisors that support UEFI boot.
>
>  I'm going to ask the proposal authors to at least mention this as a 
>  risk in the Feedback section of the change proposal. Maybe cloud 
>  providers will all see this as a good opportunity to enable UEFI on 
>  their platforms, and we'll be perfectly fine. I rather suspect it's not 
>  going to happen quite so smoothly, though.... 
I have appended added my analysis of this to the Feedback section.  For
clarity, it's copied here:

    During mailing list discussion of this change, concern was expressed
    that some of the smaller hosting providers who do not provision with
    UEFI today and do not also support Windows would drop Fedora rather
    than enabling UEFI.  Given that the major virtualization solutions
    (vsphere, kvm, xen, bhve, virtualbox, ...) all support UEFI today,
    this would likely be exposing an existing capability rather than
    making a sweeping change.  That said, it is always possible that
    providers may elect to drop Fedora rather than adjust their setups -
    be it for this change or any other change Fedora makes.

Be well,
--Robbie

[Robbie Harwood]

David Duncan <davdunc(a)gmail.com&gt; writes:

>  it also appears that issues have prevented direct contribution based
>  on some sort of misconfiguration in the repository, though it sounds
>  like this is fixed as of this discussion. It still speaks to more than
>  a year of complication in contribution. Is Neal really the only one
>  who was impacted by the inability to submit a PR? 
So far, that's the only case we're aware of, and we only learned
yesterday that they considered using it during that interval.  Anyway,
it has been fixed for a while - for instance, Zbignew has been waiting
on me to merge a pending PR to drop our use of "which" :)

(Javier (co-maintainer) has a post I believe
touching on this as well, but it's stuck in the moderation queue right
now.)

I want to emphasize again that PRs are not the only venue of
communication with maintainers, nor are they the only way to send us
code (attachments on bugzilla, patches upstream, patches to
source-git-likes, ...), nor is sending code the only way to contribute
(investigating issues, translations, ...).

>  I think that creating choice is the right response 
I don't agree that choice is inherently superior, especially when it
creates more work to support.  For a more eloquent explanation of this,
I refer you to ajax's post:
https://listman.redhat.com/archives/fedora-devel-list/2008-January/msg008...

Be well,
--Robbie

[Chris Murphy]

On Wed, Apr 6, 2022 at 8:04 PM Justin Forbes <jmforbes(a)linuxtx.org&gt; wrote:

>  We have not set up an infrastructure for it, but in all honesty,
> there
>  is no technical reason that any 3rd party repository building and
>  packaging the driver could not have done such a thing a couple of
>  years ago.  The mechanism has been there, pesign can sign modules.
>  Now, asking Fedora to trust that key is a different issue, but users
>  have to reboot after installing the nvidia drivers anyway, so clicking
>  to accept the key isn't too much of a hurdle to jump through at that
>  point. 
Create key, enroll key, confirm enrollment, sign the binary with
on-going signing requirement, lose signing key, make new signing key,
no room in NVRAM for additional signing key, remove key, enroll key,
confirm key.... it's shit. Not complete shit, but almost complete
shit. And that's excluding running into bugs (pretty common to find
myriad UEFI implementation bugs).

Ironically, only computers certified by Microsoft as part of their
marketing program are also required to have a minimum user interface.
There's a large pile of non-Microsoft certified hardware out there and
they don't have to follow those requirements and often don't.
Remarkably, right now you have to disable Secure Boot on Apple
hardware because they don't even offer a way to enroll keys. They only
include the key used for running Windows, not the key used for signing
Fedora's shim bootloader.

As much of a Secure Boot fanboy I've been, I'm rapidly approaching the
"fuck it" stage, because the burden is too high. I don't do anywhere
near as much kernel regression testing because (a) I don't want to
disable Secure Boot and (b) I'm unwilling to go through the hurdles to
sign the kernel with my own key.


-- 
Chris Murphy

[Simo Sorce]

On Thu, 2022-04-07 at 16:16 +0200, Zbigniew Jędrzejewski-Szmek wrote:
>  On Thu, Apr 07, 2022 at 10:58:29AM +0200, Peter Boy wrote:
>  > 
>  > 
>  > > Am 07.04.2022 um 00:25 schrieb Neal Gompa <ngompa13(a)gmail.com&gt;:
>  > > 
>  > > It would be useful if we do indeed get a x86 BIOS SIG as Hans de Goede
>  > > proposed. I think Fedora Server and Fedora Cloud would be interested
>  > > in such a thing, given all the caveats right now with dropping BIOS
>  > > support for server-class hardware.
>  > 
>  > As the soul who currently coordinates and moderates the work of the Server WG, I
> would be very much in favor of such a SIG as a possible way out. If it's good enough,
> that is.
>  > 
>  > Just coming up with the idea of removing the (new) installation of such a central
> part from one release to the next leaves me speechless. That's tens of thousands of
> devices / users affected and we don't even know how many tens of thousands. And then
> phrases like "..will remove it anyway". What else is there to say?
>  > 
>  > I'm afraid just creating an x86 BIOS SIG is not sufficient anymore. We need a
> completely different spirit in this area.
>  > 
>  > Don’t get me wrong. Lack of resources to maintain something is completely
> legitimate. But I expect more open-mindedness and willingness for constructive
> alternatives. And none of that is evident in the Change proposal, nor in the discussion
> here (by the change proposal authors).
>  > 
>  > And it is OK for me to migrate to UEFI only in the long run. But not that way.
>  
>  This summarizes my feelings about the proposal very well.
>  
>  We should look to the Xorg → Wayland transition for inspiration:
>  it's long, it's messy, it requires a lot of effort from people doing
>  the work, and it's still not finished. Those are the downsides. But
>  the big upside is that we're not leaving users who need Xorg in the
>  ditch.
>  
>  A similar pattern should be followed here: encourage users to switch,
>  fix bugs so that $new is better than $old in all cases we care about,
>  iterate until the number of users on $old is negligible,
>  *then* announce that $old is not supported, but keep it working,
>  and only after that start cutting off parts of $old.
>  
>  The proposed plan seems to be to jump to the last two steps before the
>  middle parts have been done. Based on the examples posted to this
>  thread, it'd leave our users and developers with 10%–30% of hardware
>  unsupported by the next installer. It also depends on changes that are
>  only *planned* in external projects like VirtualBox and libvirt.
>  
>  Sorry, but the plan needs to be inverted to at least make sure that
>  the UEFI works for all the cloud providers and virtualization software
>  in a testable way, and then switch to UEFI as the default in as many
>  places as possible. Then we can talk about dropping support for BIOS,
>  taking into account how many users are still left with BIOS-only
>  hardware. 
FWMOIW this sounds like the most reasonable comment I have seen here.

The plan is nice, it is just trying to get to the end goal too fast,
more nuanced steps are necessary and more time.
Too many users would be left behind otherwise.

simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

[Neal Gompa]

On Thu, Apr 7, 2022 at 3:16 PM Simo Sorce <simo(a)redhat.com&gt; wrote:
>  On Thu, 2022-04-07 at 16:16 +0200, Zbigniew Jędrzejewski-Szmek wrote:
>  > On Thu, Apr 07, 2022 at 10:58:29AM +0200, Peter Boy wrote:
>  > >
>  > >
>  > > > Am 07.04.2022 um 00:25 schrieb Neal Gompa <ngompa13(a)gmail.com&gt;:
>  > > >
>  > > > It would be useful if we do indeed get a x86 BIOS SIG as Hans de Goede
>  > > > proposed. I think Fedora Server and Fedora Cloud would be interested
>  > > > in such a thing, given all the caveats right now with dropping BIOS
>  > > > support for server-class hardware.
>  > >
>  > > As the soul who currently coordinates and moderates the work of the Server WG,
> I would be very much in favor of such a SIG as a possible way out. If it's good
> enough, that is.
>  > >
>  > > Just coming up with the idea of removing the (new) installation of such a
> central part from one release to the next leaves me speechless. That's tens of
> thousands of devices / users affected and we don't even know how many tens of
> thousands. And then phrases like "..will remove it anyway". What else is there
> to say?
>  > >
>  > > I'm afraid just creating an x86 BIOS SIG is not sufficient anymore. We need
> a completely different spirit in this area.
>  > >
>  > > Don’t get me wrong. Lack of resources to maintain something is completely
> legitimate. But I expect more open-mindedness and willingness for constructive
> alternatives. And none of that is evident in the Change proposal, nor in the discussion
> here (by the change proposal authors).
>  > >
>  > > And it is OK for me to migrate to UEFI only in the long run. But not that way.
>  >
>  > This summarizes my feelings about the proposal very well.
>  >
>  > We should look to the Xorg → Wayland transition for inspiration:
>  > it's long, it's messy, it requires a lot of effort from people doing
>  > the work, and it's still not finished. Those are the downsides. But
>  > the big upside is that we're not leaving users who need Xorg in the
>  > ditch.
>  >
>  > A similar pattern should be followed here: encourage users to switch,
>  > fix bugs so that $new is better than $old in all cases we care about,
>  > iterate until the number of users on $old is negligible,
>  > *then* announce that $old is not supported, but keep it working,
>  > and only after that start cutting off parts of $old.
>  >
>  > The proposed plan seems to be to jump to the last two steps before the
>  > middle parts have been done. Based on the examples posted to this
>  > thread, it'd leave our users and developers with 10%–30% of hardware
>  > unsupported by the next installer. It also depends on changes that are
>  > only *planned* in external projects like VirtualBox and libvirt.
>  >
>  > Sorry, but the plan needs to be inverted to at least make sure that
>  > the UEFI works for all the cloud providers and virtualization software
>  > in a testable way, and then switch to UEFI as the default in as many
>  > places as possible. Then we can talk about dropping support for BIOS,
>  > taking into account how many users are still left with BIOS-only
>  > hardware.
>
>  FWMOIW this sounds like the most reasonable comment I have seen here.
>
>  The plan is nice, it is just trying to get to the end goal too fast,
>  more nuanced steps are necessary and more time.
>  Too many users would be left behind otherwise.
>  
I like Zbigniew's plan too! But I gotta ask, what is "FWMOIW"?




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

[Chris Murphy]

On Thu, Apr 7, 2022 at 12:20 AM Gerd Hoffmann <kraxel(a)redhat.com&gt; wrote:
>    Hi,
>
>  > On the cloud side, it's been very difficult to articulate any benefits
>  > for supporting UEFI when the majority of the consumers of Fedora Cloud
>  > don't have any pressing need to do it and things like hibernation and
>  > snapshotting are non-functional. Last year, I changed Fedora Cloud to
>  > hybrid boot[6] so that our image artifacts support both boot modes.
>
>  Any chance for regular anaconda installs doing a hybrid boot setup too? 
Anaconda is used for this purpose to make dual firmware supporting VM
images. Cloud edition does it, and it's also done within RHEL and
CentOS.

I would sooner expect optical boot support to go away before BIOS
boot. But I only have anecdotes to go on.

>  The installed systems will look pretty much the same (gpt with both
>  bios-boot and efi-esp partition) no matter how they where installed,
>  and it'll be trivial to switch from BIOS to UEFI without reinstalling
>  the system.
>
>  We can fade out some stuff already (mbr support), and painless switching
>  to UEFI for systems which where installed in BIOS mode for whatever
>  reason should also help UEFI adaption. 
There have been two prior attempts to move to GPT by default (i.e.
drop MBR by default when legacy BIOS is detected), and due to firmware
bugs, it never progressed to any Fedora release. I can't guess what
percent of hardware in the Fedora community is BIOS vs UEFI, and it's
even harder to estimate what percent of BIOS hardware are affected by
the GPT bug.

But I suppose that can being kicked down the road has also lead to the
pressure resulting in this change proposal. Hindsight being 20/20,
maybe moving to GPT by default would have been OK after all, because
those users could just boot the installer with inst.mbr. I'm not sure
whether it makes sense to deprecate this now though.



-- 
Chris Murphy

[Samuel Sieb]

On 4/7/22 08:02, Jared Dominguez wrote:
>  This is a proposal. Nothing has changed yet. The choice is now
> whether 
>  to go forward with it or come together with a cohesive 
>  alternative, including one of the two listed in the proposal. But we 
>  need a solution that accounts for the existing maintainers not having 
>  capacity to continue maintaining legacy code. I've seen responses from  
I haven't yet seen a clear answer about what code is "rotting" and which 
legacy code is too hard to maintain.  Is there something actually broken 
right now?

[Chris Murphy]

On Thu, Apr 7, 2022 at 2:54 AM Florian Weimer <fweimer(a)redhat.com&gt; wrote:
>  * Chris Murphy:
>
>  > On Tue, Apr 5, 2022 at 9:56 AM Florian Weimer <fweimer(a)redhat.com&gt; wrote:
>  >>
>  >> * Peter Robinson:
>  >>
>  >> > This is out of context here because you can disable Secure Boot but
>  >> > still use UEFI to make that work. You're trying to link to different
>  >> > problems together.
>  >>
>  >> I think there's firmware out there which enables Secure Boot
>  >> unconditionally in UEFI mode, but still has CSM support.
>  >
>  > The UEFI spec makes CSM and Secure Boot mutually exclusive. CSM
>  > enabled renders Secure Boot impossible. So I'm not sure how the
>  > firmware can simultaneously enforce Secure Boot, but then permit the
>  > loading of non-compliant bootloaders.
>
>  I meant that without CSM, Secure Boot is always enabled.  I don't know
>  if Fedora UEFI installations work on such systems when CSM is enabled. 
CSM enabled systems get a BIOS GRUB installation just as if it was a
system without UEFI. The system gets an MBR, GRUB boot code in MBR,
GRUB stage 2 in the MBR gap, etc.


-- 
Chris Murphy

[Demi Marie Obenour]

On 4/7/22 08:52, Vitaly Zaitsev via devel wrote:
>  On 05/04/2022 17:44, Neal Gompa wrote:
> > It is easier to tell people to boot the media in BIOS mode in some
> > cases than it is to figure out how to turn off Secure Boot.
>  
>  Legacy boot on modern hardware is a hack[1]. Some hardware manufactures 
>  even doesn't test CSM support. 
Modern *physical* hardware.  *Virtual* hardware is another matter entirely.

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[Demi Marie Obenour]

On 4/6/22 16:17, Neal Gompa wrote:
>  On Wed, Apr 6, 2022 at 4:09 PM Demi Marie Obenour
> <demiobenour(a)gmail.com&gt; wrote:
> >
> > On 4/6/22 06:43, Neal Gompa wrote:
> >> On Wed, Apr 6, 2022 at 12:04 AM Gary Buhrmaster
> >> <gary.buhrmaster(a)gmail.com&gt; wrote:
> >>>
> >>> On Wed, Apr 6, 2022 at 12:59 AM Demi Marie Obenour
> >>> <demiobenour(a)gmail.com&gt; wrote:
> >>>>
> >>>> On 4/5/22 19:38, Chris Murphy wrote:
> >>>>> We either want users with NVIDIA hardware to be inside the Secure
> Boot
> >>>>> fold or we don't. I want them in the fold *despite* the driver
> that
> >>>>> needs signing is proprietary. That's a better user experience
> across
> >>>>> the board, including the security messaging is made consistent. The
> >>>>> existing policy serves no good at all and is double talk. If we
> really
> >>>>> care about security more than ideological worry, we'd sign the
> driver.
> >>>>
> >>>> I agree with this.  Sign the driver.
> >>>
> >>> Nvidia has their driver signed for their
> >>> Windows drivers.  That they choose
> >>> not to do so for Linux is their right,
> >>> even if some wish they did.
> >>>
> >>> It should be noted that while many
> >>> might wish nvidia chose a different
> >>> way, that is completely orthogonal
> >>> to bios vs uefi.
> >>
> >> Linux, like Windows, requires the distribution vendor to sign modules
> >> for automatic trust. There are a number of complicated issues that
> >> make it difficult for us to sign this particular driver, though.
> >> Notably, NVIDIA themselves acknowledges that it infringes on the GPL
> >> to redistribute built kernel module blobs of nvidia.ko[1], so that means
> >> any method of signing it needs to be done locally, which means we
> >> *need* the local signing path to be improved.
> >>
> >> [1]: https://imgur.com/LUCQ3WW
> >
> > Can we get NVIDIA to make the module build reproducible?  If so, we
> > could distribute a detached signature.
> >
>  
>  Outside of RHEL (which they already do this for), it is not
>  technically feasible to do so. The mainline Linux kernel lacks a kABI
>  and symbol churn happens constantly. The modules have to be built
>  completely from source every time, dealing with kernel churn making
>  the resulting files different every time. 
Are they different *per-user*, or only *per-kernel-version*?

If the latter, one could create signatures for every (driver version,
kernel version) combo.

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[Florian Weimer]

* Chris Murphy:

>  On Thu, Apr 7, 2022 at 2:54 AM Florian Weimer
> <fweimer(a)redhat.com&gt; wrote:
> >
> > * Chris Murphy:
> >
> > > On Tue, Apr 5, 2022 at 9:56 AM Florian Weimer <fweimer(a)redhat.com&gt; wrote:
> > >>
> > >> * Peter Robinson:
> > >>
> > >> > This is out of context here because you can disable Secure Boot but
> > >> > still use UEFI to make that work. You're trying to link to
> different
> > >> > problems together.
> > >>
> > >> I think there's firmware out there which enables Secure Boot
> > >> unconditionally in UEFI mode, but still has CSM support.
> > >
> > > The UEFI spec makes CSM and Secure Boot mutually exclusive. CSM
> > > enabled renders Secure Boot impossible. So I'm not sure how the
> > > firmware can simultaneously enforce Secure Boot, but then permit the
> > > loading of non-compliant bootloaders.
> >
> > I meant that without CSM, Secure Boot is always enabled.  I don't know
> > if Fedora UEFI installations work on such systems when CSM is enabled.
>
>  CSM enabled systems get a BIOS GRUB installation just as if it was a
>  system without UEFI. The system gets an MBR, GRUB boot code in MBR,
>  GRUB stage 2 in the MBR gap, etc. 
Okay, then Secure Boot is mandatory on these systems as far as Fedora is
concerned once Fedora removes BIOS support, just as I suspected.

Thanks,
Florian

[Chris Murphy]

On Thu, Apr 7, 2022 at 8:28 AM Lennart Poettering <mzerqung(a)0pointer.de&gt; wrote:
>  On Di, 05.04.22 17:38, Chris Murphy (lists(a)colorremedies.com) wrote:
>
>  > When users have a suboptimal experience by default, it makes Fedora
>  > look bad. We can't have security concerns overriding all other
>  > concerns. But it's really pernicious to simultaneously say security is
>  > important, but we're also not going to sign proprietary drivers. This
>  > highly incentivizes the user to disable Secure Boot because that's so
>  > much easier than users signing kernel modules and enrolling keys with
>  > the firmware, and therefore makes the user *less safe*.
>
>  Let me stress one thing though: Fedora *has* *no* working SecureBoot
>  implementation. The initrd is not authenticated. It has no signatures,
>  nothing.
>
>  By disabling SecureBoot you effectively lose exactly nothing in terms
>  of security right now.
>
>  What good is a trusted boot loader or kernel if it then goes on
>  loading an initrd that is not authenticated, super easy to modify (I
>  mean, seriously, any idiot script kiddie can unpack a cpio, add some
>  shell script and pack it up again, replacing the original one) – and
>  it's the component that actually reads your FDE LUKS password.
>
>  I mean, let's not pretend unsigned drivers were a big issue for
>  security right now. They are now, we have much much much wider gaping
>  holes in our stack. 
I agree that the lack of a signed initrd is a big gaping hole. I don't
agree it's pointless to ensure the bootloader, kernel and kernel
modules are authentic. It's bad to have malware running in user space.
It's extra bad if it's running in kernel space. There are examples of
such malware, including lie in wait, that can embed maleware into SPI
flash once Secure Boot is disabled. Even if you were to discover this
(difficult considering most vendors aren't publishing hashes of their
firmware) you'd basically be screwed, not even replacing the boot
drive would get rid of it.


-- 
Chris Murphy

[Chris Murphy]

On Thu, Apr 7, 2022 at 10:04 AM Jared Dominguez <jaredz(a)redhat.com&gt; wrote:
>  Microsoft has required since Windows 8 (released in 2012) that any systems that are
> certified with Windows must ship with UEFI by default 
The Windows Hardware Certification Program is a marketing program. If
you want to say things like "made for windows 8" in your product, you
have to comply with their requirements. And the requirements differ by
years for Windows and Windows Server. I don't know the breakdown but
quite a lot of hardware products don't participate in this program,
and thus aren't bound to it.


-- 
Chris Murphy

[Nícolas Wildner]

>  On Di, 05.04.22 17:38, Chris Murphy (lists(a)colorremedies.com)
> wrote:
>  
>  
>  Let me stress one thing though: Fedora *has* *no* working SecureBoot
>  implementation. The initrd is not authenticated. It has no signatures,
>  nothing.
>  
>  By disabling SecureBoot you effectively lose exactly nothing in terms
>  of security right now.
>  
>  What good is a trusted boot loader or kernel if it then goes on
>  loading an initrd that is not authenticated, super easy to modify (I
>  mean, seriously, any idiot script kiddie can unpack a cpio, add some
>  shell script and pack it up again, replacing the original one) – and
>  it's the component that actually reads your FDE LUKS password.
>  
>  I mean, let's not pretend unsigned drivers were a big issue for
>  security right now. They are now, we have much much much wider gaping
>  holes in our stack.
>  
>  Lennart
>  
>  --
>  Lennart Poettering, Berlin 

To achieve such feature(SecureBoot signer Unified Images) I've had to make some
hack'ish scripts to run dracut a second time glueing all together and signing it,
after generating the initrd inside /boot:

     - https://nwildner.com/posts/2021-04-10-secureboot-fedora/

Not proud of it, but it works(and I have cmdline + initrd + kernel + modules all signed as
a bundle). 

This could be the spark of a package idea for Unified images

nwildner

[Simo Sorce]

On Thu, 2022-04-07 at 15:26 -0400, Neal Gompa wrote:
>  On Thu, Apr 7, 2022 at 3:16 PM Simo Sorce <simo(a)redhat.com&gt;
> wrote:
>  > 
>  > On Thu, 2022-04-07 at 16:16 +0200, Zbigniew Jędrzejewski-Szmek wrote:
>  > > On Thu, Apr 07, 2022 at 10:58:29AM +0200, Peter Boy wrote:
>  > > > 
>  > > > 
>  > > > > Am 07.04.2022 um 00:25 schrieb Neal Gompa
> <ngompa13(a)gmail.com&gt;:
>  > > > > 
>  > > > > It would be useful if we do indeed get a x86 BIOS SIG as Hans de
> Goede
>  > > > > proposed. I think Fedora Server and Fedora Cloud would be interested
>  > > > > in such a thing, given all the caveats right now with dropping BIOS
>  > > > > support for server-class hardware.
>  > > > 
>  > > > As the soul who currently coordinates and moderates the work of the Server
> WG, I would be very much in favor of such a SIG as a possible way out. If it's good
> enough, that is.
>  > > > 
>  > > > Just coming up with the idea of removing the (new) installation of such a
> central part from one release to the next leaves me speechless. That's tens of
> thousands of devices / users affected and we don't even know how many tens of
> thousands. And then phrases like "..will remove it anyway". What else is there
> to say?
>  > > > 
>  > > > I'm afraid just creating an x86 BIOS SIG is not sufficient anymore. We
> need a completely different spirit in this area.
>  > > > 
>  > > > Don’t get me wrong. Lack of resources to maintain something is completely
> legitimate. But I expect more open-mindedness and willingness for constructive
> alternatives. And none of that is evident in the Change proposal, nor in the discussion
> here (by the change proposal authors).
>  > > > 
>  > > > And it is OK for me to migrate to UEFI only in the long run. But not that
> way.
>  > > 
>  > > This summarizes my feelings about the proposal very well.
>  > > 
>  > > We should look to the Xorg → Wayland transition for inspiration:
>  > > it's long, it's messy, it requires a lot of effort from people doing
>  > > the work, and it's still not finished. Those are the downsides. But
>  > > the big upside is that we're not leaving users who need Xorg in the
>  > > ditch.
>  > > 
>  > > A similar pattern should be followed here: encourage users to switch,
>  > > fix bugs so that $new is better than $old in all cases we care about,
>  > > iterate until the number of users on $old is negligible,
>  > > *then* announce that $old is not supported, but keep it working,
>  > > and only after that start cutting off parts of $old.
>  > > 
>  > > The proposed plan seems to be to jump to the last two steps before the
>  > > middle parts have been done. Based on the examples posted to this
>  > > thread, it'd leave our users and developers with 10%–30% of hardware
>  > > unsupported by the next installer. It also depends on changes that are
>  > > only *planned* in external projects like VirtualBox and libvirt.
>  > > 
>  > > Sorry, but the plan needs to be inverted to at least make sure that
>  > > the UEFI works for all the cloud providers and virtualization software
>  > > in a testable way, and then switch to UEFI as the default in as many
>  > > places as possible. Then we can talk about dropping support for BIOS,
>  > > taking into account how many users are still left with BIOS-only
>  > > hardware.
>  > 
>  > FWMOIW this sounds like the most reasonable comment I have seen here.
>  > 
>  > The plan is nice, it is just trying to get to the end goal too fast,
>  > more nuanced steps are necessary and more time.
>  > Too many users would be left behind otherwise.
>  > 
>  
>  I like Zbigniew's plan too! But I gotta ask, what is "FWMOIW"? 
For What My Opinion Is Worth :-)


>  
>  
>  
>  --
>  真実はいつも一つ！/ Always, there's only one truth!
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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
-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

[Jared Dominguez]

On Thu, Apr 7, 2022 at 4:18 PM Florian Weimer <fweimer(a)redhat.com&gt; wrote:

>  * Chris Murphy:
>
>  > On Thu, Apr 7, 2022 at 2:54 AM Florian Weimer <fweimer(a)redhat.com&gt;
>  wrote:
>  >>
>  >> * Chris Murphy:
>  >>
>  >> > On Tue, Apr 5, 2022 at 9:56 AM Florian Weimer <fweimer(a)redhat.com&gt;
>  wrote:
>  >> >>
>  >> >> * Peter Robinson:
>  >> >>
>  >> >> > This is out of context here because you can disable Secure Boot
> but
>  >> >> > still use UEFI to make that work. You're trying to link to
>  different
>  >> >> > problems together.
>  >> >>
>  >> >> I think there's firmware out there which enables Secure Boot
>  >> >> unconditionally in UEFI mode, but still has CSM support.
>  >> >
>  >> > The UEFI spec makes CSM and Secure Boot mutually exclusive. CSM
>  >> > enabled renders Secure Boot impossible. So I'm not sure how the
>  >> > firmware can simultaneously enforce Secure Boot, but then permit the
>  >> > loading of non-compliant bootloaders.
>  >>
>  >> I meant that without CSM, Secure Boot is always enabled.  I don't know
>  >> if Fedora UEFI installations work on such systems when CSM is enabled.
>  >
>  > CSM enabled systems get a BIOS GRUB installation just as if it was a
>  > system without UEFI. The system gets an MBR, GRUB boot code in MBR,
>  > GRUB stage 2 in the MBR gap, etc.
>
>  Okay, then Secure Boot is mandatory on these systems as far as Fedora is
>  concerned once Fedora removes BIOS support, just as I suspected.
>  
There are some Acer systems that make it harder to disable secure boot, but
it's still possible. I've not heard of cases where you cannot at all
disable secure boot.


>  Thanks,
>  Florian
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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
>  

-- 
Jared Dominguez (he/him)
Software Engineering Manager
New Platform Technologies Enablement team
RHEL Workstation Engineering

If I am emailing outside of business hours (mine or yours), it is my choice
and does not mean I expect you to respond today.

[Jared Dominguez]

On Thu, Apr 7, 2022 at 3:49 PM Samuel Sieb <samuel(a)sieb.net&gt; wrote:

>  On 4/7/22 08:02, Jared Dominguez wrote:
>  > This is a proposal. Nothing has changed yet. The choice is now whether
>  > to go forward with it or come together with a cohesive
>  > alternative, including one of the two listed in the proposal. But we
>  > need a solution that accounts for the existing maintainers not having
>  > capacity to continue maintaining legacy code. I've seen responses from
>
>  I haven't yet seen a clear answer about what code is "rotting" and which
>  legacy code is too hard to maintain.  Is there something actually broken
>  right now?
>  
For one, syslinux hasn't seen an update in 3 years and a release in 7
years, and it has outstanding bugs. Legacy boot isn't where grub2 is
getting development attention. The current maintainers in Fedora won't have
capacity to continue maintaining legacy boot support in Fedora. As grub2
continues to be developed for UEFI systems (ARMv8-9 and x86-64, not to
mention non-UEFI ppc64le and s390x), there is added risk of regressions on
legacy x86 boot that won't be getting developer attention.


>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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
>  

-- 
Jared Dominguez (he/him)
Software Engineering Manager
New Platform Technologies Enablement team
RHEL Workstation Engineering

[Peter Robinson]

> > >> >> > This is out of context here because you
> can disable Secure Boot but
> > >> >> > still use UEFI to make that work. You're trying to link to
> different
> > >> >> > problems together.
> > >> >>
> > >> >> I think there's firmware out there which enables Secure Boot
> > >> >> unconditionally in UEFI mode, but still has CSM support.
> > >> >
> > >> > The UEFI spec makes CSM and Secure Boot mutually exclusive. CSM
> > >> > enabled renders Secure Boot impossible. So I'm not sure how the
> > >> > firmware can simultaneously enforce Secure Boot, but then permit the
> > >> > loading of non-compliant bootloaders.
> > >>
> > >> I meant that without CSM, Secure Boot is always enabled.  I don't know
> > >> if Fedora UEFI installations work on such systems when CSM is enabled.
> > >
> > > CSM enabled systems get a BIOS GRUB installation just as if it was a
> > > system without UEFI. The system gets an MBR, GRUB boot code in MBR,
> > > GRUB stage 2 in the MBR gap, etc.
> >
> > Okay, then Secure Boot is mandatory on these systems as far as Fedora is
> > concerned once Fedora removes BIOS support, just as I suspected.
>
>
>  There are some Acer systems that make it harder to disable secure boot, but it's
> still possible. I've not heard of cases where you cannot at all disable secure boot.
On the systems, if there are any, that don't allow disabling of
secure-boot, they definitely wouldn't allow disabling UEFI either,
UEFI and secure boot are necessarily mutually exclusive, but a system
that won't allow you to disable secure-boot definitely wouldn't
support BIOS either.

[Matthew Miller]

On Thu, Apr 07, 2022 at 03:43:07PM +0100, Richard W.M. Jones wrote:
>  Clover is described here:
>  https://github.com/CloverHackyColor/CloverBootloader 
This is interesting. Seems like considerable up-front work, but a much
cleaner possible future than completely dual paths.

Are there docs on this somewhere other than the Arch wiki? (Which, as usual,
is very helpful!) -- https://wiki.archlinux.org/title/Clover




-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Neal Gompa]

On Thu, Apr 7, 2022 at 6:05 PM Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  On Thu, Apr 07, 2022 at 03:43:07PM +0100, Richard W.M. Jones wrote:
>  > Clover is described here:
>  > https://github.com/CloverHackyColor/CloverBootloader
>
>  This is interesting. Seems like considerable up-front work, but a much
>  cleaner possible future than completely dual paths.
>
>  Are there docs on this somewhere other than the Arch wiki? (Which, as usual,
>  is very helpful!) -- https://wiki.archlinux.org/title/Clover
>  
I don't think so? Some of the information for using DUET (which Clover
is descended from) from the rEFInd developer might be useful, though:
http://www.rodsbooks.com/bios2uefi/index.html

(As an aside, the rEFInd developer, Rod Smith, has a huge trove of
user experience EFI documentation on his site!)




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

[Gregory Bartholomew]

On Thu, Apr 7, 2022 at 5:05 PM Matthew Miller <mattdm(a)fedoraproject.org&gt;
wrote:

>  On Thu, Apr 07, 2022 at 03:43:07PM +0100, Richard W.M. Jones wrote:
>  > Clover is described here:
>  > https://github.com/CloverHackyColor/CloverBootloader
>
>  This is interesting. Seems like considerable up-front work, but a much
>  cleaner possible future than completely dual paths.
>  
I like it! I especially like that it combines all the bootloader code,
up-to and including the initramfs, under one /boot partition. Please don't
change that. I have many systems set up that way already and I think I
could drop this on them *very* easily.

Just my 2¢.

[Fabio Valentini]

On Tue, Apr 5, 2022 at 4:54 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
>
>  == Summary ==
>  Make UEFI a hardware requirement for new Fedora installations on
>  platforms that support it (x86_64).  Legacy BIOS support is not
>  removed, but new non-UEFI installation is not supported on those
>  platforms.  This is a first step toward eventually removing legacy
>  BIOS support entirely. 
I personally find the wording here extremely confusing, to the point
where it might be classified as misleading.
Usually, to "deprecate" something means that users get a grace period
where they will be warned that the thing they're using will go away at
some point in the future, and that it should no longer be used, if
possible.

However, with the current proposal, you're *already removing* the
ability to install Fedora in "non-UEFI mode". There would be zero
grace period in which users would be warned "hey, you're using the
installer for the old method, you might want to do it the new way
instead".

As far as I see, with this proposal, the only "direct" way to get a
F37+ non-UEFI system would be by upgrading from a previous release of
Fedora?
But users who do that would not receive any "hey, you installed your
system in BIOS mode, this might not be supported for much longer, we
recommend reinstalling it in UEFI mode, if possible" warning, either.

I also agree with other FESCo members who have chimed in in this
thread: It seems too early to pull the plug here. If this was a "real"
deprecation, with grace period and scary warning dialogs for users who
still end up booting in BIOS mode, I'd be sympathetic to that. But in
my opinion, this proposal as it is seems too aggressive at this point
in time.

Fabio

[Demi Marie Obenour]

On 4/7/22 15:30, Chris Murphy wrote:
>  On Thu, Apr 7, 2022 at 12:20 AM Gerd Hoffmann
> <kraxel(a)redhat.com&gt; wrote:
> >
> >   Hi,
> >
> >> On the cloud side, it's been very difficult to articulate any benefits
> >> for supporting UEFI when the majority of the consumers of Fedora Cloud
> >> don't have any pressing need to do it and things like hibernation and
> >> snapshotting are non-functional. Last year, I changed Fedora Cloud to
> >> hybrid boot[6] so that our image artifacts support both boot modes.
> >
> > Any chance for regular anaconda installs doing a hybrid boot setup too?
>  
>  Anaconda is used for this purpose to make dual firmware supporting VM
>  images. Cloud edition does it, and it's also done within RHEL and
>  CentOS.
>  
>  I would sooner expect optical boot support to go away before BIOS
>  boot. But I only have anecdotes to go on.
>  
> >
> > The installed systems will look pretty much the same (gpt with both
> > bios-boot and efi-esp partition) no matter how they where installed,
> > and it'll be trivial to switch from BIOS to UEFI without reinstalling
> > the system.
> >
> > We can fade out some stuff already (mbr support), and painless switching
> > to UEFI for systems which where installed in BIOS mode for whatever
> > reason should also help UEFI adaption.
>  
>  There have been two prior attempts to move to GPT by default (i.e.
>  drop MBR by default when legacy BIOS is detected), and due to firmware
>  bugs, it never progressed to any Fedora release. I can't guess what
>  percent of hardware in the Fedora community is BIOS vs UEFI, and it's
>  even harder to estimate what percent of BIOS hardware are affected by
>  the GPT bug. 
Can the disk be partitioned so that it is valid for *both* MBR and GPT?

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[Chris Murphy]

On Thu, Apr 7, 2022 at 2:36 PM Chris Murphy <lists(a)colorremedies.com&gt; wrote:

>  The Windows Hardware Certification Program is a marketing program.
> If
>  you want to say things like "made for windows 8" in your product, you
>  have to comply with their requirements. And the requirements differ by
>  years for Windows and Windows Server. I don't know the breakdown but
>  quite a lot of hardware products don't participate in this program,
>  and thus aren't bound to it. 
https://docs.microsoft.com/en-us/windows-hardware/design/compatibility/wh...
Windows Server 2019, version 1809 (release date 2018)

p88, System.Fundamentals.Firmware.UEFICompatibility
- All systems, except servers, must be certified in UEFI mode without
activating CSM.
- For server, certification in UEFI mode is only required if UEFI is
implemented.
- OEMs may ship with CSM mode activated and the enterprise or
government customer's licensed OS selection when requested.

System.Fundamentals.Firmware.UEFIDefaultBoot
...
This requirement is "If Implemented" for Server systems.

Starting with version 2004 (still Windows 10 / Windows Server 2019),
released in 2020 the server exception for requiring UEFI is removed,
but it's still not required to be enabled by default. I would not be
surprised if certified server hardware were shipping in 2020 without
UEFI.


-- 
Chris Murphy

[Neal Gompa]

On Thu, Apr 7, 2022 at 7:10 PM Demi Marie Obenour <demiobenour(a)gmail.com&gt; wrote:
>  On 4/7/22 15:30, Chris Murphy wrote:
>  > On Thu, Apr 7, 2022 at 12:20 AM Gerd Hoffmann <kraxel(a)redhat.com&gt; wrote:
>  >>
>  >>   Hi,
>  >>
>  >>> On the cloud side, it's been very difficult to articulate any benefits
>  >>> for supporting UEFI when the majority of the consumers of Fedora Cloud
>  >>> don't have any pressing need to do it and things like hibernation and
>  >>> snapshotting are non-functional. Last year, I changed Fedora Cloud to
>  >>> hybrid boot[6] so that our image artifacts support both boot modes.
>  >>
>  >> Any chance for regular anaconda installs doing a hybrid boot setup too?
>  >
>  > Anaconda is used for this purpose to make dual firmware supporting VM
>  > images. Cloud edition does it, and it's also done within RHEL and
>  > CentOS.
>  >
>  > I would sooner expect optical boot support to go away before BIOS
>  > boot. But I only have anecdotes to go on.
>  >
>  >>
>  >> The installed systems will look pretty much the same (gpt with both
>  >> bios-boot and efi-esp partition) no matter how they where installed,
>  >> and it'll be trivial to switch from BIOS to UEFI without reinstalling
>  >> the system.
>  >>
>  >> We can fade out some stuff already (mbr support), and painless switching
>  >> to UEFI for systems which where installed in BIOS mode for whatever
>  >> reason should also help UEFI adaption.
>  >
>  > There have been two prior attempts to move to GPT by default (i.e.
>  > drop MBR by default when legacy BIOS is detected), and due to firmware
>  > bugs, it never progressed to any Fedora release. I can't guess what
>  > percent of hardware in the Fedora community is BIOS vs UEFI, and it's
>  > even harder to estimate what percent of BIOS hardware are affected by
>  > the GPT bug.
>
>  Can the disk be partitioned so that it is valid for *both* MBR and GPT?
>  
There are two options here: protective MBR and hybrid MBR.

Protective MBRs are well-supported and I believe created by default
when you create a GPT partitioning scheme for BIOS systems already
with Anaconda. I think it's done with UEFI as well, but if not, we can
certainly force it.

The second option is known as hybrid MBR. The gdisk utility can create
them: https://www.rodsbooks.com/gdisk/hybrid.html

Needless to say, it's... interesting... I'm not sure if more tools
support hybrid MBRs since this was last refreshed in 2019.

It's also kinda scary and not really necessary unless you need to
interoperate with OSes that expect MBR in a mixed BIOS+UEFI boot
setup.






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

[Chris Murphy]

On Thu, Apr 7, 2022 at 4:50 PM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  On Tue, Apr 5, 2022 at 4:54 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  >
>  > https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
>  >
>  > == Summary ==
>  > Make UEFI a hardware requirement for new Fedora installations on
>  > platforms that support it (x86_64).  Legacy BIOS support is not
>  > removed, but new non-UEFI installation is not supported on those
>  > platforms.  This is a first step toward eventually removing legacy
>  > BIOS support entirely.
>
>  I personally find the wording here extremely confusing, to the point
>  where it might be classified as misleading.
>  Usually, to "deprecate" something means that users get a grace period
>  where they will be warned that the thing they're using will go away at
>  some point in the future, and that it should no longer be used, if
>  possible. 
Yes, the word deprecate needs to be removed.

The reason why it's not worth arguing about is because there's no
argument to be made for using this term. It's simply incorrect both in
terms of etymology, but also how it gets used in the industry.
Deprecation means "to express disapproval of" that's it. A circle is
not a square, and saying it's not worth arguing about is absolutely
true because no one can argue they're equivalent, even approximately.



-- 
Chris Murphy

[Chris Murphy]

On Thu, Apr 7, 2022 at 5:21 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  On Thu, Apr 7, 2022 at 7:10 PM Demi Marie Obenour <demiobenour(a)gmail.com&gt; wrote:
>  > Can the disk be partitioned so that it is valid for *both* MBR
> and GPT?
>  >
>
>  There are two options here: protective MBR and hybrid MBR.
>
>  Protective MBRs are well-supported and I believe created by default
>  when you create a GPT partitioning scheme for BIOS systems already
>  with Anaconda. I think it's done with UEFI as well, but if not, we can
>  certainly force it.
>
>  The second option is known as hybrid MBR. The gdisk utility can create
>  them: https://www.rodsbooks.com/gdisk/hybrid.html
>
>  Needless to say, it's... interesting... I'm not sure if more tools
>  support hybrid MBRs since this was last refreshed in 2019.
>
>  It's also kinda scary and not really necessary unless you need to
>  interoperate with OSes that expect MBR in a mixed BIOS+UEFI boot
>  setup. 
Strictly speaking per the UEFI spec, hybrid MBR's don't exist.
Creating such a thing means it's really MBR and the GPT is invalid,
and it requires all software to treat it as such. The only valid MBR
with a valid GPT, is a protective MBR (PMBR) which is defined as
having one partition the size of the device or the maximum size
supported by MBR if the device is bigger.


-- 
Chris Murphy

[Samuel Sieb]

On 4/7/22 14:51, Jared Dominguez wrote:
>  On Thu, Apr 7, 2022 at 3:49 PM Samuel Sieb <samuel(a)sieb.net 
>  <mailto:[e-mail]>> wrote:
>  
>      On 4/7/22 08:02, Jared Dominguez wrote:
>       > This is a proposal. Nothing has changed yet. The choice is now
>      whether
>       > to go forward with it or come together with a cohesive
>       > alternative, including one of the two listed in the proposal. But we
>       > need a solution that accounts for the existing maintainers not
>      having
>       > capacity to continue maintaining legacy code. I've seen responses
>      from
>  
>      I haven't yet seen a clear answer about what code is "rotting" and
>      which
>      legacy code is too hard to maintain.  Is there something actually
>      broken
>      right now?
>  
>  
>  For one, syslinux hasn't seen an update in 3 years and a release in 7 
>  years, and it has outstanding bugs. Legacy boot isn't where grub2 is 
>  getting development attention. The current maintainers in Fedora won't 
>  have capacity to continue maintaining legacy boot support in Fedora. As 
>  grub2 continues to be developed for UEFI systems (ARMv8-9 and x86-64, 
>  not to mention non-UEFI ppc64le and s390x), there is added risk of 
>  regressions on legacy x86 boot that won't be getting developer attention. 
I don't understand why we're still using syslinux instead of grub for 
legacy boots, especially since I think now you can use the same grub.cfg 
file for both.  There is always a risk of regressions, but if there is 
no current problem, then why is there this push to obsolete a lot of 
active hardware?  This is not comparable to the 32-bit removal where it 
was only a few really old systems.  This is going to affect decent 
systems that are less than 10 years old.  I have a work HP laptop from 
2012 that has "experimental" EFI support that really doesn't work well 
and possibly a newer one as well, but I can't check it right now.

[Chris Murphy]

On Thu, Apr 7, 2022 at 5:35 PM Samuel Sieb <samuel(a)sieb.net&gt; wrote:
>  On 4/7/22 14:51, Jared Dominguez wrote:
>  > On Thu, Apr 7, 2022 at 3:49 PM Samuel Sieb <samuel(a)sieb.net
>  > <mailto:[e-mail]>> wrote:
>  >
>  >     On 4/7/22 08:02, Jared Dominguez wrote:
>  >      > This is a proposal. Nothing has changed yet. The choice is now
>  >     whether
>  >      > to go forward with it or come together with a cohesive
>  >      > alternative, including one of the two listed in the proposal. But we
>  >      > need a solution that accounts for the existing maintainers not
>  >     having
>  >      > capacity to continue maintaining legacy code. I've seen responses
>  >     from
>  >
>  >     I haven't yet seen a clear answer about what code is "rotting"
> and
>  >     which
>  >     legacy code is too hard to maintain.  Is there something actually
>  >     broken
>  >     right now?
>  >
>  >
>  > For one, syslinux hasn't seen an update in 3 years and a release in 7
>  > years, and it has outstanding bugs. Legacy boot isn't where grub2 is
>  > getting development attention. The current maintainers in Fedora won't
>  > have capacity to continue maintaining legacy boot support in Fedora. As
>  > grub2 continues to be developed for UEFI systems (ARMv8-9 and x86-64,
>  > not to mention non-UEFI ppc64le and s390x), there is added risk of
>  > regressions on legacy x86 boot that won't be getting developer attention.
>
>  I don't understand why we're still using syslinux instead of grub for
>  legacy boots, especially since I think now you can use the same grub.cfg
>  file for both. 
syslinux (really isolinux) is only used on installation media.

This comment from 2012 suggests we probably should have dropped
isolinux in favor of BIOS GRUB a while ago, but c'est la vie. I think
it's in scope to exchange syslinux for GRUB in the F37 cycle, pending
review of the effort required to do it.
https://mjg59.dreamwidth.org/11285.html?thread=345621#cmt345621


>  There is always a risk of regressions, but if there is
>  no current problem, then why is there this push to obsolete a lot of
>  active hardware?  This is not comparable to the 32-bit removal where it
>  was only a few really old systems.  This is going to affect decent
>  systems that are less than 10 years old.  I have a work HP laptop from
>  2012 that has "experimental" EFI support that really doesn't work well
>  and possibly a newer one as well, but I can't check it right now. 

Given that Microsoft has had an exception for UEFI being required on
server hardware up until barely two years ago, I suspect RHEL folks
are going to have customers asking for reconsideration.


-- 
Chris Murphy

[Chris Adams]

Once upon a time, Chris Murphy <lists(a)colorremedies.com&gt; said:
>  syslinux (really isolinux) is only used on installation media.
It's commonly used for BIOS PXE booting as well.

-- 
Chris Adams <linux(a)cmadams.net&gt;

[Randy Barlow]

On Thu, 2022-04-07 at 17:02 -0400, Simo Sorce wrote:
>  > I like Zbigniew's plan too! But I gotta ask, what is
> "FWMOIW"?
>  
>  For What My Opinion Is Worth :-) 
I also hadn't seen this acronym, but I was hoping it was going to be
some kind of cipher since Simo works on the crypto team ☺

[Neal Gompa]

On Thu, Apr 7, 2022 at 9:21 PM Chris Adams <linux(a)cmadams.net&gt; wrote:
>  Once upon a time, Chris Murphy <lists(a)colorremedies.com&gt; said:
>  > syslinux (really isolinux) is only used on installation media.
>
>  It's commonly used for BIOS PXE booting as well.
>  
*shudders at the memories of dealing with pxelinux*

GRUB is way better for that. Yes, you can use GRUB for PXE and UEFI netboot too.



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

[Gary Buhrmaster]

On Thu, Apr 7, 2022 at 10:05 PM Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  On Thu, Apr 07, 2022 at 03:43:07PM +0100, Richard W.M. Jones wrote:
>  > Clover is described here:
>  > https://github.com/CloverHackyColor/CloverBootloader
>
>  This is interesting. Seems like considerable up-front work, but a much
>  cleaner possible future than completely dual paths. 
On my (still countably) infinite TODO list I had
an item on it to spend more time looking at
Clover to be able to boot (in UEFI mode) one
of my older BIOS only Core 2 duo quad systems
that I had picked up for pennies on the dollar
at a local surplus store.  At this point it is a
question of whether I will find the time to do
so or the system itself will finally die.  Since
the original placement (on my list), the Clover
devs have substantially improved it to the
point that a lot of the rough edges have been
mitigated, although given all the various
implementations of BIOS's there are still
going to be edge cased (just as there are
still rough edges with UEFI, especially the
earliest implementations).

>  Are there docs on this somewhere other than the Arch wiki? (Which, as
> usual,
>  is very helpful!) -- https://wiki.archlinux.org/title/Clover 
As is typically the case, the Arch wiki is better
than almost all other available docs.

[Neal Gompa]

On Wed, Apr 6, 2022 at 6:06 PM Brian C. Lane <bcl(a)redhat.com&gt; wrote:
>  On Tue, Apr 05, 2022 at 06:50:39PM -0600, Chris Murphy wrote:
>  > On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  > >syslinux goes away entirely
>  >
>  > If the installation media used BIOS GRUB, syslinux could still go
>  > away. What consideration has occurred to switch from syslinux to BIOS
>  > GRUB for installation media? Is BIOS GRUB being deprecated? Or is it
>  > being discontinued in Fedora?
>
>  A bit, long time time ago. I *think* wwoods and I discussed this at a
>  fudcon at one point but there were reasons not to do it. But since I can
>  no longer remember them I'll take a look again :)
>  
In case you're interested in prior art:

* kiwi's code:
https://github.com/OSInside/kiwi/blob/master/kiwi/bootloader/config/grub2.py
* drakiso's code:
http://gitweb.mageia.org/software/build-system/drakiso/tree/lib/MGA/DrakI...

The two above are from openSUSE and Mageia respectively, who have
both made this change for their distributions.





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

[Chris Murphy]

On Thu, Apr 7, 2022 at 7:15 PM Chris Murphy <lists(a)colorremedies.com&gt; wrote:

>  syslinux (really isolinux) is only used on installation media.
>
>  This comment from 2012 suggests we probably should have dropped
>  isolinux in favor of BIOS GRUB a while ago, but c'est la vie. I think
>  it's in scope to exchange syslinux for GRUB in the F37 cycle, pending
>  review of the effort required to do it.
>  https://mjg59.dreamwidth.org/11285.html?thread=345621#cmt345621 
Add this to the retrospective reading
https://mjg59.dreamwidth.org/4957.html

And for status of optical media in Fedora (tl;dr is optical boot must
work for Everything and Workstation ISOs, but there is no requirement
to test them, ergo if someone tests and finds it doesn't work, it
blocks; if no one tests it, oops oh well!)
https://docs.fedoraproject.org/en-US/releases/f36/blocking/
https://fedoraproject.org/wiki/Changes/Drop_Optical_Media_Criterion

For what it's worth, the current xorriso command used to make most of
our ISO images (hybrid images that can boot most everything whether
PXE, Macs, UEFI or BIOS, USB stick or optical) is

xorrisofs -o /var/tmp/lmc-work-hrb6zq5j/images/boot.iso -isohybrid-mbr
/usr/share/syslinux/isohdpfx.bin -b isolinux/isolinux.bin -c
isolinux/boot.cat -boot-load-size 4 -boot-info-table -no-emul-boot
-eltorito-alt-boot -e images/efiboot.img -no-emul-boot
-isohybrid-gpt-basdat -eltorito-alt-boot -e images/macboot.img
-no-emul-boot -isohybrid-gpt-hfsplus -R -J -V
Fedora-WS-Live-36-20220407-n-0 -graft-points
isolinux=/var/tmp/lmc-work-hrb6zq5j/isolinux
images/pxeboot=/var/tmp/lmc-work-hrb6zq5j/images/pxeboot
LiveOS=/var/tmp/lmc-work-hrb6zq5j/LiveOS
EFI/BOOT=/var/tmp/lmc-work-hrb6zq5j/EFI/BOOT
images/efiboot.img=/var/tmp/lmc-work-hrb6zq5j/images/efiboot.img
images/macboot.img=/var/tmp/lmc-work-hrb6zq5j/images/macboot.img
LICENSE=/var/tmp/lmc-work-hrb6zq5j/LICENSE
Fedora-Legal-README.txt=/var/tmp/lmc-work-hrb6zq5j/Fedora-Legal-README.txt

There's a bit to unpack there...

-- 
Chris Murphy

[Kevin Kofler]

Neal Gompa wrote:
>  The pull request to delete the code for BIOS support in lorax means
>  that we can't produce media with BIOS support at all once that's
>  merged. They've tied dropping syslinux to dropping BIOS support
>  entirely. It is also unclear that they'd take a contribution to rewire
>  lorax to produce media with BIOS support using GRUB like we do for
>  UEFI. 
So the change is actually already being implemented without approval? This 
kind of forcing facts turns the whole change policy to the absurd.

As I understand it, dropping support in Lorax affects both livemedia-creator 
and livecd-creator, so the only way forward to build ISOs that actually boot 
would be to fork Lorax. Unless we can reuse some other distro's tools 
instead.

The liveinst part of Anaconda can be replaced with Calamares, but ISO 
composing (which can be done with (livemedia-creator) or without Anaconda 
(livecd-creator), but both code paths end up in Lorax eventually) is not in 
the scope of Calamares.

        Kevin Kofler

[Samuel Sieb]

On 4/7/22 18:54, Neal Gompa wrote:
>  On Thu, Apr 7, 2022 at 9:21 PM Chris Adams <linux(a)cmadams.net&gt;
> wrote:
> >
> > Once upon a time, Chris Murphy <lists(a)colorremedies.com&gt; said:
> >> syslinux (really isolinux) is only used on installation media.
> >
> > It's commonly used for BIOS PXE booting as well.
> >
>  
>  *shudders at the memories of dealing with pxelinux*
>  
>  GRUB is way better for that. Yes, you can use GRUB for PXE and UEFI netboot too. 
That's what I use for both.

[Dominik 'Rathann' Mierzejewski]

On Thursday, 07 April 2022 at 14:54, Vitaly Zaitsev via devel wrote:
>  On 07/04/2022 09:59, Dominik 'Rathann' Mierzejewski wrote:
>  > OVH is another big provider and they don't offer UEFI boot with their
>  > VPS range. I've just confirmed it with their support.
>  
>  You should contact their support first. 
I already did. Isn't that what I wrote?

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Dominik 'Rathann' Mierzejewski]

On Friday, 08 April 2022 at 04:37, Gary Buhrmaster wrote:
>  On Thu, Apr 7, 2022 at 10:05 PM Matthew Miller
> <mattdm(a)fedoraproject.org&gt; wrote:
>  >
>  > On Thu, Apr 07, 2022 at 03:43:07PM +0100, Richard W.M. Jones wrote:
>  > > Clover is described here:
>  > > https://github.com/CloverHackyColor/CloverBootloader
>  >
>  > This is interesting. Seems like considerable up-front work, but a much
>  > cleaner possible future than completely dual paths.
>  
>  On my (still countably) infinite TODO list I had
>  an item on it to spend more time looking at
>  Clover to be able to boot (in UEFI mode) one
>  of my older BIOS only Core 2 duo quad systems
>  that I had picked up for pennies on the dollar
>  at a local surplus store.  At this point it is a
>  question of whether I will find the time to do
>  so or the system itself will finally die.  Since
>  the original placement (on my list), the Clover
>  devs have substantially improved it to the
>  point that a lot of the rough edges have been
>  mitigated, although given all the various
>  implementations of BIOS's there are still
>  going to be edge cased (just as there are
>  still rough edges with UEFI, especially the
>  earliest implementations). 
I'd be willing to lend a hand to adapting Clover on Fedora and testing
booting with it on my 12yo BIOS-only Intel Atom machine.

>  > Are there docs on this somewhere other than the Arch wiki?
> (Which, as usual,
>  > is very helpful!) -- https://wiki.archlinux.org/title/Clover
>  
>  As is typically the case, the Arch wiki is better
>  than almost all other available docs. 
Indeed. How do they do it? ;)

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Dominik 'Rathann' Mierzejewski]

On Friday, 08 April 2022 at 08:57, Samuel Sieb wrote:
>  On 4/7/22 18:54, Neal Gompa wrote:
>  > On Thu, Apr 7, 2022 at 9:21 PM Chris Adams <linux(a)cmadams.net&gt; wrote:
>  > > 
>  > > Once upon a time, Chris Murphy <lists(a)colorremedies.com&gt; said:
>  > > > syslinux (really isolinux) is only used on installation media.
>  > > 
>  > > It's commonly used for BIOS PXE booting as well.
>  > > 
>  > 
>  > *shudders at the memories of dealing with pxelinux*
>  > 
>  > GRUB is way better for that. Yes, you can use GRUB for PXE and UEFI netboot too.
>  
>  That's what I use for both. 
Would you care to document your set-ups?

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Dominik 'Rathann' Mierzejewski]

On Thursday, 07 April 2022 at 18:42, Robbie Harwood wrote:
>  Michael Catanzaro <mcatanzaro(a)gnome.org&gt; writes:
>  
>  > On Wed, Apr 6 2022 at 03:35:38 PM -0400, Jared Dominguez 
>  > <jaredz(a)redhat.com&gt; wrote:
>  >> This seems like a strong assumption to me considering that aside from 
>  >> the largest cloud providers (with whom Red Hat is directly working 
>  >> with on UEFI boot features and bug reports), cloud providers are 
>  >> using off-the-shelf hypervisors that support UEFI boot.
>  >
>  > I'm going to ask the proposal authors to at least mention this as a 
>  > risk in the Feedback section of the change proposal. Maybe cloud 
>  > providers will all see this as a good opportunity to enable UEFI on 
>  > their platforms, and we'll be perfectly fine. I rather suspect it's not 
>  > going to happen quite so smoothly, though....
>  
>  I have appended added my analysis of this to the Feedback section.  For
>  clarity, it's copied here:
>  
>      During mailing list discussion of this change, concern was expressed
>      that some of the smaller hosting providers who do not provision with
>      UEFI today and do not also support Windows would drop Fedora rather
>      than enabling UEFI.  Given that the major virtualization solutions
>      (vsphere, kvm, xen, bhve, virtualbox, ...) all support UEFI today, 
...latest versions of... And the provider in question might not be
running the latest version.

>      this would likely be exposing an existing capability rather than
>      making a sweeping change. 
It's equally likely that they'd have to upgrade their virtualization
platform to the latest version first and then update their internal
UI/tooling to expose UEFI. I'd call that a sweeping change while you're
downplaying the scope of it.

>      That said, it is always possible that
>      providers may elect to drop Fedora rather than adjust their setups -
>      be it for this change or any other change Fedora makes. 
That's completely unnecessary. It adds nothing but attempt to dilute the
impact of this change.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Ralf Corsépius]

Am 07.04.22 um 18:14 schrieb Robbie Harwood:
>  Robert Marcano via devel <devel(a)lists.fedoraproject.org&gt;
> writes:
>  
> > Is this change only related to install media support for booting with
> > BIOS only? Would I be able to install newer Fedora releases using Legacy
> > PXE on BIOS only machines?
>  
>  The intent is to indicate that new legacy installations are not
>  supported, regardless of how one gets there.  Mechanically, there are
>  few ways to actually *prevent* these installations[1] - rather, we send
>  a message that this is on its way out (i.e., deprecated) and that it's
>  time for users to consider migrating their setups.
>  
>  So the direct answer is: yes, probably, if you're willing to work at it
>  hard enough.  But it wouldn't be supported. 
Your answer once more confirms my impression on Red Hat's current role 
in Fedora: Red Hat is abusing Fedora is not willing to contribute to the 
community and is striving to get rid of the community (similar to RHAT's 
management faults wrt. CentOS)

That said, should this change happen, I will probably drop using und 
supporting fedora and switch to a different flavor of Linux. It's 
apparently what RHAT wants.

Ralf

[Vitaly Zaitsev]

On 08/04/2022 09:54, Dominik 'Rathann' Mierzejewski wrote:
>  I already did. Isn't that what I wrote? 
Can you post their answer?

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Vitaly Zaitsev]

On 07/04/2022 22:04, Demi Marie Obenour wrote:
>  *Virtual*  hardware is another matter entirely. 
All popular hypervisors (KVM/qemu, VirtualBox and VMWare) have full UEFI 
boot support.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Vitaly Zaitsev]

On 07/04/2022 18:10, Robbie Harwood wrote:
>  While we do maintain a large set of patches downstream, due to
> upstream
>  being inactive for a while, today upstream is alive and very much not
>  abandoned: 
Why not upstream all those patches then?

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Neal Gompa]

On Fri, Apr 8, 2022 at 8:07 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  On 07/04/2022 18:10, Robbie Harwood wrote:
>  > While we do maintain a large set of patches downstream, due to upstream
>  > being inactive for a while, today upstream is alive and very much not
>  > abandoned:
>
>  Why not upstream all those patches then?
>  
It's not quite that simple. There are currently 214 patches on
GRUB[1]. Some of those are backports of reviewed and merged patches,
but a large chunk of them are feature development patches that are
either in review or haven't been submitted because dependent patches
are in review. Patch review is long, slow, and complex. It's even more
so for GRUB. Top that with there being only one major committer for
the upstream project right now (Daniel Kiper). I'm not fully aware of
the dynamics of the GRUB project, so I don't know the reason for the
lack of other committers. But needless to say, I know that Daniel
considers it a top priority to eliminate the Red Hat GRUB fork by
incorporating its changes into mainline because a large number of
distributions use it instead of upstream due to the lack of
responsiveness, feature development, and fixes present in the upstream
code.

However, taking it all in wholesale without review is crazy because
then nobody else knows how the code was developed and if it should go
in as-is. That said, my personal opinion is that a couple of the folks
who work on RH GRUB should be part of the project leadership in
upstream GRUB and have commit access to maintain and manage this. That
may already be in place, but I don't know for sure.


[1]:
https://src.fedoraproject.org/rpms/grub2/tree/d17f80cfd556d8a582756ee3933...




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

[Robbie Harwood]

Vitaly Zaitsev via devel <devel(a)lists.fedoraproject.org&gt; writes:

>  On 07/04/2022 18:10, Robbie Harwood wrote:
>
> > While we do maintain a large set of patches downstream, due to upstream
> > being inactive for a while, today upstream is alive and very much not
> > abandoned:
>
>  Why not upstream all those patches then? 
I resent the implication that I'm not doing that.

The idea that one would show up with a decent-sized pile of patches and
have an upstream merge them immediately sits somewhere between "naïve"
and "a reason to vote no-confidence in upstream".

Be well,
--Robbie

[Zamir SUN]

On 4/5/22 22:52, Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
>  
>  == Summary ==
>  Make UEFI a hardware requirement for new Fedora installations on
>  platforms that support it (x86_64).  Legacy BIOS support is not
>  removed, but new non-UEFI installation is not supported on those
>  platforms.  This is a first step toward eventually removing legacy
>  BIOS support entirely.
>  
>  == Owner ==
>  * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří
>  Konečný]], [[User:bcl| Brian C. Lane]]
>  * Email: rharwood(a)redhat.com
>  
>  
>  == Detailed Description ==
>  UEFI is defined by a versioned standard that can be tested and
>  certified against.  By contrast, every legacy BIOS is unique. Legacy
>  BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple)
>  and on its way out.  As it ages, maintainability has decreased, and 
Probably it isn't a problem for some users, but I'm still having bad 
experience with UEFI on x86_64 now. Out of my 3 machines I only have 1 
system that works fine with UEFI. And my parents' laptop was purchased 2 
years ago and the UEFI firmware does not allow to boot anything other 
than Windows on UEFI mode (regardless of turning secure boot on or off) 
and I have to switch to BIOS mode to make Fedora work there. So in this 
situation, I think it's way too aggressive to accept the change - this 
will probably drive away some potential new users with decent laptop 
like my parents'.

>  the status quo of maintaining both stacks in perpetuity is not
> viable
>  for those currently doing that work.
>  
>  It is inevitable that legacy BIOS will be removed in a future release.
>  To ease this transition as best we can, there will be a period (of at
>  least one Fedora release) where it will be possible to boot using the
>  legacy BIOS codepaths, but new installations will not be possible.
>  While it would be easier for us to cut support off today, our hope is
>  that this compromise position will make for a smoother transition.
>  Additional support with issues during the transition would be
>  appreciated.
>  
>  While this will eventually reduce workload for boot/installation
>  components (grub2 reduces surface area, syslinux goes away entirely,
>  anaconda reduces surface area), the reduction in support burden
>  extends much further into the stack - for instance, VESA support can
>  be removed from the distro.
>  
>  Fedora already requires a 2GHz dual core CPU at minimum (and therefore
>  mandates that machines must have been made after 2006).  Like the
>  already accepted Fedora 37 change to retire ARMv7 support, the 
I know ARMv7 is irrelevant here, but I feel ARMv7 never use BIOS in Fedora.

The dropping of ARMv7 support already renders most of my ARM devices 
unable to use new Fedora, which is a great pain and I have to switch to 
something else if I need to reinstall in the future. Similarly, if we 
drive BIOS users out of fresh installation, we have even more 
possibility of attracting less new users, which I feel isn't what 
Fedoraproject want to see.

>  hardware targeted tends to be rather underpowered by today’s
>  standards, and the world has moved on from it.  Intel stopped shipping
>  the last vestiges of BIOS support in 2020 (as have other vendors, and
>  Apple and Microsoft), so this is clearly the way things are heading -
>  and therefore aligns with Fedora’s “First” objective.
>  
>  == Feedback ==
>  Dropping legacy BIOS was previously discussed (but not proposed) in 2020:
>
> https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject...
>  
>  Important, relevant points from that thread (yes, I reread the entire
>  thread) that have informed this change:
>  
>  * Some machines are BIOS-only.  This change does not prevent their use
>  yet, but they are effectively deprecated.  grub2 (our default
>  bootloader) is already capable of both BIOS and UEFI booting.
>  * Drawing a clear year cutoff, let alone a detailed list of hardware
>  this change affects, is basically impossible.  This is unfortunate but
>  unlikely to ever change.
>  * There is no migration story from Legacy BIOS to UEFI -
>  repartitioning effectively mandates a reinstall.  As a result, we
>  don’t drop support for existing Legacy BIOS systems yet, just new
>  installations.
>  * There is no way to deprecate hardware without causing some amount of friction.
>  * While at the time AWS did not support UEFI booting, that is no
>  longer the case and they support UEFI today.
>  
>  == Benefit to Fedora ==
>  UEFI is required for many desirable features, including applying
>  firmware updates (fwupd) and supporting SecureBoot.  As a standalone
>  change, it reduces support burden on everything involved in installing
>  Fedora, since there becomes only one way to do it per platform.
>  Finally, it simplifies our install/live media, since it too only has
>  to boot one way per arch.  Freedom Friends Features First - this is
>  that last one.
>  
>  == Scope ==
>  * Proposal owners:
>  ** bootloaders: No change (existing Legacy BIOS installations still supported).
>  ** anaconda: No change (there could be only optional cleanups in the
>  code). However, it needs to be verified.
>  ** Lorax: Code has already been written:
>  https://github.com/weldr/lorax/pull/1205
>  
>  * Other developers:
>  ** libvirt: UEFI works today, but is not the default.  UEFI-only
>  installation is needed for Windows 11, and per conversations, libvirt
>  is prepared for this change.
>  ** Virtualbox: UEFI Fedora installs are working and per virtualbox
>  team, UEFI will be/is the default in 7.0+.
>  ** The Hardware Overview page should be updated to mention the UEFI
>  requirement:
> https://docs.fedoraproject.org/en-US/fedora/rawhide/release-notes/welcome...
>  
>  * Release engineering: [https://pagure.io/releng/issue/10738 #Releng
>  issue 10738]
>  
>  * Policies and guidelines: N/A (not needed for this Change)
>  
>  * Trademark approval: N/A (not needed for this Change)
>  
>  * Alignment with Objectives: N/A
>  
>  == Upgrade/compatibility impact ==
>  Systems currently using Legacy BIOS for booting on x86_64 will
>  continue to do so.
>  
>  However, this modifies the baseline Fedora requirements and some
>  hardware will no longer be supported for new installations.
>  
>  == How To Test ==
>  UEFI installation has been supported for quite a while already, so
>  additional testing there should not be required.
>  
>  == User Experience ==
>  Installs will continue to work on UEFI, and will not work on Legacy
>  BIOS.  Our install media is already UEFI-capable.
>  
>  == Dependencies ==
>  None
>  
>  == Contingency Plan ==
>  Leave things as they are.  Code continues to rot.  Community
>  assistance is required to continue the status quo.  Current owners
>  plan to orphan some packages regardless of whether the proposal is
>  accepted.
>  
>  Another fallback option could be, if a Legacy BIOS SIG organizes, to
>  donate the relevant packages there and provide some initial mentoring.
>  Longer term, packages that cannot be wholly donated could be split,
>  though it is unclear whether the synchronization thereby required
>  would reduce the work for anyone.
>  
>  * Contingency mechanism: Delay until next release.
>  * Contingency deadline: Beta freeze
>  * Blocks release? No
>  
>  == Documentation ==
>  See release notes.
>  
>  == Release Notes ==
>  Fedora 37 marks legacy BIOS installation as deprecated on x86_64 in
>  favor of UEFI.  While systems already using Legacy BIOS to boot are
>  still supported, new legacy BIOS installations on these architectures
>  are no longer possible.  Legacy BIOS support will be removed entirely
>  in a future Fedora.
>  
>  (Additionally, the Hardware Overview page should be updated to mention
>  the UEFI requirement.)
>  
>   
-- 
Zamir SUN
GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E
Want to know more about Fedora?
Visit https://fedoraproject.org/wiki/
Ready to contribute? See https://whatcanidoforfedora.org/
想了解更多中文资讯，访问 https://zh.fedoracommunity.org/

[Vít Ondruch]

Dne 08. 04. 22 v 6:46 Kevin Kofler via devel napsal(a):
>  Neal Gompa wrote:
> > The pull request to delete the code for BIOS support in lorax means
> > that we can't produce media with BIOS support at all once that's
> > merged. They've tied dropping syslinux to dropping BIOS support
> > entirely. It is also unclear that they'd take a contribution to rewire
> > lorax to produce media with BIOS support using GRUB like we do for
> > UEFI.
>  So the change is actually already being implemented without approval?
>  

Having implementation ready for approval is +, isn't it?


>    This
>  kind of forcing facts turns the whole change policy to the absurd.
>  

But it also needs to be merged first to have any real effect. The PR is 
in the change proposal.


Vít


>  As I understand it, dropping support in Lorax affects both livemedia-creator
>  and livecd-creator, so the only way forward to build ISOs that actually boot
>  would be to fork Lorax. Unless we can reuse some other distro's tools
>  instead.
>
>  The liveinst part of Anaconda can be replaced with Calamares, but ISO
>  composing (which can be done with (livemedia-creator) or without Anaconda
>  (livecd-creator), but both code paths end up in Lorax eventually) is not in
>  the scope of Calamares.
>
>           Kevin Kofler
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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
>

[Jared Dominguez]

On Fri, Apr 8, 2022, 00:48 Kevin Kofler via devel <
devel(a)lists.fedoraproject.org&gt; wrote:

>  Neal Gompa wrote:
>  > The pull request to delete the code for BIOS support in lorax means
>  > that we can't produce media with BIOS support at all once that's
>  > merged. They've tied dropping syslinux to dropping BIOS support
>  > entirely. It is also unclear that they'd take a contribution to rewire
>  > lorax to produce media with BIOS support using GRUB like we do for
>  > UEFI.
>  
Neal, the change proposal already made it clear that this isn't just about
syslinux, and this fact has been discussed over and over. Your speculation
here and earlier in this thread on what would and would not be accepted
just reads to me as inflammatory, especially when the ones actually doing
development here have shown a clear willingness both in this thread and
explicitly in the change proposal for collaboration and help with
development.

So the change is actually already being implemented without approval? This
>  kind of forcing facts turns the whole change policy to the absurd.
>  
An _unmerged_ pull request still in review that's tied to this change
_proposal_.

As I understand it, dropping support in Lorax affects both
>  livemedia-creator
>  and livecd-creator, so the only way forward to build ISOs that actually
>  boot
>  would be to fork Lorax. Unless we can reuse some other distro's tools
>  instead.
>
>  The liveinst part of Anaconda can be replaced with Calamares, but ISO
>  composing (which can be done with (livemedia-creator) or without Anaconda
>  (livecd-creator), but both code paths end up in Lorax eventually) is not
>  in
>  the scope of Calamares.
>
>          Kevin Kofler
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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
>

[Jared Dominguez]

On Thu, Apr 7, 2022, 19:46 Samuel Sieb <samuel(a)sieb.net&gt; wrote:

>  On 4/7/22 14:51, Jared Dominguez wrote:
>  > On Thu, Apr 7, 2022 at 3:49 PM Samuel Sieb <samuel(a)sieb.net
>  > <mailto:[e-mail]>> wrote:
>  >
>  >     On 4/7/22 08:02, Jared Dominguez wrote:
>  >      > This is a proposal. Nothing has changed yet. The choice is now
>  >     whether
>  >      > to go forward with it or come together with a cohesive
>  >      > alternative, including one of the two listed in the proposal. But
>  we
>  >      > need a solution that accounts for the existing maintainers not
>  >     having
>  >      > capacity to continue maintaining legacy code. I've seen responses
>  >     from
>  >
>  >     I haven't yet seen a clear answer about what code is "rotting"
> and
>  >     which
>  >     legacy code is too hard to maintain.  Is there something actually
>  >     broken
>  >     right now?
>  >
>  >
>  > For one, syslinux hasn't seen an update in 3 years and a release in 7
>  > years, and it has outstanding bugs. Legacy boot isn't where grub2 is
>  > getting development attention. The current maintainers in Fedora won't
>  > have capacity to continue maintaining legacy boot support in Fedora. As
>  > grub2 continues to be developed for UEFI systems (ARMv8-9 and x86-64,
>  > not to mention non-UEFI ppc64le and s390x), there is added risk of
>  > regressions on legacy x86 boot that won't be getting developer attention.
>
>  I don't understand why we're still using syslinux instead of grub for
>  legacy boots, especially since I think now you can use the same grub.cfg
>  file for both. 

It's development and validation work for something that's not a priority
for those who are doing bootloader work, and no one else has stepped up to
put in the time to do this work. The change proposal being discussed in
this thread is calling for community contributors.

There is always a risk of regressions, but if there is
>  no current problem, then why is there this push to obsolete a lot of
>  active hardware? 

There is a problem: the current maintainers don't have capacity to support
legacy x86 boot anymore. The code is going to bit rot if no one steps up to
fill in.

This is not comparable to the 32-bit removal where it
>  was only a few really old systems.  This is going to affect decent
>  systems that are less than 10 years old.  I have a work HP laptop from
>  2012 that has "experimental" EFI support that really doesn't work well
>  and possibly a newer one as well, but I can't check it right now.
>  
I'm curious if you've updated your BIOS on that system. If it's really that
bad, Microsoft (and HP customers) would have been on HP's case about fixing
a bad user experience.

_______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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 Fri, Apr 8, 2022 at 11:47 AM Jared Dominguez <jaredz(a)redhat.com&gt; wrote:
>  On Thu, Apr 7, 2022, 19:46 Samuel Sieb <samuel(a)sieb.net&gt; wrote:
> >
> > On 4/7/22 14:51, Jared Dominguez wrote:
> > > On Thu, Apr 7, 2022 at 3:49 PM Samuel Sieb <samuel(a)sieb.net
> > > <mailto:[e-mail]>> wrote:
> > >
> > >     On 4/7/22 08:02, Jared Dominguez wrote:
> > >      > This is a proposal. Nothing has changed yet. The choice is now
> > >     whether
> > >      > to go forward with it or come together with a cohesive
> > >      > alternative, including one of the two listed in the proposal. But we
> > >      > need a solution that accounts for the existing maintainers not
> > >     having
> > >      > capacity to continue maintaining legacy code. I've seen responses
> > >     from
> > >
> > >     I haven't yet seen a clear answer about what code is "rotting"
> and
> > >     which
> > >     legacy code is too hard to maintain.  Is there something actually
> > >     broken
> > >     right now?
> > >
> > >
> > > For one, syslinux hasn't seen an update in 3 years and a release in 7
> > > years, and it has outstanding bugs. Legacy boot isn't where grub2 is
> > > getting development attention. The current maintainers in Fedora won't
> > > have capacity to continue maintaining legacy boot support in Fedora. As
> > > grub2 continues to be developed for UEFI systems (ARMv8-9 and x86-64,
> > > not to mention non-UEFI ppc64le and s390x), there is added risk of
> > > regressions on legacy x86 boot that won't be getting developer attention.
> >
> > I don't understand why we're still using syslinux instead of grub for
> > legacy boots, especially since I think now you can use the same grub.cfg
> > file for both.
>
>
>  It's development and validation work for something that's not a priority for
> those who are doing bootloader work, and no one else has stepped up to put in the time to
> do this work. The change proposal being discussed in this thread is calling for community
> contributors.
>
> > There is always a risk of regressions, but if there is
> > no current problem, then why is there this push to obsolete a lot of
> > active hardware?
>
>
>  There is a problem: the current maintainers don't have capacity to support legacy x86
> boot anymore. The code is going to bit rot if no one steps up to fill in.
>
> > This is not comparable to the 32-bit removal where it
> > was only a few really old systems.  This is going to affect decent
> > systems that are less than 10 years old.  I have a work HP laptop from
> > 2012 that has "experimental" EFI support that really doesn't work well
> > and possibly a newer one as well, but I can't check it right now.
>
>
>  I'm curious if you've updated your BIOS on that system. If it's really that
> bad, Microsoft (and HP customers) would have been on HP's case about fixing a bad user
> experience.
>  
Why? It works for Windows, and HP has only done token support for
other platforms over the past decade (see most recent thing promoting
WSL as a good Linux on HP experience[1]). All of my HP computers have
been extremely difficult to get Linux working on properly, which is
why I stopped buying them.

Just because Dell is sometimes good at its job doesn't mean everyone
else is. The reality is that most aren't.

[1]:
https://press.hp.com/us/en/press-releases/2021/hp-powers-real-time-collab...



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

[Michel Alexandre Salim]

On Fri, Apr 08, 2022 at 11:46:50AM -0400, Jared Dominguez wrote:
>  On Thu, Apr 7, 2022, 19:46 Samuel Sieb <samuel(a)sieb.net&gt;
> wrote:
>  
>  > I don't understand why we're still using syslinux instead of grub for
>  > legacy boots, especially since I think now you can use the same grub.cfg
>  > file for both.
>  
>  
>  It's development and validation work for something that's not a priority
>  for those who are doing bootloader work, and no one else has stepped up to
>  put in the time to do this work. The change proposal being discussed in
>  this thread is calling for community contributors.
>   
Would using Grub for legacy boot be more, or less work than continuing
to support syslinux, assuming people step up to do the development and
validation?

As someone who is also interested in eventually phasing out legacy BIOS
support, but think it's too early, I sense that this is a better way to
deprecate - first future proof the legacy installations in such a way
that at some future time you can simply upgrade the system, switch to
UEFI and keep your system disk - is a much better transition for our
users.

*and* I have been hearing from people who are interested in doing this
work. I sympathize with the change owners' position that detractors need
to assume their good intentions, but I feel like the same needs to be
assumed for community contributions, and we've unfortunately been
talking past each other a bit in this thread.

Best regards,

-- 
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2

[Robbie Harwood]

Michel Alexandre Salim <salimma(a)fedoraproject.org&gt; writes:

>  Would using Grub for legacy boot be more, or less work than
> continuing
>  to support syslinux, assuming people step up to do the development and
>  validation? 
syslinux is by default only used on the live media.  Legacy installs
today provision grub2.  So moving them to live media would probably be
less, but it won't solve the overall problem.

>  I sympathize with the change owners' position that detractors
> need
>  to assume their good intentions, but I feel like the same needs to be
>  assumed for community contributions, 
That's not really a "position" so much as a restatement of the Fedora
Project's code of conduct.  If you feel that our comportment is not up
to snuff, please provide specific feedback so we can improve.
(Otherwise, a statement like that just comes across as propagating FUD.)

Be well,
--Robbie

[Neal Gompa]

On Fri, Apr 8, 2022 at 12:41 PM Robbie Harwood <rharwood(a)redhat.com&gt; wrote:
>  Michel Alexandre Salim <salimma(a)fedoraproject.org&gt; writes:
>
>  > Would using Grub for legacy boot be more, or less work than continuing
>  > to support syslinux, assuming people step up to do the development and
>  > validation?
>
>  syslinux is by default only used on the live media.  Legacy installs
>  today provision grub2.  So moving them to live media would probably be
>  less, but it won't solve the overall problem.
>  
SYSLINUX is also used for PXE and a number of other boot methods in
BIOS. The main deliverable we use it for is live media, but there are
other things too. Most of that is thankfully documentation on how to
use GRUB for the same thing.




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

[Brian C. Lane]

On Fri, Apr 08, 2022 at 06:46:30AM +0200, Kevin Kofler via devel wrote:
>  Neal Gompa wrote:
>  > The pull request to delete the code for BIOS support in lorax means
>  > that we can't produce media with BIOS support at all once that's
>  > merged. They've tied dropping syslinux to dropping BIOS support
>  > entirely. It is also unclear that they'd take a contribution to rewire
>  > lorax to produce media with BIOS support using GRUB like we do for
>  > UEFI.
>  
>  So the change is actually already being implemented without approval? This 
>  kind of forcing facts turns the whole change policy to the absurd. 
No. It's just a PR, and actually it's currently in Draft state to
indicate that it isn't ready to be merged. If I merge it without
approval from the community then you can yell at me :)

>  As I understand it, dropping support in Lorax affects both
> livemedia-creator 
>  and livecd-creator, so the only way forward to build ISOs that actually boot 
>  would be to fork Lorax. Unless we can reuse some other distro's tools 
>  instead. 
This does not effect livecd-creator, that is a totally separate project
that I am no longer involved with. It would effect lorax built boot.iso
and live iso's created with livemedia-creator. Possibly also the DVD's
built by pungi.

The reason I wrote the PR was because, as I understand it, syslinux is
going away soon. It was an easy patch to write, and I find it easier to
discuss things when there is code present (or absent as in this case).

My *personal* opinion is we should not drop BIOS. I think BIOS will
continue to haunt use for the forseeable future, there is just too much
existing hardware that still works. But if the tools used to make it
work aren't present I have to remove them.

So like I said yesterday, I'll look into switching to use grub2 for
Fedora 37, assuming grub2 continues to support BIOS.

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart

[Chris Murphy]

On Fri, Apr 8, 2022 at 11:14 AM Brian C. Lane <bcl(a)redhat.com&gt; wrote:

>  The reason I wrote the PR was because, as I understand it, syslinux
> is
>  going away soon. It was an easy patch to write, and I find it easier to
>  discuss things when there is code present (or absent as in this case).
>
>  My *personal* opinion is we should not drop BIOS. I think BIOS will
>  continue to haunt use for the forseeable future, there is just too much
>  existing hardware that still works. But if the tools used to make it
>  work aren't present I have to remove them.
>
>  So like I said yesterday, I'll look into switching to use grub2 for
>  Fedora 37, assuming grub2 continues to support BIOS. 
If switching from syslinux to GRUB isn't onerous, it's essentially an
invisible change, i.e. new installations to BIOS systems is still
possible. But also, it would give some breathing room to evaluate BIOS
GRUB as a going-concern, versus clover. If we're looking at something
like 2-3 years of BIOS support, that might favor sticking it out with
BIOS GRUB. If it's much longer, that might favor using a UEFI emulator
on BIOS systems to bring them forward.

What about all the MBR handling in the installer? The change proposal
doesn't mention it. But if the ability to install to BIOS systems were
to go away, that would presumably take MBR with it. So I'm wondering
if it's viable to use BIOS GRUB instead of syslinux, should inst.gpt
become the default? And then would inst.mbr go away? Or would it stick
around for another cycle or two as a manual fallback? Or is it simple
and static enough that it'll persist for a long time without rotting?

Hindsight being 20/20 I kinda wonder if we should have just bit the
bullet on inst.gpt, because at least inst.mbr has been available this
whole time.


-- 
Chris Murphy

[Hans de Goede]

Hi Brian,

On 4/8/22 19:14, Brian C. Lane wrote:

<snip>

>  So like I said yesterday, I'll look into switching to use grub2
> for
>  Fedora 37, assuming grub2 continues to support BIOS. 
Thank you for looking into switching to using GRUB for the livecds.

If you have some test livecd img using grub instead of syslinux
for BIOS booting and you wanted it tested on some more / older
hw let me know and I'll test it on the BIOS-only machines which
I have.

Regards,

Hans

[Neal Gompa]

On Fri, Apr 8, 2022 at 1:50 PM Hans de Goede <hdegoede(a)redhat.com&gt; wrote:
>  Hi Brian,
>
>  On 4/8/22 19:14, Brian C. Lane wrote:
>
>  <snip>
>
>  > So like I said yesterday, I'll look into switching to use grub2 for
>  > Fedora 37, assuming grub2 continues to support BIOS.
>
>  Thank you for looking into switching to using GRUB for the livecds.
>
>  If you have some test livecd img using grub instead of syslinux
>  for BIOS booting and you wanted it tested on some more / older
>  hw let me know and I'll test it on the BIOS-only machines which
>  I have.
>  
I've got one or two of them around here somewhere too if you need testing. :)


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

[Michel Alexandre Salim]

On Fri, Apr 08, 2022 at 12:41:22PM -0400, Robbie Harwood wrote:
>  Michel Alexandre Salim <salimma(a)fedoraproject.org&gt; writes:
>  
>  > I sympathize with the change owners' position that detractors need
>  > to assume their good intentions, but I feel like the same needs to be
>  > assumed for community contributions,
>  
>  That's not really a "position" so much as a restatement of the Fedora
>  Project's code of conduct.  If you feel that our comportment is not up
>  to snuff, please provide specific feedback so we can improve.
>  (Otherwise, a statement like that just comes across as propagating FUD.)
>   
Apologies if this came across that way, I'm actually trying to calm
waters here. I'm rather surprised I came across as propagating FUD...

As for specifics:
- my general impression from reading this thread is this Change as
  originally written is too aggressive in its timeline, and too
  optimistic in assuming hardware, esp on the server side, is ready
- let's ignore the unfortunate dispute over the "PR was disabled" issue,
  I think that was a red herring
- as I stated, there are offers to help with getting syslinux replaced
  with GRUB. what I've not stated originally is Chris Murphy brought up
  protective MBR and switching all new installs to inst.gpt, which let
  us future proof new installations for when we do kill off legacy BIOS.

What people who want to help needs, though, is some sense that our
contributions are welcome. I've been at the receiving end of being
FUD-ed as having a 'hidden agenda', so I know how that feels, and I'm
definitely not trying to do that.

What I'm trying to point out is that the perceived lack of contribution
should not really be used as a reason to push this change right now:

- Neal pointed out he has been working on addressing this for a while,
  and have not put up a Change Proposal because he thought it was
  premature
- if the Change Proposal becomes "we can't support legacy BIOS long
  term, it's deprecated, community contributions welcome to help define
  the timeline and milestones" - that would probably get more people
  contributing rather than "this is our really fast timeline to
  deprecate this". Plus as many have stated, immediately breaking new
  installation is not deprecation, so I feel all subsequent discussion
  has been unfortunately tainted by that


Best regards,

-- 
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2

[Robbie Harwood]

Michel Alexandre Salim <salimma(a)fedoraproject.org&gt; writes:

>  - as I stated, there are offers to help with getting syslinux
> replaced
>    with GRUB. what I've not stated originally is Chris Murphy brought up
>    protective MBR and switching all new installs to inst.gpt, which let
>    us future proof new installations for when we do kill off legacy BIOS.
>
>  What people who want to help needs, though, is some sense that our
>  contributions are welcome. 
(If you're looking for me to comment on proposals to change live media
generation and installs, I can't really do that - that's Brian's and
Jiri's areas of expertise.)

>  - Neal pointed out he has been working on addressing this for a
> while,
>    and have not put up a Change Proposal because he thought it was
>    premature 
While Neal's contributions are as welcome as anyone else's, Neal is not
a maintainer of (or regular contributor to) bootloader packages and it
would be very strange for Neal to propose such a change without
discussing it with us first.  That said, if there was suggestion of such
a proposal, I have missed it (which is very possible given the size of
the thread at this point).

Be well,
--Robbie

[Thomas Schmitt]

Hi,

i'm the developer of xorriso. Please CC me with replies just in case
that i unsubscribe because of too much traffic.

Further: Sorry for my reply-id pointing to the predecessor of the message
which i quote. I found it at
  https://www.spinics.net/lists/fedora-devel/msg299915.html

Chris Murphy wrote:
>  For what it's worth, the current xorriso command used [...] is
>
>  xorrisofs -o /var/tmp/lmc-work-hrb6zq5j/images/boot.iso
>  -isohybrid-mbr /usr/share/syslinux/isohdpfx.bin
>  -b isolinux/isolinux.bin
>  -c isolinux/boot.cat
>  -boot-load-size 4 -boot-info-table -no-emul-boot
>  -eltorito-alt-boot
>  -e images/efiboot.img -no-emul-boot -isohybrid-gpt-basdat
>  -eltorito-alt-boot
>  -e images/macboot.img -no-emul-boot -isohybrid-gpt-hfsplus
>  -R -J -V Fedora-WS-Live-36-20220407-n-0
>  -graft-points
>  [... various files and directories grafted in ...]
>
>  There's a bit to unpack there... 
The lines, which will need changes for using GRUB, are at least:

  -isohybrid-mbr /usr/share/syslinux/isohdpfx.bin
  [...]
  -boot-load-size 4 -boot-info-table -no-emul-boot
  -b isolinux/isolinux.bin

grub-mkrescue (on Debian) uses instead:

  --grub2-mbr /usr/lib/grub/i386-pc/boot_hybrid.img
  -b boot/grub/i386-pc/eltorito.img
     -no-emul-boot -boot-load-size 4 -boot-info-table --grub2-boot-info

/usr/lib/grub/i386-pc/boot_hybrid.img is part of Debian's grub-pc-bin
package. It gets built by upstream file grub-core/Makefile.core
  https://sources.debian.org/src/grub2/2.06-2/grub-core/Makefile.core.am/?h...

/boot/grub/i386-pc/eltorito.img has to be inserted as data file into
the emerging ISO 9660 filesystem. grub-mkrescue puts it into the
file tree on hard disk which it then gives to xorrisofs as input file.
It gets produced by GRUB from a file named "cdboot.img". In Debian it
is part of package grub-pc-bin as
  /usr/lib/grub/i386-pc/cdboot.img
It does not appear as if the read-in cdboot.img would get modified before
it gets written back as "eltorito.img":
  https://sources.debian.org/src/grub2/2.06-2/util/mkimage.c/?hl=1271#L1266
Its production/copying gets ordered in:
  https://sources.debian.org/src/grub2/2.06-2/util/grub-mkrescue.c/?hl=598#...

The emerging GRUB MBR is supposed to boot from USB sticks quite like the
ISOLINUX MBR. Both hop with their execution onto the El Torito boot
images for BIOS.

grub-mkrescue uses no option -c, which does not matter for boot success.
Fedora can well keep its

  -c isolinux/boot.cat

The EFI-related options -isohybrid-gpt-basdat and -isohybrid-gpt-hfsplus
will continue to work, if additionally option

  -part_like_isohybrid

is given (once is enough).

------------------------------------------------------------------------
More unsolicited info:

An opportunity to watch grub-mkrescue's xorriso options is given by
the script
  frontend/grub-mkrescue-sed.sh
from the source tarball of xorriso (which in Fedora is libisoburn-*.tar.gz):

 
https://dev.lovelyhq.com/libburnia/libisoburn/raw/branch/master/frontend/...

I derived above BIOS proposal by

  mkdir minimal
  touch minimal/empty-file.txt
  export MKRESCUE_SED_DEBUG=yes
  grub-mkrescue -o output.iso minimal \
                --xorriso=/...localpath.../frontend/grub-mkrescue-sed.sh

If i install (on Debian)
  grub-common grub-pc-bin grub-efi-amd64-bin grub-efi-ia32-bin
i get from grub-mkrescue an ISO with both, BIOS and EFI equipment.

The original purpose of the script grub-mkrescue-sed.sh is to enable
variations of the xorriso options to create different layouts of partition
tables for the EFI stuff. See "Variation settings" in the script.
The main drawback of grub-mkrescue's original partition layout is that
there is no mountable partition for the ISO 9660 filesystem.
For Fedora's ISOs it might be interesting to inspect the messages and
the resulting ISO of

  export MKRESCUE_SED_MODE=mjg
  export MKRESCUE_SED_DEBUG=yes
  grub-mkrescue -o output.iso minimal \
                --xorriso=/...localpath.../frontend/grub-mkrescue-sed.sh

It produces a layout that is inspired by mjg59's from 2012, but avoids
to have the EFI partition inside the ISO 9660 filesystem and its partition
by appending the EFI partition.
(The HFS+ filesystem for Macs gets produced by libisofs. It would be
interesting to learn whether such Macs still exist and work with the
grub-mkrescue ISO.)

Discussions with other distro's ISO maintainers and their users yielded
that some old BIOS machines demand an MBR partition with "boot/active"
flag. Some new EFIs demand the presence of a GPT. So ye olde nested
pseudo-GPT partition layout of Fedora (and also of Debian) still has
its merits.
Just the nesting is ugly, unneeded, and causes protests from partition
editors.

With original grub-mkrescue layout and its pure GPT, the remedy is to use
xorrisofs option --mbr-force-bootable which makes the GPT a bit less pure
by adding a little dummy MBR partition of type 0x00.


Have a nice day :)

Thomas

[Michel Alexandre Salim]

On Fri, Apr 08, 2022 at 10:14:19PM +0800, Zamir SUN wrote:
>  
>  
>  Probably it isn't a problem for some users, but I'm still having bad
>  experience with UEFI on x86_64 now. Out of my 3 machines I only have 1
>  system that works fine with UEFI. And my parents' laptop was purchased 2
>  years ago and the UEFI firmware does not allow to boot anything other than
>  Windows on UEFI mode (regardless of turning secure boot on or off) and I
>  have to switch to BIOS mode to make Fedora work there. So in this situation,
>  I think it's way too aggressive to accept the change - this will probably
>  drive away some potential new users with decent laptop like my parents'.
>   
I've encountered one such laptop - turning off secure boot was not
enough, there's another option somewhere else for disabling key
verification (IIRC).

I agree that this means dropping legacy BIOS is premature, and we should
focus more on future-proofing our installations to make the transition
easier in the future.

Cheers,

-- 
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2

[Samuel Sieb]

On 4/8/22 08:46, Jared Dominguez wrote:
>  On Thu, Apr 7, 2022, 19:46 Samuel Sieb <samuel(a)sieb.net 
>  <mailto:[e-mail]>> wrote:
>      This is not comparable to the 32-bit removal where it
>      was only a few really old systems.  This is going to affect decent
>      systems that are less than 10 years old.  I have a work HP laptop from
>      2012 that has "experimental" EFI support that really doesn't work well
>      and possibly a newer one as well, but I can't check it right now.
>  
>  
>  I'm curious if you've updated your BIOS on that system. If it's really 
>  that bad, Microsoft (and HP customers) would have been on HP's case 
>  about fixing a bad user experience. 
It was never intended to run as a UEFI system.  The support is clearly 
marked as "experimental" in the BIOS settings.  (And yes, I updated the 
BIOS.)  That was my point.  This is not an old, outdated system, but it 
doesn't have real UEFI support.

[Robbie Harwood]

Michel Alexandre Salim <salimma(a)fedoraproject.org&gt; writes:

>  - as I stated, there are offers to help with getting syslinux
> replaced
>    with GRUB 
More generally, I'm concerned that folks think this'll help a lot more
than it actually will.  There's a tendency to think in terms of packages
- they're contained units and therefore convenient to reason about.  But
just being in a container is not an indication of complexity or size.
The obligatory example of this that is (I hope) generally understood is
the kernel.  One source package, wildly different complexity than
anything else - to the point where it's more meaningful to talk about
the workflows enabled, subsystems, etc. than the rpms themselves.  I've
mentioned this upthread as well, but this is the nature of the problem:
it's not about *packages*, it's about *use case*.

Be well,
--Robbie

[Michel Alexandre Salim]

On Fri, Apr 08, 2022 at 02:39:04PM -0400, Robbie Harwood wrote:
>  Michel Alexandre Salim <salimma(a)fedoraproject.org&gt; writes:
>  
>  > - as I stated, there are offers to help with getting syslinux replaced
>  >   with GRUB
>  
>  More generally, I'm concerned that folks think this'll help a lot more
>  than it actually will.  There's a tendency to think in terms of packages
>  - they're contained units and therefore convenient to reason about.  But
>  just being in a container is not an indication of complexity or size.
>  The obligatory example of this that is (I hope) generally understood is
>  the kernel.  One source package, wildly different complexity than
>  anything else - to the point where it's more meaningful to talk about
>  the workflows enabled, subsystems, etc. than the rpms themselves.  I've
>  mentioned this upthread as well, but this is the nature of the problem:
>  it's not about *packages*, it's about *use case*.
>   
Right, not saying this is a viable long-term solution. But having
everything being GRUB, *plus* using protective MBR, would allow us to
not force people to reinstall when we finally kill off legacy BIOS.

* yes, we still need to figure out how to convert existing systems to
* protective MBR plus GPT, but at least we won't be creating new legacy
* installs that will require reinstallation

Best,

-- 
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2

[Jared Dominguez]

On Fri, Apr 8, 2022, 11:52 Neal Gompa <ngompa13(a)gmail.com&gt; wrote:

>  On Fri, Apr 8, 2022 at 11:47 AM Jared Dominguez
> <jaredz(a)redhat.com&gt; wrote:
>  >
>  >
>  >
>  >
>  > On Thu, Apr 7, 2022, 19:46 Samuel Sieb <samuel(a)sieb.net&gt; wrote:
>  >>
>  >> On 4/7/22 14:51, Jared Dominguez wrote:
>  >> > On Thu, Apr 7, 2022 at 3:49 PM Samuel Sieb <samuel(a)sieb.net
>  >> > <mailto:[e-mail]>> wrote:
>  >> >
>  >> >     On 4/7/22 08:02, Jared Dominguez wrote:
>  >> >      > This is a proposal. Nothing has changed yet. The choice is now
>  >> >     whether
>  >> >      > to go forward with it or come together with a cohesive
>  >> >      > alternative, including one of the two listed in the proposal.
>  But we
>  >> >      > need a solution that accounts for the existing maintainers not
>  >> >     having
>  >> >      > capacity to continue maintaining legacy code. I've seen
>  responses
>  >> >     from
>  >> >
>  >> >     I haven't yet seen a clear answer about what code is
> "rotting" and
>  >> >     which
>  >> >     legacy code is too hard to maintain.  Is there something actually
>  >> >     broken
>  >> >     right now?
>  >> >
>  >> >
>  >> > For one, syslinux hasn't seen an update in 3 years and a release in 7
>  >> > years, and it has outstanding bugs. Legacy boot isn't where grub2 is
>  >> > getting development attention. The current maintainers in Fedora won't
>  >> > have capacity to continue maintaining legacy boot support in Fedora.
>  As
>  >> > grub2 continues to be developed for UEFI systems (ARMv8-9 and x86-64,
>  >> > not to mention non-UEFI ppc64le and s390x), there is added risk of
>  >> > regressions on legacy x86 boot that won't be getting developer
>  attention.
>  >>
>  >> I don't understand why we're still using syslinux instead of grub for
>  >> legacy boots, especially since I think now you can use the same grub.cfg
>  >> file for both.
>  >
>  >
>  > It's development and validation work for something that's not a priority
>  for those who are doing bootloader work, and no one else has stepped up to
>  put in the time to do this work. The change proposal being discussed in
>  this thread is calling for community contributors.
>  >
>  >> There is always a risk of regressions, but if there is
>  >> no current problem, then why is there this push to obsolete a lot of
>  >> active hardware?
>  >
>  >
>  > There is a problem: the current maintainers don't have capacity to
>  support legacy x86 boot anymore. The code is going to bit rot if no one
>  steps up to fill in.
>  >
>  >> This is not comparable to the 32-bit removal where it
>  >> was only a few really old systems.  This is going to affect decent
>  >> systems that are less than 10 years old.  I have a work HP laptop from
>  >> 2012 that has "experimental" EFI support that really doesn't work
> well
>  >> and possibly a newer one as well, but I can't check it right now.
>  >
>  >
>  > I'm curious if you've updated your BIOS on that system. If it's really
>  that bad, Microsoft (and HP customers) would have been on HP's case about
>  fixing a bad user experience.
>  >
>
>  Why? It works for Windows, and HP has only done token support for
>  other platforms over the past decade (see most recent thing promoting
>  WSL as a good Linux on HP experience[1]). All of my HP computers have
>  been extremely difficult to get Linux working on properly, which is
>  why I stopped buying them.
>  
If the experience is buggy with Windows too, HP probably has addressed that
as previously stated, which is why I asked about how up-to-date Samuel's
BIOS is. On several occasions I've seen complaints about firmware issues
that are solved by updating. Firmware is software too.

If not, that sounds like a big in Fedora and possibly Linux in general.
Windows is the reference operating system for most personal computer
manufacturers, whether we like it or not.

Just because Dell is sometimes good at its job doesn't mean everyone
>  else is. The reality is that most aren't.
>
>  [1]:
>
> https://press.hp.com/us/en/press-releases/2021/hp-powers-real-time-collab...
>
>
>
>  --
>  真実はいつも一つ！/ Always, there's only one truth!
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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
>

[Chris Murphy]

On Fri, Apr 8, 2022 at 12:29 PM Thomas Schmitt <scdbackup(a)gmx.net&gt; wrote:

>  The lines, which will need changes for using GRUB, are at least:
>
>    -isohybrid-mbr /usr/share/syslinux/isohdpfx.bin
>    [...]
>    -boot-load-size 4 -boot-info-table -no-emul-boot
>    -b isolinux/isolinux.bin
>
>  grub-mkrescue (on Debian) uses instead:
>
>    --grub2-mbr /usr/lib/grub/i386-pc/boot_hybrid.img
>    -b boot/grub/i386-pc/eltorito.img
>       -no-emul-boot -boot-load-size 4 -boot-info-table --grub2-boot-info 
Is there a possibility of dropping MBR? i.e. use GPT containing both a
biosboot partition type, and EFI System partition type?

The advantage of this is not just to get rid of MBR really. But if
there are still some systems out there that will face plant on GPT
anyway, it's probably best if they face plant when booting the
installation media rather than getting all the way to a successful
installation, just to face plant upon reboot.


-- 
Chris Murphy

[Thomas Schmitt]

Hi,

Chris Murphy wrote:
>  Is there a possibility of dropping MBR? i.e. use GPT containing both
> a
>  biosboot partition type, and EFI System partition type? 
I am not aware that legacy BIOS would hop directly on any GPT partition
or any MBR partition table partition.

The convention for hard-disk-like devices is to start the x86 code in
bytes 0 to 439 (or maybe to byte 445) of the MBR as 16-bit program.
In case of ISOLINUX or GRUB hybrid MBR, the only goal is to hand over
program execution to the El Torito boot image which is allowed to be
larger and is also the starting point for booting from DVD.
The connection is made by xorriso by patching the LBA of the boot image
into the x86 code of the MBR. Format and byte address for this patching
depends on the boot loader. Thus the mutually exclusive options
-isohybrid-mbr and --grub2-mbr.


>  The advantage of this is not just to get rid of MBR really. 
We have the room for those 440 bytes anyways if we have GPT.
The magic number of GPT is the "protective" MBR partition table at
bytes 446 to 509. There must be one partition slot of type 0xee and
no other valid partition marked by the other three slots.
The content of bytes 0 to 439 is specified by UEFI for "Protective
MBR" as "Unused by UEFI systems". In contrast to that, the bytes from
440 to 445 are specified as "Unused. Set to zero."
(UEFI 2.4 Table 15, UEFI 2.8 Table 19)


>  But if
>  there are still some systems out there that will face plant on GPT
>  anyway, it's probably best if they face plant when booting the
>  installation media rather than getting all the way to a successful
>  installation, just to face plant upon reboot. 
Legacy BIOS does not care for partition tables. At least to my knowledge
from supporting production of bootable ISOs. My mileage may vary.
Problems with partitions will arise only after BIOS handed control to
the MBR x86 code on USB stick or the El Torito boot image on DVD.

Possibly this here describes what is needed for GRUB if started by
legacy BIOS and facing GPT:
  https://wiki.archlinux.org/title/GRUB#BIOS_systems
I understand that the GPT boot partition substitutes for the traditional
gap between MBR block and the start of the first MBR partition. 1 MiB
of "embedded area" if i remember correctly.

But grub-mkrescue ISOs have GPT without a dedicated boot partition.
Probably that job is fulfilled by the El Torito boot image which has a
few more KiB than the MBR x86 code.

So i assume that face planting will happen only at later stages if the
booted system makes false assumptions like "GPT means EFI".


Have a nice day :)

Thomas

[Chris Murphy]

On Fri, Apr 8, 2022 at 4:31 PM Thomas Schmitt <scdbackup(a)gmx.net&gt; wrote:
>  Hi,
>
>  Chris Murphy wrote:
>  > Is there a possibility of dropping MBR? i.e. use GPT containing both a
>  > biosboot partition type, and EFI System partition type?
>
>  I am not aware that legacy BIOS would hop directly on any GPT partition
>  or any MBR partition table partition.
>
>  The convention for hard-disk-like devices is to start the x86 code in
>  bytes 0 to 439 (or maybe to byte 445) of the MBR as 16-bit program.
>  In case of ISOLINUX or GRUB hybrid MBR, the only goal is to hand over
>  program execution to the El Torito boot image which is allowed to be
>  larger and is also the starting point for booting from DVD.
>  The connection is made by xorriso by patching the LBA of the boot image
>  into the x86 code of the MBR. Format and byte address for this patching
>  depends on the boot loader. Thus the mutually exclusive options
>  -isohybrid-mbr and --grub2-mbr. 
OK so there isn't (yet) an option to embed the GRUB core.img in a GPT
BIOS boot partition, I take it? The assumption is MBR? On hard drives,
core.img goes in the MBR gap. I'm not sure where it goes on xorriso
produced ISOs though, but presumably not the gap because there's a
valid GPT there too.


>  > The advantage of this is not just to get rid of MBR really.
>
>  We have the room for those 440 bytes anyways if we have GPT.
>  The magic number of GPT is the "protective" MBR partition table at
>  bytes 446 to 509. There must be one partition slot of type 0xee and
>  no other valid partition marked by the other three slots.
>  The content of bytes 0 to 439 is specified by UEFI for "Protective
>  MBR" as "Unused by UEFI systems". In contrast to that, the bytes from
>  440 to 445 are specified as "Unused. Set to zero."
>  (UEFI 2.4 Table 15, UEFI 2.8 Table 19) 
Yeah, I'm not aware off hand of any UEFI that have a problem with the
first 440 bytes of LBA 0 being non-zero. I am aware though, of this
tianocore bug [1] where if the active bit on that 0xEE partition is
set, the GPT is considered invalid. This is now fixed in Tianocore,
but it might be widespread in firmware in hardware. But the idea would
be to not set this boot flag on our increasingly hypothetical future
ISOs because (a) it might cause UEFI to drop to an EFI shell, if this
bug is more widespread (b) we don't really want to work around buggy
BIOS firmware anyway, we want them to fail here rather than later.

Pretty sure I discovered this bug when testing Fedora 35 Cloud base
images, which are GPT with PMBR, and boot both BIOS and UEFI systems.
There's jump code in the first 440 bytes of LBA 0, pointing to the
core.img in BIOS Boot partition, and also there's an EFI system volume
that UEFI firmware discover.


>  > But if
>  > there are still some systems out there that will face plant on GPT
>  > anyway, it's probably best if they face plant when booting the
>  > installation media rather than getting all the way to a successful
>  > installation, just to face plant upon reboot.
>
>  Legacy BIOS does not care for partition tables. At least to my knowledge
>  from supporting production of bootable ISOs. My mileage may vary.
>  Problems with partitions will arise only after BIOS handed control to
>  the MBR x86 code on USB stick or the El Torito boot image on DVD. 
Some legacy BIOS insist on seeing certain MBR structures in LBA 0 or
they face plant. This was why Fedora never proceeded with GPT by
default on BIOS systems. Too many at the time didn't like the PMBR for
one reason or another. I think the more common reason (?) was the
single partition in the PMBR didn't have BootIndicator set, hence
parted's pmbr_boot flag, which sets this bit.


>  Possibly this here describes what is needed for GRUB if started by
>  legacy BIOS and facing GPT:
>    https://wiki.archlinux.org/title/GRUB#BIOS_systems
>  I understand that the GPT boot partition substitutes for the traditional
>  gap between MBR block and the start of the first MBR partition. 1 MiB
>  of "embedded area" if i remember correctly. 
yeah that's what I'm calling BIOS boot partition type, it's partition
type GUID is 21686148-6449-6E6F-744E-656564454649 which grub-install
is looking for, and how it knows where to embed core.img. But as I
understand it, the code in the first 440 bytes of LBA 0, written by
grub-install as well, is just jump to the LBA for core.img. There's no
code to "teach" the computer how to read the GPT and go find BIOS
Boot. It's a hard coded LBA to just blindly jump to.

>  But grub-mkrescue ISOs have GPT without a dedicated boot partition.
>  Probably that job is fulfilled by the El Torito boot image which has a
>  few more KiB than the MBR x86 code.
>
>  So i assume that face planting will happen only at later stages if the
>  booted system makes false assumptions like "GPT means EFI". 
Well it's been a long time since the GPT by default attempts, so I
kinda forget how they manifested, though that information is probably
in this list's archive :) My vague recollection is black screen.
That's it. No error, no forward progress. Maybe some systems had an
underscore character in the upper left corner? Maybe? Anyway, too many
people hit it and it was canned so we never did it.

If we can opt out of making a hybrid/faux MBR, and create a PMBR
instead, that'd also mean there's one clear unambiguous partition map
for USB sticks, which could make it easier to implement persistence.

[1]
https://bugzilla.tianocore.org/show_bug.cgi?id=3474



--
Chris Murphy

[Samuel Sieb]

On 4/8/22 12:07, Jared Dominguez wrote:
>  If the experience is buggy with Windows too, HP probably has
> addressed 
>  that as previously stated, which is why I asked about how up-to-date 
>  Samuel's BIOS is. On several occasions I've seen complaints about 
>  firmware issues that are solved by updating. Firmware is software too. 
Windows didn't run in EFI mode on it.  I only turned on the EFI mode 
when I put a new drive in with no windows, accepting the big warning 
that it was experimental.

>  If not, that sounds like a big in Fedora and possibly Linux in
> general. 
>  Windows is the reference operating system for most personal computer 
>  manufacturers, whether we like it or not. 
The biggest issue was that it seemed to ignore the efi boot entry for 
Fedora and used the fallback system.  This caused something in the 
Fedora boot system to create another entry every time.  I had to delete 
the extra entries every once in a while.

[Thomas Schmitt]

Hi,

>  OK so there isn't (yet) an option to embed the GRUB core.img in a
> GPT
>  BIOS boot partition, I take it? The assumption is MBR? On hard drives,
>  core.img goes in the MBR gap. I'm not sure where it goes on xorriso
>  produced ISOs though, but presumably not the gap because there's a
>  valid GPT there too. 
One could probably use core.img for booting from USB stick. But it would
not obsolete the x86 code in MBR and it currently is not necessary for
grub-mkrescue ISOs because eltorito.img does a job equivalent to core.img.
eltorito.img is stored in the ISO 9660 filesystem as normal data file.
The MBR x86 code transfers execution to it and the El Torito catalog has
it as boot image for x86 legacy BIOS.


>  Yeah, I'm not aware off hand of any UEFI that have a problem with
> the
>  first 440 bytes of LBA 0 being non-zero. I am aware though, of this
>  tianocore bug [1] where if the active bit on that 0xEE partition is
>  set, the GPT is considered invalid. 
That's why grub-mkrescue lets xorriso produce a pure GPT with no
boot/active flag at the 0xEE partition. But this lets old HP laptops
refuse to boot from USB stick.
A foul compromise is to add another MBR partition of type 0x00 with
boot/active flag. EFI is known to ignore it, but HP legacy BIOS takes it
as reason to run the MBR x86 code (which is not related to partitions).


>  (b) we don't really want to work around buggy
>  BIOS firmware anyway, we want them to fail here rather than later. 
That's a harsh decision but would match the purpose of this thread, indeed.
If so, then producing a pure GPT instead of the current jackalope seems
the way to go. grub-mkrescue will point the way or could even be the
solution to go for.

I would propose to care for a mountable ISO 9660 partition, by moving
the EFI boot image / EFI system partition out of the filesystem and
rather appending it as extra partition. An example can be created by
MKRESCUE_SED_MODE=gpt_appended with script frontend/grub-mkrescue-sed.sh
out of libisoburn.)
Further one would need xorrisofs option
  -partition_offset 16
so that a mountable GPT partition can be created which starts at 512-block
address 64, i.e. after the GPT partition table data. This wastes some
space because a second directory tree has to be generated additionally to
the normal directory tree which will be used when booting or mounting
the ISO from a DVD.
The waste would not be much with Fedora Live ISOs. In 3-year-old
Fedora-Workstation-Live-x86_64-31-1.9.iso the first data file is already
at 2048-block address 43. That would be at most 23 * 2048 bytes for the
directory records which form the file tree (43 - 16 blocks System Area -
4 blocks of Volume Descriptors). So the waste would be <= 46 KiB.

At that occasion consider to drop the HFS+ Mac boot image and the Apple
Partition map which marks it for some obscure non-EFI x86 Macs. I.e.
consider to remove from the current xorrisofs command the options
  -eltorito-alt-boot
  -e images/macboot.img -no-emul-boot -isohybrid-gpt-hfsplus
and try to find a Mac which misses this boot image and refuses to boot
but boots with the original ISO.


>  Some legacy BIOS insist on seeing certain MBR structures in LBA 0 or
>  they face plant. 
I only know of the buggy demand for a boot/active flag at some MBR
partition. If you can name more stumble stones, i would be highly
interested to learn about them.


>  If we can opt out of making a hybrid/faux MBR, and create a PMBR
>  instead, that'd also mean there's one clear unambiguous partition map
>  for USB sticks, which could make it easier to implement persistence. 
A PMBR is an MBR at the start of a partition and gets activated only
if the device MBR decides to do so. Sometimes there is MBR code on newly
bought USB sticks which looks for a partition with boot/active flag and
then chain-loads the PMBR from there.
But in an EL Torito bootable ISO this makes few sense. The little
hybrid MBR and the larger BIOS boot image can do everything that is
needed.

A neat partition map is indeed a valuable goal. To my knowledge it can
only be achieved by dropping support for the buggy legacy BIOSes which
demand to see an MBR partition with boot/active flag or by dropping
support for buggy EFIs which do not recognize the MBR partition type
0xEF unless a smell of GPT is on the storage device.

---------------------------------------------------------------------
Just for the fun of it i post xorriso's assessment of the jackalope boot
equipment in Fedora-Workstation-Live-x86_64-31-1.9.iso :

  $ xorriso -indev Fedora-Workstation-Live-x86_64-31-1.9.iso -report_el_torito plain
-report_system_area plain
  ...
  El Torito catalog  : 42  1
  El Torito cat path : /isolinux/boot.cat
  El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt  Ldsiz         LBA
  El Torito boot img :   1  BIOS  y   none  0x0000  0x00      4       16852
  El Torito boot img :   2  UEFI  y   none  0x0000  0x00  21716          43
  El Torito boot img :   3  UEFI  y   none  0x0000  0x00  45520        5472
  El Torito img path :   1  /isolinux/isolinux.bin
  El Torito img opts :   1  boot-info-table isohybrid-suitable
  El Torito img path :   2  /images/efiboot.img
  El Torito img path :   3  /images/macboot.img
  System area options: 0x00000202
  System area summary: MBR isohybrid cyl-align-off GPT
  ISO image size/512 : 3768320
  Partition offset   : 0
  MBR heads per cyl  : 0
  MBR secs per head  : 0
  MBR partition table:   N Status  Type        Start       Blocks
  MBR partition      :   1   0x80  0x00            0      3768320
  MBR partition      :   2   0x00  0xef          172        21716
  MBR partition      :   3   0x00  0x00        21888        45520
  MBR partition path :   2  /images/efiboot.img
  MBR partition path :   3  /images/macboot.img
  GPT                :   N  Info
  GPT disk GUID      :      892c8c3c5015534296ffb0417be2c61f
  GPT entry array    :      2  248  overlapping
  GPT lba range      :      64  3768256  3768319
  GPT partition name :   1  490053004f00480079006200720069006400
  GPT partname local :   1  ISOHybrid
  GPT partition GUID :   1  892c8c3c5015534296feb0417be2c61f
  GPT type GUID      :   1  a2a0d0ebe5b9334487c068b6b72699c7
  GPT partition flags:   1  0x1000000000000001
  GPT start and size :   1  0  3768256
  GPT partition name :   2  490053004f004800790062007200690064003100
  GPT partname local :   2  ISOHybrid1
  GPT partition GUID :   2  892c8c3c5015534296fdb0417be2c61f
  GPT type GUID      :   2  a2a0d0ebe5b9334487c068b6b72699c7
  GPT partition flags:   2  0x1000000000000001
  GPT start and size :   2  172  21716
  GPT partition path :   2  /images/efiboot.img
  GPT partition name :   3  490053004f004800790062007200690064003200
  GPT partname local :   3  ISOHybrid2
  GPT partition GUID :   3  892c8c3c5015534296fcb0417be2c61f
  GPT type GUID      :   3  005346480000aa11aa1100306543ecac
  GPT partition flags:   3  0x1000000000000001
  GPT start and size :   3  21888  45520
  GPT partition path :   3  /images/macboot.img

Note that the MBR partition table is not "protective" by consisting only
of one partition of type 0xEE. Thus the GPT is not valid, which is good
so, because the EFI system partition in GPT does not show the prescribed
Type GUID 28732ac11ff8d211ba4b00a0c93ec93b
aka C12A7328-F81F-11D2-BA4B-00A0C93EC93B.
(I wonder why this ISO does not show an Apple Partition Map. The xorrisofs
options shown in this thread should have caused one.)

For comparison a grub-mkrescue ISO for BIOS and EFI:

  ...
  El Torito catalog  : 1669  1
  El Torito cat path : /boot.catalog
  El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt  Ldsiz         LBA
  El Torito boot img :   1  BIOS  y   none  0x0000  0x00      4        3544
  El Torito boot img :   2  UEFI  y   none  0x0000  0x00   5760          84
  El Torito img path :   1  /boot/grub/i386-pc/eltorito.img
  El Torito img opts :   1  boot-info-table grub2-boot-info
  El Torito img path :   2  /efi.img
  System area options: 0x00004201
  System area summary: MBR protective-msdos-label grub2-mbr cyl-align-off GPT APM
  ISO image size/512 : 30848
  Partition offset   : 0
  MBR heads per cyl  : 64
  MBR secs per head  : 32
  MBR partition table:   N Status  Type        Start       Blocks
  MBR partition      :   1   0x00  0xee            1        30847
  GPT                :   N  Info
  GPT disk GUID      :      07f29bb153383349a5ecd605dcf5ebd6
  GPT entry array    :      20  176  separated
  GPT lba range      :      64  30802  30847
  GPT partition name :   1  4700610070003000
  GPT partname local :   1  Gap0
  GPT partition GUID :   1  07f29bb153383349a5e8d605dcf5ebd6
  GPT type GUID      :   1  a2a0d0ebe5b9334487c068b6b72699c7
  GPT partition flags:   1  0x1000000000000001
  GPT start and size :   1  64  272
  GPT partition name :   2 
450046004900200062006f006f007400200070006100720074006900740069006f006e00
  GPT partname local :   2  EFI boot partition
  GPT partition GUID :   2  07f29bb153383349a5e9d605dcf5ebd6
  GPT type GUID      :   2  28732ac11ff8d211ba4b00a0c93ec93b
  GPT partition flags:   2  0x1000000000000001
  GPT start and size :   2  336  5760
  GPT partition path :   2  /efi.img
  GPT partition name :   3  48004600530050004c0055005300
  GPT partname local :   3  HFSPLUS
  GPT partition GUID :   3  07f29bb153383349a5ead605dcf5ebd6
  GPT type GUID      :   3  005346480000aa11aa1100306543ecac
  GPT partition flags:   3  0x1000000000000001
  GPT start and size :   3  6096  24104
  GPT partition name :   4  4700610070003100
  GPT partname local :   4  Gap1
  GPT partition GUID :   4  07f29bb153383349a5ebd605dcf5ebd6
  GPT type GUID      :   4  a2a0d0ebe5b9334487c068b6b72699c7
  GPT partition flags:   4  0x1000000000000001
  GPT start and size :   4  30200  600
  APM                :   N  Info
  APM block size     :      2048
  APM gap fillers    :      2
  APM partition name :   1  Gap0
  APM partition type :   1  ISO9660_data
  APM start and size :   1  16  1508
  APM partition name :   2  HFSPLUS_Hybrid
  APM partition type :   2  Apple_HFS
  APM start and size :   2  1524  6026
  APM partition name :   3  Gap1
  APM partition type :   3  ISO9660_data
  APM start and size :   3  7550  162

The Apple Partition Map (APM) marks the mount point of the internal HFS+
filesystem tree. If we are speaking of legacy, then this is the most
obsolete part of a grub-mkrescue ISO.

A description of the above listing format is put out by a run of
  xorriso -report_el_torito help -report_system_area help


Have a nice day :)

Thomas

[Nikolay Nikolov]

On 4/9/22 03:07, Chris Murphy wrote:
>  On Fri, Apr 8, 2022 at 4:31 PM Thomas Schmitt
> <scdbackup(a)gmx.net&gt; wrote:
>
>  Yeah, I'm not aware off hand of any UEFI that have a problem with the
>  first 440 bytes of LBA 0 being non-zero. 
If they did, then they would have problems with GPT disks, initialized 
by Windows 10, because Windows 10 puts its standard non-GPT aware 
bootloader code there. :)

Only Fedora-initialized disks have zeros there. :)

I can confirm this, because I have three disks (two 512GB SSDs and one 
2TB HDD) on my UEFI-enabled, dual booting between Windows 11 and Fedora, 
desktop computer.

>    I am aware though, of this
>  tianocore bug [1] where if the active bit on that 0xEE partition is
>  set, the GPT is considered invalid. This is now fixed in Tianocore,
>  but it might be widespread in firmware in hardware. But the idea would
>  be to not set this boot flag on our increasingly hypothetical future
>  ISOs because (a) it might cause UEFI to drop to an EFI shell, if this
>  bug is more widespread (b) we don't really want to work around buggy
>  BIOS firmware anyway, we want them to fail here rather than later.
>
>  Pretty sure I discovered this bug when testing Fedora 35 Cloud base
>  images, which are GPT with PMBR, and boot both BIOS and UEFI systems.
>  There's jump code in the first 440 bytes of LBA 0, pointing to the
>  core.img in BIOS Boot partition, and also there's an EFI system volume
>  that UEFI firmware discover.
>
>
> >> But if
> >> there are still some systems out there that will face plant on GPT
> >> anyway, it's probably best if they face plant when booting the
> >> installation media rather than getting all the way to a successful
> >> installation, just to face plant upon reboot.
> > Legacy BIOS does not care for partition tables. At least to my knowledge
> > from supporting production of bootable ISOs. My mileage may vary.
> > Problems with partitions will arise only after BIOS handed control to
> > the MBR x86 code on USB stick or the El Torito boot image on DVD.
>  Some legacy BIOS insist on seeing certain MBR structures in LBA 0 or
>  they face plant. This was why Fedora never proceeded with GPT by
>  default on BIOS systems. Too many at the time didn't like the PMBR for
>  one reason or another. I think the more common reason (?) was the
>  single partition in the PMBR didn't have BootIndicator set, hence
>  parted's pmbr_boot flag, which sets this bit.
>
>
> > Possibly this here describes what is needed for GRUB if started by
> > legacy BIOS and facing GPT:
> >    https://wiki.archlinux.org/title/GRUB#BIOS_systems
> > I understand that the GPT boot partition substitutes for the traditional
> > gap between MBR block and the start of the first MBR partition. 1 MiB
> > of "embedded area" if i remember correctly.
>  yeah that's what I'm calling BIOS boot partition type, it's partition
>  type GUID is 21686148-6449-6E6F-744E-656564454649 which grub-install
>  is looking for, and how it knows where to embed core.img. But as I
>  understand it, the code in the first 440 bytes of LBA 0, written by
>  grub-install as well, is just jump to the LBA for core.img. There's no
>  code to "teach" the computer how to read the GPT and go find BIOS
>  Boot. It's a hard coded LBA to just blindly jump to. 
I haven't looked at GRUB's MBR code, but there's enough space in the MBR 
to scan the GPT entries, find a specific GUID partition type and load 
the first several kilobytes from it and transfer control to it. And this 
is even without assuming 512-byte sectors. I know this, because I have 
written such code for my hobby DOS-like OS, which I want to be able to 
support GPT in BIOS legacy mode, so it can coexist with modern Windows 
and Linux distros (which boot in UEFI mode, while my OS boots in legacy 
mode - I can switch between the two modes from my UEFI boot menu).

Here's the code I've written (consider it proof of concept), but it can 
be used by GRUB as well:

https://sourceforge.net/p/fpcdos/code/HEAD/tree/trunk/src/gptboot/mbr.asm

The code takes up only 262 bytes so far, so it has plenty of bytes to 
spare (for e.g. nicer diagnostic error messages). The only thing it 
assumes is that the INT 13h LBA BIOS extensions are available - there's 
no CHS fallback support.

The code *doesn't* assume that the sectors size is 512 bytes, it doesn't 
assume the GPT partition it is looking for is in a specific position in 
the table, or starting on a specific LBA, it doesn't assume the number 
of GPT partitions are less than 128, it doesn't assume that GUID 
partition entries are 128-byte sized and it doesn't care about the 4 MBR 
partitions at all, it only searches through the GPT partitions.

The code assumes that the GPT partition table is correct, and doesn't do 
a lot of error checking, e.g. it doesn't check the CRC32 fields in the 
GPT header.

>
>> But grub-mkrescue ISOs have GPT without a dedicated boot partition.
>> Probably that job is fulfilled by the El Torito boot image which has a
>> few more KiB than the MBR x86 code.
>>
>> So i assume that face planting will happen only at later stages if the
>> booted system makes false assumptions like "GPT means EFI".
> Well it's been a long time since the GPT by default attempts, so I
> kinda forget how they manifested, though that information is probably
> in this list's archive :) My vague recollection is black screen.
> That's it. No error, no forward progress. Maybe some systems had an
> underscore character in the upper left corner? Maybe? Anyway, too many
> people hit it and it was canned so we never did it.
>
> If we can opt out of making a hybrid/faux MBR, and create a PMBR
> instead, that'd also mean there's one clear unambiguous partition map
> for USB sticks, which could make it easier to implement persistence.
>
> [1]
> https://bugzilla.tianocore.org/show_bug.cgi?id=3474
>
>
>
> --
> Chris Murphy
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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

[Thomas Schmitt]

Hi,

Nikolay Nikolov wrote:
>  I haven't looked at GRUB's MBR code, but there's enough
> space in the MBR to
>  scan the GPT entries, find a specific GUID partition type and load the first
>  several kilobytes from it and transfer control to it. 
Well, GRUB goes a different way on legacy BIOS. It boots its core code
without knowing about partitions and then loads the modules which its
configuration expects to need. I understand GPT is handled by "part_gpt"
and MBR partitions by "part_msdos".


>  The code takes up only 262 bytes so far 
It is astounding what can be squeezed into 440 bytes of x86 machine code.

-----------------------------------------------------------------------

I meanwhile learned that the El Torito boot image eltorito.img used by
grub-mkrescue is not a plain copy of cdboot.img but rather a
concatenation of cdboot.img and a core.img :

 
https://www.gnu.org/software/grub/manual/grub/grub.html#Making-a-GRUB-boo...
  "For booting from a CD-ROM, GRUB uses a special image called cdboot.img,
   which is concatenated with core.img. The core.img used for this should
   be built with at least the ‘iso9660’ and ‘biosdisk’ modules."

So the role of the BIOS partition is properly fulfilled by the El Torito
boot image which has 27874 bytes in my example ISO from grub-mkrescue.


Have a nice day :)

Thomas

[Thomas Schmitt]

Hi,

this is what i propose as boot layout of an entirely GRUB based ISO
which boots on EFI and not-so-buggy legacy BIOS from USB stick and DVD:

------------------------------------------------------------------------

$ xorriso -indev grub_mkrescue_gpt_appended.iso -report_el_torito plain
-report_system_area plain
...
El Torito catalog  : 165  1
El Torito cat path : /boot.catalog
El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt  Ldsiz         LBA
El Torito boot img :   1  BIOS  y   none  0x0000  0x00      4        2040
El Torito boot img :   2  UEFI  y   none  0x0000  0x00   5760        6043
El Torito img path :   1  /boot/grub/i386-pc/eltorito.img
El Torito img opts :   1  boot-info-table grub2-boot-info
El Torito img blks :   2  1440
System area options: 0x00004201
System area summary: MBR protective-msdos-label grub2-mbr cyl-align-off GPT
ISO image size/512 : 29996
Partition offset   : 16
MBR heads per cyl  : 64
MBR secs per head  : 32
MBR partition table:   N Status  Type        Start       Blocks
MBR partition      :   1   0x00  0xee            1        29995
GPT                :   N  Info
GPT disk GUID      :      e59ea280058a754fb57833ebe50cd3e0
GPT entry array    :      2  248  separated
GPT lba range      :      64  29932  29995
GPT partition name :   1  490053004f003900360036003000
GPT partname local :   1  ISO9660
GPT partition GUID :   1  e59ea280058a754fb57933ebe50cd3e0
GPT type GUID      :   1  a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags:   1  0x1000000000000001
GPT start and size :   1  64  24108
GPT partition name :   2  41007000700065006e006400650064003200
GPT partname local :   2  Appended2
GPT partition GUID :   2  e59ea280058a754fb57a33ebe50cd3e0
GPT type GUID      :   2  28732ac11ff8d211ba4b00a0c93ec93b
GPT partition flags:   2  0x0000000000000000
GPT start and size :   2  24172  5760

------------------------------------------------------------------------

$ /sbin/fdisk -l grub_mkrescue_gpt_appended.iso

Disk grub_mkrescue_gpt_appended.iso: 14.7 MiB, 15357952 bytes, 29996 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 80A29EE5-8A05-4F75-B578-33EBE50CD3E0

Device                          Start   End Sectors  Size Type
grub_mkrescue_gpt_appended.iso1    64 24171   24108 11.8M Microsoft basic data
grub_mkrescue_gpt_appended.iso2 24172 29931    5760  2.8M EFI System

------------------------------------------------------------------------

xorrisofs (minimum version 1.5.2) options would be:

  --grub2-mbr /usr/lib/grub/i386-pc/boot_hybrid.img
  -partition_offset 16
  -appended_part_as_gpt
  -append_partition 2 C12A7328-F81F-11D2-BA4B-00A0C93EC93B /...diskpath.../efiboot.img
  -iso_mbr_part_type EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  -c /boot/grub/boot.cat
  -b /boot/grub/i386-pc/eltorito.img
     -no-emul-boot -boot-load-size 4 -boot-info-table --grub2-boot-info
  -eltorito-alt-boot
  -e '--interval:appended_partition_2:all::'
     -no-emul-boot

They would replace these options from the current xorriso command with
Live ISOs as quoted by Chris Murphy:

>  -isohybrid-mbr /usr/share/syslinux/isohdpfx.bin
>  -b isolinux/isolinux.bin
>  -c isolinux/boot.cat
>  -boot-load-size 4 -boot-info-table -no-emul-boot
>  -eltorito-alt-boot
>  -e images/efiboot.img -no-emul-boot -isohybrid-gpt-basdat
>  -eltorito-alt-boot
>  -e images/macboot.img -no-emul-boot -isohybrid-gpt-hfsplus 
The file efiboot.img should not be in the ISO 9660 filesystem.

Similar to the old /isolinux/isolinux.bin ione has to bring a GRUB
El Torito BIOS image as /boot/grub/i386-pc/eltorito.img into the ISO 9660
filesystem, so that option -b finds it.
(eltorito.img gets made by grub-mkimage. But i am quite sure one can
 simply grab it from a grub-mkrescue ISO of the same GRUB version as
 used inside efiboot.img. Maybe one needs to move GRUB configuration
 lines out of a grub.conf in efiboot.img to a grub.conf in the ISO 9660
 filesystem, so that both boot paths can use them.)

Support would vanish for old pre-EFI Macs and for buggy legacy BIOS
which demands to see a boot/active flag in some MBR partition slot
if the ISO is presented on a USB stick.

The benefit iwould be to have a neat GPT instead of the current MBR
partition table with the mockup of a GPT and with the EFI partition
sitting inside the ISO 9660 partition.


Have a nice day :)

Thomas

[Nikolay Nikolov]

On 4/10/22 00:30, Thomas Schmitt wrote:
>  Hi,
>
>  Nikolay Nikolov wrote:
> > I haven't looked at GRUB's MBR code, but there's enough space in the MBR
> to
> > scan the GPT entries, find a specific GUID partition type and load the first
> > several kilobytes from it and transfer control to it.
>  Well, GRUB goes a different way on legacy BIOS. It boots its core code
>  without knowing about partitions and then loads the modules which its
>  configuration expects to need. I understand GPT is handled by "part_gpt"
>  and MBR partitions by "part_msdos".
>
>
> > The code takes up only 262 bytes so far
>  It is astounding what can be squeezed into 440 bytes of x86 machine code. 
Maybe I
should try adapting my code, so that it finds the GRUB BIOS boot 
partition and loads it? It shouldn't be too hard to do, the main 
obstacle is that I'm not familiar with GRUB's code and I don't know what 
GRUB's next stage needs (i.e. at what address it should be loaded, and 
how it should be called). But regarding size, core.img is apparently 
less than 32 kb, and it fits between the MBR and the first partition on 
MBR systems, and my code already loads almost 64kb from a GPT partition, 
so even if the next GRUB stage needs some special requirements (like 
moving to a different address, enabling gate A20, entering protected 
mode, etc), it can be done at least with a wrapper, but perhaps also 
even in the remaining bytes of my MBR code.
>  -----------------------------------------------------------------------
>
>  I meanwhile learned that the El Torito boot image eltorito.img used by
>  grub-mkrescue is not a plain copy of cdboot.img but rather a
>  concatenation of cdboot.img and a core.img :
>
>    
> https://www.gnu.org/software/grub/manual/grub/grub.html#Making-a-GRUB-boo...
>     "For booting from a CD-ROM, GRUB uses a special image called cdboot.img,
>      which is concatenated with core.img. The core.img used for this should
>      be built with at least the ‘iso9660’ and ‘biosdisk’ modules."
>
>  So the role of the BIOS partition is properly fulfilled by the El Torito
>  boot image which has 27874 bytes in my example ISO from grub-mkrescue.
Unfortunately, I'm not familiar with how El Torito works, I only 
understand the legacy PC boot process from floppy/hard disk/USB flash 
drive, but not from optical media. This hybrid USB stick/DVD iso image 
has always seemed like black magic to me :) And we've been spoiled and 
expect it to work, but I think it doesn't work with Windows 10, for 
example. :) AFAIK, Windows only provides an ISO download, that is 
suitable for burning on optical media and then it boots, but it doesn't 
work, when you "dd" it to an USB flash drive. I think you need to use 
special tool, to write it to a USB stick, but I've never done it, I 
still burn DVD+R for Windows installs :) And what's worse, they now 
require the rarer and more expensive DVD+R DL discs, since their install 
image exceeds 4.7 GB :)
>
>
> Have a nice day :)
>
> Thomas
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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

[Gary Buhrmaster]

On Wed, Apr 6, 2022 at 6:01 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:

>  Moving past the Big Three(tm), the actual
>  cloud providers that matter from a Fedora context are the smaller
>  outfits that principally serve Linux users. These are companies like
>  DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who
>  graciously do offer Fedora Linux in their platforms. All of their
>  virtualization platforms are BIOS only right now, and getting them to
>  switch requires them to uplift their platforms to support UEFI in the
>  first place. 
They may only support Linux users today, but if
they want to grow (and while it is possible to
survive as a niche service, many see growth
as the way to increased revenue/profits (go
big or go home)), they are going to get pushed
(perhaps kicking and screaming) to support
UEFI as at least an alternative moving forward
as some of their customers are going to prefer
using a single provider, and Windows 11
requires UEFI(*)(**), and it would be a shame
if only the big players were eligible for hosting
such services(***).

Many of these comments seem to be about
the date, not the end state (UEFI)(****),
just like 32-bit x86 and armv7.  No one wants
their personal ox gored, but there will come
a time when it will be time to let old systems
go.

"We" (and when I say "we", I understand that
is mostly not me), are going to have to
continue to document (and fix, where "we"
have the knowledge) the areas that need
improvement for UEFI booting and runtime.

Gary



(*) Technically it is possible to jump through
enough hoops to get Windows 11 to run on
BIOS only systems, but it is not supported,
and may break at any time.  Most people
prefer something that the vendor supports.

(**) Yes, some may prefer living in a
Windows-less world, but the reality is that
(especially at business scale) there are
services and applications that require
Windows today, and will likely require
Windows for a number of tomorrows.

(***) Yes, using multiple cloud providers
is often advantageous to avoid vendor
lock-in and provider failures, but scale
(at one provider) can result in savings
(both expense, and duplication of work
supporting the different providers' services).
There is statement by a VC regarding
startups which is (essentially) everyone
should start by using AWS, and then
have a plan to move off when their
scale is sufficient (of course, many
startups never survive sufficiently long
to move off, and others simply prefer
to spend their (precious) engineering
resources in other ways).

(****) Yes, some hope coreboot/linuxboot
can replace UEFI (and it can in some use
cases).  But unless/until MS embraces it,
UEFI is the answer (even if one is still
discussing the question that was asked).

[Thomas Schmitt]

Hi,

Nikolay Nikolov wrote:
>  Maybe I should try adapting my code, so that it finds the GRUB BIOS
> boot
>  partition and loads it? 
This would be a nice stunt for which we would have to find a use case.
As stated yesterday, the GRUB El Torito image contains a core.img which
serves the same purpose as a BIOS partition.


>  the main obstacle is
>  that I'm not familiar with GRUB's code and I don't know what GRUB's next
>  stage needs 
I myself only learn about GRUB at occasions like this here.
There is a vivid community at grub-devel(a)gnu.org. If you have an
interesting use case they might be willing to explain things. But on the
other hand the BIOS stuff is old and Vladimir Serbinenko, who created it,
is not very busy with GRUB any more.


>  Unfortunately, I'm not familiar with how El Torito works, 
Roughly:

At 2048-byte-LBA 17 (decimal) there is the Boot Record, which points to
the El Torito Boot Catalog. The catalog contains entries, which describe
boot images. In case of Fedora Live there are three of them: One for BIOS,
and two for EFI.

The boot image for BIOS is a plain x86 program. The first EFI image is
a FAT filesystem with boot programs /EFI/BOOT/BOOT*.EFI for the intended
processor architectures (x86-32bit, x86-64bit, ARM-32bit, ... ).

The second boot image for EFI (macboot.img) is actually a HFS+ filesystem
image which should not be listed in the catalog. That's a hack by Matthew
J. Garrett to let the rather dumb ISOLINUX program isohybrid.c find the
HFS+ image and mark it by an Apple Partition Map. isohybrid.c does not
understand ISO 9660 but it knows the El Torito boot catalog.
Fedora does not use isohybrid.c any more, but rather lets libisofs under
xorriso create the Apple Partition Map, if at all. Nevertheless, xorriso
produces the same inappropriate catalog entry for EFI, which the firmware
ignores in favor of the appropriate EFI boot image.
(Who am i to change mjg's invention ?)

My knowledge about boot lures for various processors and firmwares is
compiled at
  https://dev.lovelyhq.com/libburnia/libisofs/raw/branch/master/doc/boot_se...

Original specs:

El Torito:
 
http://web.archive.org/web/20010706014919/http://www.ibm.com/products/sur...
UEFI:
  https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf
Legacy BIOS:
  Only rumors around. Start exploring at Wikipedia. Re-use your knowledge
  about BIOS booting from floppy/hard disk/USB flash drive.


>  This hybrid USB stick/DVD iso image has always seemed
>  like black magic to me :) 
It's just a matter of outmost cramming of boot lures which are barely
compatible. (The unusual block size 2048 for Apple Partition Map
gives room for GPT. Some noop-x86 code at the start of the MBR lets
it look like the first block of an Apple Partition Map. It's just weird
from the view of specs and BIOS tradition. But it works since 10 years.)


>  AFAIK, Windows only
>  provides an ISO download, that is suitable for burning on optical media and
>  then it boots, but it doesn't work, when you "dd" it to an USB flash
> drive.
>  I think you need to use special tool, to write it to a USB stick, 
You are supposed to create a FAT filesystem in a MBR partition of the
USB stick with a traditional partition type like 0x0C. Then you copy all
files from the ISO 9660 filesystem into that FAT filesystem.
Et voila: An undocumented property of EFI implementations will find
and start /EFI/BOOT/BOOT*.EFI to boot MS-Windows.
(M$-Knowledge gained from Pete Batard, developer of program Rufus.)

Interestingly, Fedora Live ISOs have a /EFI/BOOT/ tree in the ISO 9660
filesystem, probably to support this feature. I learned about it from
Pete Batard's protests when Ubuntu began to produce ISOs which omitted
this copy of the EFI System Partition FAT content.


>  And what's worse,
>  they now require the rarer and more expensive DVD+R DL discs, since their
>  install image exceeds 4.7 GB :) 
Consider to invest in a Blu-ray burner. Single layer BD-R and BD-RE are
much more reliable than DVD+R DL and meanwhile at least BD-R are cheaper
than DVD+R DL. BD-RE cost about the same as DVD+RW with more than 5 times
the storage capacity. Still cheaper than 16 GB USB sticks.


Have a nice day :)

Thomas

[Nikolay Nikolov]

On 4/10/22 09:56, Thomas Schmitt wrote:
>  Hi,
>
>  Nikolay Nikolov wrote:
> > Maybe I should try adapting my code, so that it finds the GRUB BIOS boot
> > partition and loads it?
>  This would be a nice stunt for which we would have to find a use case.
>  As stated yesterday, the GRUB El Torito image contains a core.img which
>  serves the same purpose as a BIOS partition. 
The use case I'm thinking about is
not for the install image, but for 
hard disk installations in legacy BIOS mode, that use the GPT partition 
scheme, instead of the MBR partition scheme. In this case, with my MBR 
bootloader code, you still need the extra GRUB BIOS boot partition, but 
it can be moved anywhere on the disk, without breaking the bootloader. 
In the case of the traditional GRUB MBR code, you would need to boot 
from a rescue media and reinstall the bootloader, every time this 
partition is moved (or partition tools should treat it as unmovable, 
which reduces your flexibility). The disadvantage of my MBR boot code is 
that it doesn't support really old systems without the INT 13h LBA 
extensions. And you cannot detect in the distro installer whether the 
system supports these extensions or not, so if it's installed by 
default, some old systems would be rendered unbootable. In theory, 
anything that supports x86_64 should support these extensions (they were 
introduced in the Windows 95/98 times, when hard drives started hitting 
the 8 GB mark, while x86_64 appeared much later, in 2003, at the time 
hard drives were hitting 160GB-200GB as far as I can remember, and the 8 
GB limit was becoming a joke), however I don't know what's the reality, 
BIOSes are surprisingly buggy.
> > the main obstacle is
> > that I'm not familiar with GRUB's code and I don't know what GRUB's
> next
> > stage needs
>  I myself only learn about GRUB at occasions like this here.
>  There is a vivid community at grub-devel(a)gnu.org. If you have an
>  interesting use case they might be willing to explain things. But on the
>  other hand the BIOS stuff is old and Vladimir Serbinenko, who created it,
>  is not very busy with GRUB any more. 
Yeah, I'll join that mailing list and
explain the use case I have in 
mind (the one that I described above).
> > Unfortunately, I'm not familiar with how El Torito works,
>  Roughly:
>
>  At 2048-byte-LBA 17 (decimal) there is the Boot Record, which points to
>  the El Torito Boot Catalog. The catalog contains entries, which describe
>  boot images. In case of Fedora Live there are three of them: One for BIOS,
>  and two for EFI.
>
>  The boot image for BIOS is a plain x86 program. The first EFI image is
>  a FAT filesystem with boot programs /EFI/BOOT/BOOT*.EFI for the intended
>  processor architectures (x86-32bit, x86-64bit, ARM-32bit, ... ).
>
>  The second boot image for EFI (macboot.img) is actually a HFS+ filesystem
>  image which should not be listed in the catalog. That's a hack by Matthew
>  J. Garrett to let the rather dumb ISOLINUX program isohybrid.c find the
>  HFS+ image and mark it by an Apple Partition Map. isohybrid.c does not
>  understand ISO 9660 but it knows the El Torito boot catalog.
>  Fedora does not use isohybrid.c any more, but rather lets libisofs under
>  xorriso create the Apple Partition Map, if at all. Nevertheless, xorriso
>  produces the same inappropriate catalog entry for EFI, which the firmware
>  ignores in favor of the appropriate EFI boot image.
>  (Who am i to change mjg's invention ?)
>
>  My knowledge about boot lures for various processors and firmwares is
>  compiled at
>     https://dev.lovelyhq.com/libburnia/libisofs/raw/branch/master/doc/boot_se...
>
>  Original specs:
>
>  El Torito:
>    
> http://web.archive.org/web/20010706014919/http://www.ibm.com/products/sur...
>  UEFI:
>     https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf
>  Legacy BIOS:
>     Only rumors around. Start exploring at Wikipedia. Re-use your knowledge
>     about BIOS booting from floppy/hard disk/USB flash drive. 
Thanks for the
explanation and the links. I'll check them out.
> > This hybrid USB stick/DVD iso image has always seemed
> > like black magic to me :)
>  It's just a matter of outmost cramming of boot lures which are barely
>  compatible. (The unusual block size 2048 for Apple Partition Map
>  gives room for GPT. Some noop-x86 code at the start of the MBR lets
>  it look like the first block of an Apple Partition Map. It's just weird
>  from the view of specs and BIOS tradition. But it works since 10 years.) 
I imagine it is like those polyglot programs, that are simultaneously 
valid in several totally different programming languages:

https://en.wikipedia.org/wiki/Polyglot_(computing)

> > AFAIK, Windows only
> > provides an ISO download, that is suitable for burning on optical media and
> > then it boots, but it doesn't work, when you "dd" it to an USB flash
> drive.
> > I think you need to use special tool, to write it to a USB stick,
>  You are supposed to create a FAT filesystem in a MBR partition of the
>  USB stick with a traditional partition type like 0x0C. Then you copy all
>  files from the ISO 9660 filesystem into that FAT filesystem.
>  Et voila: An undocumented property of EFI implementations will find
>  and start /EFI/BOOT/BOOT*.EFI to boot MS-Windows.
>  (M$-Knowledge gained from Pete Batard, developer of program Rufus.)
>
>  Interestingly, Fedora Live ISOs have a /EFI/BOOT/ tree in the ISO 9660
>  filesystem, probably to support this feature. I learned about it from
>  Pete Batard's protests when Ubuntu began to produce ISOs which omitted
>  this copy of the EFI System Partition FAT content. 
Interesting and weird, like all
things, related to the PC booting process :)
> > And what's worse,
> > they now require the rarer and more expensive DVD+R DL discs, since their
> > install image exceeds 4.7 GB :)
>  Consider to invest in a Blu-ray burner. Single layer BD-R and BD-RE are
>  much more reliable than DVD+R DL and meanwhile at least BD-R are cheaper
>  than DVD+R DL. BD-RE cost about the same as DVD+RW with more than 5 times
>  the storage capacity. Still cheaper than 16 GB USB sticks. 
Actually, I have already
invested in a Blu-ray burner, I just haven't 
purchased any BD-R or BD-RE install media, so I haven't even tested the 
Blu-ray burning :) BD-R is hard to find and more expensive than 
DVD-R/DVD+R here, so I should order online. The other reason I'm using 
DVD+R DL is compatibility, not all computers have a Blu-ray drive. I 
have only one on my desktop, while all virtually all my laptops that 
have an optical drive can read DVD (and for the ones that don't have an 
optical drive, I have an external USB DVD drive). I guess, I should also 
invest in an external USB Blu-ray drive, but it's not a high priority 
purchase for me. :)
>
>
> Have a nice day :)
>
> Thomas
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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

[Nikolay Nikolov]

On 4/10/22 05:50, Gary Buhrmaster wrote:
>  On Wed, Apr 6, 2022 at 6:01 PM Neal Gompa <ngompa13(a)gmail.com&gt;
> wrote:
>
> > Moving past the Big Three(tm), the actual
> > cloud providers that matter from a Fedora context are the smaller
> > outfits that principally serve Linux users. These are companies like
> > DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who
> > graciously do offer Fedora Linux in their platforms. All of their
> > virtualization platforms are BIOS only right now, and getting them to
> > switch requires them to uplift their platforms to support UEFI in the
> > first place.
>  They may only support Linux users today, but if
>  they want to grow (and while it is possible to
>  survive as a niche service, many see growth
>  as the way to increased revenue/profits (go
>  big or go home)), they are going to get pushed
>  (perhaps kicking and screaming) to support
>  UEFI as at least an alternative moving forward
>  as some of their customers are going to prefer
>  using a single provider, and Windows 11
>  requires UEFI(*)(**), and it would be a shame
>  if only the big players were eligible for hosting
>  such services(***).
>
>  Many of these comments seem to be about
>  the date, not the end state (UEFI)(****),
>  just like 32-bit x86 and armv7.  No one wants
>  their personal ox gored, but there will come
>  a time when it will be time to let old systems
>  go. 
Yes, but the whole point is that it's way too early. Windows 10 still 
supports not only legacy BIOS, but also i686 (which Fedora has dropped 
support for in Fedora 31; Fedora 30 was EOL'd in May 2020) and Windows 
10 will be supported until at least October 14, 2025. For comparison, 
Fedora 36 will be EOL'd in May 2023.
>  "We" (and when I say "we", I understand that
>  is mostly not me), are going to have to
>  continue to document (and fix, where "we"
>  have the knowledge) the areas that need
>  improvement for UEFI booting and runtime.
>
>  Gary
>
>
>
>  (*) Technically it is possible to jump through
>  enough hoops to get Windows 11 to run on
>  BIOS only systems, but it is not supported,
>  and may break at any time.  Most people
>  prefer something that the vendor supports. 
BIOS-only users can stay on Windows 10. They have very little reason to 
upgrade to Windows 11. It's mostly cosmetic changes to the UI and 
there's no major software product that requires Windows 11, but doesn't 
run on Windows 10. Adoption of new Windows versions has always been 
painstakingly slow, even after the old version is EOL'd, people continue 
to use it (I know it's a bad idea, but people do it anyway - look at how 
much time it took for people to upgrade from Windows XP, after it was 
EOL'd). But Windows 10 is still supported, so it can be used, it's not 
more dangerous than Windows 11.

So the question is, why should cloud providers care about Windows 11? 
Long term, yes, they do care, but none of their Windows users are in a 
hurry to upgrade, they are fine staying on Windows 10 until 2025, 
there's nothing in Windows 11 that makes it worth upgrading (in my 
personal opinion), especially not for server/cloud use. I must check 
this (please correct me if I'm wrong), but I think Windows Server 2019 
still supports legacy BIOS and has extended support until January 2029.

>  (**) Yes, some may prefer living in a
>  Windows-less world, but the reality is that
>  (especially at business scale) there are
>  services and applications that require
>  Windows today, and will likely require
>  Windows for a number of tomorrows. 
Like I said, Windows 10 supports i686 + Legacy
BIOS, as well as x86_64 + 
Legacy BIOS until at least October 14, 2025.
>  (***) Yes, using multiple cloud providers
>  is often advantageous to avoid vendor
>  lock-in and provider failures, but scale
>  (at one provider) can result in savings
>  (both expense, and duplication of work
>  supporting the different providers' services).
>  There is statement by a VC regarding
>  startups which is (essentially) everyone
>  should start by using AWS, and then
>  have a plan to move off when their
>  scale is sufficient (of course, many
>  startups never survive sufficiently long
>  to move off, and others simply prefer
>  to spend their (precious) engineering
>  resources in other ways).
>
>  (****) Yes, some hope coreboot/linuxboot
>  can replace UEFI (and it can in some use
>  cases).  But unless/until MS embraces it,
>  UEFI is the answer (even if one is still
>  discussing the question that was asked). 
I believe the PC-compatible coreboot
payloads are the way to go - either 
coreboot+SeaBIOS or coreboot+TianoCore. I don't know what's the state of 
TianoCore and whether it works on real hardware. I have one working 
system with coreboot+SeaBIOS (it's a Chromebook) and I'd like to be able 
to use it.
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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

[Thomas Schmitt]

Hi,

Nikolay Nikolov wrote:
>  I imagine it is like those polyglot programs, that are simultaneously
> valid
>  in several totally different programming languages: 
Yep. A boot-everywhere ISO for x86 is quite like that.
Every firmware variant can see in it what it expects.


>  Actually, I have already invested in a Blu-ray burner, I just
> haven't
>  purchased any BD-R or BD-RE install media, so I haven't even tested the
>  Blu-ray burning :) 
Then it's about time. :))
I propose to backup a few GiB of your favorite data by xorriso and update
that backup daily until the medium is full. See in
  https://www.gnu.org/software/xorriso/
the example
  "The following command performs incremental backup."

(I apologize to the list for this off-topic advertising of my program.)


Have a nice day :)

Thomas

[Neal Gompa]

On Sat, Apr 9, 2022 at 10:51 PM Gary Buhrmaster
<gary.buhrmaster(a)gmail.com&gt; wrote:
>  On Wed, Apr 6, 2022 at 6:01 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>
>  > Moving past the Big Three(tm), the actual
>  > cloud providers that matter from a Fedora context are the smaller
>  > outfits that principally serve Linux users. These are companies like
>  > DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who
>  > graciously do offer Fedora Linux in their platforms. All of their
>  > virtualization platforms are BIOS only right now, and getting them to
>  > switch requires them to uplift their platforms to support UEFI in the
>  > first place.
>
>  They may only support Linux users today, but if
>  they want to grow (and while it is possible to
>  survive as a niche service, many see growth
>  as the way to increased revenue/profits (go
>  big or go home)), they are going to get pushed
>  (perhaps kicking and screaming) to support
>  UEFI as at least an alternative moving forward
>  as some of their customers are going to prefer
>  using a single provider, and Windows 11
>  requires UEFI(*)(**), and it would be a shame
>  if only the big players were eligible for hosting
>  such services(***).
>
>  Many of these comments seem to be about
>  the date, not the end state (UEFI)(****),
>  just like 32-bit x86 and armv7.  No one wants
>  their personal ox gored, but there will come
>  a time when it will be time to let old systems
>  go.
>
>  "We" (and when I say "we", I understand that
>  is mostly not me), are going to have to
>  continue to document (and fix, where "we"
>  have the knowledge) the areas that need
>  improvement for UEFI booting and runtime.
>  
Windows is a niche in the server space, rather than the default. And
Microsoft didn't even remove the server exception to continue using
BIOS until last year from the Windows platform qualification
documentation. It's *definitely* going to be a while, especially with
Windows Server 2019 being supported until the end of the decade.

Windows 11 *does not matter* here. Windows Server is what matters
here, and there are no announced Windows Server versions following the
Windows 11 platform requirements.




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

[Neal Gompa]

On Fri, Apr 8, 2022 at 2:23 PM Robbie Harwood <rharwood(a)redhat.com&gt; wrote:
>  Michel Alexandre Salim <salimma(a)fedoraproject.org&gt; writes:
>
>  > - as I stated, there are offers to help with getting syslinux replaced
>  >   with GRUB. what I've not stated originally is Chris Murphy brought up
>  >   protective MBR and switching all new installs to inst.gpt, which let
>  >   us future proof new installations for when we do kill off legacy BIOS.
>  >
>  > What people who want to help needs, though, is some sense that our
>  > contributions are welcome.
>
>  (If you're looking for me to comment on proposals to change live media
>  generation and installs, I can't really do that - that's Brian's and
>  Jiri's areas of expertise.)
>
>  > - Neal pointed out he has been working on addressing this for a while,
>  >   and have not put up a Change Proposal because he thought it was
>  >   premature
>
>  While Neal's contributions are as welcome as anyone else's, Neal is not
>  a maintainer of (or regular contributor to) bootloader packages and it
>  would be very strange for Neal to propose such a change without
>  discussing it with us first.  That said, if there was suggestion of such
>  a proposal, I have missed it (which is very possible given the size of
>  the thread at this point).
>  
Alright, I'll bite. I am within my rights to propose any Change I want
for Fedora Cloud, which I help steward with David Duncan.

For Fedora Cloud, we've been discussing what we want to support going
forward. I added hybrid boot support[1] in Fedora Linux 35
specifically so that we can start working on adding Fedora Cloud to
Azure, who prefers UEFI for its Hyper-V VMs[2], but also supports
legacy BIOS. We decided to not propose a Change to deprecate BIOS
support yet specifically because we needed to have conversations with
the various VPSes that people *actually use Fedora* on before we do
that[3]. I was completely thrown by this Change proposal because it
threatens to poison the conversations that Fedora Cloud wants to have
with its actual stakeholders for a less acrimonious transition.

As an aside, I examined the state of all release blocking Fedora
deliverables, and something I noticed is that only the Workstation WG
has Red Hatters actively engaged in it. That means that this Change
comes with absolutely no understanding of the state of the world in
Fedora across the various WGs and SIGs that deliver release-blocking
artifacts. That in itself isn't necessarily a problem, but the fact
that none of you are listening to us (David Duncan and myself for
Cloud and KDE, Chris Murphy for Cloud and Workstation, and Peter Boy
for Server) when we tell you this is too early is extremely tone-deaf.

None of us want to keep supporting BIOS forever, but we all have
*real-world experience* saying that we can't do this yet. We're trying
to find a way to meet halfway to simplify legacy BIOS support, but
you're not listening to us. We've also been trying to tell you that
there are *real problems* with Fedora's UEFI support that need fixing
before we can cut off BIOS support, but you're not listening to us.

This thread has, at the time of my writing this post, has 269 posts
across 62 individuals. It is the most active thread we've had since
the switch to nano by default. However, unlike that change, almost
every single respondent has brought up feedback in this discussion
saying that we're not ready and providing examples of why we're not
ready. However, you're *not listening*.

I understand you want to drop BIOS support before Fedora Linux 40 is
branched into RHEL 10. Obviously you could drop it in RHEL 10 even if
Fedora doesn't, but it'd be better to drop it in Fedora first and make
sure everything is flushed out. I would be fine with us doing that if
there was some expectation that the UEFI experience in Fedora Linux
was going to improve to resolve the issues people have *now* by the
time we get there.

And we can take incremental steps to get there, even now:

1. Switch Anaconda to default to GPT even on BIOS setups
2. Drop syslinux and use GRUB everywhere
3. Configure new installations to always do hybrid boot installations
4. Develop documentation and/or tooling to do MBR->GPT conversions and
reconfigure for hybrid boot for existing systems

These are all reasonably achievable things we can do. And that gives
us time to work our relationships with our stakeholders to prepare
them for the day legacy BIOS support is gone from the entire Red Hat
family of distributions. It also gives room for improving the UEFI
experience so it's *at least* as good as the BIOS one, if not better.
Right now, it's not. And it needs to be in order to maintain the
momentum we have now where Fedora Linux adoption is growing by leaps
and bounds over the last couple of years.

[1]: https://fedoraproject.org/wiki/Changes/FedoraCloudHybridBoot
[2]: https://pagure.io/cloud-sig/issue/309
[3]: https://pagure.io/cloud-sig/issue/345


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

[Nikolay Nikolov]

On 4/10/22 16:27, Neal Gompa wrote:
>  On Sat, Apr 9, 2022 at 10:51 PM Gary Buhrmaster
>  <gary.buhrmaster(a)gmail.com&gt; wrote:
> > On Wed, Apr 6, 2022 at 6:01 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
> >
> >> Moving past the Big Three(tm), the actual
> >> cloud providers that matter from a Fedora context are the smaller
> >> outfits that principally serve Linux users. These are companies like
> >> DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who
> >> graciously do offer Fedora Linux in their platforms. All of their
> >> virtualization platforms are BIOS only right now, and getting them to
> >> switch requires them to uplift their platforms to support UEFI in the
> >> first place.
> > They may only support Linux users today, but if
> > they want to grow (and while it is possible to
> > survive as a niche service, many see growth
> > as the way to increased revenue/profits (go
> > big or go home)), they are going to get pushed
> > (perhaps kicking and screaming) to support
> > UEFI as at least an alternative moving forward
> > as some of their customers are going to prefer
> > using a single provider, and Windows 11
> > requires UEFI(*)(**), and it would be a shame
> > if only the big players were eligible for hosting
> > such services(***).
> >
> > Many of these comments seem to be about
> > the date, not the end state (UEFI)(****),
> > just like 32-bit x86 and armv7.  No one wants
> > their personal ox gored, but there will come
> > a time when it will be time to let old systems
> > go.
> >
> > "We" (and when I say "we", I understand that
> > is mostly not me), are going to have to
> > continue to document (and fix, where "we"
> > have the knowledge) the areas that need
> > improvement for UEFI booting and runtime.
> >
>  Windows is a niche in the server space, rather than the default. And
>  Microsoft didn't even remove the server exception to continue using
>  BIOS until last year from the Windows platform qualification
>  documentation. It's *definitely* going to be a while, especially with
>  Windows Server 2019 being supported until the end of the decade. 
Just tested
installing Windows Server 2019 in a QEMU virtual machine on 
a 40 GB virtual hard disk and 2 GB RAM. It formatted the disk as MBR and 
installed just fine, no warnings, no deprecations, no nothing. 
Mainstream support for Windows Server 2019 ends in January 9, 2024, 
extended support lasts until January 9, 2029.
>  Windows 11 *does not matter* here. Windows Server is what matters
>  here, and there are no announced Windows Server versions following the
>  Windows 11 platform requirements. 
I agree. IMO, Windows 11 is only good for home
desktop use (and for that 
purpose, Windows 10 is just as good, there are only cosmetic differences 
in the UI), it is irrelevant for servers, because of the artificial 
restrictions that Microsoft puts on their desktop operating systems 
(limited number of connections, limited number of websites you can host 
in IIS, etc.) in order to boost their Windows Server sales. Ironically, 
due to this fact, Windows Server works better as a desktop, than Windows 
10 or 11 as a server. At work we use Windows Server for web development 
in Visual Studio, because it just works better, e.g. you can deploy 
multiple web sites on your machine, etc. :)
>
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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

[Zbigniew Jędrzejewski-Szmek]

On Sun, Apr 10, 2022 at 10:27:25AM -0400, Neal Gompa wrote:
>  And we can take incremental steps to get there, even now:
>  
>  1. Switch Anaconda to default to GPT even on BIOS setups
>  2. Drop syslinux and use GRUB everywhere
>  3. Configure new installations to always do hybrid boot installations
>  4. Develop documentation and/or tooling to do MBR->GPT conversions and
>  reconfigure for hybrid boot for existing systems
>  
>  These are all reasonably achievable things we can do. And that gives
>  us time to work our relationships with our stakeholders to prepare
>  them for the day legacy BIOS support is gone from the entire Red Hat
>  family of distributions. It also gives room for improving the UEFI
>  experience so it's *at least* as good as the BIOS one, if not better.
>  Right now, it's not. And it needs to be in order to maintain the
>  momentum we have now where Fedora Linux adoption is growing by leaps
>  and bounds over the last couple of years. 
This is a very concrete actionable and achievable proposal. /me likes.

Zbyszek

[Zbigniew Jędrzejewski-Szmek]

On Thu, Apr 07, 2022 at 10:43:02AM +0200, Lennart Poettering wrote:
>  On Mi, 06.04.22 07:33, Neal Gompa (ngompa13(a)gmail.com) wrote:
>  > Irrespective of this change, I would flat-out oppose moving to
>  > sd-boot. In any case, you can't use sd-boot for live media.
>  >
>  > If we were going to move to pure EFI boot manager, I'd rather use one
>  > that has a decent user experience and not a barebones crappy one.
>  
>  OK, I'll bite.
>  
>  What are you missing in sd-boot, specifically?
>  
>  Also, why would a boot menu need a particularly fancy user experience?
>  It's a boot manager, not a web browser. 
"barebones crappy one" is pretty strong. I'm too am interested in
hearing what is so wrong with the sd-boot experience.

Zbyszek

[Dominik 'Rathann' Mierzejewski]

On Friday, 08 April 2022 at 13:41, Vitaly Zaitsev via devel wrote:
>  On 08/04/2022 09:54, Dominik 'Rathann' Mierzejewski wrote:
>  > I already did. Isn't that what I wrote?
>  
>  Can you post their answer? 
Yes:
```
On VPS, we do not provide images with UEFI enabled.
```

They support UEFI on their Public Cloud instances, but the same
configuration as my current VPS seems to be twice as expensive.

I've asked them to clarify if they have any plans to enable UEFI for
their VPS instances.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Dominik 'Rathann' Mierzejewski]

On Friday, 08 April 2022 at 19:14, Brian C. Lane wrote:
[...]
>  So like I said yesterday, I'll look into switching to use grub2
> for
>  Fedora 37, assuming grub2 continues to support BIOS. 
Thank you very much! From my side, I've found another BIOS-only machine
in my junkyard and I'm willing to put both up for testing any changes
and maybe even help write some code if time permits.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Dominik 'Rathann' Mierzejewski]

On Friday, 08 April 2022 at 16:14, Zamir SUN wrote:
[...]
>  Probably it isn't a problem for some users, but I'm still
> having bad
>  experience with UEFI on x86_64 now. Out of my 3 machines I only have 1
>  system that works fine with UEFI. And my parents' laptop was purchased
>  2 years ago and the UEFI firmware does not allow to boot anything
>  other than Windows on UEFI mode (regardless of turning secure boot on
>  or off) and I have to switch to BIOS mode to make Fedora work there.
>  So in this situation, I think it's way too aggressive to accept the
>  change - this will probably drive away some potential new users with
>  decent laptop like my parents'. 
Have you tried renaming your Fedora boot entry to "Windows Boot
Manager"? I have one Sony laptop that boots only the boot entry with
that exact name.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Neal Gompa]

On Sun, Apr 10, 2022 at 4:37 PM Dominik 'Rathann' Mierzejewski
<dominik(a)greysector.net&gt; wrote:
>  On Friday, 08 April 2022 at 16:14, Zamir SUN wrote:
>  [...]
>  > Probably it isn't a problem for some users, but I'm still having bad
>  > experience with UEFI on x86_64 now. Out of my 3 machines I only have 1
>  > system that works fine with UEFI. And my parents' laptop was purchased
>  > 2 years ago and the UEFI firmware does not allow to boot anything
>  > other than Windows on UEFI mode (regardless of turning secure boot on
>  > or off) and I have to switch to BIOS mode to make Fedora work there.
>  > So in this situation, I think it's way too aggressive to accept the
>  > change - this will probably drive away some potential new users with
>  > decent laptop like my parents'.
>
>  Have you tried renaming your Fedora boot entry to "Windows Boot
>  Manager"? I have one Sony laptop that boots only the boot entry with
>  that exact name.
>  
I wonder if this would work with one of my old machines too. I've
never thought to rename the boot entry in the firmware before...


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

[Gabriel Ramirez]

On 4/10/22 16:10, Neal Gompa wrote:
>  On Sun, Apr 10, 2022 at 4:37 PM Dominik 'Rathann'
> Mierzejewski
>  <dominik(a)greysector.net&gt; wrote:
> > On Friday, 08 April 2022 at 16:14, Zamir SUN wrote:
> > [...]
> >> Probably it isn't a problem for some users, but I'm still having bad
> >> experience with UEFI on x86_64 now. Out of my 3 machines I only have 1
> >> system that works fine with UEFI. And my parents' laptop was purchased
> >> 2 years ago and the UEFI firmware does not allow to boot anything
> >> other than Windows on UEFI mode (regardless of turning secure boot on
> >> or off) and I have to switch to BIOS mode to make Fedora work there.
> >> So in this situation, I think it's way too aggressive to accept the
> >> change - this will probably drive away some potential new users with
> >> decent laptop like my parents'.
> > Have you tried renaming your Fedora boot entry to "Windows Boot
> > Manager"? I have one Sony laptop that boots only the boot entry with
> > that exact name.
> >
>  I wonder if this would work with one of my old machines too. I've
>  never thought to rename the boot entry in the firmware before...
>
>  
about "Windows Boot Manager" efi entry required to boot: 
https://mjg59.dreamwidth.org/20187.html

the above happens too with the lenovo thinkcentre m91

[Neal Gompa]

On Sun, Apr 10, 2022 at 7:08 PM Gabriel Ramirez <gabrielo(a)aekert.com&gt; wrote:
>  On 4/10/22 16:10, Neal Gompa wrote:
>  > On Sun, Apr 10, 2022 at 4:37 PM Dominik 'Rathann' Mierzejewski
>  > <dominik(a)greysector.net&gt; wrote:
>  >> On Friday, 08 April 2022 at 16:14, Zamir SUN wrote:
>  >> [...]
>  >>> Probably it isn't a problem for some users, but I'm still having
> bad
>  >>> experience with UEFI on x86_64 now. Out of my 3 machines I only have 1
>  >>> system that works fine with UEFI. And my parents' laptop was purchased
>  >>> 2 years ago and the UEFI firmware does not allow to boot anything
>  >>> other than Windows on UEFI mode (regardless of turning secure boot on
>  >>> or off) and I have to switch to BIOS mode to make Fedora work there.
>  >>> So in this situation, I think it's way too aggressive to accept the
>  >>> change - this will probably drive away some potential new users with
>  >>> decent laptop like my parents'.
>  >> Have you tried renaming your Fedora boot entry to "Windows Boot
>  >> Manager"? I have one Sony laptop that boots only the boot entry with
>  >> that exact name.
>  >>
>  > I wonder if this would work with one of my old machines too. I've
>  > never thought to rename the boot entry in the firmware before...
>  >
>  >
>
>  about "Windows Boot Manager" efi entry required to boot:
>  https://mjg59.dreamwidth.org/20187.html
>
>  the above happens too with the lenovo thinkcentre m91 
From the blog post:
>  For now, if you want to run Fedora[2] on these systems you're
> probably best off changing the firmware to perform a legacy boot. 
*sigh*


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

[Gary Buhrmaster]

On Sun, Apr 10, 2022 at 1:27 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:

>  Windows 11 *does not matter* here. 
(Windows) Desktop as a Service (DaaS)[0] may
change that faster than some expect (or faster
than some hope).  There is a large push by
some orgs to move services off premise
into the cloud (for a number of stated reasons
including zero trust and WfH scenarios).

And while I have zero plans to give up my
linux systems in favor of cloud desktops,
and some of the push for DaaS may be
more hype than real, I do agree that there
are valid use cases, and that is going to
push some to support UEFI in the future.

Gary

[0] And certain SaaS application solutions.

[Neal Gompa]

On Sun, Apr 10, 2022 at 11:06 PM Gary Buhrmaster
<gary.buhrmaster(a)gmail.com&gt; wrote:
>  On Sun, Apr 10, 2022 at 1:27 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>
>  > Windows 11 *does not matter* here.
>
>  (Windows) Desktop as a Service (DaaS)[0] may
>  change that faster than some expect (or faster
>  than some hope).  There is a large push by
>  some orgs to move services off premise
>  into the cloud (for a number of stated reasons
>  including zero trust and WfH scenarios).
>
>  And while I have zero plans to give up my
>  linux systems in favor of cloud desktops,
>  and some of the push for DaaS may be
>  more hype than real, I do agree that there
>  are valid use cases, and that is going to
>  push some to support UEFI in the future.
>  
The economics of Windows in the cloud is not great unless you're on
Azure, where Microsoft can give itself preferential pricing. And most
people that use Fedora in the Cloud aren't using Azure (or AWS or GCP
for that matter).


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

[Dominik 'Rathann' Mierzejewski]

On Sunday, 10 April 2022 at 22:30, Dominik 'Rathann' Mierzejewski wrote:
>  On Friday, 08 April 2022 at 13:41, Vitaly Zaitsev via devel wrote:
>  > On 08/04/2022 09:54, Dominik 'Rathann' Mierzejewski wrote:
>  > > I already did. Isn't that what I wrote?
>  > 
>  > Can you post their answer?
>  
>  Yes:
>  ```
>  On VPS, we do not provide images with UEFI enabled.
>  ```
>  
>  They support UEFI on their Public Cloud instances, but the same
>  configuration as my current VPS seems to be twice as expensive.
>  
>  I've asked them to clarify if they have any plans to enable UEFI for
>  their VPS instances. 
And their answer is:
```
Currently we do not have any plans for enabling UEFI booting with VPS.
```

So, if this change went ahead as planned, it would cost me twice as much
as I'm paying OVH right now to (re-)install Fedora 37+ on their hosting,
because I'd have to switch to a different, more expensive service.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Chris Murphy]

On Sat, Apr 9, 2022 at 1:51 AM Thomas Schmitt <scdbackup(a)gmx.net&gt; wrote:
>  Hi,
>
>  > OK so there isn't (yet) an option to embed the GRUB core.img in a GPT
>  > BIOS boot partition, I take it? The assumption is MBR? On hard drives,
>  > core.img goes in the MBR gap. I'm not sure where it goes on xorriso
>  > produced ISOs though, but presumably not the gap because there's a
>  > valid GPT there too.
>
>  One could probably use core.img for booting from USB stick. But it would
>  not obsolete the x86 code in MBR and it currently is not necessary for
>  grub-mkrescue ISOs because eltorito.img does a job equivalent to core.img.
>  eltorito.img is stored in the ISO 9660 filesystem as normal data file.
>  The MBR x86 code transfers execution to it and the El Torito catalog has
>  it as boot image for x86 legacy BIOS. 
At least with the BIOS firmware without a bug, the GRUB LBA 0 code
jumps direct to core.img, no instruction on how to read the GPT and
find the core.img from BIOS boot partition.


>  > Yeah, I'm not aware off hand of any UEFI that have a problem
> with the
>  > first 440 bytes of LBA 0 being non-zero. I am aware though, of this
>  > tianocore bug [1] where if the active bit on that 0xEE partition is
>  > set, the GPT is considered invalid.
>
>  That's why grub-mkrescue lets xorriso produce a pure GPT with no
>  boot/active flag at the 0xEE partition. But this lets old HP laptops
>  refuse to boot from USB stick.
>  A foul compromise is to add another MBR partition of type 0x00 with
>  boot/active flag. EFI is known to ignore it, but HP legacy BIOS takes it
>  as reason to run the MBR x86 code (which is not related to partitions).
>
>
>  > (b) we don't really want to work around buggy
>  > BIOS firmware anyway, we want them to fail here rather than later.
>
>  That's a harsh decision but would match the purpose of this thread, indeed.
>  If so, then producing a pure GPT instead of the current jackalope seems
>  the way to go. grub-mkrescue will point the way or could even be the
>  solution to go for. 
Still another idea might be to create a "legacy" image variant of
Everything ISO that does things exactly as we do them today. That way
there is a fallback for one image that isn't release blocking, for as
long as it can be maintained. The one thing I think we'd still need to
tweak sooner than later is swapping isolinux with GRUB.

A legacy/fallback image (or two) would provide some breathing room to
remove more legacy layers. Including possibly even ISO 9660. If
Everything ISO is for that use case, desktop and server images can
focus on being USB centric, including supporting persistence out of
the box.


>  I would propose to care for a mountable ISO 9660 partition, by moving
>  the EFI boot image / EFI system partition out of the filesystem and
>  rather appending it as extra partition. An example can be created by
>  MKRESCUE_SED_MODE=gpt_appended with script frontend/grub-mkrescue-sed.sh
>  out of libisoburn.)
>  Further one would need xorrisofs option
>    -partition_offset 16
>  so that a mountable GPT partition can be created which starts at 512-block
>  address 64, i.e. after the GPT partition table data. This wastes some
>  space because a second directory tree has to be generated additionally to
>  the normal directory tree which will be used when booting or mounting
>  the ISO from a DVD.
>  The waste would not be much with Fedora Live ISOs. In 3-year-old
>  Fedora-Workstation-Live-x86_64-31-1.9.iso the first data file is already
>  at 2048-block address 43. That would be at most 23 * 2048 bytes for the
>  directory records which form the file tree (43 - 16 blocks System Area -
>  4 blocks of Volume Descriptors). So the waste would be <= 46 KiB.
>
>  At that occasion consider to drop the HFS+ Mac boot image and the Apple
>  Partition map which marks it for some obscure non-EFI x86 Macs. I.e.
>  consider to remove from the current xorrisofs command the options
>    -eltorito-alt-boot
>    -e images/macboot.img -no-emul-boot -isohybrid-gpt-hfsplus
>  and try to find a Mac which misses this boot image and refuses to boot
>  but boots with the original ISO. 
I have a 2011 Mac. Virtually certain ages ago I booted an openSUSE ISO
from USB stick, no problem, and it had no special tricks liks Fedora
is using (HFS+ and mactel boot).



>  > If we can opt out of making a hybrid/faux MBR, and create a
> PMBR
>  > instead, that'd also mean there's one clear unambiguous partition map
>  > for USB sticks, which could make it easier to implement persistence.
>
>  A PMBR is an MBR at the start of a partition and gets activated only
>  if the device MBR decides to do so. Sometimes there is MBR code on newly
>  bought USB sticks which looks for a partition with boot/active flag and
>  then chain-loads the PMBR from there.
>  But in an EL Torito bootable ISO this makes few sense. The little
>  hybrid MBR and the larger BIOS boot image can do everything that is
>  needed.
>
>  A neat partition map is indeed a valuable goal. To my knowledge it can
>  only be achieved by dropping support for the buggy legacy BIOSes which
>  demand to see an MBR partition with boot/active flag or by dropping
>  support for buggy EFIs which do not recognize the MBR partition type
>  0xEF unless a smell of GPT is on the storage device.
>
>  ---------------------------------------------------------------------
>  Just for the fun of it i post xorriso's assessment of the jackalope boot
>  equipment in Fedora-Workstation-Live-x86_64-31-1.9.iso :
>
>    $ xorriso -indev Fedora-Workstation-Live-x86_64-31-1.9.iso -report_el_torito plain
> -report_system_area plain
>    ...
>    El Torito catalog  : 42  1
>    El Torito cat path : /isolinux/boot.cat
>    El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt  Ldsiz         LBA
>    El Torito boot img :   1  BIOS  y   none  0x0000  0x00      4       16852
>    El Torito boot img :   2  UEFI  y   none  0x0000  0x00  21716          43
>    El Torito boot img :   3  UEFI  y   none  0x0000  0x00  45520        5472
>    El Torito img path :   1  /isolinux/isolinux.bin
>    El Torito img opts :   1  boot-info-table isohybrid-suitable
>    El Torito img path :   2  /images/efiboot.img
>    El Torito img path :   3  /images/macboot.img
>    System area options: 0x00000202
>    System area summary: MBR isohybrid cyl-align-off GPT
>    ISO image size/512 : 3768320
>    Partition offset   : 0
>    MBR heads per cyl  : 0
>    MBR secs per head  : 0
>    MBR partition table:   N Status  Type        Start       Blocks
>    MBR partition      :   1   0x80  0x00            0      3768320
>    MBR partition      :   2   0x00  0xef          172        21716
>    MBR partition      :   3   0x00  0x00        21888        45520
>    MBR partition path :   2  /images/efiboot.img
>    MBR partition path :   3  /images/macboot.img
>    GPT                :   N  Info
>    GPT disk GUID      :      892c8c3c5015534296ffb0417be2c61f
>    GPT entry array    :      2  248  overlapping
>    GPT lba range      :      64  3768256  3768319
>    GPT partition name :   1  490053004f00480079006200720069006400
>    GPT partname local :   1  ISOHybrid
>    GPT partition GUID :   1  892c8c3c5015534296feb0417be2c61f
>    GPT type GUID      :   1  a2a0d0ebe5b9334487c068b6b72699c7
>    GPT partition flags:   1  0x1000000000000001
>    GPT start and size :   1  0  3768256
>    GPT partition name :   2  490053004f004800790062007200690064003100
>    GPT partname local :   2  ISOHybrid1
>    GPT partition GUID :   2  892c8c3c5015534296fdb0417be2c61f
>    GPT type GUID      :   2  a2a0d0ebe5b9334487c068b6b72699c7
>    GPT partition flags:   2  0x1000000000000001
>    GPT start and size :   2  172  21716
>    GPT partition path :   2  /images/efiboot.img
>    GPT partition name :   3  490053004f004800790062007200690064003200
>    GPT partname local :   3  ISOHybrid2
>    GPT partition GUID :   3  892c8c3c5015534296fcb0417be2c61f
>    GPT type GUID      :   3  005346480000aa11aa1100306543ecac
>    GPT partition flags:   3  0x1000000000000001
>    GPT start and size :   3  21888  45520
>    GPT partition path :   3  /images/macboot.img
>
>  Note that the MBR partition table is not "protective" by consisting only
>  of one partition of type 0xEE. Thus the GPT is not valid, which is good
>  so, because the EFI system partition in GPT does not show the prescribed
>  Type GUID 28732ac11ff8d211ba4b00a0c93ec93b
>  aka C12A7328-F81F-11D2-BA4B-00A0C93EC93B.
>  (I wonder why this ISO does not show an Apple Partition Map. The xorrisofs
>  options shown in this thread should have caused one.) 
I noticed the APM seemed to go away at one point - I'm not sure when.
I thought the command had changed but maybe there's a conflict with
one of the other commands now?


>  For comparison a grub-mkrescue ISO for BIOS and EFI:
>
>    ...
>    El Torito catalog  : 1669  1
>    El Torito cat path : /boot.catalog
>    El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt  Ldsiz         LBA
>    El Torito boot img :   1  BIOS  y   none  0x0000  0x00      4        3544
>    El Torito boot img :   2  UEFI  y   none  0x0000  0x00   5760          84
>    El Torito img path :   1  /boot/grub/i386-pc/eltorito.img
>    El Torito img opts :   1  boot-info-table grub2-boot-info
>    El Torito img path :   2  /efi.img
>    System area options: 0x00004201
>    System area summary: MBR protective-msdos-label grub2-mbr cyl-align-off GPT APM
>    ISO image size/512 : 30848
>    Partition offset   : 0
>    MBR heads per cyl  : 64
>    MBR secs per head  : 32
>    MBR partition table:   N Status  Type        Start       Blocks
>    MBR partition      :   1   0x00  0xee            1        30847
>    GPT                :   N  Info
>    GPT disk GUID      :      07f29bb153383349a5ecd605dcf5ebd6
>    GPT entry array    :      20  176  separated
>    GPT lba range      :      64  30802  30847
>    GPT partition name :   1  4700610070003000
>    GPT partname local :   1  Gap0
>    GPT partition GUID :   1  07f29bb153383349a5e8d605dcf5ebd6
>    GPT type GUID      :   1  a2a0d0ebe5b9334487c068b6b72699c7
>    GPT partition flags:   1  0x1000000000000001
>    GPT start and size :   1  64  272
>    GPT partition name :   2 
> 450046004900200062006f006f007400200070006100720074006900740069006f006e00
>    GPT partname local :   2  EFI boot partition
>    GPT partition GUID :   2  07f29bb153383349a5e9d605dcf5ebd6
>    GPT type GUID      :   2  28732ac11ff8d211ba4b00a0c93ec93b
>    GPT partition flags:   2  0x1000000000000001
>    GPT start and size :   2  336  5760
>    GPT partition path :   2  /efi.img
>    GPT partition name :   3  48004600530050004c0055005300
>    GPT partname local :   3  HFSPLUS
>    GPT partition GUID :   3  07f29bb153383349a5ead605dcf5ebd6
>    GPT type GUID      :   3  005346480000aa11aa1100306543ecac
>    GPT partition flags:   3  0x1000000000000001
>    GPT start and size :   3  6096  24104
>    GPT partition name :   4  4700610070003100
>    GPT partname local :   4  Gap1
>    GPT partition GUID :   4  07f29bb153383349a5ebd605dcf5ebd6
>    GPT type GUID      :   4  a2a0d0ebe5b9334487c068b6b72699c7
>    GPT partition flags:   4  0x1000000000000001
>    GPT start and size :   4  30200  600
>    APM                :   N  Info
>    APM block size     :      2048
>    APM gap fillers    :      2
>    APM partition name :   1  Gap0
>    APM partition type :   1  ISO9660_data
>    APM start and size :   1  16  1508
>    APM partition name :   2  HFSPLUS_Hybrid
>    APM partition type :   2  Apple_HFS
>    APM start and size :   2  1524  6026
>    APM partition name :   3  Gap1
>    APM partition type :   3  ISO9660_data
>    APM start and size :   3  7550  162
>
>  The Apple Partition Map (APM) marks the mount point of the internal HFS+
>  filesystem tree. If we are speaking of legacy, then this is the most
>  obsolete part of a grub-mkrescue ISO. 
I'm pretty sure we don't need either APM or HFS+ stuff for mac support
anymore. But all the more reason to make an "older models" best
effort.


-- 
Chris Murphy

[Chris Murphy]

On Sun, Apr 10, 2022 at 1:31 PM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; wrote:
>  On Thu, Apr 07, 2022 at 10:43:02AM +0200, Lennart Poettering wrote:
>  > On Mi, 06.04.22 07:33, Neal Gompa (ngompa13(a)gmail.com) wrote:
>  > > Irrespective of this change, I would flat-out oppose moving to
>  > > sd-boot. In any case, you can't use sd-boot for live media.
>  > >
>  > > If we were going to move to pure EFI boot manager, I'd rather use one
>  > > that has a decent user experience and not a barebones crappy one.
>  >
>  > OK, I'll bite.
>  >
>  > What are you missing in sd-boot, specifically?
>  >
>  > Also, why would a boot menu need a particularly fancy user experience?
>  > It's a boot manager, not a web browser.
>
>  "barebones crappy one" is pretty strong. I'm too am interested in
>  hearing what is so wrong with the sd-boot experience. 
The problem with systemd-boot is it still has an interface. I prefer
no interface for bootloaders.

I'm a bit frustrated that systemd-boot isn't signed, and apparently (I
guess) shim hard codes GRUB as the next bootloader?

This portion of the thread maybe ought to be split out?

-- 
Chris Murphy

[Hans de Goede]

Hi,

On 4/11/22 01:07, Gabriel Ramirez wrote:
>  On 4/10/22 16:10, Neal Gompa wrote:
> > On Sun, Apr 10, 2022 at 4:37 PM Dominik 'Rathann' Mierzejewski
> > <dominik(a)greysector.net&gt; wrote:
> >> On Friday, 08 April 2022 at 16:14, Zamir SUN wrote:
> >> [...]
> >>> Probably it isn't a problem for some users, but I'm still having bad
> >>> experience with UEFI on x86_64 now. Out of my 3 machines I only have 1
> >>> system that works fine with UEFI. And my parents' laptop was purchased
> >>> 2 years ago and the UEFI firmware does not allow to boot anything
> >>> other than Windows on UEFI mode (regardless of turning secure boot on
> >>> or off) and I have to switch to BIOS mode to make Fedora work there.
> >>> So in this situation, I think it's way too aggressive to accept the
> >>> change - this will probably drive away some potential new users with
> >>> decent laptop like my parents'.
> >> Have you tried renaming your Fedora boot entry to "Windows Boot
> >> Manager"? I have one Sony laptop that boots only the boot entry with
> >> that exact name.
> >>
> > I wonder if this would work with one of my old machines too. I've
> > never thought to rename the boot entry in the firmware before...
> >
> >
>  
>  about "Windows Boot Manager" efi entry required to boot:
> https://mjg59.dreamwidth.org/20187.html
>  
>  the above happens too with the lenovo thinkcentre m91 
Yes and some UEFI-s will only consider non USB disks to be bootable if they
have a FAT ESP with  EFI/Microsoft/Boot/bootmgfw.efi on there.

Some of them are hardcoded to boot that file (just put shim + grubia32.efi
/ grubx64.efi there), while others check for the file, but boot another
path (which may also be hardcoded) see:

https://hansdegoede.dreamwidth.org/24232.html

For a couple of devices which I encountered which do this. I did not
know about the "Windows Boot Manager" name being a thing too.

So yes so much for UEFI being a sensible standard...

Regards,

Hans

[Lennart Poettering]

On Mo, 11.04.22 02:34, Chris Murphy (lists(a)colorremedies.com) wrote:

>  > > OK, I'll bite.
>  > >
>  > > What are you missing in sd-boot, specifically?
>  > >
>  > > Also, why would a boot menu need a particularly fancy user experience?
>  > > It's a boot manager, not a web browser.
>  >
>  > "barebones crappy one" is pretty strong. I'm too am interested in
>  > hearing what is so wrong with the sd-boot experience.
>
>  The problem with systemd-boot is it still has an interface. I prefer
>  no interface for bootloaders. 
Too much for some, too little for others ;-)

The UI it has is by default turned off and you only get it if you hold
shift down or so at boot.

I mean, we do need some logic how you can pick an older kernel/edit
kernel cmdline for debugging/recovery/testing reasons. And that's
exactly what we offer, but not much more.

(And of course, you can hold W down to boot windows. But booting into
windows on dual-boot systems should actually move into gdm or so, we
provide all the basic building blocks to make this nice, except the UI
for it is actually missing).

>  I'm a bit frustrated that systemd-boot isn't signed, and
> apparently (I
>  guess) shim hard codes GRUB as the next bootloader? 
That's mostly a political issue.

(We actually have some support in sd-boot to be installed inder the
"grubx64.efi" name, to work around this political mess...)

Lennart

--
Lennart Poettering, Berlin

[Thomas Schmitt]

Hi,

Chris Murphy wrote:
>  At least with the BIOS firmware without a bug, the GRUB LBA 0 code
>  jumps direct to core.img, no instruction on how to read the GPT and
>  find the core.img from BIOS boot partition. 
That's probably because the GRUB MBR code for hard disk gets the LBA
of the next stage patched in at install time.

xorrisofs does the equivalent to the boot_hybrid.img MBR from GRUB:

   --grub2-mbr disk_path
      Install disk_path in the System Area  and  treat  it  as  modern
      GRUB2 MBR.  The content start address of the first boot image is
      converted to a count of 512 byte blocks, and an offset of  4  is
      added.   The result is written as 64 bit little-endian number to
      byte address 0x1b0.

"Install in the System Area" means "Copy it to the start of the ISO
image".
"first boot image" means the one that is pointed to by first entry in the
El Torito catalog, which is supposed to be the GRUB boot image for
El Torito. GRUB docs say that this image gets concatenated from "cdrom.img"
and a suitably built "core.img".


>  Still another idea might be to create a "legacy" image
> variant of
>  Everything ISO that does things exactly as we do them today. 
This would be handy at least during the first months of a new ISO image
layout being used. Any user complaint could be checked whether the problem
was introduced by the ISO image change.


>  A legacy/fallback image (or two) would provide some breathing room
> to
>  remove more legacy layers. Including possibly even ISO 9660. 
Aww. 14 years of xorriso development would be obsoleted. {:|

Giving up ISO 9660 would mean to give up El Torito, which means to give
up legacy BIOS booting from CD/DVD/BD.
With UEFI i am not so sure about the consequences. OVMF is known to boot
via partition table from qemu -cdrom devices and via El Torito from -hda.
Whether other EFIs do the same would have to be broadly tested.

UEFI 2.8 Errata A, February 2020 still has the prescription for EFI to
follow the El Torito boot catalog when it encounters an optical drive
with medium:

  10.3.5.2 CD-ROM Media Device Path
  The CD-ROM Media Device Path is used to define a system partition that
  exists on a CD-ROM. The CD-ROM is assumed to contain an ISO-9660 file
  system and follow the CD-ROM “El Torito” format. [...]
  In EFI the bootable entity is an EFI System Partition that is pointed to
  by the Boot Entry.

  10.4.5 Media Device Path Rules
  The Media Device Path is used to define the location of information on
  a medium. Hard Drives are subdivided into partitions by the MBR and a
  Media Device Path is used to define which partition is being used.
  A CD-ROM has boot partitions that are defined by the “El Torito”
  specification, and the Media Device Path is used to point to these
  partitions.

(Somebody at UEFI should look at the statement "subdivided into
 partitions by the MBR" whether this needs mentioning of GPT.)

EFI was not invented when El Torito was specified. Thus UEFI extends
the original El Torito specs by

  13.3.2.1 ISO-9660 and El Torito
  [...] To boot from a CD-ROM or DVD-ROM in the boot services environment,
  an EFI System partition is stored in a “no emulation” mode as defined
  by the “El Torito” specification. A Platform ID of 0xEF indicates an
  EFI System Partition. EFI differs from “El Torito” “no emulation” mode
  in that it does not load the “no emulation” image into memory and jump
  to it. EFI interprets the “no emulation” image as an EFI system
  partition. [... more technicalities follow ...]


>  The one thing I think we'd still need to
>  tweak sooner than later is swapping isolinux with GRUB. 
I am optimistic that this will be possible with few new user complaints.

Summary as i understand this part of our discussion:

Fedora just has to decide whether it wants to stay with the layout
described in
  https://mjg59.dreamwidth.org/11285.html
or whether it wants to migrate to a specs compliant GPT as i propose in
 
https://lists.fedoraproject.org/archives/list/[e-mail].o...
  Date: Sun, 10 Apr 2022 00:29:54 +0200
  Message-Id: <28174385295326549884(a)scdbackup.webframe.org&gt;

In the latter case the xorrisofs options to change are given in the above
list post. It would drop support for an obscure class of x86 Macs which
need HFS+ for booting, and it would drop support for a class of buggy
legacy BIOSes which don't boot if the boot/active isn't set in any MBR
partition table slot. (Old HP laptops have been caught with such BIOS.)

In the former case my change proposal is in
 
https://lists.fedoraproject.org/archives/list/[e-mail].o...
  Date: Fri, 08 Apr 2022 20:29:07 +0200
  Message-Id: <25501385177039509423(a)scdbackup.webframe.org&gt;
Please read the first part up to "More unsolicited info:" to see all
proposed options.

I am ready to discuss xorriso-specific problems at bug-xorriso(a)gnu.org
or in private, if not here. Cc me when starting a discussion here.


Have a nice day :)

Thomas

[Robbie Harwood]

Neal Gompa <ngompa13(a)gmail.com&gt; writes:

>  Windows is a niche in the server space, rather than the default
That may be true for many workloads, but I doubt it's true in all cases
- Active Directory has a huge footprint, for instance, and Linux is not
"the default" for identity services.

Be well,
--Robbie

[Chris Murphy]

On Mon, Apr 11, 2022 at 3:02 AM Lennart Poettering <mzerqung(a)0pointer.de&gt; wrote:
>  On Mo, 11.04.22 02:34, Chris Murphy (lists(a)colorremedies.com) wrote:
>
>  > > > OK, I'll bite.
>  > > >
>  > > > What are you missing in sd-boot, specifically?
>  > > >
>  > > > Also, why would a boot menu need a particularly fancy user experience?
>  > > > It's a boot manager, not a web browser.
>  > >
>  > > "barebones crappy one" is pretty strong. I'm too am interested
> in
>  > > hearing what is so wrong with the sd-boot experience.
>  >
>  > The problem with systemd-boot is it still has an interface. I prefer
>  > no interface for bootloaders.
>
>  Too much for some, too little for others ;-)
>
>  The UI it has is by default turned off and you only get it if you hold
>  shift down or so at boot.
>
>  I mean, we do need some logic how you can pick an older kernel/edit
>  kernel cmdline for debugging/recovery/testing reasons. And that's
>  exactly what we offer, but not much more. 
My comment was tongue in cheek, but yeah the "general case" in Fedora
is either no UI or boot an older kernel. Hence hidden GRUB menu by
default unless dual boot with Windows is detected (but due to
Bitlocker and TPM measured boot, the GRUB menu's Windows entry
increasingly won't work; where sd-boot has worked around this
correctly with the UEFI bootnext variable, upstream GRUB hasn't
committed to even recognizing the problem let alone a solution).


>  > I'm a bit frustrated that systemd-boot isn't signed, and
> apparently (I
>  > guess) shim hard codes GRUB as the next bootloader?
>
>  That's mostly a political issue. 
OK but it's true? I've got the story line correct? I'll start a
separate thread because if it's true...



-- 
Chris Murphy

[David Cantrell]

On Wed, Apr 06, 2022 at 01:57:00PM -0400, Neal Gompa wrote:
>  On Wed, Apr 6, 2022 at 11:50 AM Jared Dominguez
> <jaredz(a)redhat.com&gt; wrote:
>  >
>  >
>  >
>  > On Wed, Apr 6, 2022 at 8:20 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  >>
>  >> On Wed, Apr 6, 2022 at 8:04 AM Vít Ondruch <vondruch(a)redhat.com&gt; wrote:
>  >> >
>  >> >
>  >> > Dne 05. 04. 22 v 17:08 Neal Gompa napsal(a):
>  >> > > On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton <bcotton(a)redhat.com&gt;
> wrote:
>  >> > >> https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
>  >> > >>
>  >> > >> == Summary ==
>  >> > >> Make UEFI a hardware requirement for new Fedora installations on
>  >> > >> platforms that support it (x86_64).  Legacy BIOS support is not
>  >> > >> removed, but new non-UEFI installation is not supported on those
>  >> > >> platforms.  This is a first step toward eventually removing
> legacy
>  >> > >> BIOS support entirely.
>  >> > >>
>  >> > >> == Owner ==
>  >> > >> * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří
>  >> > >> Konečný]], [[User:bcl| Brian C. Lane]]
>  >> > >> * Email: rharwood(a)redhat.com
>  >> > >>
>  >> > >>
>  >> > >> == Detailed Description ==
>  >> > >> UEFI is defined by a versioned standard that can be tested and
>  >> > >> certified against.  By contrast, every legacy BIOS is unique.
> Legacy
>  >> > >> BIOS is widely considered deprecated (Intel, AMD, Microsoft,
> Apple)
>  >> > >> and on its way out.  As it ages, maintainability has decreased,
> and
>  >> > >> the status quo of maintaining both stacks in perpetuity is not
> viable
>  >> > >> for those currently doing that work.
>  >> > >>
>  >> > >> It is inevitable that legacy BIOS will be removed in a future
> release.
>  >> > >> To ease this transition as best we can, there will be a period (of
> at
>  >> > >> least one Fedora release) where it will be possible to boot using
> the
>  >> > >> legacy BIOS codepaths, but new installations will not be
> possible.
>  >> > >> While it would be easier for us to cut support off today, our hope
> is
>  >> > >> that this compromise position will make for a smoother
> transition.
>  >> > >> Additional support with issues during the transition would be
>  >> > >> appreciated.
>  >> > >>
>  >> > >> While this will eventually reduce workload for boot/installation
>  >> > >> components (grub2 reduces surface area, syslinux goes away
> entirely,
>  >> > >> anaconda reduces surface area), the reduction in support burden
>  >> > >> extends much further into the stack - for instance, VESA support
> can
>  >> > >> be removed from the distro.
>  >> > >>
>  >> > >> Fedora already requires a 2GHz dual core CPU at minimum (and
> therefore
>  >> > >> mandates that machines must have been made after 2006).  Like the
>  >> > >> already accepted Fedora 37 change to retire ARMv7 support, the
>  >> > >> hardware targeted tends to be rather underpowered by today’s
>  >> > >> standards, and the world has moved on from it.  Intel stopped
> shipping
>  >> > >> the last vestiges of BIOS support in 2020 (as have other vendors,
> and
>  >> > >> Apple and Microsoft), so this is clearly the way things are
> heading -
>  >> > >> and therefore aligns with Fedora’s “First” objective.
>  >> > >>
>  >> > >> == Feedback ==
>  >> > >> Dropping legacy BIOS was previously discussed (but not proposed)
> in 2020:
>  >> > >>
> https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject...
>  >> > >>
>  >> > >> Important, relevant points from that thread (yes, I reread the
> entire
>  >> > >> thread) that have informed this change:
>  >> > >>
>  >> > >> * Some machines are BIOS-only.  This change does not prevent their
> use
>  >> > >> yet, but they are effectively deprecated.  grub2 (our default
>  >> > >> bootloader) is already capable of both BIOS and UEFI booting.
>  >> > >> * Drawing a clear year cutoff, let alone a detailed list of
> hardware
>  >> > >> this change affects, is basically impossible.  This is unfortunate
> but
>  >> > >> unlikely to ever change.
>  >> > >> * There is no migration story from Legacy BIOS to UEFI -
>  >> > >> repartitioning effectively mandates a reinstall.  As a result, we
>  >> > >> don’t drop support for existing Legacy BIOS systems yet, just new
>  >> > >> installations.
>  >> > >> * There is no way to deprecate hardware without causing some
> amount of friction.
>  >> > >> * While at the time AWS did not support UEFI booting, that is no
>  >> > >> longer the case and they support UEFI today.
>  >> > >>
>  >> > >> == Benefit to Fedora ==
>  >> > >> UEFI is required for many desirable features, including applying
>  >> > >> firmware updates (fwupd) and supporting SecureBoot.  As a
> standalone
>  >> > >> change, it reduces support burden on everything involved in
> installing
>  >> > >> Fedora, since there becomes only one way to do it per platform.
>  >> > >> Finally, it simplifies our install/live media, since it too only
> has
>  >> > >> to boot one way per arch.  Freedom Friends Features First - this
> is
>  >> > >> that last one.
>  >> > >>
>  >> > >> == Scope ==
>  >> > >> * Proposal owners:
>  >> > >> ** bootloaders: No change (existing Legacy BIOS installations
> still supported).
>  >> > >> ** anaconda: No change (there could be only optional cleanups in
> the
>  >> > >> code). However, it needs to be verified.
>  >> > >> ** Lorax: Code has already been written:
>  >> > >> https://github.com/weldr/lorax/pull/1205
>  >> > >>
>  >> > > This pull request primarily drops legacy BIOS support by dropping
>  >> > > syslinux/isolinux. We don't necessarily have to drop legacy BIOS
>  >> > > support there if we reuse GRUB there too. Other distributions
>  >> > > (openSUSE and Mageia, notably) both use GRUB for both BIOS and UEFI
> on
>  >> > > live media.
>  >> > >
>  >> > >> * Other developers:
>  >> > >> ** libvirt: UEFI works today, but is not the default.  UEFI-only
>  >> > >> installation is needed for Windows 11, and per conversations,
> libvirt
>  >> > >> is prepared for this change.
>  >> > >> ** Virtualbox: UEFI Fedora installs are working and per
> virtualbox
>  >> > >> team, UEFI will be/is the default in 7.0+.
>  >> > >> ** The Hardware Overview page should be updated to mention the
> UEFI
>  >> > >> requirement:
> https://docs.fedoraproject.org/en-US/fedora/rawhide/release-notes/welcome...
>  >> > >>
>  >> > >> * Release engineering: [https://pagure.io/releng/issue/10738
> #Releng
>  >> > >> issue 10738]
>  >> > >>
>  >> > >> * Policies and guidelines: N/A (not needed for this Change)
>  >> > >>
>  >> > >> * Trademark approval: N/A (not needed for this Change)
>  >> > >>
>  >> > >> * Alignment with Objectives: N/A
>  >> > >>
>  >> > >> == Upgrade/compatibility impact ==
>  >> > >> Systems currently using Legacy BIOS for booting on x86_64 will
>  >> > >> continue to do so.
>  >> > >>
>  >> > >> However, this modifies the baseline Fedora requirements and some
>  >> > >> hardware will no longer be supported for new installations.
>  >> > >>
>  >> > >> == How To Test ==
>  >> > >> UEFI installation has been supported for quite a while already,
> so
>  >> > >> additional testing there should not be required.
>  >> > >>
>  >> > >> == User Experience ==
>  >> > >> Installs will continue to work on UEFI, and will not work on
> Legacy
>  >> > >> BIOS.  Our install media is already UEFI-capable.
>  >> > >>
>  >> > >> == Dependencies ==
>  >> > >> None
>  >> > >>
>  >> > >> == Contingency Plan ==
>  >> > >> Leave things as they are.  Code continues to rot.  Community
>  >> > >> assistance is required to continue the status quo.  Current
> owners
>  >> > >> plan to orphan some packages regardless of whether the proposal
> is
>  >> > >> accepted.
>  >> > >>
>  >> > >> Another fallback option could be, if a Legacy BIOS SIG organizes,
> to
>  >> > >> donate the relevant packages there and provide some initial
> mentoring.
>  >> > >> Longer term, packages that cannot be wholly donated could be
> split,
>  >> > >> though it is unclear whether the synchronization thereby required
>  >> > >> would reduce the work for anyone.
>  >> > >>
>  >> > >> * Contingency mechanism: Delay until next release.
>  >> > >> * Contingency deadline: Beta freeze
>  >> > >> * Blocks release? No
>  >> > >>
>  >> > >> == Documentation ==
>  >> > >> See release notes.
>  >> > >>
>  >> > >> == Release Notes ==
>  >> > >> Fedora 37 marks legacy BIOS installation as deprecated on x86_64
> in
>  >> > >> favor of UEFI.  While systems already using Legacy BIOS to boot
> are
>  >> > >> still supported, new legacy BIOS installations on these
> architectures
>  >> > >> are no longer possible.  Legacy BIOS support will be removed
> entirely
>  >> > >> in a future Fedora.
>  >> > >>
>  >> > >> (Additionally, the Hardware Overview page should be updated to
> mention
>  >> > >> the UEFI requirement.)
>  >> > >>
>  >> > > While I'm sympathetic to this Change, I think this is way too
> early to
>  >> > > do across the board. UEFI came onto the scene in the PC space in
>  >> > > 2011~2012 with Windows 8, and even to this day, there are
> sufficiently
>  >> > > buggy hardware platforms that Linux does not boot in UEFI mode:
>  >> > > https://twitter.com/VKCsh/status/1511132132885815307
>  >> > >
>  >> > > I even have one such machine, an HP desktop machine that came with
>  >> > > Windows 8. My current desktop PC has problems booting Linux UEFI as
>  >> > > well, though I've done "clever" things to work around
> that. I don't
>  >> > > expect most users to be able to deal with that. Server platforms were
>  >> > > *worse* as they were slower to offer UEFI. The first time I was able
>  >> > > to get a server with UEFI was in 2014.
>  >> >
>  >> >
>  >> > Maybe I don't correctly understand the "Legacy BIOS support is
> not
>  >> > removed, but new non-UEFI installation is not supported on those
>  >> > platforms." quoted from the the change description, but if you have
> your
>  >> > system installed, it should keep working. You just keep updating. IOW as
>  >> > long as you don't reinstall the system, you are fine and you don't
> have
>  >> > to be concerned.
>  >> >
>  >> > If you really have a need to reinstall such machine, you'll take the
> F36
>  >> > image and upgrade to F37+ and you should still be good.
>  >> >
>  >>
>  >> This is not a deprecation change, this is effectively a removal
>  >> change. By removing the packages and the tooling support for legacy
>  >> BIOS, it makes several scenarios (including recovery) harder.
>  >> Moreover, it puts the burden on people to figure out if their hardware
>  >> can boot and install Fedora when we clearly haven't reached a critical
>  >> mass yet for doing so, like we did when we finally removed the i686
>  >> kernel build.
>  >>
>  >> I'm personally a fan of using UEFI instead of BIOS. Heck, I
>  >> implemented support for UEFI in Fedora's cloud images when other
>  >> people told me it was not possible, while preserving BIOS support.
>  >> I've been trying to figure out the roadmap for BIOS deprecation for a
>  >> year now, and the reason *I* didn't propose a Change yet is because I
>  >> have not sufficiently determined that it was reasonable to do so.
>  >>
>  >> I'm particularly upset about this Change because it feels like a
>  >> hostage change where the proposal owners blithely ignore what we're
>  >> saying as unimportant or irrelevant and abuse our principles to do
>  >> things that are clearly against what the community feels is right.
>  >
>  >
>  > This strikes me as a very negative view of what we're trying to do. We're
> trying to figure out a timeline for deprecation and openly discuss, which is why this
> change proposal is here now. Support for legacy x86 boot is rapidly vanishing across the
> industry. Code is rotting in Fedora. The Red Hat team doing the work in the bootloader
> space doesn't have capacity for continuing support for legacy x86 boot anyway.
> We're attempting to communicate boundaries and available commitment and work in the
> community on a workable plan. This proposal includes a call for community assistance if
> there's sufficient desire to maintain the status quo longer. You are welcome to
> constructively help with that. Hearing accusations of folks, who are operating on good
> faith, engaging in "abuse" and executing a "hostage change" feels
> concerning to me.
>  >
>  >> I have been trying in the background for years to try to figure out
>  >> solutions for usability problems in Fedora Linux on UEFI because *I
>  >> want our experience to be good there*. But it's extremely hard when:
>  >>
>  >> 1. Bugs and feature requests around UEFI related features are ignored
>  >
>  >
>  > Per my reply to you yesterday, I would be grateful if you would list out examples
> here. This is the second time I've heard this, and it's not concrete enough for a
> constructive conversation on that topic.
>  >
>  
>  This comes from years of trying to engage on improving the UEFI
>  situation in Fedora. To be perfectly clear: I don't want to maintain
>  the status quo. The status quo sucks.
>  
>  The status quo is:
>  
>  * UEFI is where everything is going in hardware
>  * Linux UEFI is a second-class experience to legacy boot
>  * No interest in making the UEFI-based environments better for users
>  
>  We have a ton of nice things in UEFI environments when they work, as
>  long as we don't step out of the happy path. However, the majority of
>  Linux PC users *must* step out of the happy path to get their hardware
>  working for two cases:
>  
>  * NVIDIA graphics
>  * Broadcom wireless 
This was already addressed.  Fedora should not be expected to jump through
hoops to support vendors unwilling to participate in the open source Linux
ecosystem.  Users should stop buying their hardware -or- contribute to
projects like nouveau to make this a non-issue.

>  The former case is excessively common, and the latter case is fairly
>  common with HP and Dell machines as well as some smaller OEMs. I
>  literally helped someone this past week with both[1][2][3]. The
>  Workstation WG has been tracking both issues for years now[4][5]. This
>  situation is *worse* now because we have Fedora Linux preloaded on
>  computers, and OEMs basically have to disable Secure Boot to make
>  things "work". How's that for improving security? 
To add more anecdotes... it has been years since I have had to disable Secure
Boot on a new laptop in order to install Fedora.  Maybe I'm lucky, but I will
say that the experience has only improved over time and you can't really say
that for all distributions.  Step 0 for many of them is still to disable
Secure Boot first then begin installation.

-- 
David Cantrell <dcantrell(a)redhat.com&gt;
Red Hat, Inc. | Boston, MA | EST5EDT

[Robbie Harwood]

Neal Gompa <ngompa13(a)gmail.com&gt; writes:

>  Alright, I'll bite. I am within my rights to propose any Change I
> want
>  for Fedora Cloud, which I help steward with David Duncan. 
As, presumably, is anyone else?

>  As an aside, I examined the state of all release blocking Fedora
>  deliverables, and something I noticed is that only the Workstation WG
>  has Red Hatters actively engaged in it. That means that this Change
>  comes with absolutely no understanding of the state of the world in
>  Fedora across the various WGs and SIGs that deliver release-blocking
>  artifacts. That in itself isn't necessarily a problem, but the fact
>  that none of you are listening to us (David Duncan and myself for
>  Cloud and KDE, Chris Murphy for Cloud and Workstation, and Peter Boy
>  for Server) when we tell you this is too early is extremely tone-deaf.
>
>  None of us want to keep supporting BIOS forever, but we all have
>  *real-world experience* saying that we can't do this yet. We're trying
>  to find a way to meet halfway to simplify legacy BIOS support, but
>  you're not listening to us. We've also been trying to tell you that
>  there are *real problems* with Fedora's UEFI support that need fixing
>  before we can cut off BIOS support, but you're not listening to us.
>
>  This thread has, at the time of my writing this post, has 269 posts
>  across 62 individuals. It is the most active thread we've had since
>  the switch to nano by default. However, unlike that change, almost
>  every single respondent has brought up feedback in this discussion
>  saying that we're not ready and providing examples of why we're not
>  ready. However, you're *not listening*. 
Okay, this is really important: just because I don't agree with you
doesn't mean I'm not hearing what you say.  You appear to be conflating
the two things.

I hear your position that this is too soon.  But I need you to hear what
I'm saying too: community assistance is required to keep up the status
quo, if that's how we want to go.  If you think the best way to go is to
vote this down, and have firmly made up your mind to vote it down, then
vote it down!  But do so with that knowledge.

>  I understand you want to drop BIOS support before Fedora Linux 40 is
>  branched into RHEL 10. 
No one has said anything at all about RHEL.  As a member of the team
responsible for RHEL's boot stack, I can say that most of our focus is
at the moment on <=9, not >9.

Be well,
--Robbie

[Chris Murphy]

On Mon, Apr 11, 2022 at 4:36 AM Thomas Schmitt <scdbackup(a)gmx.net&gt; wrote:

>  > A legacy/fallback image (or two) would provide some breathing
> room to
>  > remove more legacy layers. Including possibly even ISO 9660.
>
>  Aww. 14 years of xorriso development would be obsoleted. {:|
>
>  Giving up ISO 9660 would mean to give up El Torito, which means to give
>  up legacy BIOS booting from CD/DVD/BD. 
It's a fair point that this proposal is not considering ISO 9660 a
legacy or deprecated format. That's my editorialization.  But all good
things come to an end? Long live ISO 9660?  :D  Consider millions of
user's lives were made a ton easier because we have had these
remarkably clever universal boot images for so long that can boot
almost anything.

 The legacy/fallback image(s) would definitely include ISO 9660
support, using xorriso essentially as we are now if not exactly as it
is now, and support it as long as it can be supported by the future
Legacy BIOS Booting SIG. It'd be up to the SIG to decide whether ISO
9660 is eventually dropped, if ever.

But as long as the SIG and its work products are being produced
reliably, and at least one image is release blocking - that gives
quite a lot of room to drop ISO 9660 on other images *if* there's a
clear advantage of doing so. That's all I meant to indicate.

>  > The one thing I think we'd still need to
>  > tweak sooner than later is swapping isolinux with GRUB.
>
>  I am optimistic that this will be possible with few new user complaints. 
OK super.


>  Summary as i understand this part of our discussion:
>
>  Fedora just has to decide whether it wants to stay with the layout
>  described in
>    https://mjg59.dreamwidth.org/11285.html
>  or whether it wants to migrate to a specs compliant GPT as i propose in
>   
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>    Date: Sun, 10 Apr 2022 00:29:54 +0200
>    Message-Id: <28174385295326549884(a)scdbackup.webframe.org&gt;
>
>  In the latter case the xorrisofs options to change are given in the above
>  list post. It would drop support for an obscure class of x86 Macs which
>  need HFS+ for booting, and it would drop support for a class of buggy
>  legacy BIOSes which don't boot if the boot/active isn't set in any MBR
>  partition table slot. (Old HP laptops have been caught with such BIOS.)
>
>  In the former case my change proposal is in
>   
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>    Date: Fri, 08 Apr 2022 20:29:07 +0200
>    Message-Id: <25501385177039509423(a)scdbackup.webframe.org&gt;
>  Please read the first part up to "More unsolicited info:" to see all
>  proposed options.
>
>  I am ready to discuss xorriso-specific problems at bug-xorriso(a)gnu.org
>  or in private, if not here. Cc me when starting a discussion here. 
OK great thanks for all the input!


--
Chris Murphy

[Peter Boy]

>  Am 10.04.2022 um 04:50 schrieb Gary Buhrmaster
> <gary.buhrmaster(a)gmail.com&gt;:
>  
>  On Wed, Apr 6, 2022 at 6:01 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  
> > Moving past the Big Three(tm), the actual
> > cloud providers that matter from a Fedora context are the smaller
> > outfits that principally serve Linux users. These are companies like
> > DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who
> > graciously do offer Fedora Linux in their platforms. All of their
> > virtualization platforms are BIOS only right now, and getting them to
> > switch requires them to uplift their platforms to support UEFI in the
> > first place. 
I want to reiterate, it's not just about cloud platforms! if we remove BIOS boot (too
early), we also kick Fedora servers, installed on hardware, out of these data centers. 
And the reason is not that this server hardware does not support UEFI, but the management
infrastructure of the data centers.

And kicking ourselves out, really doesn't strike me as a brilliant idea. 

>  They may only support Linux users today, but if
>  they want to grow (and while it is possible to
>  survive as a niche service, many see growth
>  as the way to increased revenue/profits (go
>  big or go home)), they are going to get pushed
>  (perhaps kicking and screaming) to support
>  UEFI as at least an alternative … 
It’s not so much about kicking and streaming, but about time, man power and financial
resources.


>  Many of these comments seem to be about
>  the date, not the end state (UEFI)(****),
>  just like 32-bit x86 and armv7.  No one wants
>  their personal ox gored, but there will come
>  a time when it will be time to let old systems
>  go. 
Yes indeed. It’s about time. 

And we need a solution we can keep operable longer than 3 years. It's more of a
10-year thing.

[Chris Adams]

Once upon a time, Peter Boy <pboy(a)uni-bremen.de&gt; said:
>  I want to reiterate, it's not just about cloud platforms! if we
> remove BIOS boot (too early), we also kick Fedora servers, installed on hardware, out of
> these data centers.  And the reason is not that this server hardware does not support
> UEFI, but the management infrastructure of the data centers. 
Speaking of servers... one thing I noticed is that a pure-Fedora system
only uses about 8M of /boot/efi.  Even my dual-boot laptop with Win10 is
only using 35M.  Is there a reason 256M was chosen for the default UEFI
system partition size (from the standard somewhere)?  I guess that's
what Windows does too (since Win10 was on this laptop first).

I did notice that anaconda forces it to be at least 50M - again, is
there a reason?
-- 
Chris Adams <linux(a)cmadams.net&gt;

[Zbigniew Jędrzejewski-Szmek]

On Mon, Apr 11, 2022 at 02:21:04PM -0500, Chris Adams wrote:
>  Once upon a time, Peter Boy <pboy(a)uni-bremen.de&gt; said:
>  > I want to reiterate, it's not just about cloud platforms! if we remove BIOS boot
> (too early), we also kick Fedora servers, installed on hardware, out of these data
> centers.  And the reason is not that this server hardware does not support UEFI, but the
> management infrastructure of the data centers.
>  
>  Speaking of servers... one thing I noticed is that a pure-Fedora system
>  only uses about 8M of /boot/efi.  Even my dual-boot laptop with Win10 is
>  only using 35M.  Is there a reason 256M was chosen for the default UEFI
>  system partition size (from the standard somewhere)?  I guess that's
>  what Windows does too (since Win10 was on this laptop first). 
Windows wants >= 100 MB, or >= 256 MB on 4k-sector drives.
(https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/con...)
Whoever creates the partition should make it "large enough",
i.e. it's reasonable to make it large enough to satisfy also windows,
even if we only use a few MBs.

Zbyszek

[Peter Boy]

>  Am 11.04.2022 um 21:21 schrieb Chris Adams
> <linux(a)cmadams.net&gt;:
>  
>  Once upon a time, Peter Boy <pboy(a)uni-bremen.de&gt; said:
> > I want to reiterate, it's not just about cloud platforms! if we remove BIOS boot
> (too early), we also kick Fedora servers, installed on hardware, out of these data
> centers.  And the reason is not that this server hardware does not support UEFI, but the
> management infrastructure of the data centers.
>  
>  Speaking of servers... one thing I noticed is that a pure-Fedora system
>  only uses about 8M of /boot/efi.  Even my dual-boot laptop with Win10 is
>  only using 35M.  Is there a reason 256M was chosen for the default UEFI
>  system partition size (from the standard somewhere)?  I guess that's
>  what Windows does too (since Win10 was on this laptop first).
>  
>  I did notice that anaconda forces it to be at least 50M - again, is
>  there a reason? 
I really don’t know. Never thought about it before, and it hasn't even occurred to me,
unfortunately. Knowing our group members, it's kind of a general best practice, and
the idea of not making it too small in any way.

[Chris Murphy]

On Mon, Apr 11, 2022 at 1:21 PM Chris Adams <linux(a)cmadams.net&gt; wrote:
>  Once upon a time, Peter Boy <pboy(a)uni-bremen.de&gt; said:
>  > I want to reiterate, it's not just about cloud platforms! if we remove BIOS boot
> (too early), we also kick Fedora servers, installed on hardware, out of these data
> centers.  And the reason is not that this server hardware does not support UEFI, but the
> management infrastructure of the data centers.
>
>  Speaking of servers... one thing I noticed is that a pure-Fedora system
>  only uses about 8M of /boot/efi.  Even my dual-boot laptop with Win10 is
>  only using 35M.  Is there a reason 256M was chosen for the default UEFI
>  system partition size (from the standard somewhere)?  I guess that's
>  what Windows does too (since Win10 was on this laptop first). 
Any Microsoft produced ISO image (downloadable from microsoft.com,
versus an OEM created image) creates 100 MiB EFI system partitions.
OEM's are kinda all over the map.

Fedora makes them 600 MiB these days.

UEFI Spec 2.8, 13.3.1.1 says "The EFI firmware must support the FAT32,
FAT16, and FAT12 variants of the EFI file system. What variant of EFI
FAT to use is defined by the size of the media. The rules defining the
relationship between media size and FAT variants is defined in the
specification for the EFI file system."

I've never been able to find a separate spec though.

The UEFI spec itself defines the EFI file system earlier in this 13.3
section as "The file system supported by the Extensible Firmware
Interface is based on the FAT file system." i.e. it is intended to be
based on a frozen in time version of FAT. Further, "EFI encompasses
the use of FAT32 for a system partition, and FAT12 or FAT16 for
removable media."

>  I did notice that anaconda forces it to be at least 50M - again, is
>  there a reason? 
Anaconda folks prefer to use mkfs defaults. And dosfstools doesn't
have an "EFI file system" specific flag to follow the UEFI rules,
including feature freezing it in time. It just so happens FAT isn't
changing much or at least not in a way that makes EFI firmware
confused. But one day we might need an actual mkfs.efi utility to
correctly make them.

Per the spec the internal drive should be a FAT 32 file system, and
either FAT 12 or 32 file system for removable drives. In practice,
mkdosfs's size based logic won't make a FAT 32 volume unless the
partition size is ~550 MiB (I'm not certain of the cutoff). When
Anaconda was making ~250 MiB EFI system partitions, they were FAT 16.
Now they are FAT 32 because the partition size is above mkdosfs's
cutoff for FAT 16. I don't know if anyone ever ran into weird bugs
related to the file system being 16-bit based, rather than 32-bit, but
it would be hard to find out because - why would you even think to try
a different FAT variant and see if what you think might be a bug still
reproduces?

I tried formatting a 2011 Apple Macbook as FAT 16 and FAT 12. FAT 16
was OK (although I didn't do any firmware updates which is the only
reason the EFI system partition is used on Macs of this era). But FAT
12 was a bad experience - my vague recollection is I had to remove the
drive from the laptop and reformat it FAT 32 because I couldn't get it
to boot anything, not even from a CD or into the recovery mode. There
can be pretty nasty bugs lurking around the corners of such a vast
spec as UEFI, with the only requirement that involves any testing is
Microsoft's hardware compatibility/certification program.

-- 
Chris Murphy

[Brian C. Lane]

On Mon, Apr 11, 2022 at 02:21:04PM -0500, Chris Adams wrote:
>  Once upon a time, Peter Boy <pboy(a)uni-bremen.de&gt; said:
>  > I want to reiterate, it's not just about cloud platforms! if we remove BIOS boot
> (too early), we also kick Fedora servers, installed on hardware, out of these data
> centers.  And the reason is not that this server hardware does not support UEFI, but the
> management infrastructure of the data centers.
>  
>  Speaking of servers... one thing I noticed is that a pure-Fedora system
>  only uses about 8M of /boot/efi.  Even my dual-boot laptop with Win10 is
>  only using 35M.  Is there a reason 256M was chosen for the default UEFI
>  system partition size (from the standard somewhere)?  I guess that's
>  what Windows does too (since Win10 was on this laptop first). 
It is likely because UEFI specifies FAT32 on harddrives, and the minimum
size for FAT32 is 256MB.

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart

[Chris Murphy]

On Mon, Apr 11, 2022 at 3:36 PM Brian C. Lane <bcl(a)redhat.com&gt; wrote:
>  On Mon, Apr 11, 2022 at 02:21:04PM -0500, Chris Adams wrote:
>  > Once upon a time, Peter Boy <pboy(a)uni-bremen.de&gt; said:
>  > > I want to reiterate, it's not just about cloud platforms! if we remove BIOS
> boot (too early), we also kick Fedora servers, installed on hardware, out of these data
> centers.  And the reason is not that this server hardware does not support UEFI, but the
> management infrastructure of the data centers.
>  >
>  > Speaking of servers... one thing I noticed is that a pure-Fedora system
>  > only uses about 8M of /boot/efi.  Even my dual-boot laptop with Win10 is
>  > only using 35M.  Is there a reason 256M was chosen for the default UEFI
>  > system partition size (from the standard somewhere)?  I guess that's
>  > what Windows does too (since Win10 was on this laptop first).
>
>  It is likely because UEFI specifies FAT32 on harddrives, and the minimum
>  size for FAT32 is 256MB. 
That's just for 4KiB logical sectors though. Most everyone still has
512 byte logical sector size for internal drives. My nvme drive is 512
byte sectors, came with FAT 32 and 100 MiB EFI system (and reformatted
with Microsoft's own installer the same).


-- 
Chris Murphy

[Chris Adams]

Once upon a time, Brian C. Lane <bcl(a)redhat.com&gt; said:
>  It is likely because UEFI specifies FAT32 on harddrives, and the
> minimum
>  size for FAT32 is 256MB. 
mkdosfs will make a FAT32 without warning on a size of 33296KB.
-- 
Chris Adams <linux(a)cmadams.net&gt;

[Mark Otaris]

>  However, the majority of Linux PC users *must* step out of the happy
> path
>  to get their hardware working for two cases:
>  
>  * NVIDIA graphics
>  * Broadcom wireless 
In the Firefox Public Data Report, GPU vendor is 69% Intel, 13% Nvidia, 13% AMD, 5% other.
I don’t think Broadcom wireless is that common either. So it’s a lot of people, but not a
majority of Linux PC users, probably less than 25%.

[Gary Buhrmaster]

On Mon, Apr 11, 2022 at 5:26 PM David Cantrell <dcantrell(a)redhat.com&gt; wrote:

>  This was already addressed.  Fedora should not be expected to jump
> through
>  hoops to support vendors unwilling to participate in the open source Linux
>  ecosystem.  Users should stop buying their hardware -or- contribute to
>  projects like nouveau to make this a non-issue. 
And while I agree with the overall sentiment that Linux
should not hoop jump for others, the reality is that many
desktop and laptop users use their corporate provided
systems(*), and those systems are often not (at all) Linux
friendly(**).

Saying to those people "we feel your pain", while
offering nothing else, is a a perfectly reasonable
thing to do/say, but we should, at least, state it
explicitly, should that be the direction we are going.

Gary



(*) Due to corporate purchasing decisions, I have
more than once chosen to spend my own money
to purchase laptops and desktop systems that can
easily install/run Linux/Fedora.  Not everyone
realistically has that option, or will chose it even
if they do have it (and sometimes corporate policy
states you must use their pre-configured systems).

(**) The number of organizations that believe in
Linux first, first, and first, and purchase accordingly,
is small.  Last I knew RH itself allowed their staff
to choose Mac's.  Why?  Do they, themselves, not
believe in Linux first, first, and first?  No, I don't
expect a reasonable answer here, but if RH does
not require Linux first, first, and first there should
be no expectation that other organizations will do
so.

[Vitaly Zaitsev]

On 11/04/2022 23:35, Brian C. Lane wrote:
>  It is likely because UEFI specifies FAT32 on harddrives, and the
> minimum
>  size for FAT32 is 256MB. 
This is not true. From my Fedora VM:

Disk /dev/sda1: 200 MiB, 209715200 bytes, 409600 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Vitaly Zaitsev]

On 11/04/2022 22:29, Chris Murphy wrote:
>  UEFI Spec 2.8, 13.3.1.1 says "The EFI firmware must support the
> FAT32,
>  FAT16, and FAT12 variants of the EFI file system. What variant of EFI
>  FAT to use is defined by the size of the media. The rules defining the
>  relationship between media size and FAT variants is defined in the
>  specification for the EFI file system." 
Also, ESP can use any FS that your firmware can read. I'm using ext4 on 
my desktop.

You can use efifs[1], packaged on Fedora[2].

[1]: https://github.com/pbatard/efifs
[2]: https://src.fedoraproject.org/rpms/efifs

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Vitaly Zaitsev]

On 12/04/2022 02:24, Mark Otaris wrote:
>  In the Firefox Public Data Report, GPU vendor is 69% Intel, 13%
> Nvidia, 13% AMD, 5% other. 
Keep in mind that most advanced Firefox users turn telemetry off completely.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Jóhann B. Guðmundsson]

On 12.4.2022 00:24, Mark Otaris wrote:
> > However, the majority of Linux PC users *must* step out of the
> happy path
> > to get their hardware working for two cases:
> >
> > * NVIDIA graphics
> > * Broadcom wireless
>  In the Firefox Public Data Report, GPU vendor is 69% Intel, 13% Nvidia, 13% AMD, 5%
> other. I don’t think Broadcom wireless is that common either. So it’s a lot of people, but
> not a majority of Linux PC users, probably less than 25%. 

Well it's not like it's affecting a large number of desktop users since 
those 25% are at best 25% of the desktop market share in Linux, which is 
just 2.36% ( excluding Chrome OS which has 2.79% market share on it's 
own, higher than all other Linux distributions combined ( which are 
around 500 ) ...  ).

Then you can further reduce that number by figuring how much % each 
distribution has of those 2.36% which should give you what Fedora has of 
that and that ends up being what 10 people, 100 hundred at best so you 
are sacrificing the core values of Fedora for those 10 - 100 vocal 
people...

JBG

[Brian C. Lane]

On Mon, Apr 11, 2022 at 04:59:01PM -0600, Chris Murphy wrote:
>  On Mon, Apr 11, 2022 at 3:36 PM Brian C. Lane <bcl(a)redhat.com&gt;
> wrote:
>  >
>  > On Mon, Apr 11, 2022 at 02:21:04PM -0500, Chris Adams wrote:
>  > > Once upon a time, Peter Boy <pboy(a)uni-bremen.de&gt; said:
>  > > > I want to reiterate, it's not just about cloud platforms! if we remove
> BIOS boot (too early), we also kick Fedora servers, installed on hardware, out of these
> data centers.  And the reason is not that this server hardware does not support UEFI, but
> the management infrastructure of the data centers.
>  > >
>  > > Speaking of servers... one thing I noticed is that a pure-Fedora system
>  > > only uses about 8M of /boot/efi.  Even my dual-boot laptop with Win10 is
>  > > only using 35M.  Is there a reason 256M was chosen for the default UEFI
>  > > system partition size (from the standard somewhere)?  I guess that's
>  > > what Windows does too (since Win10 was on this laptop first).
>  >
>  > It is likely because UEFI specifies FAT32 on harddrives, and the minimum
>  > size for FAT32 is 256MB.
>  
>  That's just for 4KiB logical sectors though. Most everyone still has
>  512 byte logical sector size for internal drives. My nvme drive is 512
>  byte sectors, came with FAT 32 and 100 MiB EFI system (and reformatted
>  with Microsoft's own installer the same). 
Ah, right. I'd forgotten about 4k sectors. I ran into this limit while
trying to reduce the footprint of parted tests, which uses 512, 1024,
2048 and 4096 sector sizes so 256MB was as small as I could get.

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart

[Mark Otaris]

Your calculations have to be off; I’m pretty sure there are way more than 100 Fedora users
with a Nvidia GPU. The Linux Hardware Project alone reports 106 Fedora users with Nvidia
GPUs (which is actually 29% of their sample) so that’s a hard minimum:
https://linux-hardware.org/?view=gpu_vendor&d=Fedora. I think there are at least tens
of thousands of Fedora users with a Nvidia GPU. It’s not a majority, is all.

[Jóhann B. Guðmundsson]

On 12.4.2022 20:44, Mark Otaris wrote:
>  Your calculations have to be off; I’m pretty sure there are way more
> than 100 Fedora users with a Nvidia GPU. The Linux Hardware Project alone reports 106
> Fedora users with Nvidia GPUs (which is actually 29% of their sample) so that’s a hard
> minimum: https://linux-hardware.org/?view=gpu_vendor&d=Fedora. I think there are at
> least tens of thousands of Fedora users with a Nvidia GPU. It’s not a majority, is all.

Let's give you your tens of thousand of fedora users with Nvidia GPU, 
it's still not even a blimp in the chart of the overall desktop market 
share, let alone a number worth sacrificing core values for.

Fedora only holds a very small % of those 2.36% of the Linux desktop 
market share which is such a small number it wont even be worth raising 
someone's eyebrow at Nvidia...


JBG

[Demi Marie Obenour]

On 4/11/22 14:18, Peter Boy wrote:
>  
>  
> > Am 10.04.2022 um 04:50 schrieb Gary Buhrmaster <gary.buhrmaster(a)gmail.com&gt;:
> >
> > On Wed, Apr 6, 2022 at 6:01 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
> >
> >> Moving past the Big Three(tm), the actual
> >> cloud providers that matter from a Fedora context are the smaller
> >> outfits that principally serve Linux users. These are companies like
> >> DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who
> >> graciously do offer Fedora Linux in their platforms. All of their
> >> virtualization platforms are BIOS only right now, and getting them to
> >> switch requires them to uplift their platforms to support UEFI in the
> >> first place.
>  
>  I want to reiterate, it's not just about cloud platforms! if we remove BIOS boot (too
> early), we also kick Fedora servers, installed on hardware, out of these data centers. 
> And the reason is not that this server hardware does not support UEFI, but the management
> infrastructure of the data centers.
>  
>  And kicking ourselves out, really doesn't strike me as a brilliant idea. 
>  
> > They may only support Linux users today, but if
> > they want to grow (and while it is possible to
> > survive as a niche service, many see growth
> > as the way to increased revenue/profits (go
> > big or go home)), they are going to get pushed
> > (perhaps kicking and screaming) to support
> > UEFI as at least an alternative …
>  
>  It’s not so much about kicking and streaming, but about time, man power and financial
> resources. 
Given how large a company Red Hat is, I presume that they could come up
with these resources.  The cost to Red Hat of maintaining legacy BIOS
support is much less than the cost to the community of not doing so.

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[Stewart Smith]

Ben Cotton <bcotton(a)redhat.com&gt; writes:
>  https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
>
>  == Summary ==
>  Make UEFI a hardware requirement for new Fedora installations on
>  platforms that support it (x86_64).  Legacy BIOS support is not
>  removed, but new non-UEFI installation is not supported on those
>  platforms.  This is a first step toward eventually removing legacy
>  BIOS support entirely. 
I want to add a few thoughts both from an EC2 perspective, and an Amazon
Linux as a downstream of Fedora perspective.

Currently, nearly all EC2 instance types will boot by default with
legacy-bios. All aarch64 instances are UEFI, and I'd find it unlikely
that any new x86-64 instance type would not also support UEFI. But the
default for all existing Intel and AMD instance types is
legacy-bios. This is largely to preserve backwards compatibility, and at
least for existing instance types, I cannot forsee this ever
changing. You just don't want to needlessly break customers.

Relatively recently, UEFI started becoming an option for some
non-aarch64 instance types, and can be selected either at instance
launch time, or configured to be part of the AMI.
See https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-boot.html

There are however a *lot* of instance types, a whole bunch of which are
less likely to support UEFI - the documentation gives t2.xlarge as an
example of one that only supports legacy-bios.

AMIs that don't run on all instance types tend to cause confusion, no
matter how clear you document the limitations. It's only now that this
is something that's even emerging as something that the EC2 APIs would
assist in enforcing. In fact, in Amazon Linux 2022 we went for the
decision that for aarch64 we'd require Graviton 2 and x86-64v2 as
minimal requirements, and having AL2022 AMIs not boot on a1 instances
types did surprise some people, even though we documented it.

With things like spot instances, there's a lot of customer demand for
"the cheapest possible compute, doesn't matter what or where" to run
things that aren't time critical.

Now, the interesting thing about Cloud images is that there isn't an
installer. In fact, Amazon Linux doesn't have one and we don't package
Anaconda anywhere. All users come from a disk image, which we create
using separate tooling. Thus, from an AL perspective, if Anaconda were
to stop  supporting installing for legacy-bios, this wouldn't affect
us at all.

However, we would have a big interest in having legacy-bios work well to
boot the OS, likely for a decent number of years to come (however much I
wish this wasn't the case).

I guess the interesting balance here is maintenance responsibility as
well. I *very* much don't want any of this to read like a request for
the community to maintain something that's primarily useful only to a
specific vendor. There's a point where if it's functionality that's
needed by a vendor, then said vendor has to maintain it, or be very
involved in maintaining it.

(and for non-EC2 and non-Amazon-Linux input, I have at least one machine
at home that run Fedora that don't have UEFI, a HP Microserver of a
certain age. Now, maybe it's time for me to upgrade that hardware, but I
bet there's a lot of folk who either don't want to do that, or cannot
reasonably afford to)

[Stewart Smith]

Chris Adams <linux(a)cmadams.net&gt; writes:
>  Once upon a time, Jared Dominguez <jaredz(a)redhat.com&gt; said:
> > Looks like they are using vSphere, which supports UEFI VMs. The same is
> > true for KVM, Xen and bhyve, so it's more about what feature set cloud
> > providers using these hypervisors are choosing to turn on.
>
>  In a way, this is similar to "your router supports IPv6, why don't you
>  just turn it on?":
>
>  - version considerations: when did $HYPERVISOR start supporting UEFI?
>    what versions may still be running in some parts of infrastructure?
>
>  - "support" vs. "really support": just because something says it
>    "supports UEFI" doesn't mean it works right; large-scale hosters need
>    to do lots of testing of all their supported systems and setups to see
>    how they actually react
>
>  - internal tooling: just because a hoster is using KVM for example
>    doesn't mean they just install the vendor software and go; they have
>    their own internal management systems built on top, calling vendor
>    APIs to do things
>
>  - presentation: adding user-facing options should always be carefully
>    considered, especially when they are "change this option and your VM
>    possibly won't boot" type (so more support tickets) 
Support tickets don't worry me as much as making breaking changes for
customers that possibly result in outages for them do.

For example, I don't think it'd ever be possible to flip the default for
existing EC2 instance types. Maybe the default for a new major OS
version, but there's likely going to be an amount of time before all EC2
instance types support UEFI, and then there'll be customers with a
multitude of custom things enabled that don't (at least yet) work with
UEFI and will take the easy option of going back to legacy-bios,
probably for years.

[Jeremy Linton]

On 4/6/22 12:57, Neal Gompa wrote:
(trimming)
>  * NVIDIA graphics
>  * Broadcom wireless
>  
>  The former case is excessively common, and the latter case is fairly
>  common with HP and Dell machines as well as some smaller OEMs. I
>  literally helped someone this past week with both[1][2][3]. The
>  Workstation WG has been tracking both issues for years now[4][5]. This
>  situation is *worse* now because we have Fedora Linux preloaded on
>  computers, and OEMs basically have to disable Secure Boot to make
>  things "work". How's that for improving security? 
I too have been a bit surprised at some of the difficulties of 
hibernate/secure boot on recent fedora releases. It seems people are 
entirely unaware that ACPI/S3 standby is gone from most consumer 
laptops, and the modern standby replacement implementations tend to work 
very poorly WRT conserving battery with the lid closed in Linux.

Leaving hibernate as the only workable solution if you want to just 
close the laptop lid, and come back the next day without having the 
machine at 0% battery. This is the expected/default windows behavior 
too. After ~5% IIRC battery loss in modern standby mode, it hibernates. 
(look up windows adaptive hibernate).

So, on a recent fedora machine, it took me more than 4 hours to get a 
hibernation file on btrfs plus LUKS encrypted partition working. The 
documentation for that wasn't to be found anywhere on the fedora/RH 
sites and required compiling a tool to do the block offset calculations 
and manually adding the resume_offset options to grub/etc. All while 
avoiding the mass of incorrect information found on the internet. And of 
course it also requires disabling swap on zram (which was nonsense on 
the machine anyway, given the disks are faster than it can 
compress/decompress pages).

And of course the lockdown patches in the kernel still aren't smart 
enough to be able to detect that the swapfile is actually encrypted, so 
it also requires disabling secure boot (this IMHO is frankly 
unacceptable, that one can't have both options enabled at the same time).

So, this is really less about BIOS/EFI and more about some pretty basic 
functionality being broken in the distro.



>  
>  On the cloud side, it's been very difficult to articulate any benefits
>  for supporting UEFI when the majority of the consumers of Fedora Cloud
>  don't have any pressing need to do it and things like hibernation and
>  snapshotting are non-functional. Last year, I changed Fedora Cloud to
>  hybrid boot[6] so that our image artifacts support both boot modes.
>  While GCP requires UEFI and Azure prefers it, AWS has very basic
>  support for UEFI and using UEFI causes you to lose some features that
>  exist only in BIOS mode. One of those is leveraging hibernation in the
>  cloud for spot instances[7]. Moving past the Big Three(tm), the actual
>  cloud providers that matter from a Fedora context are the smaller
>  outfits that principally serve Linux users. These are companies like
>  DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who
>  graciously do offer Fedora Linux in their platforms. All of their
>  virtualization platforms are BIOS only right now, and getting them to
>  switch requires them to uplift their platforms to support UEFI in the
>  first place. And again, when UEFI means things like VM snapshots and
>  cloud hibernation don't work, it's not very compelling.
>  
>  You'd think that given how important this is for the Cloud that it
>  would have mattered for RHEL, but nope. These problems are not new.
>  They've existed since we supported UEFI Secure Boot, and given how
>  people have responded saying these issues are irrelevant to this
>  Change, it shows how out of sync with reality this Change is. 

>  
>  Frankly, I'm extremely frustrated and exhausted over the situation.
>  
>  [1]: https://twitter.com/Det_Conan_Kudo/status/1508968025785049088
>  [2]: https://twitter.com/Det_Conan_Kudo/status/1508984123339202560
>  [3]: https://twitter.com/Det_Conan_Kudo/status/1511755879687012354
>  [4]: https://pagure.io/fedora-workstation/issue/155
>  [5]: https://pagure.io/fedora-workstation/issue/116
>  [6]: https://fedoraproject.org/wiki/Changes/FedoraCloudHybridBoot
>  [7]: https://lwn.net/Articles/821158/
>  
>  
>  --
>  真実はいつも一つ！/ Always, there's only one truth!
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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

[Chris Murphy]

On Mon, May 2, 2022 at 5:29 PM Jeremy Linton <jeremy.linton(a)arm.com&gt; wrote:
>  On 4/6/22 12:57, Neal Gompa wrote:
>  (trimming)
>  > * NVIDIA graphics
>  > * Broadcom wireless
>  >
>  > The former case is excessively common, and the latter case is fairly
>  > common with HP and Dell machines as well as some smaller OEMs. I
>  > literally helped someone this past week with both[1][2][3]. The
>  > Workstation WG has been tracking both issues for years now[4][5]. This
>  > situation is *worse* now because we have Fedora Linux preloaded on
>  > computers, and OEMs basically have to disable Secure Boot to make
>  > things "work". How's that for improving security?
>
>  I too have been a bit surprised at some of the difficulties of
>  hibernate/secure boot on recent fedora releases. It seems people are
>  entirely unaware that ACPI/S3 standby is gone from most consumer
>  laptops, and the modern standby replacement implementations tend to work
>  very poorly WRT conserving battery with the lid closed in Linux. 
It's a kernel problem. I'm not sure to what degree upstream is aware
of it. But there's not a lot we can do about it except file bugs and
ask for improvement.


>  So, on a recent fedora machine, it took me more than 4 hours to get a
>  hibernation file on btrfs plus LUKS encrypted partition working. The
>  documentation for that wasn't to be found anywhere on the fedora/RH
>  sites and required compiling a tool to do the block offset calculations
>  and manually adding the resume_offset options to grub/etc. All while
>  avoiding the mass of incorrect information found on the internet. And of
>  course it also requires disabling swap on zram (which was nonsense on
>  the machine anyway, given the disks are faster than it can
>  compress/decompress pages). 
I don't think it requires disabling swap on zram per se - from what
I've been told the hibernation code knows it can't use it for the
hibernation image, not least of which is it's not big enough for a
contiguous write of the image. The issue might be that so much needs
to be swapped out, to free ~50% RAM, which is used to create the
hibernation image in memory before it's written out. We need a clear
reproducer with logs and get it posted to the Linux memory management
mailing list to see what's going wrong. Since zram is threaded, it's
pretty unlikely drive writes are faster than memory writes with
compression. LZO+RLE is computationally pretty cheap.


>  And of course the lockdown patches in the kernel still aren't smart
>  enough to be able to detect that the swapfile is actually encrypted, so
>  it also requires disabling secure boot (this IMHO is frankly
>  unacceptable, that one can't have both options enabled at the same time). 
Encryption isn't enough to ensure the image is valid. It needs to be
signed. But in any case this is also upstream effort required,
including discovering the offset via a standard API for all file
systems.


>  So, this is really less about BIOS/EFI and more about some pretty basic
>  functionality being broken in the distro. 

-- 
Chris Murphy

[Jeremy Linton]

Hi,

On 5/2/22 22:53, Chris Murphy wrote:
>  On Mon, May 2, 2022 at 5:29 PM Jeremy Linton
> <jeremy.linton(a)arm.com&gt; wrote:
> >
> > On 4/6/22 12:57, Neal Gompa wrote:
> > (trimming)
> >> * NVIDIA graphics
> >> * Broadcom wireless
> >>
> >> The former case is excessively common, and the latter case is fairly
> >> common with HP and Dell machines as well as some smaller OEMs. I
> >> literally helped someone this past week with both[1][2][3]. The
> >> Workstation WG has been tracking both issues for years now[4][5]. This
> >> situation is *worse* now because we have Fedora Linux preloaded on
> >> computers, and OEMs basically have to disable Secure Boot to make
> >> things "work". How's that for improving security?
> >
> > I too have been a bit surprised at some of the difficulties of
> > hibernate/secure boot on recent fedora releases. It seems people are
> > entirely unaware that ACPI/S3 standby is gone from most consumer
> > laptops, and the modern standby replacement implementations tend to work
> > very poorly WRT conserving battery with the lid closed in Linux.
>  
>  It's a kernel problem. I'm not sure to what degree upstream is aware
>  of it. But there's not a lot we can do about it except file bugs and
>  ask for improvement.
>  
>  
> >
> > So, on a recent fedora machine, it took me more than 4 hours to get a
> > hibernation file on btrfs plus LUKS encrypted partition working. The
> > documentation for that wasn't to be found anywhere on the fedora/RH
> > sites and required compiling a tool to do the block offset calculations
> > and manually adding the resume_offset options to grub/etc. All while
> > avoiding the mass of incorrect information found on the internet. And of
> > course it also requires disabling swap on zram (which was nonsense on
> > the machine anyway, given the disks are faster than it can
> > compress/decompress pages).
>  
>  I don't think it requires disabling swap on zram per se - from what
>  I've been told the hibernation code knows it can't use it for the
>  hibernation image, not least of which is it's not big enough for a
>  contiguous write of the image. The issue might be that so much needs
>  to be swapped out, to free ~50% RAM, which is used to create the
>  hibernation image in memory before it's written out. We need a clear
>  reproducer with logs and get it posted to the Linux memory management
>  mailing list to see what's going wrong. Since zram is threaded, it's
>  pretty unlikely drive writes are faster than memory writes with
>  compression. LZO+RLE is computationally pretty cheap. 
DMA is computationally free. and at >3GB/sec on modern hw with 
sufficient queue depth or contiguous. And the RLE improvements only help 
when the page is basically empty. AKA its a great chrome benchmark tool, 
less so for real workloads.

>  
>  
> >
> > And of course the lockdown patches in the kernel still aren't smart
> > enough to be able to detect that the swapfile is actually encrypted, so
> > it also requires disabling secure boot (this IMHO is frankly
> > unacceptable, that one can't have both options enabled at the same time).
>  
>  Encryption isn't enough to ensure the image is valid. It needs to be
>  signed. But in any case this is also upstream effort required,
>  including discovering the offset via a standard API for all file
>  systems. 
Yes, I'm aware much of this is a kernel problem, but the point being 
that in the meantime, most random machines people are buying at retail 
won't last more than a day or so without being plugged in using fedora, 
vs many days with windows because its hibernating with secure boot 
turned on.



>  
>  
> >
> > So, this is really less about BIOS/EFI and more about some pretty basic
> > functionality being broken in the distro.
>  
>

[Chris Murphy]

On Tue, May 3, 2022 at 11:32 AM Jeremy Linton <jeremy.linton(a)arm.com&gt; wrote:

>  Hi,
>
>  On 5/2/22 22:53, Chris Murphy wrote:
>  > On Mon, May 2, 2022 at 5:29 PM Jeremy Linton <jeremy.linton(a)arm.com&gt;
>  wrote:
>  >>
>  >> On 4/6/22 12:57, Neal Gompa wrote:
>  >> (trimming)
>  >>> * NVIDIA graphics
>  >>> * Broadcom wireless
>  >>>
>  >>> The former case is excessively common, and the latter case is fairly
>  >>> common with HP and Dell machines as well as some smaller OEMs. I
>  >>> literally helped someone this past week with both[1][2][3]. The
>  >>> Workstation WG has been tracking both issues for years now[4][5]. This
>  >>> situation is *worse* now because we have Fedora Linux preloaded on
>  >>> computers, and OEMs basically have to disable Secure Boot to make
>  >>> things "work". How's that for improving security?
>  >>
>  >> I too have been a bit surprised at some of the difficulties of
>  >> hibernate/secure boot on recent fedora releases. It seems people are
>  >> entirely unaware that ACPI/S3 standby is gone from most consumer
>  >> laptops, and the modern standby replacement implementations tend to work
>  >> very poorly WRT conserving battery with the lid closed in Linux.
>  >
>  > It's a kernel problem. I'm not sure to what degree upstream is aware
>  > of it. But there's not a lot we can do about it except file bugs and
>  > ask for improvement.
>  >
>  >
>  >>
>  >> So, on a recent fedora machine, it took me more than 4 hours to get a
>  >> hibernation file on btrfs plus LUKS encrypted partition working. The
>  >> documentation for that wasn't to be found anywhere on the fedora/RH
>  >> sites and required compiling a tool to do the block offset calculations
>  >> and manually adding the resume_offset options to grub/etc. All while
>  >> avoiding the mass of incorrect information found on the internet. And of
>  >> course it also requires disabling swap on zram (which was nonsense on
>  >> the machine anyway, given the disks are faster than it can
>  >> compress/decompress pages).
>  >
>  > I don't think it requires disabling swap on zram per se - from what
>  > I've been told the hibernation code knows it can't use it for the
>  > hibernation image, not least of which is it's not big enough for a
>  > contiguous write of the image. The issue might be that so much needs
>  > to be swapped out, to free ~50% RAM, which is used to create the
>  > hibernation image in memory before it's written out. We need a clear
>  > reproducer with logs and get it posted to the Linux memory management
>  > mailing list to see what's going wrong. Since zram is threaded, it's
>  > pretty unlikely drive writes are faster than memory writes with
>  > compression. LZO+RLE is computationally pretty cheap.
>
>  DMA is computationally free. and at >3GB/sec on modern hw with
>  sufficient queue depth or contiguous. And the RLE improvements only help
>  when the page is basically empty. AKA its a great chrome benchmark tool,
>  less so for real workloads.
>  
Quite a lot of folks in the Fedora community do not have NVMe drives. If
you have a real workload that's straightforward to reproduce better
performance when swap on NVME plain partition vs zram, I'd like to give it
a go. There'a always tradeoffs, the goal is to do a good job for most use
cases, not optimize for a few.



>  >
>  >
>  >>
>  >> And of course the lockdown patches in the kernel still aren't smart
>  >> enough to be able to detect that the swapfile is actually encrypted, so
>  >> it also requires disabling secure boot (this IMHO is frankly
>  >> unacceptable, that one can't have both options enabled at the same
>  time).
>  >
>  > Encryption isn't enough to ensure the image is valid. It needs to be
>  > signed. But in any case this is also upstream effort required,
>  > including discovering the offset via a standard API for all file
>  > systems.
>
>  Yes, I'm aware much of this is a kernel problem, but the point being
>  that in the meantime, most random machines people are buying at retail
>  won't last more than a day or so without being plugged in using fedora,
>  vs many days with windows because its hibernating with secure boot
>  turned on.
>  
On a recently purchased Lenovo, s2idle is what's used with Windows 10 sleep
set in the firmware setup. I see about 1% battery drop per hour. When
switching it to Linux sleep, it uses ACPI S3, and I see maybe 1% battery
drop per 8 hours. I don't know why. But until there's
authenticated+encrypted hibernation images, I think there's not much to be
done out of the box. Even once we have hibernation images, we can't depend
on hibernation working for various reasons:

https://pagure.io/fedora-workstation/blob/master/f/hibernationstatus.md

It's not good that hibernation doesn't work well right now. But it's
possible to give users an even worse experience, including a false sense of
security regarding their data when hibernation is used.




-- 
Chris Murphy

[Zbigniew Jędrzejewski-Szmek]

On Mon, May 02, 2022 at 11:53:12PM -0400, Chris Murphy wrote:
>  On Mon, May 2, 2022 at 5:29 PM Jeremy Linton
> <jeremy.linton(a)arm.com&gt; wrote:
>  > And of
>  > course it also requires disabling swap on zram (which was nonsense on
>  > the machine anyway, given the disks are faster than it can
>  > compress/decompress pages).
>  
>  I don't think it requires disabling swap on zram per se - from what
>  I've been told the hibernation code knows it can't use it for the
>  hibernation image, not least of which is it's not big enough for a
>  contiguous write of the image. The issue might be that so much needs
>  to be swapped out, to free ~50% RAM, which is used to create the
>  hibernation image in memory before it's written out. We need a clear
>  reproducer with logs and get it posted to the Linux memory management
>  mailing list to see what's going wrong. Since zram is threaded, it's
>  pretty unlikely drive writes are faster than memory writes with
>  compression. LZO+RLE is computationally pretty cheap. 
In general, hibernation is expected to work if a zram device is present.
Systemd will automatically filter out zram devices from the candidate list.

If it didn't work for you, it's probably somehting like Chris wrote,
not enough swap for the amount of memory used.

>  > So, on a recent fedora machine, it took me more than 4 hours to
> get a
>  > hibernation file on btrfs plus LUKS encrypted partition working. The
>  > documentation for that wasn't to be found anywhere on the fedora/RH
>  > sites and required compiling a tool to do the block offset calculations
>  > and manually adding the resume_offset options to grub/etc. 
systemd has code to calculate the offset. It is used to try to figure
out which of the swap partitions matches swap_offset= configured on
the kernel command line. I guess it'd be helpful if we exposed this
functionality somewhere. Maybe something like
'systemd-analyze suggest-hibernation-config-that-works' ;)

Zbyszek