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@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.or...
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/Ha...
* 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.)
On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton bcotton@redhat.com 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@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.or...
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/Ha...
- 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!
On Tue, Apr 5, 2022 at 4:09 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton bcotton@redhat.com 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@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.or...
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/Ha...
- 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.
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.
On Tue, Apr 5, 2022 at 11:26 AM Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Apr 5, 2022 at 4:09 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton bcotton@redhat.com 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@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.or...
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/Ha...
- 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.
* 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
Neal Gompa ngompa13@gmail.com 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
On Tue, Apr 5 2022 at 11:56:07 AM -0400, Robbie Harwood rharwood@redhat.com 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
On Apr 5, 2022, at 8:08 AM, Neal Gompa ngompa13@gmail.com wrote:
On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton bcotton@redhat.com 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@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.or...
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/Ha...
- 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.
On Tue, Apr 5, 2022, 11:15 Neal Gompa ngompa13@gmail.com wrote:
On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton bcotton@redhat.com 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@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.or...
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/Ha...
- 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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Tue, 2022-04-05 at 09:33 -0700, David Duncan wrote:
On Apr 5, 2022, at 8:08 AM, Neal Gompa ngompa13@gmail.com wrote:
On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton bcotton@redhat.com 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@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.or...
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/Ha...
- Release engineering:
[https://pagure.io/releng/issue/10738%C2%A0#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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Neal Gompa ngompa13@gmail.com 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
David Duncan davdunc@gmail.com 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
Once upon a time, Robbie Harwood rharwood@redhat.com 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.
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
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
On Tue, Apr 5, 2022 at 1:31 PM Tom Hughes via devel devel@lists.fedoraproject.org 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!
On 05/04/2022 18:38, Neal Gompa wrote:
On Tue, Apr 5, 2022 at 1:31 PM Tom Hughes via devel devel@lists.fedoraproject.org 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
On Tue, Apr 5, 2022 at 12:31 PM Tom Hughes via devel < devel@lists.fedoraproject.org> 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
On Tue, Apr 5, 2022 at 12:39 PM Neal Gompa ngompa13@gmail.com 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?
On Tue, Apr 5, 2022 at 1:46 PM Tom Hughes tom@compton.nu wrote:
On 05/04/2022 18:38, Neal Gompa wrote:
On Tue, Apr 5, 2022 at 1:31 PM Tom Hughes via devel devel@lists.fedoraproject.org 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!
Am 05.04.2022 um 16:52 schrieb Ben Cotton bcotton@redhat.com:
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.)
On Tue, Apr 5, 2022 at 1:47 PM Gregory Bartholomew gregory.lee.bartholomew@gmail.com wrote:
On Tue, Apr 5, 2022 at 12:39 PM Neal Gompa ngompa13@gmail.com 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.
Tom Hughes via devel devel@lists.fedoraproject.org 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
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_dev...
Tom
Peter Boy pboy@uni-bremen.de 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
Gregory Bartholomew gregory.lee.bartholomew@gmail.com 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
Am 05.04.2022 um 19:38 schrieb Neal Gompa ngompa13@gmail.com:
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.
Tom Hughes tom@compton.nu 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_dev...
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
Am 05.04.2022 um 19:57 schrieb Robbie Harwood rharwood@redhat.com:
Peter Boy pboy@uni-bremen.de 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
Ben Cotton bcotton@redhat.com 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<
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.
On Tue, Apr 5, 2022 at 1:17 PM Jason L Tibbitts III j@tib.bs 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.
PGNet Dev pgnet.dev@gmail.com 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
(Akamai is, to my knowledge, not a provider of VPSs.)
https://www.linode.com/press-release/akamai-to-acquire-linode/
On Tue, Apr 5, 2022 at 2:36 PM Robbie Harwood rharwood@redhat.com wrote:
PGNet Dev pgnet.dev@gmail.com 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.
On 4/5/22 12:29, Michael Catanzaro wrote:
On Tue, Apr 5 2022 at 11:56:07 AM -0400, Robbie Harwood rharwood@redhat.com 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.
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.
On 4/5/22 13:38, Neal Gompa wrote:
On Tue, Apr 5, 2022 at 1:31 PM Tom Hughes via devel devel@lists.fedoraproject.org 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?
On Tue, Apr 5, 2022 at 3:06 PM Demi Marie Obenour demiobenour@gmail.com wrote:
On 4/5/22 13:38, Neal Gompa wrote:
On Tue, Apr 5, 2022 at 1:31 PM Tom Hughes via devel devel@lists.fedoraproject.org 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.
On 4/5/22 15:09, Neal Gompa wrote:
On Tue, Apr 5, 2022 at 3:06 PM Demi Marie Obenour demiobenour@gmail.com wrote:
On 4/5/22 13:38, Neal Gompa wrote:
On Tue, Apr 5, 2022 at 1:31 PM Tom Hughes via devel devel@lists.fedoraproject.org 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.
On Tue, Apr 5, 2022 at 3:15 PM Neal Gompa ngompa13@gmail.com 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
On Tue, Apr 5, 2022 at 11:18 AM Ben Cotton bcotton@redhat.com 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
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.
On Tue, Apr 5, 2022 at 3:38 PM Adam Jackson ajax@redhat.com wrote:
On Tue, Apr 5, 2022 at 3:15 PM Neal Gompa ngompa13@gmail.com 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!
On Wed, Apr 6, 2022 at 1:18 AM Ben Cotton bcotton@redhat.com 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@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.
On Tue, Apr 5, 2022 at 4:01 PM Sebastian Crane seabass-labrax@gmx.com 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
On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton bcotton@redhat.com 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 lists@colorremedies.com writes:
On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton bcotton@redhat.com 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://docs.fedoraproject.org/en-US/fedora/rawhide/release-notes/welcome/Ha...
Be well, --Robbie
On Tue, Apr 5, 2022 at 9:56 AM Florian Weimer fweimer@redhat.com 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.
On Tue, Apr 5, 2022 at 4:28 PM Chris Murphy lists@colorremedies.com wrote:
On Tue, Apr 5, 2022 at 9:56 AM Florian Weimer fweimer@redhat.com 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.
On Tue, Apr 5, 2022 at 11:31 AM Tom Hughes via devel devel@lists.fedoraproject.org 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.
On Tue, Apr 5, 2022 at 11:47 AM Gregory Bartholomew gregory.lee.bartholomew@gmail.com wrote:
On Tue, Apr 5, 2022 at 12:39 PM Neal Gompa ngompa13@gmail.com 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.
On Tue, Apr 5, 2022 at 4:10 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Apr 5, 2022 at 3:38 PM Adam Jackson ajax@redhat.com wrote:
On Tue, Apr 5, 2022 at 3:15 PM Neal Gompa ngompa13@gmail.com 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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Tue, Apr 5, 2022 at 5:46 PM Richard Shaw hobbes1069@gmail.com wrote:
On Tue, Apr 5, 2022 at 12:31 PM Tom Hughes via devel devel@lists.fedoraproject.org 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.
On Tue, Apr 5, 2022 at 3:51 PM Chris Murphy lists@colorremedies.com wrote:
On Tue, Apr 5, 2022 at 11:47 AM Gregory Bartholomew gregory.lee.bartholomew@gmail.com 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.
On Tue, Apr 5, 2022 at 3:42 PM Gregory Bartholomew gregory.lee.bartholomew@gmail.com wrote:
On Tue, Apr 5, 2022 at 3:51 PM Chris Murphy lists@colorremedies.com wrote:
On Tue, Apr 5, 2022 at 11:47 AM Gregory Bartholomew gregory.lee.bartholomew@gmail.com 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.
On 4/5/22 15:58, Adam Jackson wrote:
On Tue, Apr 5, 2022 at 11:18 AM Ben Cotton bcotton@redhat.com 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?
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@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
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
On Tue, Apr 5, 2022 at 3:08 PM Jared Dominguez jaredz@redhat.com 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.
Those figures are recommended minimums, not requirements. I have a single core F35 machine which works fine.
On Tue, Apr 5, 2022 at 7:39 PM Chris Murphy lists@colorremedies.com wrote:
On Tue, Apr 5, 2022 at 3:08 PM Jared Dominguez jaredz@redhat.com 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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton bcotton@redhat.com 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.
On Tue, Apr 5, 2022 at 8:51 PM Chris Murphy lists@colorremedies.com wrote:
On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton bcotton@redhat.com 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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 4/5/22 19:38, Chris Murphy wrote:
On Tue, Apr 5, 2022 at 3:08 PM Jared Dominguez jaredz@redhat.com 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.
On Tue, Apr 5, 2022 at 6:55 PM Jared Dominguez jaredz@redhat.com wrote:
On Tue, Apr 5, 2022 at 8:51 PM Chris Murphy lists@colorremedies.com wrote:
On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton bcotton@redhat.com 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.
On 4/5/22 16:09, Neal Gompa wrote:
On Tue, Apr 5, 2022 at 3:38 PM Adam Jackson ajax@redhat.com wrote:
On Tue, Apr 5, 2022 at 3:15 PM Neal Gompa ngompa13@gmail.com 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.
On Tue, Apr 5, 2022 at 8:59 PM Demi Marie Obenour demiobenour@gmail.com wrote:
On 4/5/22 19:38, Chris Murphy wrote:
On Tue, Apr 5, 2022 at 3:08 PM Jared Dominguez jaredz@redhat.com 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.
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...
On Tue, Apr 5, 2022 at 9:07 PM Demi Marie Obenour demiobenour@gmail.com wrote:
On 4/5/22 16:09, Neal Gompa wrote:
On Tue, Apr 5, 2022 at 3:38 PM Adam Jackson ajax@redhat.com wrote:
On Tue, Apr 5, 2022 at 3:15 PM Neal Gompa ngompa13@gmail.com 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.
On Wed, Apr 6, 2022 at 12:59 AM Demi Marie Obenour demiobenour@gmail.com 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.
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@gmail.com To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Subject: Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Wed, Apr 6, 2022 at 12:59 AM Demi Marie Obenour demiobenour@gmail.com 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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
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.
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@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.or...
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
On Wed, Apr 6, 2022 at 12:04 AM Gary Buhrmaster gary.buhrmaster@gmail.com wrote:
On Wed, Apr 6, 2022 at 12:59 AM Demi Marie Obenour demiobenour@gmail.com 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!
On Wed, 6 Apr 2022 at 11:20, Dominik 'Rathann' Mierzejewski dominik@greysector.net 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
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.
On Wed, Apr 6, 2022 at 7:14 AM John Boero boeroboy@gmail.com 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.
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.
On Wed, Apr 6, 2022 at 7:30 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org 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!
Dne 05. 04. 22 v 17:08 Neal Gompa napsal(a):
On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton bcotton@redhat.com 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@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.or...
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/Ha...
- 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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
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.
On Wed, Apr 6, 2022 at 7:08 AM Richard Hughes hughsient@gmail.com wrote:
On Wed, 6 Apr 2022 at 11:20, Dominik 'Rathann' Mierzejewski dominik@greysector.net 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
On Wed, Apr 6, 2022 at 8:04 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 05. 04. 22 v 17:08 Neal Gompa napsal(a):
On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton bcotton@redhat.com 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@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.or...
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/Ha...
- 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.
On Wed, Apr 6, 2022 at 1:16 AM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Apr 5, 2022 at 9:07 PM Demi Marie Obenour demiobenour@gmail.com 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.
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:
- Bugs and feature requests around UEFI related features are ignored
- The packages are locked down so there is no way for the community to help
- 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.
On Wednesday, 06 April 2022 at 13:07, Richard Hughes wrote:
On Wed, 6 Apr 2022 at 11:20, Dominik 'Rathann' Mierzejewski dominik@greysector.net 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
On Wed, Apr 6, 2022 at 12:15 PM Josh Boyer jwboyer@fedoraproject.org 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.
On Wed, Apr 6, 2022 at 4:06 AM laolux laolux via devel < devel@lists.fedoraproject.org> 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
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.
There are other ways to create bootable media, right? Does everything need to be Koji+Lorax?
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
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:
<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
On Wed, Apr 6, 2022 at 10:18 AM Hans de Goede hdegoede@redhat.com 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:
<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:
- 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.
- 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.
- 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:
- 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.
- 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.
Once upon a time, Alberto Abrao alberto@abrao.net 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).
majid hussain mhussaincov93@gmx.com 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
Vít Ondruch vondruch@redhat.com 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
Neal Gompa ngompa13@gmail.com 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.
- 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.
- 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
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
"Andre Robatino" robatino@fedoraproject.org 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
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
On Wed, Apr 6, 2022 at 10:59 AM Robbie Harwood rharwood@redhat.com wrote:
Neal Gompa ngompa13@gmail.com 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.
- 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.
- 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!
Chris Murphy lists@colorremedies.com writes:
On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton bcotton@redhat.com 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
Neal Gompa ngompa13@gmail.com writes:
On Wed, Apr 6, 2022 at 7:14 AM John Boero boeroboy@gmail.com 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
On Wed, 6 Apr 2022 06:28:59 +0200 majid hussain mhussaincov93@gmx.com 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-la...
Neal Gompa ngompa13@gmail.com writes:
On Wed, Apr 6, 2022 at 10:59 AM Robbie Harwood rharwood@redhat.com wrote:
Neal Gompa ngompa13@gmail.com writes:
- 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
On 4/5/22 10:52 AM, Ben Cotton wrote:
...
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?
On Wed, Apr 6, 2022 at 8:20 AM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Apr 6, 2022 at 8:04 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 05. 04. 22 v 17:08 Neal Gompa napsal(a):
On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton bcotton@redhat.com 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@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.or...
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/Ha...
- 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:
- 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
- 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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Wed, Apr 6 2022 at 08:16:09 AM -0400, Neal Gompa ngompa13@gmail.com 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
On Wed, Apr 6 2022 at 11:11:37 AM -0400, Neal Gompa ngompa13@gmail.com 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?
On Tue, Apr 5, 2022 at 6:39 PM Chris Murphy lists@colorremedies.com wrote:
On Tue, Apr 5, 2022 at 3:08 PM Jared Dominguez jaredz@redhat.com 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
On Wed, Apr 6, 2022 at 12:23 PM Justin Forbes jmforbes@linuxtx.org wrote:
On Tue, Apr 5, 2022 at 6:39 PM Chris Murphy lists@colorremedies.com wrote:
On Tue, Apr 5, 2022 at 3:08 PM Jared Dominguez jaredz@redhat.com 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!
On Tue, Apr 5, 2022 at 6:51 PM Demi Marie Obenour demiobenour@gmail.com 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
Michael Catanzaro mcatanzaro@gnome.org 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
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
On Wed, Apr 6, 2022 at 11:50 AM Jared Dominguez jaredz@redhat.com wrote:
On Wed, Apr 6, 2022 at 8:20 AM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Apr 6, 2022 at 8:04 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 05. 04. 22 v 17:08 Neal Gompa napsal(a):
On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton bcotton@redhat.com 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@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.or...
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/Ha...
- 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:
- 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!
On Wed, Apr 6 2022 at 01:57:00 PM -0400, Neal Gompa ngompa13@gmail.com 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.
On Wed, Apr 6, 2022 at 2:26 PM Michael Catanzaro mcatanzaro@gnome.org wrote:
On Wed, Apr 6 2022 at 01:57:00 PM -0400, Neal Gompa ngompa13@gmail.com 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-limit... 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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 4/6/22 06:43, Neal Gompa wrote:
On Wed, Apr 6, 2022 at 12:04 AM Gary Buhrmaster gary.buhrmaster@gmail.com wrote:
On Wed, Apr 6, 2022 at 12:59 AM Demi Marie Obenour demiobenour@gmail.com 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.
Can we get NVIDIA to make the module build reproducible? If so, we could distribute a detached signature.
On Wed, Apr 6, 2022 at 4:09 PM Demi Marie Obenour demiobenour@gmail.com wrote:
On 4/6/22 06:43, Neal Gompa wrote:
On Wed, Apr 6, 2022 at 12:04 AM Gary Buhrmaster gary.buhrmaster@gmail.com wrote:
On Wed, Apr 6, 2022 at 12:59 AM Demi Marie Obenour demiobenour@gmail.com 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.
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.
Hi,
On 4/6/22 16:23, Neal Gompa wrote:
On Wed, Apr 6, 2022 at 10:18 AM Hans de Goede hdegoede@redhat.com 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:
<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:
- 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.
- 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.
- 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:
- 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.
- 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
On Wed, Apr 6 2022 at 03:35:38 PM -0400, Jared Dominguez jaredz@redhat.com 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....
On Wed, Apr 6, 2022 at 5:51 PM Jared Dominguez jaredz@redhat.com 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.
- The packages are locked down so there is no way for the community to help
- 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
On Wed, Apr 06, 2022 at 11:02:17AM -0400, Robbie Harwood wrote:
"Andre Robatino" robatino@fedoraproject.org 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
Demi Marie Obenour demiobenour@gmail.com writes:
On 4/5/22 12:29, Michael Catanzaro wrote:
On Tue, Apr 5 2022 at 11:56:07 AM -0400, Robbie Harwood rharwood@redhat.com 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
Dominik 'Rathann' Mierzejewski dominik@greysector.net writes:
On Wednesday, 06 April 2022 at 13:07, Richard Hughes wrote:
Dominik 'Rathann' Mierzejewski dominik@greysector.net 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
Demi Marie Obenour demiobenour@gmail.com writes:
On 4/6/22 06:43, Neal Gompa wrote:
On Wed, Apr 6, 2022 at 12:04 AM Gary Buhrmaster gary.buhrmaster@gmail.com wrote:
On Wed, Apr 6, 2022 at 12:59 AM Demi Marie Obenour demiobenour@gmail.com 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.
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
On 4/6/22 16:59, Robbie Harwood wrote:
Demi Marie Obenour demiobenour@gmail.com writes:
On 4/5/22 12:29, Michael Catanzaro wrote:
On Tue, Apr 5 2022 at 11:56:07 AM -0400, Robbie Harwood rharwood@redhat.com 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.
Demi Marie Obenour demiobenour@gmail.com writes:
On 4/6/22 16:59, Robbie Harwood wrote:
Demi Marie Obenour demiobenour@gmail.com writes:
On 4/5/22 12:29, Michael Catanzaro wrote:
On Tue, Apr 5 2022 at 11:56:07 AM -0400, Robbie Harwood rharwood@redhat.com 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
On Wed, Apr 6, 2022 at 5:37 PM Demi Marie Obenour demiobenour@gmail.com wrote:
On 4/6/22 16:59, Robbie Harwood wrote:
Demi Marie Obenour demiobenour@gmail.com writes:
On 4/5/22 12:29, Michael Catanzaro wrote:
On Tue, Apr 5 2022 at 11:56:07 AM -0400, Robbie Harwood rharwood@redhat.com 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!
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@redhat.com 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
On Wed, Apr 6, 2022 at 6:06 PM Brian C. Lane bcl@redhat.com 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@redhat.com 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.
On Wed, Apr 6, 2022 at 10:23 AM Justin Forbes jmforbes@linuxtx.org 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.
On Wed, Apr 6, 2022 at 6:31 PM Chris Murphy lists@colorremedies.com wrote:
On Wed, Apr 6, 2022 at 10:23 AM Justin Forbes jmforbes@linuxtx.org 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
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.
On Thu, Apr 7, 2022 at 12:33 PM Luya Tshimbalanga luya@fedoraproject.org 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.
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
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
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
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.
On Mi, 06.04.22 07:33, Neal Gompa (ngompa13@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
On Wed, Apr 6, 2022 at 6:31 PM Chris Murphy <lists(a)colorremedies.com> 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.
On Wednesday, 06 April 2022 at 21:35, Jared Dominguez wrote:
On Wed, Apr 6, 2022 at 2:26 PM Michael Catanzaro mcatanzaro@gnome.org wrote:
On Wed, Apr 6 2022 at 01:57:00 PM -0400, Neal Gompa ngompa13@gmail.com 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
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
* Chris Murphy:
On Tue, Apr 5, 2022 at 9:56 AM Florian Weimer fweimer@redhat.com 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
Am 07.04.2022 um 00:25 schrieb Neal Gompa ngompa13@gmail.com:
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.
On Thu, Apr 7, 2022 at 2:20 AM Gerd Hoffmann kraxel@redhat.com 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!
On Thu, 7 Apr 2022 at 09:43, Lennart Poettering mzerqung@0pointer.de 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.
On Apr 7, 2022, at 2:31 AM, Neal Gompa ngompa13@gmail.com wrote:
On Thu, Apr 7, 2022 at 2:20 AM Gerd Hoffmann kraxel@redhat.com 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
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.
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
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.
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.
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.
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.
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.
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).
On Wed, 2022-04-06 at 21:03 -0500, Justin Forbes wrote:
On Wed, Apr 6, 2022 at 6:31 PM Chris Murphy lists@colorremedies.com wrote:
On Wed, Apr 6, 2022 at 10:23 AM Justin Forbes jmforbes@linuxtx.org 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.
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.
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).
Once upon a time, Simo Sorce simo@redhat.com 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.
On Thu, Apr 7, 2022 at 9:20 AM Simo Sorce simo@redhat.com 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@colorremedies.com wrote:
On Wed, Apr 6, 2022 at 10:23 AM Justin Forbes jmforbes@linuxtx.org 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!
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.
On Thu, Apr 7, 2022 at 9:27 AM Chris Adams linux@cmadams.net wrote:
Once upon a time, Simo Sorce simo@redhat.com 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.
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.
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 - virtuall