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, 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.
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
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.
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.
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 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 Thursday, 07 April 2022 at 14:54, Vitaly Zaitsev via devel wrote:
On 07/04/2022 09:59, Dominik 'Rathann' Mierzejewski wrote:
OVH is another big provider and they don't offer UEFI boot with their VPS range. I've just confirmed it with their support.
You should contact their support first.
I already did. Isn't that what I wrote?
Regards, Dominik
On Friday, 08 April 2022 at 13:41, Vitaly Zaitsev via devel wrote:
On 08/04/2022 09:54, Dominik 'Rathann' Mierzejewski wrote:
I already did. Isn't that what I wrote?
Can you post their answer?
Yes: ``` On VPS, we do not provide images with UEFI enabled. ```
They support UEFI on their Public Cloud instances, but the same configuration as my current VPS seems to be twice as expensive.
I've asked them to clarify if they have any plans to enable UEFI for their VPS instances.
Regards, Dominik
On Sunday, 10 April 2022 at 22:30, Dominik 'Rathann' Mierzejewski wrote:
On Friday, 08 April 2022 at 13:41, Vitaly Zaitsev via devel wrote:
On 08/04/2022 09:54, Dominik 'Rathann' Mierzejewski wrote:
I already did. Isn't that what I wrote?
Can you post their answer?
Yes:
On VPS, we do not provide images with UEFI enabled.They support UEFI on their Public Cloud instances, but the same configuration as my current VPS seems to be twice as expensive.
I've asked them to clarify if they have any plans to enable UEFI for their VPS instances.
And their answer is: ``` Currently we do not have any plans for enabling UEFI booting with VPS. ```
So, if this change went ahead as planned, it would cost me twice as much as I'm paying OVH right now to (re-)install Fedora 37+ on their hosting, because I'd have to switch to a different, more expensive service.
Regards, Dominik
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 4/7/22 08:52, Vitaly Zaitsev via devel wrote:
On 05/04/2022 17:44, Neal Gompa wrote:
It is easier to tell people to boot the media in BIOS mode in some cases than it is to figure out how to turn off Secure Boot.
Legacy boot on modern hardware is a hack[1]. Some hardware manufactures even doesn't test CSM support.
Modern *physical* hardware. *Virtual* hardware is another matter entirely.
* 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
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.
* 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
On Thu, Apr 7, 2022 at 2:54 AM Florian Weimer fweimer@redhat.com wrote:
- 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.
CSM enabled systems get a BIOS GRUB installation just as if it was a system without UEFI. The system gets an MBR, GRUB boot code in MBR, GRUB stage 2 in the MBR gap, etc.
* Chris Murphy:
On Thu, Apr 7, 2022 at 2:54 AM Florian Weimer fweimer@redhat.com wrote:
- 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.
CSM enabled systems get a BIOS GRUB installation just as if it was a system without UEFI. The system gets an MBR, GRUB boot code in MBR, GRUB stage 2 in the MBR gap, etc.
Okay, then Secure Boot is mandatory on these systems as far as Fedora is concerned once Fedora removes BIOS support, just as I suspected.
Thanks, Florian
On Thu, Apr 7, 2022 at 4:18 PM Florian Weimer fweimer@redhat.com wrote:
- Chris Murphy:
On Thu, Apr 7, 2022 at 2:54 AM Florian Weimer fweimer@redhat.com
wrote:
- 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.
CSM enabled systems get a BIOS GRUB installation just as if it was a system without UEFI. The system gets an MBR, GRUB boot code in MBR, GRUB stage 2 in the MBR gap, etc.
Okay, then Secure Boot is mandatory on these systems as far as Fedora is concerned once Fedora removes BIOS support, just as I suspected.
There are some Acer systems that make it harder to disable secure boot, but it's still possible. I've not heard of cases where you cannot at all disable secure boot.
Thanks, Florian _______________________________________________ devel mailing list -- devel@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
> This is out of context here because you can disable Secure Boot but > still use UEFI to make that work. You're trying to link to different > problems together.
I think there's firmware out there which enables Secure Boot unconditionally in UEFI mode, but still has CSM support.
The UEFI spec makes CSM and Secure Boot mutually exclusive. CSM enabled renders Secure Boot impossible. So I'm not sure how the firmware can simultaneously enforce Secure Boot, but then permit the loading of non-compliant bootloaders.
I meant that without CSM, Secure Boot is always enabled. I don't know if Fedora UEFI installations work on such systems when CSM is enabled.
CSM enabled systems get a BIOS GRUB installation just as if it was a system without UEFI. The system gets an MBR, GRUB boot code in MBR, GRUB stage 2 in the MBR gap, etc.
Okay, then Secure Boot is mandatory on these systems as far as Fedora is concerned once Fedora removes BIOS support, just as I suspected.
There are some Acer systems that make it harder to disable secure boot, but it's still possible. I've not heard of cases where you cannot at all disable secure boot.
On the systems, if there are any, that don't allow disabling of secure-boot, they definitely wouldn't allow disabling UEFI either, UEFI and secure boot are necessarily mutually exclusive, but a system that won't allow you to disable secure-boot definitely wouldn't support BIOS either.
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 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.
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
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 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 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 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 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 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, 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
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.
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, 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 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 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 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.
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 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 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 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
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
On Wed, Apr 06, 2022 at 10:47:30AM -0400, Robbie Harwood wrote:
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.
Based on a web query, it most likely has EFI support, but it also supports BIOS-compat (CSM?).
Easiest is probably to do:
ls /sys/firmware/efi
This tells you whether the machine booted using UEFI. anaconda will set up a UEFI-capable system if booted that way, unless partitioning is overridden to prevent that.
If it didn't boot using UEFI today, that doesn't mean it can't (you could check with a live image as well). UEFI tends to be enabled on machines made these days by default for Windows logo requirements, but this is firmware land, and there are no absolutes.
Changing UEFI setting in the firmware is a big problem. We know that a) it can only be done by tweaking settings in the firmware interface which looks different on every machine, b) users find it very hard in general, and c) for blind users it's virtually impossible.
So even if a machine has UEFI, if it is currently in BIOS-compat mode, to some extent it's like if it didn't have UEFI.
Zbyszek
Once upon a time, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl said:
Changing UEFI setting in the firmware is a big problem. We know that a) it can only be done by tweaking settings in the firmware interface which looks different on every machine, b) users find it very hard in general, and c) for blind users it's virtually impossible.
Yeah, even as a highly-knowledgeable person, I've had to dig around to find it in some systems.
One thing I really like about Dell PowerEdge servers and OMSA is the ability to change firmware settings from within Linux with omconfig. I really wish UEFI would include a standard mechanism for that, with all the "normal" options standardized.
On Thu, Apr 7, 2022 at 11:09 AM Zbigniew Jędrzejewski-Szmek < zbyszek@in.waw.pl> wrote:
On Wed, Apr 06, 2022 at 10:47:30AM -0400, Robbie Harwood wrote:
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.
Based on a web query, it most likely has EFI support, but it also supports BIOS-compat (CSM?).
Easiest is probably to do:
ls /sys/firmware/efi
This tells you whether the machine booted using UEFI. anaconda will set up a UEFI-capable system if booted that way, unless partitioning is overridden to prevent that.
If it didn't boot using UEFI today, that doesn't mean it can't (you could check with a live image as well). UEFI tends to be enabled on machines made these days by default for Windows logo requirements, but this is firmware land, and there are no absolutes.
Changing UEFI setting in the firmware is a big problem. We know that a) it can only be done by tweaking settings in the firmware interface which looks different on every machine, b) users find it very hard in general, and c) for blind users it's virtually impossible.
So even if a machine has UEFI, if it is currently in BIOS-compat mode, to some extent it's like if it didn't have UEFI.
Microsoft has required since Windows 8 (released in 2012) that any systems that are certified with Windows must ship with UEFI by default, so in those cases, the user would have had to manually change BIOS settings in the first place. Alternatively, the person manually chose Windows 7 instead (while that was still an option), built a system out of parts that didn't get certified for Windows (rare), or found a small vendor to sell them hardware that's not Windows certified and/or came with Linux. Having been one of the folks who started Project Sputnik, I know that Dell, which was one of the few companies shipping Linux in 2012, very quickly switched to UEFI booting for Linux because of the advantages. So I would think that the number of cases where a user doesn't know how to change to UEFI booting are limited.
Zbyszek _______________________________________________ devel mailing list -- devel@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 Thu, Apr 7, 2022 at 10:04 AM Jared Dominguez jaredz@redhat.com wrote:
Microsoft has required since Windows 8 (released in 2012) that any systems that are certified with Windows must ship with UEFI by default
The Windows Hardware Certification Program is a marketing program. If you want to say things like "made for windows 8" in your product, you have to comply with their requirements. And the requirements differ by years for Windows and Windows Server. I don't know the breakdown but quite a lot of hardware products don't participate in this program, and thus aren't bound to it.
On Thu, Apr 7, 2022 at 2:36 PM Chris Murphy lists@colorremedies.com wrote:
The Windows Hardware Certification Program is a marketing program. If you want to say things like "made for windows 8" in your product, you have to comply with their requirements. And the requirements differ by years for Windows and Windows Server. I don't know the breakdown but quite a lot of hardware products don't participate in this program, and thus aren't bound to it.
https://docs.microsoft.com/en-us/windows-hardware/design/compatibility/whcp-... Windows Server 2019, version 1809 (release date 2018)
p88, System.Fundamentals.Firmware.UEFICompatibility - All systems, except servers, must be certified in UEFI mode without activating CSM. - For server, certification in UEFI mode is only required if UEFI is implemented. - OEMs may ship with CSM mode activated and the enterprise or government customer's licensed OS selection when requested.
System.Fundamentals.Firmware.UEFIDefaultBoot ... This requirement is "If Implemented" for Server systems.
Starting with version 2004 (still Windows 10 / Windows Server 2019), released in 2020 the server exception for requiring UEFI is removed, but it's still not required to be enabled by default. I would not be surprised if certified server hardware were shipping in 2020 without UEFI.
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...
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 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.
On 4/6/22 16:17, Neal Gompa wrote:
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.
Are they different *per-user*, or only *per-kernel-version*?
If the latter, one could create signatures for every (driver version, kernel version) combo.
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 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 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 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 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
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 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.
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: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 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 Wed, Apr 6, 2022 at 8:04 PM Justin Forbes jmforbes@linuxtx.org wrote:
We have not set up an infrastructure for it, but in all honesty, there is no technical reason that any 3rd party repository building and packaging the driver could not have done such a thing a couple of years ago. The mechanism has been there, pesign can sign modules. Now, asking Fedora to trust that key is a different issue, but users have to reboot after installing the nvidia drivers anyway, so clicking to accept the key isn't too much of a hurdle to jump through at that point.
Create key, enroll key, confirm enrollment, sign the binary with on-going signing requirement, lose signing key, make new signing key, no room in NVRAM for additional signing key, remove key, enroll key, confirm key.... it's shit. Not complete shit, but almost complete shit. And that's excluding running into bugs (pretty common to find myriad UEFI implementation bugs).
Ironically, only computers certified by Microsoft as part of their marketing program are also required to have a minimum user interface. There's a large pile of non-Microsoft certified hardware out there and they don't have to follow those requirements and often don't. Remarkably, right now you have to disable Secure Boot on Apple hardware because they don't even offer a way to enroll keys. They only include the key used for running Windows, not the key used for signing Fedora's shim bootloader.
As much of a Secure Boot fanboy I've been, I'm rapidly approaching the "fuck it" stage, because the burden is too high. I don't do anywhere near as much kernel regression testing because (a) I don't want to disable Secure Boot and (b) I'm unwilling to go through the hurdles to sign the kernel with my own key.
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).
On Di, 05.04.22 17:38, Chris Murphy (lists@colorremedies.com) wrote:
When users have a suboptimal experience by default, it makes Fedora look bad. We can't have security concerns overriding all other concerns. But it's really pernicious to simultaneously say security is important, but we're also not going to sign proprietary drivers. This highly incentivizes the user to disable Secure Boot because that's so much easier than users signing kernel modules and enrolling keys with the firmware, and therefore makes the user *less safe*.
Let me stress one thing though: Fedora *has* *no* working SecureBoot implementation. The initrd is not authenticated. It has no signatures, nothing.
By disabling SecureBoot you effectively lose exactly nothing in terms of security right now.
What good is a trusted boot loader or kernel if it then goes on loading an initrd that is not authenticated, super easy to modify (I mean, seriously, any idiot script kiddie can unpack a cpio, add some shell script and pack it up again, replacing the original one) – and it's the component that actually reads your FDE LUKS password.
I mean, let's not pretend unsigned drivers were a big issue for security right now. They are now, we have much much much wider gaping holes in our stack.
Lennart
-- Lennart Poettering, Berlin
On 4/7/22 10:28 AM, Lennart Poettering wrote:
On Di, 05.04.22 17:38, Chris Murphy (lists@colorremedies.com) wrote:
When users have a suboptimal experience by default, it makes Fedora look bad. We can't have security concerns overriding all other concerns. But it's really pernicious to simultaneously say security is important, but we're also not going to sign proprietary drivers. This highly incentivizes the user to disable Secure Boot because that's so much easier than users signing kernel modules and enrolling keys with the firmware, and therefore makes the user *less safe*.
Let me stress one thing though: Fedora *has* *no* working SecureBoot implementation. The initrd is not authenticated. It has no signatures, nothing.
Couldn't the other Fedora change about adding file signatures to the RPM installed files be used to close this hole?. Enabling some policy at boot that disallows execution on code not signed that is inside the initrd. I think all code copied to the initrd must come from Fedora packages, maybe the only exception are third party kernel modules.
Note: It appears cpio doesn't support extended attributes [1]
[1] https://bugzilla.redhat.com/show_bug.cgi?id=771926
By disabling SecureBoot you effectively lose exactly nothing in terms of security right now.
What good is a trusted boot loader or kernel if it then goes on loading an initrd that is not authenticated, super easy to modify (I mean, seriously, any idiot script kiddie can unpack a cpio, add some shell script and pack it up again, replacing the original one) – and it's the component that actually reads your FDE LUKS password.
I mean, let's not pretend unsigned drivers were a big issue for security right now. They are now, we have much much much wider gaping holes in our stack.
Lennart
-- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@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 Do, 07.04.22 10:53, Fedora Development ML (devel@lists.fedoraproject.org) wrote:
On 4/7/22 10:28 AM, Lennart Poettering wrote:
On Di, 05.04.22 17:38, Chris Murphy (lists@colorremedies.com) wrote:
When users have a suboptimal experience by default, it makes Fedora look bad. We can't have security concerns overriding all other concerns. But it's really pernicious to simultaneously say security is important, but we're also not going to sign proprietary drivers. This highly incentivizes the user to disable Secure Boot because that's so much easier than users signing kernel modules and enrolling keys with the firmware, and therefore makes the user *less safe*.
Let me stress one thing though: Fedora *has* *no* working SecureBoot implementation. The initrd is not authenticated. It has no signatures, nothing.
Couldn't the other Fedora change about adding file signatures to the RPM installed files be used to close this hole?. Enabling some policy at boot that disallows execution on code not signed that is inside the initrd. I think all code copied to the initrd must come from Fedora packages, maybe the only exception are third party kernel modules.
You need to sign the whole thing, and figure out what to do about configuration so that you can still configure the thing but also authenticate it so that you know it is in order.
Lennart
-- Lennart Poettering, Berlin
On Thu, Apr 7, 2022 at 8:28 AM Lennart Poettering mzerqung@0pointer.de wrote:
On Di, 05.04.22 17:38, Chris Murphy (lists@colorremedies.com) wrote:
When users have a suboptimal experience by default, it makes Fedora look bad. We can't have security concerns overriding all other concerns. But it's really pernicious to simultaneously say security is important, but we're also not going to sign proprietary drivers. This highly incentivizes the user to disable Secure Boot because that's so much easier than users signing kernel modules and enrolling keys with the firmware, and therefore makes the user *less safe*.
Let me stress one thing though: Fedora *has* *no* working SecureBoot implementation. The initrd is not authenticated. It has no signatures, nothing.
By disabling SecureBoot you effectively lose exactly nothing in terms of security right now.
What good is a trusted boot loader or kernel if it then goes on loading an initrd that is not authenticated, super easy to modify (I mean, seriously, any idiot script kiddie can unpack a cpio, add some shell script and pack it up again, replacing the original one) – and it's the component that actually reads your FDE LUKS password.
I mean, let's not pretend unsigned drivers were a big issue for security right now. They are now, we have much much much wider gaping holes in our stack.
I agree that the lack of a signed initrd is a big gaping hole. I don't agree it's pointless to ensure the bootloader, kernel and kernel modules are authentic. It's bad to have malware running in user space. It's extra bad if it's running in kernel space. There are examples of such malware, including lie in wait, that can embed maleware into SPI flash once Secure Boot is disabled. Even if you were to discover this (difficult considering most vendors aren't publishing hashes of their firmware) you'd basically be screwed, not even replacing the boot drive would get rid of it.
On Di, 05.04.22 17:38, Chris Murphy (lists(a)colorremedies.com) wrote:
Let me stress one thing though: Fedora *has* *no* working SecureBoot implementation. The initrd is not authenticated. It has no signatures, nothing.
By disabling SecureBoot you effectively lose exactly nothing in terms of security right now.
What good is a trusted boot loader or kernel if it then goes on loading an initrd that is not authenticated, super easy to modify (I mean, seriously, any idiot script kiddie can unpack a cpio, add some shell script and pack it up again, replacing the original one) – and it's the component that actually reads your FDE LUKS password.
I mean, let's not pretend unsigned drivers were a big issue for security right now. They are now, we have much much much wider gaping holes in our stack.
Lennart
-- Lennart Poettering, Berlin
To achieve such feature(SecureBoot signer Unified Images) I've had to make some hack'ish scripts to run dracut a second time glueing all together and signing it, after generating the initrd inside /boot:
- https://nwildner.com/posts/2021-04-10-secureboot-fedora/
Not proud of it, but it works(and I have cmdline + initrd + kernel + modules all signed as a bundle).
This could be the spark of a package idea for Unified images
nwildner
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 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 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.
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
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 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.
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.
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
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).
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
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
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!
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 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?
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 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 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 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....
Michael Catanzaro mcatanzaro@gnome.org writes:
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....
I have appended added my analysis of this to the Feedback section. For clarity, it's copied here:
During mailing list discussion of this change, concern was expressed that some of the smaller hosting providers who do not provision with UEFI today and do not also support Windows would drop Fedora rather than enabling UEFI. Given that the major virtualization solutions (vsphere, kvm, xen, bhve, virtualbox, ...) all support UEFI today, this would likely be exposing an existing capability rather than making a sweeping change. That said, it is always possible that providers may elect to drop Fedora rather than adjust their setups - be it for this change or any other change Fedora makes.
Be well, --Robbie
On Thursday, 07 April 2022 at 18:42, Robbie Harwood wrote:
Michael Catanzaro mcatanzaro@gnome.org writes:
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....
I have appended added my analysis of this to the Feedback section. For clarity, it's copied here:
During mailing list discussion of this change, concern was expressed that some of the smaller hosting providers who do not provision with UEFI today and do not also support Windows would drop Fedora rather than enabling UEFI. Given that the major virtualization solutions (vsphere, kvm, xen, bhve, virtualbox, ...) all support UEFI today,
...latest versions of... And the provider in question might not be running the latest version.
this would likely be exposing an existing capability rather than making a sweeping change.
It's equally likely that they'd have to upgrade their virtualization platform to the latest version first and then update their internal UI/tooling to expose UEFI. I'd call that a sweeping change while you're downplaying the scope of it.
That said, it is always possible that providers may elect to drop Fedora rather than adjust their setups - be it for this change or any other change Fedora makes.
That's completely unnecessary. It adds nothing but attempt to dilute the impact of this change.
Regards, Dominik
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 Thu, Apr 7, 2022 at 4:51 AM Dominik 'Rathann' Mierzejewski < dominik@greysector.net> wrote:
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.
Looks like they are using vSphere, which supports UEFI VMs. The same is true for KVM, Xen and bhyve, so it's more about what feature set cloud providers using these hypervisors are choosing to turn on.
[...]
I suppose we should consider that all or most of these platforms are likely to drop Fedora as a supported option if we proceed with this change proposal.
Why? VMware vSphere dropped legacy x86 boot support recently too. We already know that Windows 11 requires UEFI. We (Red Hat) are actively working with several cloud providers on UEFI-related features, some of which are not possible with legacy x86 boot. I find it much more likely that smaller cloud providers will update their software to support UEFI rather than drop OS's that require it, at least if they want to remain competitive.
Fedora doesn't have the market share to be able to compel such action. I'm convinced the smaller providers will rather drop Fedora than increase their maintenance burden of supporting both BIOS and UEFI. After all, most Linux users use Ubuntu, which, to my knowledge, is not removing or even deprecating BIOS support.
Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan _______________________________________________ devel mailing list -- devel@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
Once upon a time, Jared Dominguez jaredz@redhat.com said:
Looks like they are using vSphere, which supports UEFI VMs. The same is true for KVM, Xen and bhyve, so it's more about what feature set cloud providers using these hypervisors are choosing to turn on.
In a way, this is similar to "your router supports IPv6, why don't you just turn it on?":
- version considerations: when did $HYPERVISOR start supporting UEFI? what versions may still be running in some parts of infrastructure?
- "support" vs. "really support": just because something says it "supports UEFI" doesn't mean it works right; large-scale hosters need to do lots of testing of all their supported systems and setups to see how they actually react
- internal tooling: just because a hoster is using KVM for example doesn't mean they just install the vendor software and go; they have their own internal management systems built on top, calling vendor APIs to do things
- presentation: adding user-facing options should always be carefully considered, especially when they are "change this option and your VM possibly won't boot" type (so more support tickets)
That all combines to lots of effort to support UEFI booting. When there's little demand, and little obvious gain up front, low-overhead providers aren't going to put that high on the priority list.
Chris Adams linux@cmadams.net writes:
Once upon a time, Jared Dominguez jaredz@redhat.com said:
Looks like they are using vSphere, which supports UEFI VMs. The same is true for KVM, Xen and bhyve, so it's more about what feature set cloud providers using these hypervisors are choosing to turn on.
In a way, this is similar to "your router supports IPv6, why don't you just turn it on?":
version considerations: when did $HYPERVISOR start supporting UEFI? what versions may still be running in some parts of infrastructure?
"support" vs. "really support": just because something says it "supports UEFI" doesn't mean it works right; large-scale hosters need to do lots of testing of all their supported systems and setups to see how they actually react
internal tooling: just because a hoster is using KVM for example doesn't mean they just install the vendor software and go; they have their own internal management systems built on top, calling vendor APIs to do things
presentation: adding user-facing options should always be carefully considered, especially when they are "change this option and your VM possibly won't boot" type (so more support tickets)
Support tickets don't worry me as much as making breaking changes for customers that possibly result in outages for them do.
For example, I don't think it'd ever be possible to flip the default for existing EC2 instance types. Maybe the default for a new major OS version, but there's likely going to be an amount of time before all EC2 instance types support UEFI, and then there'll be customers with a multitude of custom things enabled that don't (at least yet) work with UEFI and will take the easy option of going back to legacy-bios, probably for years.
On Thu, Apr 7, 2022 at 10:03 AM Jared Dominguez jaredz@redhat.com wrote:
On Thu, Apr 7, 2022 at 4:51 AM Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
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.
Looks like they are using vSphere, which supports UEFI VMs. The same is true for KVM, Xen and bhyve, so it's more about what feature set cloud providers using these hypervisors are choosing to turn on.
OVHcloud is OpenStack based: https://www.theregister.com/2019/04/29/ovh_adds_bare_metal_fighters_to_its_r...
However, OpenStack's UEFI support is seemingly broken. For example, the OpenStack deployment I use at work fail to boot UEFI VMs when I set the appropriate flags, which have existed since OpenStack Mitaka (we're testing on Ussuri right now). According to internal research, it *may* be fixed in an upcoming OpenStack release, but no one is sure...
-- 真実はいつも一つ！/ Always, there's only one truth!
On Thu, Apr 7, 2022 at 10:36 AM Neal Gompa ngompa13@gmail.com wrote:
On Thu, Apr 7, 2022 at 10:03 AM Jared Dominguez jaredz@redhat.com wrote:
On Thu, Apr 7, 2022 at 4:51 AM Dominik 'Rathann' Mierzejewski <
dominik@greysector.net> wrote:
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.
Looks like they are using vSphere, which supports UEFI VMs. The same is
true for KVM, Xen and bhyve, so it's more about what feature set cloud providers using these hypervisors are choosing to turn on.
OVHcloud is OpenStack based:
https://www.theregister.com/2019/04/29/ovh_adds_bare_metal_fighters_to_its_r...
However, OpenStack's UEFI support is seemingly broken. For example, the OpenStack deployment I use at work fail to boot UEFI VMs when I set the appropriate flags, which have existed since OpenStack Mitaka (we're testing on Ussuri right now). According to internal research, it *may* be fixed in an upcoming OpenStack release, but no one is sure...
From what I've found, it looks like they use both. Anyway, Red Hat has customers using UEFI with OpenStack, which I'm aware of from seeing bug reports which we fix. Have you reported the bugs that you've seen?
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@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
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 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
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 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
David Duncan davdunc@gmail.com writes:
it also appears that issues have prevented direct contribution based on some sort of misconfiguration in the repository, though it sounds like this is fixed as of this discussion. It still speaks to more than a year of complication in contribution. Is Neal really the only one who was impacted by the inability to submit a PR?
So far, that's the only case we're aware of, and we only learned yesterday that they considered using it during that interval. Anyway, it has been fixed for a while - for instance, Zbignew has been waiting on me to merge a pending PR to drop our use of "which" :)
(Javier (co-maintainer) has a post I believe touching on this as well, but it's stuck in the moderation queue right now.)
I want to emphasize again that PRs are not the only venue of communication with maintainers, nor are they the only way to send us code (attachments on bugzilla, patches upstream, patches to source-git-likes, ...), nor is sending code the only way to contribute (investigating issues, translations, ...).
I think that creating choice is the right response
I don't agree that choice is inherently superior, especially when it creates more work to support. For a more eloquent explanation of this, I refer you to ajax's post: https://listman.redhat.com/archives/fedora-devel-list/2008-January/msg00861....
Be well, --Robbie
On Thu, Apr 7, 2022 at 12: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?
Anaconda is used for this purpose to make dual firmware supporting VM images. Cloud edition does it, and it's also done within RHEL and CentOS.
I would sooner expect optical boot support to go away before BIOS boot. But I only have anecdotes to go on.
The installed systems will look pretty much the same (gpt with both bios-boot and efi-esp partition) no matter how they where installed, and it'll be trivial to switch from BIOS to UEFI without reinstalling the system.
We can fade out some stuff already (mbr support), and painless switching to UEFI for systems which where installed in BIOS mode for whatever reason should also help UEFI adaption.
There have been two prior attempts to move to GPT by default (i.e. drop MBR by default when legacy BIOS is detected), and due to firmware bugs, it never progressed to any Fedora release. I can't guess what percent of hardware in the Fedora community is BIOS vs UEFI, and it's even harder to estimate what percent of BIOS hardware are affected by the GPT bug.
But I suppose that can being kicked down the road has also lead to the pressure resulting in this change proposal. Hindsight being 20/20, maybe moving to GPT by default would have been OK after all, because those users could just boot the installer with inst.mbr. I'm not sure whether it makes sense to deprecate this now though.
On 4/7/22 15:30, Chris Murphy wrote:
On Thu, Apr 7, 2022 at 12: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?
Anaconda is used for this purpose to make dual firmware supporting VM images. Cloud edition does it, and it's also done within RHEL and CentOS.
I would sooner expect optical boot support to go away before BIOS boot. But I only have anecdotes to go on.
The installed systems will look pretty much the same (gpt with both bios-boot and efi-esp partition) no matter how they where installed, and it'll be trivial to switch from BIOS to UEFI without reinstalling the system.
We can fade out some stuff already (mbr support), and painless switching to UEFI for systems which where installed in BIOS mode for whatever reason should also help UEFI adaption.
There have been two prior attempts to move to GPT by default (i.e. drop MBR by default when legacy BIOS is detected), and due to firmware bugs, it never progressed to any Fedora release. I can't guess what percent of hardware in the Fedora community is BIOS vs UEFI, and it's even harder to estimate what percent of BIOS hardware are affected by the GPT bug.
Can the disk be partitioned so that it is valid for *both* MBR and GPT?
On Thu, Apr 7, 2022 at 7:10 PM Demi Marie Obenour demiobenour@gmail.com wrote:
On 4/7/22 15:30, Chris Murphy wrote:
On Thu, Apr 7, 2022 at 12: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?
Anaconda is used for this purpose to make dual firmware supporting VM images. Cloud edition does it, and it's also done within RHEL and CentOS.
I would sooner expect optical boot support to go away before BIOS boot. But I only have anecdotes to go on.
The installed systems will look pretty much the same (gpt with both bios-boot and efi-esp partition) no matter how they where installed, and it'll be trivial to switch from BIOS to UEFI without reinstalling the system.
We can fade out some stuff already (mbr support), and painless switching to UEFI for systems which where installed in BIOS mode for whatever reason should also help UEFI adaption.
There have been two prior attempts to move to GPT by default (i.e. drop MBR by default when legacy BIOS is detected), and due to firmware bugs, it never progressed to any Fedora release. I can't guess what percent of hardware in the Fedora community is BIOS vs UEFI, and it's even harder to estimate what percent of BIOS hardware are affected by the GPT bug.
Can the disk be partitioned so that it is valid for *both* MBR and GPT?
There are two options here: protective MBR and hybrid MBR.
Protective MBRs are well-supported and I believe created by default when you create a GPT partitioning scheme for BIOS systems already with Anaconda. I think it's done with UEFI as well, but if not, we can certainly force it.
The second option is known as hybrid MBR. The gdisk utility can create them: https://www.rodsbooks.com/gdisk/hybrid.html
Needless to say, it's... interesting... I'm not sure if more tools support hybrid MBRs since this was last refreshed in 2019.
It's also kinda scary and not really necessary unless you need to interoperate with OSes that expect MBR in a mixed BIOS+UEFI boot setup.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Thu, Apr 7, 2022 at 5:21 PM Neal Gompa ngompa13@gmail.com wrote:
On Thu, Apr 7, 2022 at 7:10 PM Demi Marie Obenour demiobenour@gmail.com wrote:
Can the disk be partitioned so that it is valid for *both* MBR and GPT?
There are two options here: protective MBR and hybrid MBR.
Protective MBRs are well-supported and I believe created by default when you create a GPT partitioning scheme for BIOS systems already with Anaconda. I think it's done with UEFI as well, but if not, we can certainly force it.
The second option is known as hybrid MBR. The gdisk utility can create them: https://www.rodsbooks.com/gdisk/hybrid.html
Needless to say, it's... interesting... I'm not sure if more tools support hybrid MBRs since this was last refreshed in 2019.
It's also kinda scary and not really necessary unless you need to interoperate with OSes that expect MBR in a mixed BIOS+UEFI boot setup.
Strictly speaking per the UEFI spec, hybrid MBR's don't exist. Creating such a thing means it's really MBR and the GPT is invalid, and it requires all software to treat it as such. The only valid MBR with a valid GPT, is a protective MBR (PMBR) which is defined as having one partition the size of the device or the maximum size supported by MBR if the device is bigger.
On Wed, Apr 6, 2022 at 6:01 PM 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.
They may only support Linux users today, but if they want to grow (and while it is possible to survive as a niche service, many see growth as the way to increased revenue/profits (go big or go home)), they are going to get pushed (perhaps kicking and screaming) to support UEFI as at least an alternative moving forward as some of their customers are going to prefer using a single provider, and Windows 11 requires UEFI(*)(**), and it would be a shame if only the big players were eligible for hosting such services(***).
Many of these comments seem to be about the date, not the end state (UEFI)(****), just like 32-bit x86 and armv7. No one wants their personal ox gored, but there will come a time when it will be time to let old systems go.
"We" (and when I say "we", I understand that is mostly not me), are going to have to continue to document (and fix, where "we" have the knowledge) the areas that need improvement for UEFI booting and runtime.
Gary
(*) Technically it is possible to jump through enough hoops to get Windows 11 to run on BIOS only systems, but it is not supported, and may break at any time. Most people prefer something that the vendor supports.
(**) Yes, some may prefer living in a Windows-less world, but the reality is that (especially at business scale) there are services and applications that require Windows today, and will likely require Windows for a number of tomorrows.
(***) Yes, using multiple cloud providers is often advantageous to avoid vendor lock-in and provider failures, but scale (at one provider) can result in savings (both expense, and duplication of work supporting the different providers' services). There is statement by a VC regarding startups which is (essentially) everyone should start by using AWS, and then have a plan to move off when their scale is sufficient (of course, many startups never survive sufficiently long to move off, and others simply prefer to spend their (precious) engineering resources in other ways).
(****) Yes, some hope coreboot/linuxboot can replace UEFI (and it can in some use cases). But unless/until MS embraces it, UEFI is the answer (even if one is still discussing the question that was asked).
On 4/10/22 05:50, Gary Buhrmaster wrote:
On Wed, Apr 6, 2022 at 6:01 PM 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.
They may only support Linux users today, but if they want to grow (and while it is possible to survive as a niche service, many see growth as the way to increased revenue/profits (go big or go home)), they are going to get pushed (perhaps kicking and screaming) to support UEFI as at least an alternative moving forward as some of their customers are going to prefer using a single provider, and Windows 11 requires UEFI(*)(**), and it would be a shame if only the big players were eligible for hosting such services(***).
Many of these comments seem to be about the date, not the end state (UEFI)(****), just like 32-bit x86 and armv7. No one wants their personal ox gored, but there will come a time when it will be time to let old systems go.
Yes, but the whole point is that it's way too early. Windows 10 still supports not only legacy BIOS, but also i686 (which Fedora has dropped support for in Fedora 31; Fedora 30 was EOL'd in May 2020) and Windows 10 will be supported until at least October 14, 2025. For comparison, Fedora 36 will be EOL'd in May 2023.
"We" (and when I say "we", I understand that is mostly not me), are going to have to continue to document (and fix, where "we" have the knowledge) the areas that need improvement for UEFI booting and runtime.
Gary
(*) Technically it is possible to jump through enough hoops to get Windows 11 to run on BIOS only systems, but it is not supported, and may break at any time. Most people prefer something that the vendor supports.
BIOS-only users can stay on Windows 10. They have very little reason to upgrade to Windows 11. It's mostly cosmetic changes to the UI and there's no major software product that requires Windows 11, but doesn't run on Windows 10. Adoption of new Windows versions has always been painstakingly slow, even after the old version is EOL'd, people continue to use it (I know it's a bad idea, but people do it anyway - look at how much time it took for people to upgrade from Windows XP, after it was EOL'd). But Windows 10 is still supported, so it can be used, it's not more dangerous than Windows 11.
So the question is, why should cloud providers care about Windows 11? Long term, yes, they do care, but none of their Windows users are in a hurry to upgrade, they are fine staying on Windows 10 until 2025, there's nothing in Windows 11 that makes it worth upgrading (in my personal opinion), especially not for server/cloud use. I must check this (please correct me if I'm wrong), but I think Windows Server 2019 still supports legacy BIOS and has extended support until January 2029.
(**) Yes, some may prefer living in a Windows-less world, but the reality is that (especially at business scale) there are services and applications that require Windows today, and will likely require Windows for a number of tomorrows.
Like I said, Windows 10 supports i686 + Legacy BIOS, as well as x86_64 + Legacy BIOS until at least October 14, 2025.
(***) Yes, using multiple cloud providers is often advantageous to avoid vendor lock-in and provider failures, but scale (at one provider) can result in savings (both expense, and duplication of work supporting the different providers' services). There is statement by a VC regarding startups which is (essentially) everyone should start by using AWS, and then have a plan to move off when their scale is sufficient (of course, many startups never survive sufficiently long to move off, and others simply prefer to spend their (precious) engineering resources in other ways).
(****) Yes, some hope coreboot/linuxboot can replace UEFI (and it can in some use cases). But unless/until MS embraces it, UEFI is the answer (even if one is still discussing the question that was asked).
I believe the PC-compatible coreboot payloads are the way to go - either coreboot+SeaBIOS or coreboot+TianoCore. I don't know what's the state of TianoCore and whether it works on real hardware. I have one working system with coreboot+SeaBIOS (it's a Chromebook) and I'd like to be able to use it.
devel mailing list -- devel@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 Sat, Apr 9, 2022 at 10:51 PM Gary Buhrmaster gary.buhrmaster@gmail.com wrote:
On Wed, Apr 6, 2022 at 6:01 PM 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.
They may only support Linux users today, but if they want to grow (and while it is possible to survive as a niche service, many see growth as the way to increased revenue/profits (go big or go home)), they are going to get pushed (perhaps kicking and screaming) to support UEFI as at least an alternative moving forward as some of their customers are going to prefer using a single provider, and Windows 11 requires UEFI(*)(**), and it would be a shame if only the big players were eligible for hosting such services(***).
Many of these comments seem to be about the date, not the end state (UEFI)(****), just like 32-bit x86 and armv7. No one wants their personal ox gored, but there will come a time when it will be time to let old systems go.
"We" (and when I say "we", I understand that is mostly not me), are going to have to continue to document (and fix, where "we" have the knowledge) the areas that need improvement for UEFI booting and runtime.
Windows is a niche in the server space, rather than the default. And Microsoft didn't even remove the server exception to continue using BIOS until last year from the Windows platform qualification documentation. It's *definitely* going to be a while, especially with Windows Server 2019 being supported until the end of the decade.
Windows 11 *does not matter* here. Windows Server is what matters here, and there are no announced Windows Server versions following the Windows 11 platform requirements.
-- 真実はいつも一つ！/ Always, there's only one truth!
On 4/10/22 16:27, Neal Gompa wrote:
On Sat, Apr 9, 2022 at 10:51 PM Gary Buhrmaster gary.buhrmaster@gmail.com wrote:
On Wed, Apr 6, 2022 at 6:01 PM 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.
They may only support Linux users today, but if they want to grow (and while it is possible to survive as a niche service, many see growth as the way to increased revenue/profits (go big or go home)), they are going to get pushed (perhaps kicking and screaming) to support UEFI as at least an alternative moving forward as some of their customers are going to prefer using a single provider, and Windows 11 requires UEFI(*)(**), and it would be a shame if only the big players were eligible for hosting such services(***).
Many of these comments seem to be about the date, not the end state (UEFI)(****), just like 32-bit x86 and armv7. No one wants their personal ox gored, but there will come a time when it will be time to let old systems go.
"We" (and when I say "we", I understand that is mostly not me), are going to have to continue to document (and fix, where "we" have the knowledge) the areas that need improvement for UEFI booting and runtime.
Windows is a niche in the server space, rather than the default. And Microsoft didn't even remove the server exception to continue using BIOS until last year from the Windows platform qualification documentation. It's *definitely* going to be a while, especially with Windows Server 2019 being supported until the end of the decade.
Just tested installing Windows Server 2019 in a QEMU virtual machine on a 40 GB virtual hard disk and 2 GB RAM. It formatted the disk as MBR and installed just fine, no warnings, no deprecations, no nothing. Mainstream support for Windows Server 2019 ends in January 9, 2024, extended support lasts until January 9, 2029.
Windows 11 *does not matter* here. Windows Server is what matters here, and there are no announced Windows Server versions following the Windows 11 platform requirements.
I agree. IMO, Windows 11 is only good for home desktop use (and for that purpose, Windows 10 is just as good, there are only cosmetic differences in the UI), it is irrelevant for servers, because of the artificial restrictions that Microsoft puts on their desktop operating systems (limited number of connections, limited number of websites you can host in IIS, etc.) in order to boost their Windows Server sales. Ironically, due to this fact, Windows Server works better as a desktop, than Windows 10 or 11 as a server. At work we use Windows Server for web development in Visual Studio, because it just works better, e.g. you can deploy multiple web sites on your machine, etc. :)
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@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 Sun, Apr 10, 2022 at 1:27 PM Neal Gompa ngompa13@gmail.com wrote:
Windows 11 *does not matter* here.
(Windows) Desktop as a Service (DaaS)[0] may change that faster than some expect (or faster than some hope). There is a large push by some orgs to move services off premise into the cloud (for a number of stated reasons including zero trust and WfH scenarios).
And while I have zero plans to give up my linux systems in favor of cloud desktops, and some of the push for DaaS may be more hype than real, I do agree that there are valid use cases, and that is going to push some to support UEFI in the future.
Gary
[0] And certain SaaS application solutions.
On Sun, Apr 10, 2022 at 11:06 PM Gary Buhrmaster gary.buhrmaster@gmail.com wrote:
On Sun, Apr 10, 2022 at 1:27 PM Neal Gompa ngompa13@gmail.com wrote:
Windows 11 *does not matter* here.
(Windows) Desktop as a Service (DaaS)[0] may change that faster than some expect (or faster than some hope). There is a large push by some orgs to move services off premise into the cloud (for a number of stated reasons including zero trust and WfH scenarios).
And while I have zero plans to give up my linux systems in favor of cloud desktops, and some of the push for DaaS may be more hype than real, I do agree that there are valid use cases, and that is going to push some to support UEFI in the future.
The economics of Windows in the cloud is not great unless you're on Azure, where Microsoft can give itself preferential pricing. And most people that use Fedora in the Cloud aren't using Azure (or AWS or GCP for that matter).
Neal Gompa ngompa13@gmail.com writes:
Windows is a niche in the server space, rather than the default
That may be true for many workloads, but I doubt it's true in all cases - Active Directory has a huge footprint, for instance, and Linux is not "the default" for identity services.
Be well, --Robbie
Am 10.04.2022 um 04:50 schrieb Gary Buhrmaster gary.buhrmaster@gmail.com:
On Wed, Apr 6, 2022 at 6:01 PM 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.
I want to reiterate, it's not just about cloud platforms! if we remove BIOS boot (too early), we also kick Fedora servers, installed on hardware, out of these data centers. And the reason is not that this server hardware does not support UEFI, but the management infrastructure of the data centers.
And kicking ourselves out, really doesn't strike me as a brilliant idea.
They may only support Linux users today, but if they want to grow (and while it is possible to survive as a niche service, many see growth as the way to increased revenue/profits (go big or go home)), they are going to get pushed (perhaps kicking and screaming) to support UEFI as at least an alternative …
It’s not so much about kicking and streaming, but about time, man power and financial resources.
Many of these comments seem to be about the date, not the end state (UEFI)(****), just like 32-bit x86 and armv7. No one wants their personal ox gored, but there will come a time when it will be time to let old systems go.
Yes indeed. It’s about time.
And we need a solution we can keep operable longer than 3 years. It's more of a 10-year thing.
Once upon a time, Peter Boy pboy@uni-bremen.de said:
I want to reiterate, it's not just about cloud platforms! if we remove BIOS boot (too early), we also kick Fedora servers, installed on hardware, out of these data centers. And the reason is not that this server hardware does not support UEFI, but the management infrastructure of the data centers.
Speaking of servers... one thing I noticed is that a pure-Fedora system only uses about 8M of /boot/efi. Even my dual-boot laptop with Win10 is only using 35M. Is there a reason 256M was chosen for the default UEFI system partition size (from the standard somewhere)? I guess that's what Windows does too (since Win10 was on this laptop first).
I did notice that anaconda forces it to be at least 50M - again, is there a reason?
On Mon, Apr 11, 2022 at 02:21:04PM -0500, Chris Adams wrote:
Once upon a time, Peter Boy pboy@uni-bremen.de said:
I want to reiterate, it's not just about cloud platforms! if we remove BIOS boot (too early), we also kick Fedora servers, installed on hardware, out of these data centers. And the reason is not that this server hardware does not support UEFI, but the management infrastructure of the data centers.
Speaking of servers... one thing I noticed is that a pure-Fedora system only uses about 8M of /boot/efi. Even my dual-boot laptop with Win10 is only using 35M. Is there a reason 256M was chosen for the default UEFI system partition size (from the standard somewhere)? I guess that's what Windows does too (since Win10 was on this laptop first).
Windows wants >= 100 MB, or >= 256 MB on 4k-sector drives. (https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/config...) Whoever creates the partition should make it "large enough", i.e. it's reasonable to make it large enough to satisfy also windows, even if we only use a few MBs.
Zbyszek
Am 11.04.2022 um 21:21 schrieb Chris Adams linux@cmadams.net:
Once upon a time, Peter Boy pboy@uni-bremen.de said:
I want to reiterate, it's not just about cloud platforms! if we remove BIOS boot (too early), we also kick Fedora servers, installed on hardware, out of these data centers. And the reason is not that this server hardware does not support UEFI, but the management infrastructure of the data centers.
Speaking of servers... one thing I noticed is that a pure-Fedora system only uses about 8M of /boot/efi. Even my dual-boot laptop with Win10 is only using 35M. Is there a reason 256M was chosen for the default UEFI system partition size (from the standard somewhere)? I guess that's what Windows does too (since Win10 was on this laptop first).
I did notice that anaconda forces it to be at least 50M - again, is there a reason?
I really don’t know. Never thought about it before, and it hasn't even occurred to me, unfortunately. Knowing our group members, it's kind of a general best practice, and the idea of not making it too small in any way.
On Mon, Apr 11, 2022 at 1:21 PM Chris Adams linux@cmadams.net wrote:
Once upon a time, Peter Boy pboy@uni-bremen.de said:
I want to reiterate, it's not just about cloud platforms! if we remove BIOS boot (too early), we also kick Fedora servers, installed on hardware, out of these data centers. And the reason is not that this server hardware does not support UEFI, but the management infrastructure of the data centers.
Speaking of servers... one thing I noticed is that a pure-Fedora system only uses about 8M of /boot/efi. Even my dual-boot laptop with Win10 is only using 35M. Is there a reason 256M was chosen for the default UEFI system partition size (from the standard somewhere)? I guess that's what Windows does too (since Win10 was on this laptop first).
Any Microsoft produced ISO image (downloadable from microsoft.com, versus an OEM created image) creates 100 MiB EFI system partitions. OEM's are kinda all over the map.
Fedora makes them 600 MiB these days.
UEFI Spec 2.8, 13.3.1.1 says "The EFI firmware must support the FAT32, FAT16, and FAT12 variants of the EFI file system. What variant of EFI FAT to use is defined by the size of the media. The rules defining the relationship between media size and FAT variants is defined in the specification for the EFI file system."
I've never been able to find a separate spec though.
The UEFI spec itself defines the EFI file system earlier in this 13.3 section as "The file system supported by the Extensible Firmware Interface is based on the FAT file system." i.e. it is intended to be based on a frozen in time version of FAT. Further, "EFI encompasses the use of FAT32 for a system partition, and FAT12 or FAT16 for removable media."
I did notice that anaconda forces it to be at least 50M - again, is there a reason?
Anaconda folks prefer to use mkfs defaults. And dosfstools doesn't have an "EFI file system" specific flag to follow the UEFI rules, including feature freezing it in time. It just so happens FAT isn't changing much or at least not in a way that makes EFI firmware confused. But one day we might need an actual mkfs.efi utility to correctly make them.
Per the spec the internal drive should be a FAT 32 file system, and either FAT 12 or 32 file system for removable drives. In practice, mkdosfs's size based logic won't make a FAT 32 volume unless the partition size is ~550 MiB (I'm not certain of the cutoff). When Anaconda was making ~250 MiB EFI system partitions, they were FAT 16. Now they are FAT 32 because the partition size is above mkdosfs's cutoff for FAT 16. I don't know if anyone ever ran into weird bugs related to the file system being 16-bit based, rather than 32-bit, but it would be hard to find out because - why would you even think to try a different FAT variant and see if what you think might be a bug still reproduces?
I tried formatting a 2011 Apple Macbook as FAT 16 and FAT 12. FAT 16 was OK (although I didn't do any firmware updates which is the only reason the EFI system partition is used on Macs of this era). But FAT 12 was a bad experience - my vague recollection is I had to remove the drive from the laptop and reformat it FAT 32 because I couldn't get it to boot anything, not even from a CD or into the recovery mode. There can be pretty nasty bugs lurking around the corners of such a vast spec as UEFI, with the only requirement that involves any testing is Microsoft's hardware compatibility/certification program.
On 11/04/2022 22:29, Chris Murphy wrote:
UEFI Spec 2.8, 13.3.1.1 says "The EFI firmware must support the FAT32, FAT16, and FAT12 variants of the EFI file system. What variant of EFI FAT to use is defined by the size of the media. The rules defining the relationship between media size and FAT variants is defined in the specification for the EFI file system."
Also, ESP can use any FS that your firmware can read. I'm using ext4 on my desktop.
You can use efifs[1], packaged on Fedora[2].
[1]: https://github.com/pbatard/efifs [2]: https://src.fedoraproject.org/rpms/efifs
On Mon, Apr 11, 2022 at 02:21:04PM -0500, Chris Adams wrote:
Once upon a time, Peter Boy pboy@uni-bremen.de said:
I want to reiterate, it's not just about cloud platforms! if we remove BIOS boot (too early), we also kick Fedora servers, installed on hardware, out of these data centers. And the reason is not that this server hardware does not support UEFI, but the management infrastructure of the data centers.
Speaking of servers... one thing I noticed is that a pure-Fedora system only uses about 8M of /boot/efi. Even my dual-boot laptop with Win10 is only using 35M. Is there a reason 256M was chosen for the default UEFI system partition size (from the standard somewhere)? I guess that's what Windows does too (since Win10 was on this laptop first).
It is likely because UEFI specifies FAT32 on harddrives, and the minimum size for FAT32 is 256MB.
Brian
On Mon, Apr 11, 2022 at 3:36 PM Brian C. Lane bcl@redhat.com wrote:
On Mon, Apr 11, 2022 at 02:21:04PM -0500, Chris Adams wrote:
Once upon a time, Peter Boy pboy@uni-bremen.de said:
I want to reiterate, it's not just about cloud platforms! if we remove BIOS boot (too early), we also kick Fedora servers, installed on hardware, out of these data centers. And the reason is not that this server hardware does not support UEFI, but the management infrastructure of the data centers.
Speaking of servers... one thing I noticed is that a pure-Fedora system only uses about 8M of /boot/efi. Even my dual-boot laptop with Win10 is only using 35M. Is there a reason 256M was chosen for the default UEFI system partition size (from the standard somewhere)? I guess that's what Windows does too (since Win10 was on this laptop first).
It is likely because UEFI specifies FAT32 on harddrives, and the minimum size for FAT32 is 256MB.
That's just for 4KiB logical sectors though. Most everyone still has 512 byte logical sector size for internal drives. My nvme drive is 512 byte sectors, came with FAT 32 and 100 MiB EFI system (and reformatted with Microsoft's own installer the same).
On Mon, Apr 11, 2022 at 04:59:01PM -0600, Chris Murphy wrote:
On Mon, Apr 11, 2022 at 3:36 PM Brian C. Lane bcl@redhat.com wrote:
On Mon, Apr 11, 2022 at 02:21:04PM -0500, Chris Adams wrote:
Once upon a time, Peter Boy pboy@uni-bremen.de said:
I want to reiterate, it's not just about cloud platforms! if we remove BIOS boot (too early), we also kick Fedora servers, installed on hardware, out of these data centers. And the reason is not that this server hardware does not support UEFI, but the management infrastructure of the data centers.
Speaking of servers... one thing I noticed is that a pure-Fedora system only uses about 8M of /boot/efi. Even my dual-boot laptop with Win10 is only using 35M. Is there a reason 256M was chosen for the default UEFI system partition size (from the standard somewhere)? I guess that's what Windows does too (since Win10 was on this laptop first).
It is likely because UEFI specifies FAT32 on harddrives, and the minimum size for FAT32 is 256MB.
That's just for 4KiB logical sectors though. Most everyone still has 512 byte logical sector size for internal drives. My nvme drive is 512 byte sectors, came with FAT 32 and 100 MiB EFI system (and reformatted with Microsoft's own installer the same).
Ah, right. I'd forgotten about 4k sectors. I ran into this limit while trying to reduce the footprint of parted tests, which uses 512, 1024, 2048 and 4096 sector sizes so 256MB was as small as I could get.
Brian
Once upon a time, Brian C. Lane bcl@redhat.com said:
It is likely because UEFI specifies FAT32 on harddrives, and the minimum size for FAT32 is 256MB.
mkdosfs will make a FAT32 without warning on a size of 33296KB.
On 11/04/2022 23:35, Brian C. Lane wrote:
It is likely because UEFI specifies FAT32 on harddrives, and the minimum size for FAT32 is 256MB.
This is not true. From my Fedora VM:
Disk /dev/sda1: 200 MiB, 209715200 bytes, 409600 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000
On 4/11/22 14:18, Peter Boy wrote:
Am 10.04.2022 um 04:50 schrieb Gary Buhrmaster gary.buhrmaster@gmail.com:
On Wed, Apr 6, 2022 at 6:01 PM 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.
I want to reiterate, it's not just about cloud platforms! if we remove BIOS boot (too early), we also kick Fedora servers, installed on hardware, out of these data centers. And the reason is not that this server hardware does not support UEFI, but the management infrastructure of the data centers.
And kicking ourselves out, really doesn't strike me as a brilliant idea.
They may only support Linux users today, but if they want to grow (and while it is possible to survive as a niche service, many see growth as the way to increased revenue/profits (go big or go home)), they are going to get pushed (perhaps kicking and screaming) to support UEFI as at least an alternative …
It’s not so much about kicking and streaming, but about time, man power and financial resources.
Given how large a company Red Hat is, I presume that they could come up with these resources. The cost to Red Hat of maintaining legacy BIOS support is much less than the cost to the community of not doing so.
On Wed, Apr 06, 2022 at 01:57:00PM -0400, Neal Gompa wrote:
On Wed, Apr 6, 2022 at 11:50 AM Jared Dominguez jaredz@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
This was already addressed. Fedora should not be expected to jump through hoops to support vendors unwilling to participate in the open source Linux ecosystem. Users should stop buying their hardware -or- contribute to projects like nouveau to make this a non-issue.
The former case is excessively common, and the latter case is fairly common with HP and Dell machines as well as some smaller OEMs. I literally helped someone this past week with both[1][2][3]. The Workstation WG has been tracking both issues for years now[4][5]. This situation is *worse* now because we have Fedora Linux preloaded on computers, and OEMs basically have to disable Secure Boot to make things "work". How's that for improving security?
To add more anecdotes... it has been years since I have had to disable Secure Boot on a new laptop in order to install Fedora. Maybe I'm lucky, but I will say that the experience has only improved over time and you can't really say that for all distributions. Step 0 for many of them is still to disable Secure Boot first then begin installation.
On Mon, Apr 11, 2022 at 5:26 PM David Cantrell dcantrell@redhat.com wrote:
This was already addressed. Fedora should not be expected to jump through hoops to support vendors unwilling to participate in the open source Linux ecosystem. Users should stop buying their hardware -or- contribute to projects like nouveau to make this a non-issue.
And while I agree with the overall sentiment that Linux should not hoop jump for others, the reality is that many desktop and laptop users use their corporate provided systems(*), and those systems are often not (at all) Linux friendly(**).
Saying to those people "we feel your pain", while offering nothing else, is a a perfectly reasonable thing to do/say, but we should, at least, state it explicitly, should that be the direction we are going.
Gary
(*) Due to corporate purchasing decisions, I have more than once chosen to spend my own money to purchase laptops and desktop systems that can easily install/run Linux/Fedora. Not everyone realistically has that option, or will chose it even if they do have it (and sometimes corporate policy states you must use their pre-configured systems).
(**) The number of organizations that believe in Linux first, first, and first, and purchase accordingly, is small. Last I knew RH itself allowed their staff to choose Mac's. Why? Do they, themselves, not believe in Linux first, first, and first? No, I don't expect a reasonable answer here, but if RH does not require Linux first, first, and first there should be no expectation that other organizations will do so.
However, the majority of Linux PC users *must* step out of the happy path to get their hardware working for two cases:
- NVIDIA graphics
- Broadcom wireless
In the Firefox Public Data Report, GPU vendor is 69% Intel, 13% Nvidia, 13% AMD, 5% other. I don’t think Broadcom wireless is that common either. So it’s a lot of people, but not a majority of Linux PC users, probably less than 25%.
On 12.4.2022 00:24, Mark Otaris wrote:
However, the majority of Linux PC users *must* step out of the happy path to get their hardware working for two cases:
- NVIDIA graphics
- Broadcom wireless
In the Firefox Public Data Report, GPU vendor is 69% Intel, 13% Nvidia, 13% AMD, 5% other. I don’t think Broadcom wireless is that common either. So it’s a lot of people, but not a majority of Linux PC users, probably less than 25%.
Well it's not like it's affecting a large number of desktop users since those 25% are at best 25% of the desktop market share in Linux, which is just 2.36% ( excluding Chrome OS which has 2.79% market share on it's own, higher than all other Linux distributions combined ( which are around 500 ) ... ).
Then you can further reduce that number by figuring how much % each distribution has of those 2.36% which should give you what Fedora has of that and that ends up being what 10 people, 100 hundred at best so you are sacrificing the core values of Fedora for those 10 - 100 vocal people...
JBG
Your calculations have to be off; I’m pretty sure there are way more than 100 Fedora users with a Nvidia GPU. The Linux Hardware Project alone reports 106 Fedora users with Nvidia GPUs (which is actually 29% of their sample) so that’s a hard minimum: https://linux-hardware.org/?view=gpu_vendor&d=Fedora. I think there are at least tens of thousands of Fedora users with a Nvidia GPU. It’s not a majority, is all.
On 12.4.2022 20:44, Mark Otaris wrote:
Your calculations have to be off; I’m pretty sure there are way more than 100 Fedora users with a Nvidia GPU. The Linux Hardware Project alone reports 106 Fedora users with Nvidia GPUs (which is actually 29% of their sample) so that’s a hard minimum: https://linux-hardware.org/?view=gpu_vendor&d=Fedora. I think there are at least tens of thousands of Fedora users with a Nvidia GPU. It’s not a majority, is all.
Let's give you your tens of thousand of fedora users with Nvidia GPU, it's still not even a blimp in the chart of the overall desktop market share, let alone a number worth sacrificing core values for.
Fedora only holds a very small % of those 2.36% of the Linux desktop market share which is such a small number it wont even be worth raising someone's eyebrow at Nvidia...
JBG
On 4/6/22 12:57, Neal Gompa wrote: (trimming)
- NVIDIA graphics
- Broadcom wireless
The former case is excessively common, and the latter case is fairly common with HP and Dell machines as well as some smaller OEMs. I literally helped someone this past week with both[1][2][3]. The Workstation WG has been tracking both issues for years now[4][5]. This situation is *worse* now because we have Fedora Linux preloaded on computers, and OEMs basically have to disable Secure Boot to make things "work". How's that for improving security?
I too have been a bit surprised at some of the difficulties of hibernate/secure boot on recent fedora releases. It seems people are entirely unaware that ACPI/S3 standby is gone from most consumer laptops, and the modern standby replacement implementations tend to work very poorly WRT conserving battery with the lid closed in Linux.
Leaving hibernate as the only workable solution if you want to just close the laptop lid, and come back the next day without having the machine at 0% battery. This is the expected/default windows behavior too. After ~5% IIRC battery loss in modern standby mode, it hibernates. (look up windows adaptive hibernate).
So, on a recent fedora machine, it took me more than 4 hours to get a hibernation file on btrfs plus LUKS encrypted partition working. The documentation for that wasn't to be found anywhere on the fedora/RH sites and required compiling a tool to do the block offset calculations and manually adding the resume_offset options to grub/etc. All while avoiding the mass of incorrect information found on the internet. And of course it also requires disabling swap on zram (which was nonsense on the machine anyway, given the disks are faster than it can compress/decompress pages).
And of course the lockdown patches in the kernel still aren't smart enough to be able to detect that the swapfile is actually encrypted, so it also requires disabling secure boot (this IMHO is frankly unacceptable, that one can't have both options enabled at the same time).
So, this is really less about BIOS/EFI and more about some pretty basic functionality being broken in the distro.
On the cloud side, it's been very difficult to articulate any benefits for supporting UEFI when the majority of the consumers of Fedora Cloud don't have any pressing need to do it and things like hibernation and snapshotting are non-functional. Last year, I changed Fedora Cloud to hybrid boot[6] so that our image artifacts support both boot modes. While GCP requires UEFI and Azure prefers it, AWS has very basic support for UEFI and using UEFI causes you to lose some features that exist only in BIOS mode. One of those is leveraging hibernation in the cloud for spot instances[7]. Moving past the Big Three(tm), the actual cloud providers that matter from a Fedora context are the smaller outfits that principally serve Linux users. These are companies like DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who graciously do offer Fedora Linux in their platforms. All of their virtualization platforms are BIOS only right now, and getting them to switch requires them to uplift their platforms to support UEFI in the first place. And again, when UEFI means things like VM snapshots and cloud hibernation don't work, it's not very compelling.
You'd think that given how important this is for the Cloud that it would have mattered for RHEL, but nope. These problems are not new. They've existed since we supported UEFI Secure Boot, and given how people have responded saying these issues are irrelevant to this Change, it shows how out of sync with reality this Change is.
Frankly, I'm extremely frustrated and exhausted over the situation.
-- 真実はいつも一つ！/ 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 Mon, May 2, 2022 at 5:29 PM Jeremy Linton jeremy.linton@arm.com wrote:
On 4/6/22 12:57, Neal Gompa wrote: (trimming)
- NVIDIA graphics
- Broadcom wireless
The former case is excessively common, and the latter case is fairly common with HP and Dell machines as well as some smaller OEMs. I literally helped someone this past week with both[1][2][3]. The Workstation WG has been tracking both issues for years now[4][5]. This situation is *worse* now because we have Fedora Linux preloaded on computers, and OEMs basically have to disable Secure Boot to make things "work". How's that for improving security?
I too have been a bit surprised at some of the difficulties of hibernate/secure boot on recent fedora releases. It seems people are entirely unaware that ACPI/S3 standby is gone from most consumer laptops, and the modern standby replacement implementations tend to work very poorly WRT conserving battery with the lid closed in Linux.
It's a kernel problem. I'm not sure to what degree upstream is aware of it. But there's not a lot we can do about it except file bugs and ask for improvement.
So, on a recent fedora machine, it took me more than 4 hours to get a hibernation file on btrfs plus LUKS encrypted partition working. The documentation for that wasn't to be found anywhere on the fedora/RH sites and required compiling a tool to do the block offset calculations and manually adding the resume_offset options to grub/etc. All while avoiding the mass of incorrect information found on the internet. And of course it also requires disabling swap on zram (which was nonsense on the machine anyway, given the disks are faster than it can compress/decompress pages).
I don't think it requires disabling swap on zram per se - from what I've been told the hibernation code knows it can't use it for the hibernation image, not least of which is it's not big enough for a contiguous write of the image. The issue might be that so much needs to be swapped out, to free ~50% RAM, which is used to create the hibernation image in memory before it's written out. We need a clear reproducer with logs and get it posted to the Linux memory management mailing list to see what's going wrong. Since zram is threaded, it's pretty unlikely drive writes are faster than memory writes with compression. LZO+RLE is computationally pretty cheap.
And of course the lockdown patches in the kernel still aren't smart enough to be able to detect that the swapfile is actually encrypted, so it also requires disabling secure boot (this IMHO is frankly unacceptable, that one can't have both options enabled at the same time).
Encryption isn't enough to ensure the image is valid. It needs to be signed. But in any case this is also upstream effort required, including discovering the offset via a standard API for all file systems.
So, this is really less about BIOS/EFI and more about some pretty basic functionality being broken in the distro.
Hi,
On 5/2/22 22:53, Chris Murphy wrote:
On Mon, May 2, 2022 at 5:29 PM Jeremy Linton jeremy.linton@arm.com wrote:
On 4/6/22 12:57, Neal Gompa wrote: (trimming)
- NVIDIA graphics
- Broadcom wireless
The former case is excessively common, and the latter case is fairly common with HP and Dell machines as well as some smaller OEMs. I literally helped someone this past week with both[1][2][3]. The Workstation WG has been tracking both issues for years now[4][5]. This situation is *worse* now because we have Fedora Linux preloaded on computers, and OEMs basically have to disable Secure Boot to make things "work". How's that for improving security?
I too have been a bit surprised at some of the difficulties of hibernate/secure boot on recent fedora releases. It seems people are entirely unaware that ACPI/S3 standby is gone from most consumer laptops, and the modern standby replacement implementations tend to work very poorly WRT conserving battery with the lid closed in Linux.
It's a kernel problem. I'm not sure to what degree upstream is aware of it. But there's not a lot we can do about it except file bugs and ask for improvement.
So, on a recent fedora machine, it took me more than 4 hours to get a hibernation file on btrfs plus LUKS encrypted partition working. The documentation for that wasn't to be found anywhere on the fedora/RH sites and required compiling a tool to do the block offset calculations and manually adding the resume_offset options to grub/etc. All while avoiding the mass of incorrect information found on the internet. And of course it also requires disabling swap on zram (which was nonsense on the machine anyway, given the disks are faster than it can compress/decompress pages).
I don't think it requires disabling swap on zram per se - from what I've been told the hibernation code knows it can't use it for the hibernation image, not least of which is it's not big enough for a contiguous write of the image. The issue might be that so much needs to be swapped out, to free ~50% RAM, which is used to create the hibernation image in memory before it's written out. We need a clear reproducer with logs and get it posted to the Linux memory management mailing list to see what's going wrong. Since zram is threaded, it's pretty unlikely drive writes are faster than memory writes with compression. LZO+RLE is computationally pretty cheap.
DMA is computationally free. and at >3GB/sec on modern hw with sufficient queue depth or contiguous. And the RLE improvements only help when the page is basically empty. AKA its a great chrome benchmark tool, less so for real workloads.
And of course the lockdown patches in the kernel still aren't smart enough to be able to detect that the swapfile is actually encrypted, so it also requires disabling secure boot (this IMHO is frankly unacceptable, that one can't have both options enabled at the same time).
Encryption isn't enough to ensure the image is valid. It needs to be signed. But in any case this is also upstream effort required, including discovering the offset via a standard API for all file systems.
Yes, I'm aware much of this is a kernel problem, but the point being that in the meantime, most random machines people are buying at retail won't last more than a day or so without being plugged in using fedora, vs many days with windows because its hibernating with secure boot turned on.
So, this is really less about BIOS/EFI and more about some pretty basic functionality being broken in the distro.
On Tue, May 3, 2022 at 11:32 AM Jeremy Linton jeremy.linton@arm.com wrote:
Hi,
On 5/2/22 22:53, Chris Murphy wrote:
On Mon, May 2, 2022 at 5:29 PM Jeremy Linton jeremy.linton@arm.com
wrote:
On 4/6/22 12:57, Neal Gompa wrote: (trimming)
- NVIDIA graphics
- Broadcom wireless
The former case is excessively common, and the latter case is fairly common with HP and Dell machines as well as some smaller OEMs. I literally helped someone this past week with both[1][2][3]. The Workstation WG has been tracking both issues for years now[4][5]. This situation is *worse* now because we have Fedora Linux preloaded on computers, and OEMs basically have to disable Secure Boot to make things "work". How's that for improving security?
I too have been a bit surprised at some of the difficulties of hibernate/secure boot on recent fedora releases. It seems people are entirely unaware that ACPI/S3 standby is gone from most consumer laptops, and the modern standby replacement implementations tend to work very poorly WRT conserving battery with the lid closed in Linux.
It's a kernel problem. I'm not sure to what degree upstream is aware of it. But there's not a lot we can do about it except file bugs and ask for improvement.
So, on a recent fedora machine, it took me more than 4 hours to get a hibernation file on btrfs plus LUKS encrypted partition working. The documentation for that wasn't to be found anywhere on the fedora/RH sites and required compiling a tool to do the block offset calculations and manually adding the resume_offset options to grub/etc. All while avoiding the mass of incorrect information found on the internet. And of course it also requires disabling swap on zram (which was nonsense on the machine anyway, given the disks are faster than it can compress/decompress pages).
I don't think it requires disabling swap on zram per se - from what I've been told the hibernation code knows it can't use it for the hibernation image, not least of which is it's not big enough for a contiguous write of the image. The issue might be that so much needs to be swapped out, to free ~50% RAM, which is used to create the hibernation image in memory before it's written out. We need a clear reproducer with logs and get it posted to the Linux memory management mailing list to see what's going wrong. Since zram is threaded, it's pretty unlikely drive writes are faster than memory writes with compression. LZO+RLE is computationally pretty cheap.
DMA is computationally free. and at >3GB/sec on modern hw with sufficient queue depth or contiguous. And the RLE improvements only help when the page is basically empty. AKA its a great chrome benchmark tool, less so for real workloads.
Quite a lot of folks in the Fedora community do not have NVMe drives. If you have a real workload that's straightforward to reproduce better performance when swap on NVME plain partition vs zram, I'd like to give it a go. There'a always tradeoffs, the goal is to do a good job for most use cases, not optimize for a few.
And of course the lockdown patches in the kernel still aren't smart enough to be able to detect that the swapfile is actually encrypted, so it also requires disabling secure boot (this IMHO is frankly unacceptable, that one can't have both options enabled at the same
time).
Encryption isn't enough to ensure the image is valid. It needs to be signed. But in any case this is also upstream effort required, including discovering the offset via a standard API for all file systems.
Yes, I'm aware much of this is a kernel problem, but the point being that in the meantime, most random machines people are buying at retail won't last more than a day or so without being plugged in using fedora, vs many days with windows because its hibernating with secure boot turned on.
On a recently purchased Lenovo, s2idle is what's used with Windows 10 sleep set in the firmware setup. I see about 1% battery drop per hour. When switching it to Linux sleep, it uses ACPI S3, and I see maybe 1% battery drop per 8 hours. I don't know why. But until there's authenticated+encrypted hibernation images, I think there's not much to be done out of the box. Even once we have hibernation images, we can't depend on hibernation working for various reasons:
https://pagure.io/fedora-workstation/blob/master/f/hibernationstatus.md
It's not good that hibernation doesn't work well right now. But it's possible to give users an even worse experience, including a false sense of security regarding their data when hibernation is used.
On Mon, May 02, 2022 at 11:53:12PM -0400, Chris Murphy wrote:
On Mon, May 2, 2022 at 5:29 PM Jeremy Linton jeremy.linton@arm.com wrote:
And of course it also requires disabling swap on zram (which was nonsense on the machine anyway, given the disks are faster than it can compress/decompress pages).
I don't think it requires disabling swap on zram per se - from what I've been told the hibernation code knows it can't use it for the hibernation image, not least of which is it's not big enough for a contiguous write of the image. The issue might be that so much needs to be swapped out, to free ~50% RAM, which is used to create the hibernation image in memory before it's written out. We need a clear reproducer with logs and get it posted to the Linux memory management mailing list to see what's going wrong. Since zram is threaded, it's pretty unlikely drive writes are faster than memory writes with compression. LZO+RLE is computationally pretty cheap.
In general, hibernation is expected to work if a zram device is present. Systemd will automatically filter out zram devices from the candidate list.
If it didn't work for you, it's probably somehting like Chris wrote, not enough swap for the amount of memory used.
So, on a recent fedora machine, it took me more than 4 hours to get a hibernation file on btrfs plus LUKS encrypted partition working. The documentation for that wasn't to be found anywhere on the fedora/RH sites and required compiling a tool to do the block offset calculations and manually adding the resume_offset options to grub/etc.
systemd has code to calculate the offset. It is used to try to figure out which of the swap partitions matches swap_offset= configured on the kernel command line. I guess it'd be helpful if we exposed this functionality somewhere. Maybe something like 'systemd-analyze suggest-hibernation-config-that-works' ;)
Zbyszek
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 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
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
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 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.
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 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!
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: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.
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
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 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.
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.
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 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 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.
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
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
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 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 19:30, Tom Hughes via devel wrote:
This is where I have a problem with this, the fact that there is no upgrade path - virtually my entire installed base of Fedora is running legacy BIOS and not being able to upgrade them will be something of a headache.
If you want to switch from legacy boot to UEFI, you need to do the following: 1. Switch from MBR (msdos) to GPT. 2. Create ESP (FAT32 by default) partition. 3. Move data.
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.)
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
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<
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.
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
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?
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
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 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 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 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
Those figures are recommended minimums, not requirements. I have a single core F35 machine which works fine.
"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
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
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 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 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.
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
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.
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 07, 2022 at 10:58:29AM +0200, Peter Boy wrote:
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.
This summarizes my feelings about the proposal very well.
We should look to the Xorg → Wayland transition for inspiration: it's long, it's messy, it requires a lot of effort from people doing the work, and it's still not finished. Those are the downsides. But the big upside is that we're not leaving users who need Xorg in the ditch.
A similar pattern should be followed here: encourage users to switch, fix bugs so that $new is better than $old in all cases we care about, iterate until the number of users on $old is negligible, *then* announce that $old is not supported, but keep it working, and only after that start cutting off parts of $old.
The proposed plan seems to be to jump to the last two steps before the middle parts have been done. Based on the examples posted to this thread, it'd leave our users and developers with 10%–30% of hardware unsupported by the next installer. It also depends on changes that are only *planned* in external projects like VirtualBox and libvirt.
Sorry, but the plan needs to be inverted to at least make sure that the UEFI works for all the cloud providers and virtualization software in a testable way, and then switch to UEFI as the default in as many places as possible. Then we can talk about dropping support for BIOS, taking into account how many users are still left with BIOS-only hardware.
Zbyszek
On Thu, 2022-04-07 at 16:16 +0200, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Apr 07, 2022 at 10:58:29AM +0200, Peter Boy wrote:
Am 07.04.2022 um 00:25 schrieb Neal Gompa ngompa13@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.
This summarizes my feelings about the proposal very well.
We should look to the Xorg → Wayland transition for inspiration: it's long, it's messy, it requires a lot of effort from people doing the work, and it's still not finished. Those are the downsides. But the big upside is that we're not leaving users who need Xorg in the ditch.
A similar pattern should be followed here: encourage users to switch, fix bugs so that $new is better than $old in all cases we care about, iterate until the number of users on $old is negligible, *then* announce that $old is not supported, but keep it working, and only after that start cutting off parts of $old.
The proposed plan seems to be to jump to the last two steps before the middle parts have been done. Based on the examples posted to this thread, it'd leave our users and developers with 10%–30% of hardware unsupported by the next installer. It also depends on changes that are only *planned* in external projects like VirtualBox and libvirt.
Sorry, but the plan needs to be inverted to at least make sure that the UEFI works for all the cloud providers and virtualization software in a testable way, and then switch to UEFI as the default in as many places as possible. Then we can talk about dropping support for BIOS, taking into account how many users are still left with BIOS-only hardware.
FWMOIW this sounds like the most reasonable comment I have seen here.
The plan is nice, it is just trying to get to the end goal too fast, more nuanced steps are necessary and more time. Too many users would be left behind otherwise.
simo.
On Thu, Apr 7, 2022 at 3:16 PM Simo Sorce simo@redhat.com wrote:
On Thu, 2022-04-07 at 16:16 +0200, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Apr 07, 2022 at 10:58:29AM +0200, Peter Boy wrote:
Am 07.04.2022 um 00:25 schrieb Neal Gompa ngompa13@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.
This summarizes my feelings about the proposal very well.
We should look to the Xorg → Wayland transition for inspiration: it's long, it's messy, it requires a lot of effort from people doing the work, and it's still not finished. Those are the downsides. But the big upside is that we're not leaving users who need Xorg in the ditch.
A similar pattern should be followed here: encourage users to switch, fix bugs so that $new is better than $old in all cases we care about, iterate until the number of users on $old is negligible, *then* announce that $old is not supported, but keep it working, and only after that start cutting off parts of $old.
The proposed plan seems to be to jump to the last two steps before the middle parts have been done. Based on the examples posted to this thread, it'd leave our users and developers with 10%–30% of hardware unsupported by the next installer. It also depends on changes that are only *planned* in external projects like VirtualBox and libvirt.
Sorry, but the plan needs to be inverted to at least make sure that the UEFI works for all the cloud providers and virtualization software in a testable way, and then switch to UEFI as the default in as many places as possible. Then we can talk about dropping support for BIOS, taking into account how many users are still left with BIOS-only hardware.
FWMOIW this sounds like the most reasonable comment I have seen here.
The plan is nice, it is just trying to get to the end goal too fast, more nuanced steps are necessary and more time. Too many users would be left behind otherwise.
I like Zbigniew's plan too! But I gotta ask, what is "FWMOIW"?
-- 真実はいつも一つ！/ Always, there's only one truth!
On Thu, 2022-04-07 at 15:26 -0400, Neal Gompa wrote:
On Thu, Apr 7, 2022 at 3:16 PM Simo Sorce simo@redhat.com wrote:
On Thu, 2022-04-07 at 16:16 +0200, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Apr 07, 2022 at 10:58:29AM +0200, Peter Boy wrote:
Am 07.04.2022 um 00:25 schrieb Neal Gompa ngompa13@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.
This summarizes my feelings about the proposal very well.
We should look to the Xorg → Wayland transition for inspiration: it's long, it's messy, it requires a lot of effort from people doing the work, and it's still not finished. Those are the downsides. But the big upside is that we're not leaving users who need Xorg in the ditch.
A similar pattern should be followed here: encourage users to switch, fix bugs so that $new is better than $old in all cases we care about, iterate until the number of users on $old is negligible, *then* announce that $old is not supported, but keep it working, and only after that start cutting off parts of $old.
The proposed plan seems to be to jump to the last two steps before the middle parts have been done. Based on the examples posted to this thread, it'd leave our users and developers with 10%–30% of hardware unsupported by the next installer. It also depends on changes that are only *planned* in external projects like VirtualBox and libvirt.
Sorry, but the plan needs to be inverted to at least make sure that the UEFI works for all the cloud providers and virtualization software in a testable way, and then switch to UEFI as the default in as many places as possible. Then we can talk about dropping support for BIOS, taking into account how many users are still left with BIOS-only hardware.
FWMOIW this sounds like the most reasonable comment I have seen here.
The plan is nice, it is just trying to get to the end goal too fast, more nuanced steps are necessary and more time. Too many users would be left behind otherwise.
I like Zbigniew's plan too! But I gotta ask, what is "FWMOIW"?
For What My Opinion Is Worth :-)
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@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 Thu, Apr 7, 2022 at 4:58 AM Peter Boy pboy@uni-bremen.de wrote:
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).
This is a proposal. Nothing has changed yet. The choice is now whether to go forward with it or come together with a cohesive alternative, including one of the two listed in the proposal. But we need a solution that accounts for the existing maintainers not having capacity to continue maintaining legacy code. I've seen responses from Robbie and Brian (and myself) that are correcting false statements or following up on questions and nothing that indicates to me close-mindedness or unwillingness for constructive alternatives.
And it is OK for me to migrate to UEFI only in the long run. But not that way. _______________________________________________ devel mailing list -- devel@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/7/22 08:02, Jared Dominguez wrote:
This is a proposal. Nothing has changed yet. The choice is now whether to go forward with it or come together with a cohesive alternative, including one of the two listed in the proposal. But we need a solution that accounts for the existing maintainers not having capacity to continue maintaining legacy code. I've seen responses from
I haven't yet seen a clear answer about what code is "rotting" and which legacy code is too hard to maintain. Is there something actually broken right now?
On Thu, Apr 7, 2022 at 3:49 PM Samuel Sieb samuel@sieb.net wrote:
On 4/7/22 08:02, Jared Dominguez wrote:
This is a proposal. Nothing has changed yet. The choice is now whether to go forward with it or come together with a cohesive alternative, including one of the two listed in the proposal. But we need a solution that accounts for the existing maintainers not having capacity to continue maintaining legacy code. I've seen responses from
I haven't yet seen a clear answer about what code is "rotting" and which legacy code is too hard to maintain. Is there something actually broken right now?
For one, syslinux hasn't seen an update in 3 years and a release in 7 years, and it has outstanding bugs. Legacy boot isn't where grub2 is getting development attention. The current maintainers in Fedora won't have capacity to continue maintaining legacy boot support in Fedora. As grub2 continues to be developed for UEFI systems (ARMv8-9 and x86-64, not to mention non-UEFI ppc64le and s390x), there is added risk of regressions on legacy x86 boot that won't be getting developer attention.
devel mailing list -- devel@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/7/22 14:51, Jared Dominguez wrote:
On Thu, Apr 7, 2022 at 3:49 PM Samuel Sieb <samuel@sieb.net mailto:samuel@sieb.net> wrote:
On 4/7/22 08:02, Jared Dominguez wrote: > This is a proposal. Nothing has changed yet. The choice is now whether > to go forward with it or come together with a cohesive > alternative, including one of the two listed in the proposal. But we > need a solution that accounts for the existing maintainers not having > capacity to continue maintaining legacy code. I've seen responses from I haven't yet seen a clear answer about what code is "rotting" and which legacy code is too hard to maintain. Is there something actually broken right now?For one, syslinux hasn't seen an update in 3 years and a release in 7 years, and it has outstanding bugs. Legacy boot isn't where grub2 is getting development attention. The current maintainers in Fedora won't have capacity to continue maintaining legacy boot support in Fedora. As grub2 continues to be developed for UEFI systems (ARMv8-9 and x86-64, not to mention non-UEFI ppc64le and s390x), there is added risk of regressions on legacy x86 boot that won't be getting developer attention.
I don't understand why we're still using syslinux instead of grub for legacy boots, especially since I think now you can use the same grub.cfg file for both. There is always a risk of regressions, but if there is no current problem, then why is there this push to obsolete a lot of active hardware? This is not comparable to the 32-bit removal where it was only a few really old systems. This is going to affect decent systems that are less than 10 years old. I have a work HP laptop from 2012 that has "experimental" EFI support that really doesn't work well and possibly a newer one as well, but I can't check it right now.
On Thu, Apr 7, 2022 at 5:35 PM Samuel Sieb samuel@sieb.net wrote:
On 4/7/22 14:51, Jared Dominguez wrote:
On Thu, Apr 7, 2022 at 3:49 PM Samuel Sieb <samuel@sieb.net mailto:samuel@sieb.net> wrote:
On 4/7/22 08:02, Jared Dominguez wrote: > This is a proposal. Nothing has changed yet. The choice is now whether > to go forward with it or come together with a cohesive > alternative, including one of the two listed in the proposal. But we > need a solution that accounts for the existing maintainers not having > capacity to continue maintaining legacy code. I've seen responses from I haven't yet seen a clear answer about what code is "rotting" and which legacy code is too hard to maintain. Is there something actually broken right now?For one, syslinux hasn't seen an update in 3 years and a release in 7 years, and it has outstanding bugs. Legacy boot isn't where grub2 is getting development attention. The current maintainers in Fedora won't have capacity to continue maintaining legacy boot support in Fedora. As grub2 continues to be developed for UEFI systems (ARMv8-9 and x86-64, not to mention non-UEFI ppc64le and s390x), there is added risk of regressions on legacy x86 boot that won't be getting developer attention.
I don't understand why we're still using syslinux instead of grub for legacy boots, especially since I think now you can use the same grub.cfg file for both.
syslinux (really isolinux) is only used on installation media.
This comment from 2012 suggests we probably should have dropped isolinux in favor of BIOS GRUB a while ago, but c'est la vie. I think it's in scope to exchange syslinux for GRUB in the F37 cycle, pending review of the effort required to do it. https://mjg59.dreamwidth.org/11285.html?thread=345621#cmt345621
There is always a risk of regressions, but if there is no current problem, then why is there this push to obsolete a lot of active hardware? This is not comparable to the 32-bit removal where it was only a few really old systems. This is going to affect decent systems that are less than 10 years old. I have a work HP laptop from 2012 that has "experimental" EFI support that really doesn't work well and possibly a newer one as well, but I can't check it right now.
Given that Microsoft has had an exception for UEFI being required on server hardware up until barely two years ago, I suspect RHEL folks are going to have customers asking for reconsideration.
Once upon a time, Chris Murphy lists@colorremedies.com said:
syslinux (really isolinux) is only used on installation media.
It's commonly used for BIOS PXE booting as well.
On Thu, Apr 7, 2022 at 9:21 PM Chris Adams linux@cmadams.net wrote:
Once upon a time, Chris Murphy lists@colorremedies.com said:
syslinux (really isolinux) is only used on installation media.
It's commonly used for BIOS PXE booting as well.
*shudders at the memories of dealing with pxelinux*
GRUB is way better for that. Yes, you can use GRUB for PXE and UEFI netboot too.
-- 真実はいつも一つ！/ Always, there's only one truth!
On 4/7/22 18:54, Neal Gompa wrote:
On Thu, Apr 7, 2022 at 9:21 PM Chris Adams linux@cmadams.net wrote:
Once upon a time, Chris Murphy lists@colorremedies.com said:
syslinux (really isolinux) is only used on installation media.
It's commonly used for BIOS PXE booting as well.
*shudders at the memories of dealing with pxelinux*
GRUB is way better for that. Yes, you can use GRUB for PXE and UEFI netboot too.
That's what I use for both.
On Friday, 08 April 2022 at 08:57, Samuel Sieb wrote:
On 4/7/22 18:54, Neal Gompa wrote:
On Thu, Apr 7, 2022 at 9:21 PM Chris Adams linux@cmadams.net wrote:
Once upon a time, Chris Murphy lists@colorremedies.com said:
syslinux (really isolinux) is only used on installation media.
It's commonly used for BIOS PXE booting as well.
*shudders at the memories of dealing with pxelinux*
GRUB is way better for that. Yes, you can use GRUB for PXE and UEFI netboot too.
That's what I use for both.
Would you care to document your set-ups?
Regards, Dominik
On Thu, Apr 7, 2022 at 7:15 PM Chris Murphy lists@colorremedies.com wrote:
syslinux (really isolinux) is only used on installation media.
This comment from 2012 suggests we probably should have dropped isolinux in favor of BIOS GRUB a while ago, but c'est la vie. I think it's in scope to exchange syslinux for GRUB in the F37 cycle, pending review of the effort required to do it. https://mjg59.dreamwidth.org/11285.html?thread=345621#cmt345621
Add this to the retrospective reading https://mjg59.dreamwidth.org/4957.html
And for status of optical media in Fedora (tl;dr is optical boot must work for Everything and Workstation ISOs, but there is no requirement to test them, ergo if someone tests and finds it doesn't work, it blocks; if no one tests it, oops oh well!) https://docs.fedoraproject.org/en-US/releases/f36/blocking/ https://fedoraproject.org/wiki/Changes/Drop_Optical_Media_Criterion
For what it's worth, the current xorriso command used to make most of our ISO images (hybrid images that can boot most everything whether PXE, Macs, UEFI or BIOS, USB stick or optical) is
xorrisofs -o /var/tmp/lmc-work-hrb6zq5j/images/boot.iso -isohybrid-mbr /usr/share/syslinux/isohdpfx.bin -b isolinux/isolinux.bin -c isolinux/boot.cat -boot-load-size 4 -boot-info-table -no-emul-boot -eltorito-alt-boot -e images/efiboot.img -no-emul-boot -isohybrid-gpt-basdat -eltorito-alt-boot -e images/macboot.img -no-emul-boot -isohybrid-gpt-hfsplus -R -J -V Fedora-WS-Live-36-20220407-n-0 -graft-points isolinux=/var/tmp/lmc-work-hrb6zq5j/isolinux images/pxeboot=/var/tmp/lmc-work-hrb6zq5j/images/pxeboot LiveOS=/var/tmp/lmc-work-hrb6zq5j/LiveOS EFI/BOOT=/var/tmp/lmc-work-hrb6zq5j/EFI/BOOT images/efiboot.img=/var/tmp/lmc-work-hrb6zq5j/images/efiboot.img images/macboot.img=/var/tmp/lmc-work-hrb6zq5j/images/macboot.img LICENSE=/var/tmp/lmc-work-hrb6zq5j/LICENSE Fedora-Legal-README.txt=/var/tmp/lmc-work-hrb6zq5j/Fedora-Legal-README.txt
There's a bit to unpack there...
Hi,
i'm the developer of xorriso. Please CC me with replies just in case that i unsubscribe because of too much traffic.
Further: Sorry for my reply-id pointing to the predecessor of the message which i quote. I found it at https://www.spinics.net/lists/fedora-devel/msg299915.html
Chris Murphy wrote:
For what it's worth, the current xorriso command used [...] is
xorrisofs -o /var/tmp/lmc-work-hrb6zq5j/images/boot.iso -isohybrid-mbr /usr/share/syslinux/isohdpfx.bin -b isolinux/isolinux.bin -c isolinux/boot.cat -boot-load-size 4 -boot-info-table -no-emul-boot -eltorito-alt-boot -e images/efiboot.img -no-emul-boot -isohybrid-gpt-basdat -eltorito-alt-boot -e images/macboot.img -no-emul-boot -isohybrid-gpt-hfsplus -R -J -V Fedora-WS-Live-36-20220407-n-0 -graft-points [... various files and directories grafted in ...]
There's a bit to unpack there...
The lines, which will need changes for using GRUB, are at least:
-isohybrid-mbr /usr/share/syslinux/isohdpfx.bin [...] -boot-load-size 4 -boot-info-table -no-emul-boot -b isolinux/isolinux.bin
grub-mkrescue (on Debian) uses instead:
--grub2-mbr /usr/lib/grub/i386-pc/boot_hybrid.img -b boot/grub/i386-pc/eltorito.img -no-emul-boot -boot-load-size 4 -boot-info-table --grub2-boot-info
/usr/lib/grub/i386-pc/boot_hybrid.img is part of Debian's grub-pc-bin package. It gets built by upstream file grub-core/Makefile.core https://sources.debian.org/src/grub2/2.06-2/grub-core/Makefile.core.am/?hl=2...
/boot/grub/i386-pc/eltorito.img has to be inserted as data file into the emerging ISO 9660 filesystem. grub-mkrescue puts it into the file tree on hard disk which it then gives to xorrisofs as input file. It gets produced by GRUB from a file named "cdboot.img". In Debian it is part of package grub-pc-bin as /usr/lib/grub/i386-pc/cdboot.img It does not appear as if the read-in cdboot.img would get modified before it gets written back as "eltorito.img": https://sources.debian.org/src/grub2/2.06-2/util/mkimage.c/?hl=1271#L1266 Its production/copying gets ordered in: https://sources.debian.org/src/grub2/2.06-2/util/grub-mkrescue.c/?hl=598#L58...
The emerging GRUB MBR is supposed to boot from USB sticks quite like the ISOLINUX MBR. Both hop with their execution onto the El Torito boot images for BIOS.
grub-mkrescue uses no option -c, which does not matter for boot success. Fedora can well keep its
-c isolinux/boot.cat
The EFI-related options -isohybrid-gpt-basdat and -isohybrid-gpt-hfsplus will continue to work, if additionally option
-part_like_isohybrid
is given (once is enough).
------------------------------------------------------------------------ More unsolicited info:
An opportunity to watch grub-mkrescue's xorriso options is given by the script frontend/grub-mkrescue-sed.sh from the source tarball of xorriso (which in Fedora is libisoburn-*.tar.gz):
https://dev.lovelyhq.com/libburnia/libisoburn/raw/branch/master/frontend/gru...
I derived above BIOS proposal by
mkdir minimal touch minimal/empty-file.txt export MKRESCUE_SED_DEBUG=yes grub-mkrescue -o output.iso minimal \ --xorriso=/...localpath.../frontend/grub-mkrescue-sed.sh
If i install (on Debian) grub-common grub-pc-bin grub-efi-amd64-bin grub-efi-ia32-bin i get from grub-mkrescue an ISO with both, BIOS and EFI equipment.
The original purpose of the script grub-mkrescue-sed.sh is to enable variations of the xorriso options to create different layouts of partition tables for the EFI stuff. See "Variation settings" in the script. The main drawback of grub-mkrescue's original partition layout is that there is no mountable partition for the ISO 9660 filesystem. For Fedora's ISOs it might be interesting to inspect the messages and the resulting ISO of
export MKRESCUE_SED_MODE=mjg export MKRESCUE_SED_DEBUG=yes grub-mkrescue -o output.iso minimal \ --xorriso=/...localpath.../frontend/grub-mkrescue-sed.sh
It produces a layout that is inspired by mjg59's from 2012, but avoids to have the EFI partition inside the ISO 9660 filesystem and its partition by appending the EFI partition. (The HFS+ filesystem for Macs gets produced by libisofs. It would be interesting to learn whether such Macs still exist and work with the grub-mkrescue ISO.)
Discussions with other distro's ISO maintainers and their users yielded that some old BIOS machines demand an MBR partition with "boot/active" flag. Some new EFIs demand the presence of a GPT. So ye olde nested pseudo-GPT partition layout of Fedora (and also of Debian) still has its merits. Just the nesting is ugly, unneeded, and causes protests from partition editors.
With original grub-mkrescue layout and its pure GPT, the remedy is to use xorrisofs option --mbr-force-bootable which makes the GPT a bit less pure by adding a little dummy MBR partition of type 0x00.
Have a nice day :)
Thomas
On Fri, Apr 8, 2022 at 12:29 PM Thomas Schmitt scdbackup@gmx.net wrote:
The lines, which will need changes for using GRUB, are at least:
-isohybrid-mbr /usr/share/syslinux/isohdpfx.bin [...] -boot-load-size 4 -boot-info-table -no-emul-boot -b isolinux/isolinux.bin
grub-mkrescue (on Debian) uses instead:
--grub2-mbr /usr/lib/grub/i386-pc/boot_hybrid.img -b boot/grub/i386-pc/eltorito.img -no-emul-boot -boot-load-size 4 -boot-info-table --grub2-boot-info
Is there a possibility of dropping MBR? i.e. use GPT containing both a biosboot partition type, and EFI System partition type?
The advantage of this is not just to get rid of MBR really. But if there are still some systems out there that will face plant on GPT anyway, it's probably best if they face plant when booting the installation media rather than getting all the way to a successful installation, just to face plant upon reboot.
Hi,
Chris Murphy wrote:
Is there a possibility of dropping MBR? i.e. use GPT containing both a biosboot partition type, and EFI System partition type?
I am not aware that legacy BIOS would hop directly on any GPT partition or any MBR partition table partition.
The convention for hard-disk-like devices is to start the x86 code in bytes 0 to 439 (or maybe to byte 445) of the MBR as 16-bit program. In case of ISOLINUX or GRUB hybrid MBR, the only goal is to hand over program execution to the El Torito boot image which is allowed to be larger and is also the starting point for booting from DVD. The connection is made by xorriso by patching the LBA of the boot image into the x86 code of the MBR. Format and byte address for this patching depends on the boot loader. Thus the mutually exclusive options -isohybrid-mbr and --grub2-mbr.
The advantage of this is not just to get rid of MBR really.
We have the room for those 440 bytes anyways if we have GPT. The magic number of GPT is the "protective" MBR partition table at bytes 446 to 509. There must be one partition slot of type 0xee and no other valid partition marked by the other three slots. The content of bytes 0 to 439 is specified by UEFI for "Protective MBR" as "Unused by UEFI systems". In contrast to that, the bytes from 440 to 445 are specified as "Unused. Set to zero." (UEFI 2.4 Table 15, UEFI 2.8 Table 19)
But if there are still some systems out there that will face plant on GPT anyway, it's probably best if they face plant when booting the installation media rather than getting all the way to a successful installation, just to face plant upon reboot.
Legacy BIOS does not care for partition tables. At least to my knowledge from supporting production of bootable ISOs. My mileage may vary. Problems with partitions will arise only after BIOS handed control to the MBR x86 code on USB stick or the El Torito boot image on DVD.
Possibly this here describes what is needed for GRUB if started by legacy BIOS and facing GPT: https://wiki.archlinux.org/title/GRUB#BIOS_systems I understand that the GPT boot partition substitutes for the traditional gap between MBR block and the start of the first MBR partition. 1 MiB of "embedded area" if i remember correctly.
But grub-mkrescue ISOs have GPT without a dedicated boot partition. Probably that job is fulfilled by the El Torito boot image which has a few more KiB than the MBR x86 code.
So i assume that face planting will happen only at later stages if the booted system makes false assumptions like "GPT means EFI".
Have a nice day :)
Thomas
On Fri, Apr 8, 2022 at 4:31 PM Thomas Schmitt scdbackup@gmx.net wrote:
Hi,
Chris Murphy wrote:
Is there a possibility of dropping MBR? i.e. use GPT containing both a biosboot partition type, and EFI System partition type?
I am not aware that legacy BIOS would hop directly on any GPT partition or any MBR partition table partition.
The convention for hard-disk-like devices is to start the x86 code in bytes 0 to 439 (or maybe to byte 445) of the MBR as 16-bit program. In case of ISOLINUX or GRUB hybrid MBR, the only goal is to hand over program execution to the El Torito boot image which is allowed to be larger and is also the starting point for booting from DVD. The connection is made by xorriso by patching the LBA of the boot image into the x86 code of the MBR. Format and byte address for this patching depends on the boot loader. Thus the mutually exclusive options -isohybrid-mbr and --grub2-mbr.
OK so there isn't (yet) an option to embed the GRUB core.img in a GPT BIOS boot partition, I take it? The assumption is MBR? On hard drives, core.img goes in the MBR gap. I'm not sure where it goes on xorriso produced ISOs though, but presumably not the gap because there's a valid GPT there too.
The advantage of this is not just to get rid of MBR really.
We have the room for those 440 bytes anyways if we have GPT. The magic number of GPT is the "protective" MBR partition table at bytes 446 to 509. There must be one partition slot of type 0xee and no other valid partition marked by the other three slots. The content of bytes 0 to 439 is specified by UEFI for "Protective MBR" as "Unused by UEFI systems". In contrast to that, the bytes from 440 to 445 are specified as "Unused. Set to zero." (UEFI 2.4 Table 15, UEFI 2.8 Table 19)
Yeah, I'm not aware off hand of any UEFI that have a problem with the first 440 bytes of LBA 0 being non-zero. I am aware though, of this tianocore bug [1] where if the active bit on that 0xEE partition is set, the GPT is considered invalid. This is now fixed in Tianocore, but it might be widespread in firmware in hardware. But the idea would be to not set this boot flag on our increasingly hypothetical future ISOs because (a) it might cause UEFI to drop to an EFI shell, if this bug is more widespread (b) we don't really want to work around buggy BIOS firmware anyway, we want them to fail here rather than later.
Pretty sure I discovered this bug when testing Fedora 35 Cloud base images, which are GPT with PMBR, and boot both BIOS and UEFI systems. There's jump code in the first 440 bytes of LBA 0, pointing to the core.img in BIOS Boot partition, and also there's an EFI system volume that UEFI firmware discover.
But if there are still some systems out there that will face plant on GPT anyway, it's probably best if they face plant when booting the installation media rather than getting all the way to a successful installation, just to face plant upon reboot.
Legacy BIOS does not care for partition tables. At least to my knowledge from supporting production of bootable ISOs. My mileage may vary. Problems with partitions will arise only after BIOS handed control to the MBR x86 code on USB stick or the El Torito boot image on DVD.
Some legacy BIOS insist on seeing certain MBR structures in LBA 0 or they face plant. This was why Fedora never proceeded with GPT by default on BIOS systems. Too many at the time didn't like the PMBR for one reason or another. I think the more common reason (?) was the single partition in the PMBR didn't have BootIndicator set, hence parted's pmbr_boot flag, which sets this bit.
Possibly this here describes what is needed for GRUB if started by legacy BIOS and facing GPT: https://wiki.archlinux.org/title/GRUB#BIOS_systems I understand that the GPT boot partition substitutes for the traditional gap between MBR block and the start of the first MBR partition. 1 MiB of "embedded area" if i remember correctly.
yeah that's what I'm calling BIOS boot partition type, it's partition type GUID is 21686148-6449-6E6F-744E-656564454649 which grub-install is looking for, and how it knows where to embed core.img. But as I understand it, the code in the first 440 bytes of LBA 0, written by grub-install as well, is just jump to the LBA for core.img. There's no code to "teach" the computer how to read the GPT and go find BIOS Boot. It's a hard coded LBA to just blindly jump to.
But grub-mkrescue ISOs have GPT without a dedicated boot partition. Probably that job is fulfilled by the El Torito boot image which has a few more KiB than the MBR x86 code.
So i assume that face planting will happen only at later stages if the booted system makes false assumptions like "GPT means EFI".
Well it's been a long time since the GPT by default attempts, so I kinda forget how they manifested, though that information is probably in this list's archive :) My vague recollection is black screen. That's it. No error, no forward progress. Maybe some systems had an underscore character in the upper left corner? Maybe? Anyway, too many people hit it and it was canned so we never did it.
If we can opt out of making a hybrid/faux MBR, and create a PMBR instead, that'd also mean there's one clear unambiguous partition map for USB sticks, which could make it easier to implement persistence.
[1] https://bugzilla.tianocore.org/show_bug.cgi?id=3474
-- Chris Murphy
Hi,
OK so there isn't (yet) an option to embed the GRUB core.img in a GPT BIOS boot partition, I take it? The assumption is MBR? On hard drives, core.img goes in the MBR gap. I'm not sure where it goes on xorriso produced ISOs though, but presumably not the gap because there's a valid GPT there too.
One could probably use core.img for booting from USB stick. But it would not obsolete the x86 code in MBR and it currently is not necessary for grub-mkrescue ISOs because eltorito.img does a job equivalent to core.img. eltorito.img is stored in the ISO 9660 filesystem as normal data file. The MBR x86 code transfers execution to it and the El Torito catalog has it as boot image for x86 legacy BIOS.
Yeah, I'm not aware off hand of any UEFI that have a problem with the first 440 bytes of LBA 0 being non-zero. I am aware though, of this tianocore bug [1] where if the active bit on that 0xEE partition is set, the GPT is considered invalid.
That's why grub-mkrescue lets xorriso produce a pure GPT with no boot/active flag at the 0xEE partition. But this lets old HP laptops refuse to boot from USB stick. A foul compromise is to add another MBR partition of type 0x00 with boot/active flag. EFI is known to ignore it, but HP legacy BIOS takes it as reason to run the MBR x86 code (which is not related to partitions).
(b) we don't really want to work around buggy BIOS firmware anyway, we want them to fail here rather than later.
That's a harsh decision but would match the purpose of this thread, indeed. If so, then producing a pure GPT instead of the current jackalope seems the way to go. grub-mkrescue will point the way or could even be the solution to go for.
I would propose to care for a mountable ISO 9660 partition, by moving the EFI boot image / EFI system partition out of the filesystem and rather appending it as extra partition. An example can be created by MKRESCUE_SED_MODE=gpt_appended with script frontend/grub-mkrescue-sed.sh out of libisoburn.) Further one would need xorrisofs option -partition_offset 16 so that a mountable GPT partition can be created which starts at 512-block address 64, i.e. after the GPT partition table data. This wastes some space because a second directory tree has to be generated additionally to the normal directory tree which will be used when booting or mounting the ISO from a DVD. The waste would not be much with Fedora Live ISOs. In 3-year-old Fedora-Workstation-Live-x86_64-31-1.9.iso the first data file is already at 2048-block address 43. That would be at most 23 * 2048 bytes for the directory records which form the file tree (43 - 16 blocks System Area - 4 blocks of Volume Descriptors). So the waste would be <= 46 KiB.
At that occasion consider to drop the HFS+ Mac boot image and the Apple Partition map which marks it for some obscure non-EFI x86 Macs. I.e. consider to remove from the current xorrisofs command the options -eltorito-alt-boot -e images/macboot.img -no-emul-boot -isohybrid-gpt-hfsplus and try to find a Mac which misses this boot image and refuses to boot but boots with the original ISO.
Some legacy BIOS insist on seeing certain MBR structures in LBA 0 or they face plant.
I only know of the buggy demand for a boot/active flag at some MBR partition. If you can name more stumble stones, i would be highly interested to learn about them.
If we can opt out of making a hybrid/faux MBR, and create a PMBR instead, that'd also mean there's one clear unambiguous partition map for USB sticks, which could make it easier to implement persistence.
A PMBR is an MBR at the start of a partition and gets activated only if the device MBR decides to do so. Sometimes there is MBR code on newly bought USB sticks which looks for a partition with boot/active flag and then chain-loads the PMBR from there. But in an EL Torito bootable ISO this makes few sense. The little hybrid MBR and the larger BIOS boot image can do everything that is needed.
A neat partition map is indeed a valuable goal. To my knowledge it can only be achieved by dropping support for the buggy legacy BIOSes which demand to see an MBR partition with boot/active flag or by dropping support for buggy EFIs which do not recognize the MBR partition type 0xEF unless a smell of GPT is on the storage device.
--------------------------------------------------------------------- Just for the fun of it i post xorriso's assessment of the jackalope boot equipment in Fedora-Workstation-Live-x86_64-31-1.9.iso :
$ xorriso -indev Fedora-Workstation-Live-x86_64-31-1.9.iso -report_el_torito plain -report_system_area plain ... El Torito catalog : 42 1 El Torito cat path : /isolinux/boot.cat El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 BIOS y none 0x0000 0x00 4 16852 El Torito boot img : 2 UEFI y none 0x0000 0x00 21716 43 El Torito boot img : 3 UEFI y none 0x0000 0x00 45520 5472 El Torito img path : 1 /isolinux/isolinux.bin El Torito img opts : 1 boot-info-table isohybrid-suitable El Torito img path : 2 /images/efiboot.img El Torito img path : 3 /images/macboot.img System area options: 0x00000202 System area summary: MBR isohybrid cyl-align-off GPT ISO image size/512 : 3768320 Partition offset : 0 MBR heads per cyl : 0 MBR secs per head : 0 MBR partition table: N Status Type Start Blocks MBR partition : 1 0x80 0x00 0 3768320 MBR partition : 2 0x00 0xef 172 21716 MBR partition : 3 0x00 0x00 21888 45520 MBR partition path : 2 /images/efiboot.img MBR partition path : 3 /images/macboot.img GPT : N Info GPT disk GUID : 892c8c3c5015534296ffb0417be2c61f GPT entry array : 2 248 overlapping GPT lba range : 64 3768256 3768319 GPT partition name : 1 490053004f00480079006200720069006400 GPT partname local : 1 ISOHybrid GPT partition GUID : 1 892c8c3c5015534296feb0417be2c61f GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 1 0x1000000000000001 GPT start and size : 1 0 3768256 GPT partition name : 2 490053004f004800790062007200690064003100 GPT partname local : 2 ISOHybrid1 GPT partition GUID : 2 892c8c3c5015534296fdb0417be2c61f GPT type GUID : 2 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 2 0x1000000000000001 GPT start and size : 2 172 21716 GPT partition path : 2 /images/efiboot.img GPT partition name : 3 490053004f004800790062007200690064003200 GPT partname local : 3 ISOHybrid2 GPT partition GUID : 3 892c8c3c5015534296fcb0417be2c61f GPT type GUID : 3 005346480000aa11aa1100306543ecac GPT partition flags: 3 0x1000000000000001 GPT start and size : 3 21888 45520 GPT partition path : 3 /images/macboot.img
Note that the MBR partition table is not "protective" by consisting only of one partition of type 0xEE. Thus the GPT is not valid, which is good so, because the EFI system partition in GPT does not show the prescribed Type GUID 28732ac11ff8d211ba4b00a0c93ec93b aka C12A7328-F81F-11D2-BA4B-00A0C93EC93B. (I wonder why this ISO does not show an Apple Partition Map. The xorrisofs options shown in this thread should have caused one.)
For comparison a grub-mkrescue ISO for BIOS and EFI:
... El Torito catalog : 1669 1 El Torito cat path : /boot.catalog El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 BIOS y none 0x0000 0x00 4 3544 El Torito boot img : 2 UEFI y none 0x0000 0x00 5760 84 El Torito img path : 1 /boot/grub/i386-pc/eltorito.img El Torito img opts : 1 boot-info-table grub2-boot-info El Torito img path : 2 /efi.img System area options: 0x00004201 System area summary: MBR protective-msdos-label grub2-mbr cyl-align-off GPT APM ISO image size/512 : 30848 Partition offset : 0 MBR heads per cyl : 64 MBR secs per head : 32 MBR partition table: N Status Type Start Blocks MBR partition : 1 0x00 0xee 1 30847 GPT : N Info GPT disk GUID : 07f29bb153383349a5ecd605dcf5ebd6 GPT entry array : 20 176 separated GPT lba range : 64 30802 30847 GPT partition name : 1 4700610070003000 GPT partname local : 1 Gap0 GPT partition GUID : 1 07f29bb153383349a5e8d605dcf5ebd6 GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 1 0x1000000000000001 GPT start and size : 1 64 272 GPT partition name : 2 450046004900200062006f006f007400200070006100720074006900740069006f006e00 GPT partname local : 2 EFI boot partition GPT partition GUID : 2 07f29bb153383349a5e9d605dcf5ebd6 GPT type GUID : 2 28732ac11ff8d211ba4b00a0c93ec93b GPT partition flags: 2 0x1000000000000001 GPT start and size : 2 336 5760 GPT partition path : 2 /efi.img GPT partition name : 3 48004600530050004c0055005300 GPT partname local : 3 HFSPLUS GPT partition GUID : 3 07f29bb153383349a5ead605dcf5ebd6 GPT type GUID : 3 005346480000aa11aa1100306543ecac GPT partition flags: 3 0x1000000000000001 GPT start and size : 3 6096 24104 GPT partition name : 4 4700610070003100 GPT partname local : 4 Gap1 GPT partition GUID : 4 07f29bb153383349a5ebd605dcf5ebd6 GPT type GUID : 4 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 4 0x1000000000000001 GPT start and size : 4 30200 600 APM : N Info APM block size : 2048 APM gap fillers : 2 APM partition name : 1 Gap0 APM partition type : 1 ISO9660_data APM start and size : 1 16 1508 APM partition name : 2 HFSPLUS_Hybrid APM partition type : 2 Apple_HFS APM start and size : 2 1524 6026 APM partition name : 3 Gap1 APM partition type : 3 ISO9660_data APM start and size : 3 7550 162
The Apple Partition Map (APM) marks the mount point of the internal HFS+ filesystem tree. If we are speaking of legacy, then this is the most obsolete part of a grub-mkrescue ISO.
A description of the above listing format is put out by a run of xorriso -report_el_torito help -report_system_area help
Have a nice day :)
Thomas
On Sat, Apr 9, 2022 at 1:51 AM Thomas Schmitt scdbackup@gmx.net wrote:
Hi,
OK so there isn't (yet) an option to embed the GRUB core.img in a GPT BIOS boot partition, I take it? The assumption is MBR? On hard drives, core.img goes in the MBR gap. I'm not sure where it goes on xorriso produced ISOs though, but presumably not the gap because there's a valid GPT there too.
One could probably use core.img for booting from USB stick. But it would not obsolete the x86 code in MBR and it currently is not necessary for grub-mkrescue ISOs because eltorito.img does a job equivalent to core.img. eltorito.img is stored in the ISO 9660 filesystem as normal data file. The MBR x86 code transfers execution to it and the El Torito catalog has it as boot image for x86 legacy BIOS.
At least with the BIOS firmware without a bug, the GRUB LBA 0 code jumps direct to core.img, no instruction on how to read the GPT and find the core.img from BIOS boot partition.
Yeah, I'm not aware off hand of any UEFI that have a problem with the first 440 bytes of LBA 0 being non-zero. I am aware though, of this tianocore bug [1] where if the active bit on that 0xEE partition is set, the GPT is considered invalid.
That's why grub-mkrescue lets xorriso produce a pure GPT with no boot/active flag at the 0xEE partition. But this lets old HP laptops refuse to boot from USB stick. A foul compromise is to add another MBR partition of type 0x00 with boot/active flag. EFI is known to ignore it, but HP legacy BIOS takes it as reason to run the MBR x86 code (which is not related to partitions).
(b) we don't really want to work around buggy BIOS firmware anyway, we want them to fail here rather than later.
That's a harsh decision but would match the purpose of this thread, indeed. If so, then producing a pure GPT instead of the current jackalope seems the way to go. grub-mkrescue will point the way or could even be the solution to go for.
Still another idea might be to create a "legacy" image variant of Everything ISO that does things exactly as we do them today. That way there is a fallback for one image that isn't release blocking, for as long as it can be maintained. The one thing I think we'd still need to tweak sooner than later is swapping isolinux with GRUB.
A legacy/fallback image (or two) would provide some breathing room to remove more legacy layers. Including possibly even ISO 9660. If Everything ISO is for that use case, desktop and server images can focus on being USB centric, including supporting persistence out of the box.
I would propose to care for a mountable ISO 9660 partition, by moving the EFI boot image / EFI system partition out of the filesystem and rather appending it as extra partition. An example can be created by MKRESCUE_SED_MODE=gpt_appended with script frontend/grub-mkrescue-sed.sh out of libisoburn.) Further one would need xorrisofs option -partition_offset 16 so that a mountable GPT partition can be created which starts at 512-block address 64, i.e. after the GPT partition table data. This wastes some space because a second directory tree has to be generated additionally to the normal directory tree which will be used when booting or mounting the ISO from a DVD. The waste would not be much with Fedora Live ISOs. In 3-year-old Fedora-Workstation-Live-x86_64-31-1.9.iso the first data file is already at 2048-block address 43. That would be at most 23 * 2048 bytes for the directory records which form the file tree (43 - 16 blocks System Area - 4 blocks of Volume Descriptors). So the waste would be <= 46 KiB.
At that occasion consider to drop the HFS+ Mac boot image and the Apple Partition map which marks it for some obscure non-EFI x86 Macs. I.e. consider to remove from the current xorrisofs command the options -eltorito-alt-boot -e images/macboot.img -no-emul-boot -isohybrid-gpt-hfsplus and try to find a Mac which misses this boot image and refuses to boot but boots with the original ISO.
I have a 2011 Mac. Virtually certain ages ago I booted an openSUSE ISO from USB stick, no problem, and it had no special tricks liks Fedora is using (HFS+ and mactel boot).
If we can opt out of making a hybrid/faux MBR, and create a PMBR instead, that'd also mean there's one clear unambiguous partition map for USB sticks, which could make it easier to implement persistence.
A PMBR is an MBR at the start of a partition and gets activated only if the device MBR decides to do so. Sometimes there is MBR code on newly bought USB sticks which looks for a partition with boot/active flag and then chain-loads the PMBR from there. But in an EL Torito bootable ISO this makes few sense. The little hybrid MBR and the larger BIOS boot image can do everything that is needed.
A neat partition map is indeed a valuable goal. To my knowledge it can only be achieved by dropping support for the buggy legacy BIOSes which demand to see an MBR partition with boot/active flag or by dropping support for buggy EFIs which do not recognize the MBR partition type 0xEF unless a smell of GPT is on the storage device.
Just for the fun of it i post xorriso's assessment of the jackalope boot equipment in Fedora-Workstation-Live-x86_64-31-1.9.iso :
$ xorriso -indev Fedora-Workstation-Live-x86_64-31-1.9.iso -report_el_torito plain -report_system_area plain ... El Torito catalog : 42 1 El Torito cat path : /isolinux/boot.cat El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 BIOS y none 0x0000 0x00 4 16852 El Torito boot img : 2 UEFI y none 0x0000 0x00 21716 43 El Torito boot img : 3 UEFI y none 0x0000 0x00 45520 5472 El Torito img path : 1 /isolinux/isolinux.bin El Torito img opts : 1 boot-info-table isohybrid-suitable El Torito img path : 2 /images/efiboot.img El Torito img path : 3 /images/macboot.img System area options: 0x00000202 System area summary: MBR isohybrid cyl-align-off GPT ISO image size/512 : 3768320 Partition offset : 0 MBR heads per cyl : 0 MBR secs per head : 0 MBR partition table: N Status Type Start Blocks MBR partition : 1 0x80 0x00 0 3768320 MBR partition : 2 0x00 0xef 172 21716 MBR partition : 3 0x00 0x00 21888 45520 MBR partition path : 2 /images/efiboot.img MBR partition path : 3 /images/macboot.img GPT : N Info GPT disk GUID : 892c8c3c5015534296ffb0417be2c61f GPT entry array : 2 248 overlapping GPT lba range : 64 3768256 3768319 GPT partition name : 1 490053004f00480079006200720069006400 GPT partname local : 1 ISOHybrid GPT partition GUID : 1 892c8c3c5015534296feb0417be2c61f GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 1 0x1000000000000001 GPT start and size : 1 0 3768256 GPT partition name : 2 490053004f004800790062007200690064003100 GPT partname local : 2 ISOHybrid1 GPT partition GUID : 2 892c8c3c5015534296fdb0417be2c61f GPT type GUID : 2 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 2 0x1000000000000001 GPT start and size : 2 172 21716 GPT partition path : 2 /images/efiboot.img GPT partition name : 3 490053004f004800790062007200690064003200 GPT partname local : 3 ISOHybrid2 GPT partition GUID : 3 892c8c3c5015534296fcb0417be2c61f GPT type GUID : 3 005346480000aa11aa1100306543ecac GPT partition flags: 3 0x1000000000000001 GPT start and size : 3 21888 45520 GPT partition path : 3 /images/macboot.img
Note that the MBR partition table is not "protective" by consisting only of one partition of type 0xEE. Thus the GPT is not valid, which is good so, because the EFI system partition in GPT does not show the prescribed Type GUID 28732ac11ff8d211ba4b00a0c93ec93b aka C12A7328-F81F-11D2-BA4B-00A0C93EC93B. (I wonder why this ISO does not show an Apple Partition Map. The xorrisofs options shown in this thread should have caused one.)
I noticed the APM seemed to go away at one point - I'm not sure when. I thought the command had changed but maybe there's a conflict with one of the other commands now?
For comparison a grub-mkrescue ISO for BIOS and EFI:
... El Torito catalog : 1669 1 El Torito cat path : /boot.catalog El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 BIOS y none 0x0000 0x00 4 3544 El Torito boot img : 2 UEFI y none 0x0000 0x00 5760 84 El Torito img path : 1 /boot/grub/i386-pc/eltorito.img El Torito img opts : 1 boot-info-table grub2-boot-info El Torito img path : 2 /efi.img System area options: 0x00004201 System area summary: MBR protective-msdos-label grub2-mbr cyl-align-off GPT APM ISO image size/512 : 30848 Partition offset : 0 MBR heads per cyl : 64 MBR secs per head : 32 MBR partition table: N Status Type Start Blocks MBR partition : 1 0x00 0xee 1 30847 GPT : N Info GPT disk GUID : 07f29bb153383349a5ecd605dcf5ebd6 GPT entry array : 20 176 separated GPT lba range : 64 30802 30847 GPT partition name : 1 4700610070003000 GPT partname local : 1 Gap0 GPT partition GUID : 1 07f29bb153383349a5e8d605dcf5ebd6 GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 1 0x1000000000000001 GPT start and size : 1 64 272 GPT partition name : 2 450046004900200062006f006f007400200070006100720074006900740069006f006e00 GPT partname local : 2 EFI boot partition GPT partition GUID : 2 07f29bb153383349a5e9d605dcf5ebd6 GPT type GUID : 2 28732ac11ff8d211ba4b00a0c93ec93b GPT partition flags: 2 0x1000000000000001 GPT start and size : 2 336 5760 GPT partition path : 2 /efi.img GPT partition name : 3 48004600530050004c0055005300 GPT partname local : 3 HFSPLUS GPT partition GUID : 3 07f29bb153383349a5ead605dcf5ebd6 GPT type GUID : 3 005346480000aa11aa1100306543ecac GPT partition flags: 3 0x1000000000000001 GPT start and size : 3 6096 24104 GPT partition name : 4 4700610070003100 GPT partname local : 4 Gap1 GPT partition GUID : 4 07f29bb153383349a5ebd605dcf5ebd6 GPT type GUID : 4 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 4 0x1000000000000001 GPT start and size : 4 30200 600 APM : N Info APM block size : 2048 APM gap fillers : 2 APM partition name : 1 Gap0 APM partition type : 1 ISO9660_data APM start and size : 1 16 1508 APM partition name : 2 HFSPLUS_Hybrid APM partition type : 2 Apple_HFS APM start and size : 2 1524 6026 APM partition name : 3 Gap1 APM partition type : 3 ISO9660_data APM start and size : 3 7550 162
The Apple Partition Map (APM) marks the mount point of the internal HFS+ filesystem tree. If we are speaking of legacy, then this is the most obsolete part of a grub-mkrescue ISO.
I'm pretty sure we don't need either APM or HFS+ stuff for mac support anymore. But all the more reason to make an "older models" best effort.
Hi,
Chris Murphy wrote:
At least with the BIOS firmware without a bug, the GRUB LBA 0 code jumps direct to core.img, no instruction on how to read the GPT and find the core.img from BIOS boot partition.
That's probably because the GRUB MBR code for hard disk gets the LBA of the next stage patched in at install time.
xorrisofs does the equivalent to the boot_hybrid.img MBR from GRUB:
--grub2-mbr disk_path Install disk_path in the System Area and treat it as modern GRUB2 MBR. The content start address of the first boot image is converted to a count of 512 byte blocks, and an offset of 4 is added. The result is written as 64 bit little-endian number to byte address 0x1b0.
"Install in the System Area" means "Copy it to the start of the ISO image". "first boot image" means the one that is pointed to by first entry in the El Torito catalog, which is supposed to be the GRUB boot image for El Torito. GRUB docs say that this image gets concatenated from "cdrom.img" and a suitably built "core.img".
Still another idea might be to create a "legacy" image variant of Everything ISO that does things exactly as we do them today.
This would be handy at least during the first months of a new ISO image layout being used. Any user complaint could be checked whether the problem was introduced by the ISO image change.
A legacy/fallback image (or two) would provide some breathing room to remove more legacy layers. Including possibly even ISO 9660.
Aww. 14 years of xorriso development would be obsoleted. {:|
Giving up ISO 9660 would mean to give up El Torito, which means to give up legacy BIOS booting from CD/DVD/BD. With UEFI i am not so sure about the consequences. OVMF is known to boot via partition table from qemu -cdrom devices and via El Torito from -hda. Whether other EFIs do the same would have to be broadly tested.
UEFI 2.8 Errata A, February 2020 still has the prescription for EFI to follow the El Torito boot catalog when it encounters an optical drive with medium:
10.3.5.2 CD-ROM Media Device Path The CD-ROM Media Device Path is used to define a system partition that exists on a CD-ROM. The CD-ROM is assumed to contain an ISO-9660 file system and follow the CD-ROM “El Torito” format. [...] In EFI the bootable entity is an EFI System Partition that is pointed to by the Boot Entry.
10.4.5 Media Device Path Rules The Media Device Path is used to define the location of information on a medium. Hard Drives are subdivided into partitions by the MBR and a Media Device Path is used to define which partition is being used. A CD-ROM has boot partitions that are defined by the “El Torito” specification, and the Media Device Path is used to point to these partitions.
(Somebody at UEFI should look at the statement "subdivided into partitions by the MBR" whether this needs mentioning of GPT.)
EFI was not invented when El Torito was specified. Thus UEFI extends the original El Torito specs by
13.3.2.1 ISO-9660 and El Torito [...] To boot from a CD-ROM or DVD-ROM in the boot services environment, an EFI System partition is stored in a “no emulation” mode as defined by the “El Torito” specification. A Platform ID of 0xEF indicates an EFI System Partition. EFI differs from “El Torito” “no emulation” mode in that it does not load the “no emulation” image into memory and jump to it. EFI interprets the “no emulation” image as an EFI system partition. [... more technicalities follow ...]
The one thing I think we'd still need to tweak sooner than later is swapping isolinux with GRUB.
I am optimistic that this will be possible with few new user complaints.
Summary as i understand this part of our discussion:
Fedora just has to decide whether it wants to stay with the layout described in https://mjg59.dreamwidth.org/11285.html or whether it wants to migrate to a specs compliant GPT as i propose in https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... Date: Sun, 10 Apr 2022 00:29:54 +0200 Message-Id: 28174385295326549884@scdbackup.webframe.org
In the latter case the xorrisofs options to change are given in the above list post. It would drop support for an obscure class of x86 Macs which need HFS+ for booting, and it would drop support for a class of buggy legacy BIOSes which don't boot if the boot/active isn't set in any MBR partition table slot. (Old HP laptops have been caught with such BIOS.)
In the former case my change proposal is in https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... Date: Fri, 08 Apr 2022 20:29:07 +0200 Message-Id: 25501385177039509423@scdbackup.webframe.org Please read the first part up to "More unsolicited info:" to see all proposed options.
I am ready to discuss xorriso-specific problems at bug-xorriso@gnu.org or in private, if not here. Cc me when starting a discussion here.
Have a nice day :)
Thomas
On Mon, Apr 11, 2022 at 4:36 AM Thomas Schmitt scdbackup@gmx.net wrote:
A legacy/fallback image (or two) would provide some breathing room to remove more legacy layers. Including possibly even ISO 9660.
Aww. 14 years of xorriso development would be obsoleted. {:|
Giving up ISO 9660 would mean to give up El Torito, which means to give up legacy BIOS booting from CD/DVD/BD.
It's a fair point that this proposal is not considering ISO 9660 a legacy or deprecated format. That's my editorialization. But all good things come to an end? Long live ISO 9660? :D Consider millions of user's lives were made a ton easier because we have had these remarkably clever universal boot images for so long that can boot almost anything.
The legacy/fallback image(s) would definitely include ISO 9660 support, using xorriso essentially as we are now if not exactly as it is now, and support it as long as it can be supported by the future Legacy BIOS Booting SIG. It'd be up to the SIG to decide whether ISO 9660 is eventually dropped, if ever.
But as long as the SIG and its work products are being produced reliably, and at least one image is release blocking - that gives quite a lot of room to drop ISO 9660 on other images *if* there's a clear advantage of doing so. That's all I meant to indicate.
The one thing I think we'd still need to tweak sooner than later is swapping isolinux with GRUB.
I am optimistic that this will be possible with few new user complaints.
OK super.
Summary as i understand this part of our discussion:
Fedora just has to decide whether it wants to stay with the layout described in https://mjg59.dreamwidth.org/11285.html or whether it wants to migrate to a specs compliant GPT as i propose in https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... Date: Sun, 10 Apr 2022 00:29:54 +0200 Message-Id: 28174385295326549884@scdbackup.webframe.org
In the latter case the xorrisofs options to change are given in the above list post. It would drop support for an obscure class of x86 Macs which need HFS+ for booting, and it would drop support for a class of buggy legacy BIOSes which don't boot if the boot/active isn't set in any MBR partition table slot. (Old HP laptops have been caught with such BIOS.)
In the former case my change proposal is in https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... Date: Fri, 08 Apr 2022 20:29:07 +0200 Message-Id: 25501385177039509423@scdbackup.webframe.org Please read the first part up to "More unsolicited info:" to see all proposed options.
I am ready to discuss xorriso-specific problems at bug-xorriso@gnu.org or in private, if not here. Cc me when starting a discussion here.
OK great thanks for all the input!
-- Chris Murphy
On 4/9/22 03:07, Chris Murphy wrote:
On Fri, Apr 8, 2022 at 4:31 PM Thomas Schmitt scdbackup@gmx.net wrote:
Yeah, I'm not aware off hand of any UEFI that have a problem with the first 440 bytes of LBA 0 being non-zero.
If they did, then they would have problems with GPT disks, initialized by Windows 10, because Windows 10 puts its standard non-GPT aware bootloader code there. :)
Only Fedora-initialized disks have zeros there. :)
I can confirm this, because I have three disks (two 512GB SSDs and one 2TB HDD) on my UEFI-enabled, dual booting between Windows 11 and Fedora, desktop computer.
I am aware though, of this tianocore bug [1] where if the active bit on that 0xEE partition is set, the GPT is considered invalid. This is now fixed in Tianocore, but it might be widespread in firmware in hardware. But the idea would be to not set this boot flag on our increasingly hypothetical future ISOs because (a) it might cause UEFI to drop to an EFI shell, if this bug is more widespread (b) we don't really want to work around buggy BIOS firmware anyway, we want them to fail here rather than later.
Pretty sure I discovered this bug when testing Fedora 35 Cloud base images, which are GPT with PMBR, and boot both BIOS and UEFI systems. There's jump code in the first 440 bytes of LBA 0, pointing to the core.img in BIOS Boot partition, and also there's an EFI system volume that UEFI firmware discover.
But if there are still some systems out there that will face plant on GPT anyway, it's probably best if they face plant when booting the installation media rather than getting all the way to a successful installation, just to face plant upon reboot.
Legacy BIOS does not care for partition tables. At least to my knowledge from supporting production of bootable ISOs. My mileage may vary. Problems with partitions will arise only after BIOS handed control to the MBR x86 code on USB stick or the El Torito boot image on DVD.
Some legacy BIOS insist on seeing certain MBR structures in LBA 0 or they face plant. This was why Fedora never proceeded with GPT by default on BIOS systems. Too many at the time didn't like the PMBR for one reason or another. I think the more common reason (?) was the single partition in the PMBR didn't have BootIndicator set, hence parted's pmbr_boot flag, which sets this bit.
Possibly this here describes what is needed for GRUB if started by legacy BIOS and facing GPT: https://wiki.archlinux.org/title/GRUB#BIOS_systems I understand that the GPT boot partition substitutes for the traditional gap between MBR block and the start of the first MBR partition. 1 MiB of "embedded area" if i remember correctly.
yeah that's what I'm calling BIOS boot partition type, it's partition type GUID is 21686148-6449-6E6F-744E-656564454649 which grub-install is looking for, and how it knows where to embed core.img. But as I understand it, the code in the first 440 bytes of LBA 0, written by grub-install as well, is just jump to the LBA for core.img. There's no code to "teach" the computer how to read the GPT and go find BIOS Boot. It's a hard coded LBA to just blindly jump to.
I haven't looked at GRUB's MBR code, but there's enough space in the MBR to scan the GPT entries, find a specific GUID partition type and load the first several kilobytes from it and transfer control to it. And this is even without assuming 512-byte sectors. I know this, because I have written such code for my hobby DOS-like OS, which I want to be able to support GPT in BIOS legacy mode, so it can coexist with modern Windows and Linux distros (which boot in UEFI mode, while my OS boots in legacy mode - I can switch between the two modes from my UEFI boot menu).
Here's the code I've written (consider it proof of concept), but it can be used by GRUB as well:
https://sourceforge.net/p/fpcdos/code/HEAD/tree/trunk/src/gptboot/mbr.asm
The code takes up only 262 bytes so far, so it has plenty of bytes to spare (for e.g. nicer diagnostic error messages). The only thing it assumes is that the INT 13h LBA BIOS extensions are available - there's no CHS fallback support.
The code *doesn't* assume that the sectors size is 512 bytes, it doesn't assume the GPT partition it is looking for is in a specific position in the table, or starting on a specific LBA, it doesn't assume the number of GPT partitions are less than 128, it doesn't assume that GUID partition entries are 128-byte sized and it doesn't care about the 4 MBR partitions at all, it only searches through the GPT partitions.
The code assumes that the GPT partition table is correct, and doesn't do a lot of error checking, e.g. it doesn't check the CRC32 fields in the GPT header.
But grub-mkrescue ISOs have GPT without a dedicated boot partition. Probably that job is fulfilled by the El Torito boot image which has a few more KiB than the MBR x86 code.
So i assume that face planting will happen only at later stages if the booted system makes false assumptions like "GPT means EFI".
Well it's been a long time since the GPT by default attempts, so I kinda forget how they manifested, though that information is probably in this list's archive :) My vague recollection is black screen. That's it. No error, no forward progress. Maybe some systems had an underscore character in the upper left corner? Maybe? Anyway, too many people hit it and it was canned so we never did it.
If we can opt out of making a hybrid/faux MBR, and create a PMBR instead, that'd also mean there's one clear unambiguous partition map for USB sticks, which could make it easier to implement persistence.
[1] https://bugzilla.tianocore.org/show_bug.cgi?id=3474
-- Chris Murphy _______________________________________________ devel mailing list -- devel@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
Hi,
Nikolay Nikolov wrote:
I haven't looked at GRUB's MBR code, but there's enough space in the MBR to scan the GPT entries, find a specific GUID partition type and load the first several kilobytes from it and transfer control to it.
Well, GRUB goes a different way on legacy BIOS. It boots its core code without knowing about partitions and then loads the modules which its configuration expects to need. I understand GPT is handled by "part_gpt" and MBR partitions by "part_msdos".
The code takes up only 262 bytes so far
It is astounding what can be squeezed into 440 bytes of x86 machine code.
-----------------------------------------------------------------------
I meanwhile learned that the El Torito boot image eltorito.img used by grub-mkrescue is not a plain copy of cdboot.img but rather a concatenation of cdboot.img and a core.img :
https://www.gnu.org/software/grub/manual/grub/grub.html#Making-a-GRUB-bootab... "For booting from a CD-ROM, GRUB uses a special image called cdboot.img, which is concatenated with core.img. The core.img used for this should be built with at least the ‘iso9660’ and ‘biosdisk’ modules."
So the role of the BIOS partition is properly fulfilled by the El Torito boot image which has 27874 bytes in my example ISO from grub-mkrescue.
Have a nice day :)
Thomas
Hi,
this is what i propose as boot layout of an entirely GRUB based ISO which boots on EFI and not-so-buggy legacy BIOS from USB stick and DVD:
------------------------------------------------------------------------
$ xorriso -indev grub_mkrescue_gpt_appended.iso -report_el_torito plain -report_system_area plain ... El Torito catalog : 165 1 El Torito cat path : /boot.catalog El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 BIOS y none 0x0000 0x00 4 2040 El Torito boot img : 2 UEFI y none 0x0000 0x00 5760 6043 El Torito img path : 1 /boot/grub/i386-pc/eltorito.img El Torito img opts : 1 boot-info-table grub2-boot-info El Torito img blks : 2 1440 System area options: 0x00004201 System area summary: MBR protective-msdos-label grub2-mbr cyl-align-off GPT ISO image size/512 : 29996 Partition offset : 16 MBR heads per cyl : 64 MBR secs per head : 32 MBR partition table: N Status Type Start Blocks MBR partition : 1 0x00 0xee 1 29995 GPT : N Info GPT disk GUID : e59ea280058a754fb57833ebe50cd3e0 GPT entry array : 2 248 separated GPT lba range : 64 29932 29995 GPT partition name : 1 490053004f003900360036003000 GPT partname local : 1 ISO9660 GPT partition GUID : 1 e59ea280058a754fb57933ebe50cd3e0 GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 1 0x1000000000000001 GPT start and size : 1 64 24108 GPT partition name : 2 41007000700065006e006400650064003200 GPT partname local : 2 Appended2 GPT partition GUID : 2 e59ea280058a754fb57a33ebe50cd3e0 GPT type GUID : 2 28732ac11ff8d211ba4b00a0c93ec93b GPT partition flags: 2 0x0000000000000000 GPT start and size : 2 24172 5760
------------------------------------------------------------------------
$ /sbin/fdisk -l grub_mkrescue_gpt_appended.iso
Disk grub_mkrescue_gpt_appended.iso: 14.7 MiB, 15357952 bytes, 29996 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 80A29EE5-8A05-4F75-B578-33EBE50CD3E0
Device Start End Sectors Size Type grub_mkrescue_gpt_appended.iso1 64 24171 24108 11.8M Microsoft basic data grub_mkrescue_gpt_appended.iso2 24172 29931 5760 2.8M EFI System
------------------------------------------------------------------------
xorrisofs (minimum version 1.5.2) options would be:
--grub2-mbr /usr/lib/grub/i386-pc/boot_hybrid.img -partition_offset 16 -appended_part_as_gpt -append_partition 2 C12A7328-F81F-11D2-BA4B-00A0C93EC93B /...diskpath.../efiboot.img -iso_mbr_part_type EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 -c /boot/grub/boot.cat -b /boot/grub/i386-pc/eltorito.img -no-emul-boot -boot-load-size 4 -boot-info-table --grub2-boot-info -eltorito-alt-boot -e '--interval:appended_partition_2:all::' -no-emul-boot
They would replace these options from the current xorriso command with Live ISOs as quoted by Chris Murphy:
-isohybrid-mbr /usr/share/syslinux/isohdpfx.bin -b isolinux/isolinux.bin -c isolinux/boot.cat -boot-load-size 4 -boot-info-table -no-emul-boot -eltorito-alt-boot -e images/efiboot.img -no-emul-boot -isohybrid-gpt-basdat -eltorito-alt-boot -e images/macboot.img -no-emul-boot -isohybrid-gpt-hfsplus
The file efiboot.img should not be in the ISO 9660 filesystem.
Similar to the old /isolinux/isolinux.bin ione has to bring a GRUB El Torito BIOS image as /boot/grub/i386-pc/eltorito.img into the ISO 9660 filesystem, so that option -b finds it. (eltorito.img gets made by grub-mkimage. But i am quite sure one can simply grab it from a grub-mkrescue ISO of the same GRUB version as used inside efiboot.img. Maybe one needs to move GRUB configuration lines out of a grub.conf in efiboot.img to a grub.conf in the ISO 9660 filesystem, so that both boot paths can use them.)
Support would vanish for old pre-EFI Macs and for buggy legacy BIOS which demands to see a boot/active flag in some MBR partition slot if the ISO is presented on a USB stick.
The benefit iwould be to have a neat GPT instead of the current MBR partition table with the mockup of a GPT and with the EFI partition sitting inside the ISO 9660 partition.
Have a nice day :)
Thomas
On 4/10/22 00:30, Thomas Schmitt wrote:
Hi,
Nikolay Nikolov wrote:
I haven't looked at GRUB's MBR code, but there's enough space in the MBR to scan the GPT entries, find a specific GUID partition type and load the first several kilobytes from it and transfer control to it.
Well, GRUB goes a different way on legacy BIOS. It boots its core code without knowing about partitions and then loads the modules which its configuration expects to need. I understand GPT is handled by "part_gpt" and MBR partitions by "part_msdos".
The code takes up only 262 bytes so far
It is astounding what can be squeezed into 440 bytes of x86 machine code.
Maybe I should try adapting my code, so that it finds the GRUB BIOS boot partition and loads it? It shouldn't be too hard to do, the main obstacle is that I'm not familiar with GRUB's code and I don't know what GRUB's next stage needs (i.e. at what address it should be loaded, and how it should be called). But regarding size, core.img is apparently less than 32 kb, and it fits between the MBR and the first partition on MBR systems, and my code already loads almost 64kb from a GPT partition, so even if the next GRUB stage needs some special requirements (like moving to a different address, enabling gate A20, entering protected mode, etc), it can be done at least with a wrapper, but perhaps also even in the remaining bytes of my MBR code.
I meanwhile learned that the El Torito boot image eltorito.img used by grub-mkrescue is not a plain copy of cdboot.img but rather a concatenation of cdboot.img and a core.img :
https://www.gnu.org/software/grub/manual/grub/grub.html#Making-a-GRUB-bootab... "For booting from a CD-ROM, GRUB uses a special image called cdboot.img, which is concatenated with core.img. The core.img used for this should be built with at least the ‘iso9660’ and ‘biosdisk’ modules."
So the role of the BIOS partition is properly fulfilled by the El Torito boot image which has 27874 bytes in my example ISO from grub-mkrescue.
Unfortunately, I'm not familiar with how El Torito works, I only understand the legacy PC boot process from floppy/hard disk/USB flash drive, but not from optical media. This hybrid USB stick/DVD iso image has always seemed like black magic to me :) And we've been spoiled and expect it to work, but I think it doesn't work with Windows 10, for example. :) AFAIK, Windows only provides an ISO download, that is suitable for burning on optical media and then it boots, but it doesn't work, when you "dd" it to an USB flash drive. I think you need to use special tool, to write it to a USB stick, but I've never done it, I still burn DVD+R for Windows installs :) And what's worse, they now require the rarer and more expensive DVD+R DL discs, since their install image exceeds 4.7 GB :)
Have a nice day :)
Thomas _______________________________________________ devel mailing list -- devel@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
Hi,
Nikolay Nikolov wrote:
Maybe I should try adapting my code, so that it finds the GRUB BIOS boot partition and loads it?
This would be a nice stunt for which we would have to find a use case. As stated yesterday, the GRUB El Torito image contains a core.img which serves the same purpose as a BIOS partition.
the main obstacle is that I'm not familiar with GRUB's code and I don't know what GRUB's next stage needs
I myself only learn about GRUB at occasions like this here. There is a vivid community at grub-devel@gnu.org. If you have an interesting use case they might be willing to explain things. But on the other hand the BIOS stuff is old and Vladimir Serbinenko, who created it, is not very busy with GRUB any more.
Unfortunately, I'm not familiar with how El Torito works,
Roughly:
At 2048-byte-LBA 17 (decimal) there is the Boot Record, which points to the El Torito Boot Catalog. The catalog contains entries, which describe boot images. In case of Fedora Live there are three of them: One for BIOS, and two for EFI.
The boot image for BIOS is a plain x86 program. The first EFI image is a FAT filesystem with boot programs /EFI/BOOT/BOOT*.EFI for the intended processor architectures (x86-32bit, x86-64bit, ARM-32bit, ... ).
The second boot image for EFI (macboot.img) is actually a HFS+ filesystem image which should not be listed in the catalog. That's a hack by Matthew J. Garrett to let the rather dumb ISOLINUX program isohybrid.c find the HFS+ image and mark it by an Apple Partition Map. isohybrid.c does not understand ISO 9660 but it knows the El Torito boot catalog. Fedora does not use isohybrid.c any more, but rather lets libisofs under xorriso create the Apple Partition Map, if at all. Nevertheless, xorriso produces the same inappropriate catalog entry for EFI, which the firmware ignores in favor of the appropriate EFI boot image. (Who am i to change mjg's invention ?)
My knowledge about boot lures for various processors and firmwares is compiled at https://dev.lovelyhq.com/libburnia/libisofs/raw/branch/master/doc/boot_secto...
Original specs:
El Torito: http://web.archive.org/web/20010706014919/http://www.ibm.com/products/surepa... UEFI: https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf Legacy BIOS: Only rumors around. Start exploring at Wikipedia. Re-use your knowledge about BIOS booting from floppy/hard disk/USB flash drive.
This hybrid USB stick/DVD iso image has always seemed like black magic to me :)
It's just a matter of outmost cramming of boot lures which are barely compatible. (The unusual block size 2048 for Apple Partition Map gives room for GPT. Some noop-x86 code at the start of the MBR lets it look like the first block of an Apple Partition Map. It's just weird from the view of specs and BIOS tradition. But it works since 10 years.)
AFAIK, Windows only provides an ISO download, that is suitable for burning on optical media and then it boots, but it doesn't work, when you "dd" it to an USB flash drive. I think you need to use special tool, to write it to a USB stick,
You are supposed to create a FAT filesystem in a MBR partition of the USB stick with a traditional partition type like 0x0C. Then you copy all files from the ISO 9660 filesystem into that FAT filesystem. Et voila: An undocumented property of EFI implementations will find and start /EFI/BOOT/BOOT*.EFI to boot MS-Windows. (M$-Knowledge gained from Pete Batard, developer of program Rufus.)
Interestingly, Fedora Live ISOs have a /EFI/BOOT/ tree in the ISO 9660 filesystem, probably to support this feature. I learned about it from Pete Batard's protests when Ubuntu began to produce ISOs which omitted this copy of the EFI System Partition FAT content.
And what's worse, they now require the rarer and more expensive DVD+R DL discs, since their install image exceeds 4.7 GB :)
Consider to invest in a Blu-ray burner. Single layer BD-R and BD-RE are much more reliable than DVD+R DL and meanwhile at least BD-R are cheaper than DVD+R DL. BD-RE cost about the same as DVD+RW with more than 5 times the storage capacity. Still cheaper than 16 GB USB sticks.
Have a nice day :)
Thomas
On 4/10/22 09:56, Thomas Schmitt wrote:
Hi,
Nikolay Nikolov wrote:
Maybe I should try adapting my code, so that it finds the GRUB BIOS boot partition and loads it?
This would be a nice stunt for which we would have to find a use case. As stated yesterday, the GRUB El Torito image contains a core.img which serves the same purpose as a BIOS partition.
The use case I'm thinking about is not for the install image, but for hard disk installations in legacy BIOS mode, that use the GPT partition scheme, instead of the MBR partition scheme. In this case, with my MBR bootloader code, you still need the extra GRUB BIOS boot partition, but it can be moved anywhere on the disk, without breaking the bootloader. In the case of the traditional GRUB MBR code, you would need to boot from a rescue media and reinstall the bootloader, every time this partition is moved (or partition tools should treat it as unmovable, which reduces your flexibility). The disadvantage of my MBR boot code is that it doesn't support really old systems without the INT 13h LBA extensions. And you cannot detect in the distro installer whether the system supports these extensions or not, so if it's installed by default, some old systems would be rendered unbootable. In theory, anything that supports x86_64 should support these extensions (they were introduced in the Windows 95/98 times, when hard drives started hitting the 8 GB mark, while x86_64 appeared much later, in 2003, at the time hard drives were hitting 160GB-200GB as far as I can remember, and the 8 GB limit was becoming a joke), however I don't know what's the reality, BIOSes are surprisingly buggy.
the main obstacle is that I'm not familiar with GRUB's code and I don't know what GRUB's next stage needs
I myself only learn about GRUB at occasions like this here. There is a vivid community at grub-devel@gnu.org. If you have an interesting use case they might be willing to explain things. But on the other hand the BIOS stuff is old and Vladimir Serbinenko, who created it, is not very busy with GRUB any more.
Yeah, I'll join that mailing list and explain the use case I have in mind (the one that I described above).
Unfortunately, I'm not familiar with how El Torito works,
Roughly:
At 2048-byte-LBA 17 (decimal) there is the Boot Record, which points to the El Torito Boot Catalog. The catalog contains entries, which describe boot images. In case of Fedora Live there are three of them: One for BIOS, and two for EFI.
The boot image for BIOS is a plain x86 program. The first EFI image is a FAT filesystem with boot programs /EFI/BOOT/BOOT*.EFI for the intended processor architectures (x86-32bit, x86-64bit, ARM-32bit, ... ).
The second boot image for EFI (macboot.img) is actually a HFS+ filesystem image which should not be listed in the catalog. That's a hack by Matthew J. Garrett to let the rather dumb ISOLINUX program isohybrid.c find the HFS+ image and mark it by an Apple Partition Map. isohybrid.c does not understand ISO 9660 but it knows the El Torito boot catalog. Fedora does not use isohybrid.c any more, but rather lets libisofs under xorriso create the Apple Partition Map, if at all. Nevertheless, xorriso produces the same inappropriate catalog entry for EFI, which the firmware ignores in favor of the appropriate EFI boot image. (Who am i to change mjg's invention ?)
My knowledge about boot lures for various processors and firmwares is compiled at https://dev.lovelyhq.com/libburnia/libisofs/raw/branch/master/doc/boot_secto...
Original specs:
El Torito: http://web.archive.org/web/20010706014919/http://www.ibm.com/products/surepa... UEFI: https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf Legacy BIOS: Only rumors around. Start exploring at Wikipedia. Re-use your knowledge about BIOS booting from floppy/hard disk/USB flash drive.
Thanks for the explanation and the links. I'll check them out.
This hybrid USB stick/DVD iso image has always seemed like black magic to me :)
It's just a matter of outmost cramming of boot lures which are barely compatible. (The unusual block size 2048 for Apple Partition Map gives room for GPT. Some noop-x86 code at the start of the MBR lets it look like the first block of an Apple Partition Map. It's just weird from the view of specs and BIOS tradition. But it works since 10 years.)
I imagine it is like those polyglot programs, that are simultaneously valid in several totally different programming languages:
https://en.wikipedia.org/wiki/Polyglot_(computing)
AFAIK, Windows only provides an ISO download, that is suitable for burning on optical media and then it boots, but it doesn't work, when you "dd" it to an USB flash drive. I think you need to use special tool, to write it to a USB stick,
You are supposed to create a FAT filesystem in a MBR partition of the USB stick with a traditional partition type like 0x0C. Then you copy all files from the ISO 9660 filesystem into that FAT filesystem. Et voila: An undocumented property of EFI implementations will find and start /EFI/BOOT/BOOT*.EFI to boot MS-Windows. (M$-Knowledge gained from Pete Batard, developer of program Rufus.)
Interestingly, Fedora Live ISOs have a /EFI/BOOT/ tree in the ISO 9660 filesystem, probably to support this feature. I learned about it from Pete Batard's protests when Ubuntu began to produce ISOs which omitted this copy of the EFI System Partition FAT content.
Interesting and weird, like all things, related to the PC booting process :)
And what's worse, they now require the rarer and more expensive DVD+R DL discs, since their install image exceeds 4.7 GB :)
Consider to invest in a Blu-ray burner. Single layer BD-R and BD-RE are much more reliable than DVD+R DL and meanwhile at least BD-R are cheaper than DVD+R DL. BD-RE cost about the same as DVD+RW with more than 5 times the storage capacity. Still cheaper than 16 GB USB sticks.
Actually, I have already invested in a Blu-ray burner, I just haven't purchased any BD-R or BD-RE install media, so I haven't even tested the Blu-ray burning :) BD-R is hard to find and more expensive than DVD-R/DVD+R here, so I should order online. The other reason I'm using DVD+R DL is compatibility, not all computers have a Blu-ray drive. I have only one on my desktop, while all virtually all my laptops that have an optical drive can read DVD (and for the ones that don't have an optical drive, I have an external USB DVD drive). I guess, I should also invest in an external USB Blu-ray drive, but it's not a high priority purchase for me. :)
Have a nice day :)
Thomas _______________________________________________ devel mailing list -- devel@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
Hi,
Nikolay Nikolov wrote:
I imagine it is like those polyglot programs, that are simultaneously valid in several totally different programming languages:
Yep. A boot-everywhere ISO for x86 is quite like that. Every firmware variant can see in it what it expects.
Actually, I have already invested in a Blu-ray burner, I just haven't purchased any BD-R or BD-RE install media, so I haven't even tested the Blu-ray burning :)
Then it's about time. :)) I propose to backup a few GiB of your favorite data by xorriso and update that backup daily until the medium is full. See in https://www.gnu.org/software/xorriso/ the example "The following command performs incremental backup."
(I apologize to the list for this off-topic advertising of my program.)
Have a nice day :)
Thomas
On Thu, Apr 7, 2022, 19:46 Samuel Sieb samuel@sieb.net wrote:
On 4/7/22 14:51, Jared Dominguez wrote:
On Thu, Apr 7, 2022 at 3:49 PM Samuel Sieb <samuel@sieb.net mailto:samuel@sieb.net> wrote:
On 4/7/22 08:02, Jared Dominguez wrote: > This is a proposal. Nothing has changed yet. The choice is now whether > to go forward with it or come together with a cohesive > alternative, including one of the two listed in the proposal. Butwe
> need a solution that accounts for the existing maintainers not having > capacity to continue maintaining legacy code. I've seen responses from I haven't yet seen a clear answer about what code is "rotting" and which legacy code is too hard to maintain. Is there something actually broken right now?For one, syslinux hasn't seen an update in 3 years and a release in 7 years, and it has outstanding bugs. Legacy boot isn't where grub2 is getting development attention. The current maintainers in Fedora won't have capacity to continue maintaining legacy boot support in Fedora. As grub2 continues to be developed for UEFI systems (ARMv8-9 and x86-64, not to mention non-UEFI ppc64le and s390x), there is added risk of regressions on legacy x86 boot that won't be getting developer attention.
I don't understand why we're still using syslinux instead of grub for legacy boots, especially since I think now you can use the same grub.cfg file for both.
It's development and validation work for something that's not a priority for those who are doing bootloader work, and no one else has stepped up to put in the time to do this work. The change proposal being discussed in this thread is calling for community contributors.
There is always a risk of regressions, but if there is
no current problem, then why is there this push to obsolete a lot of active hardware?
There is a problem: the current maintainers don't have capacity to support legacy x86 boot anymore. The code is going to bit rot if no one steps up to fill in.
This is not comparable to the 32-bit removal where it
was only a few really old systems. This is going to affect decent systems that are less than 10 years old. I have a work HP laptop from 2012 that has "experimental" EFI support that really doesn't work well and possibly a newer one as well, but I can't check it right now.
I'm curious if you've updated your BIOS on that system. If it's really that bad, Microsoft (and HP customers) would have been on HP's case about fixing a bad user experience.
_______________________________________________
devel mailing list -- devel@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 Fri, Apr 8, 2022 at 11:47 AM Jared Dominguez jaredz@redhat.com wrote:
On Thu, Apr 7, 2022, 19:46 Samuel Sieb samuel@sieb.net wrote:
On 4/7/22 14:51, Jared Dominguez wrote:
On Thu, Apr 7, 2022 at 3:49 PM Samuel Sieb <samuel@sieb.net mailto:samuel@sieb.net> wrote:
On 4/7/22 08:02, Jared Dominguez wrote: > This is a proposal. Nothing has changed yet. The choice is now whether > to go forward with it or come together with a cohesive > alternative, including one of the two listed in the proposal. But we > need a solution that accounts for the existing maintainers not having > capacity to continue maintaining legacy code. I've seen responses from I haven't yet seen a clear answer about what code is "rotting" and which legacy code is too hard to maintain. Is there something actually broken right now?For one, syslinux hasn't seen an update in 3 years and a release in 7 years, and it has outstanding bugs. Legacy boot isn't where grub2 is getting development attention. The current maintainers in Fedora won't have capacity to continue maintaining legacy boot support in Fedora. As grub2 continues to be developed for UEFI systems (ARMv8-9 and x86-64, not to mention non-UEFI ppc64le and s390x), there is added risk of regressions on legacy x86 boot that won't be getting developer attention.
I don't understand why we're still using syslinux instead of grub for legacy boots, especially since I think now you can use the same grub.cfg file for both.
It's development and validation work for something that's not a priority for those who are doing bootloader work, and no one else has stepped up to put in the time to do this work. The change proposal being discussed in this thread is calling for community contributors.
There is always a risk of regressions, but if there is no current problem, then why is there this push to obsolete a lot of active hardware?
There is a problem: the current maintainers don't have capacity to support legacy x86 boot anymore. The code is going to bit rot if no one steps up to fill in.
This is not comparable to the 32-bit removal where it was only a few really old systems. This is going to affect decent systems that are less than 10 years old. I have a work HP laptop from 2012 that has "experimental" EFI support that really doesn't work well and possibly a newer one as well, but I can't check it right now.
I'm curious if you've updated your BIOS on that system. If it's really that bad, Microsoft (and HP customers) would have been on HP's case about fixing a bad user experience.
Why? It works for Windows, and HP has only done token support for other platforms over the past decade (see most recent thing promoting WSL as a good Linux on HP experience[1]). All of my HP computers have been extremely difficult to get Linux working on properly, which is why I stopped buying them.
Just because Dell is sometimes good at its job doesn't mean everyone else is. The reality is that most aren't.
[1]: https://press.hp.com/us/en/press-releases/2021/hp-powers-real-time-collabora...
On Fri, Apr 8, 2022, 11:52 Neal Gompa ngompa13@gmail.com wrote:
On Fri, Apr 8, 2022 at 11:47 AM Jared Dominguez jaredz@redhat.com wrote:
On Thu, Apr 7, 2022, 19:46 Samuel Sieb samuel@sieb.net wrote:
On 4/7/22 14:51, Jared Dominguez wrote:
On Thu, Apr 7, 2022 at 3:49 PM Samuel Sieb <samuel@sieb.net mailto:samuel@sieb.net> wrote:
On 4/7/22 08:02, Jared Dominguez wrote: > This is a proposal. Nothing has changed yet. The choice is now whether > to go forward with it or come together with a cohesive > alternative, including one of the two listed in the proposal.But we
> need a solution that accounts for the existing maintainers not having > capacity to continue maintaining legacy code. I've seenresponses
from I haven't yet seen a clear answer about what code is "rotting" and which legacy code is too hard to maintain. Is there something actually broken right now?For one, syslinux hasn't seen an update in 3 years and a release in 7 years, and it has outstanding bugs. Legacy boot isn't where grub2 is getting development attention. The current maintainers in Fedora won't have capacity to continue maintaining legacy boot support in Fedora.
As
grub2 continues to be developed for UEFI systems (ARMv8-9 and x86-64, not to mention non-UEFI ppc64le and s390x), there is added risk of regressions on legacy x86 boot that won't be getting developer
attention.
I don't understand why we're still using syslinux instead of grub for legacy boots, especially since I think now you can use the same grub.cfg file for both.
It's development and validation work for something that's not a priority
for those who are doing bootloader work, and no one else has stepped up to put in the time to do this work. The change proposal being discussed in this thread is calling for community contributors.
There is always a risk of regressions, but if there is no current problem, then why is there this push to obsolete a lot of active hardware?
There is a problem: the current maintainers don't have capacity to
support legacy x86 boot anymore. The code is going to bit rot if no one steps up to fill in.
This is not comparable to the 32-bit removal where it was only a few really old systems. This is going to affect decent systems that are less than 10 years old. I have a work HP laptop from 2012 that has "experimental" EFI support that really doesn't work well and possibly a newer one as well, but I can't check it right now.
I'm curious if you've updated your BIOS on that system. If it's really
that bad, Microsoft (and HP customers) would have been on HP's case about fixing a bad user experience.
Why? It works for Windows, and HP has only done token support for other platforms over the past decade (see most recent thing promoting WSL as a good Linux on HP experience[1]). All of my HP computers have been extremely difficult to get Linux working on properly, which is why I stopped buying them.
If the experience is buggy with Windows too, HP probably has addressed that as previously stated, which is why I asked about how up-to-date Samuel's BIOS is. On several occasions I've seen complaints about firmware issues that are solved by updating. Firmware is software too.
If not, that sounds like a big in Fedora and possibly Linux in general. Windows is the reference operating system for most personal computer manufacturers, whether we like it or not.
Just because Dell is sometimes good at its job doesn't mean everyone
else is. The reality is that most aren't.
-- 真実はいつも一つ！/ 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 4/8/22 12:07, Jared Dominguez wrote:
If the experience is buggy with Windows too, HP probably has addressed that as previously stated, which is why I asked about how up-to-date Samuel's BIOS is. On several occasions I've seen complaints about firmware issues that are solved by updating. Firmware is software too.
Windows didn't run in EFI mode on it. I only turned on the EFI mode when I put a new drive in with no windows, accepting the big warning that it was experimental.
If not, that sounds like a big in Fedora and possibly Linux in general. Windows is the reference operating system for most personal computer manufacturers, whether we like it or not.
The biggest issue was that it seemed to ignore the efi boot entry for Fedora and used the fallback system. This caused something in the Fedora boot system to create another entry every time. I had to delete the extra entries every once in a while.
On Fri, Apr 08, 2022 at 11:46:50AM -0400, Jared Dominguez wrote:
On Thu, Apr 7, 2022, 19:46 Samuel Sieb samuel@sieb.net wrote:
I don't understand why we're still using syslinux instead of grub for legacy boots, especially since I think now you can use the same grub.cfg file for both.
It's development and validation work for something that's not a priority for those who are doing bootloader work, and no one else has stepped up to put in the time to do this work. The change proposal being discussed in this thread is calling for community contributors.
Would using Grub for legacy boot be more, or less work than continuing to support syslinux, assuming people step up to do the development and validation?
As someone who is also interested in eventually phasing out legacy BIOS support, but think it's too early, I sense that this is a better way to deprecate - first future proof the legacy installations in such a way that at some future time you can simply upgrade the system, switch to UEFI and keep your system disk - is a much better transition for our users.
*and* I have been hearing from people who are interested in doing this work. I sympathize with the change owners' position that detractors need to assume their good intentions, but I feel like the same needs to be assumed for community contributions, and we've unfortunately been talking past each other a bit in this thread.
Best regards,
Michel Alexandre Salim salimma@fedoraproject.org writes:
Would using Grub for legacy boot be more, or less work than continuing to support syslinux, assuming people step up to do the development and validation?
syslinux is by default only used on the live media. Legacy installs today provision grub2. So moving them to live media would probably be less, but it won't solve the overall problem.
I sympathize with the change owners' position that detractors need to assume their good intentions, but I feel like the same needs to be assumed for community contributions,
That's not really a "position" so much as a restatement of the Fedora Project's code of conduct. If you feel that our comportment is not up to snuff, please provide specific feedback so we can improve. (Otherwise, a statement like that just comes across as propagating FUD.)
Be well, --Robbie
On Fri, Apr 8, 2022 at 12:41 PM Robbie Harwood rharwood@redhat.com wrote:
Michel Alexandre Salim salimma@fedoraproject.org writes:
Would using Grub for legacy boot be more, or less work than continuing to support syslinux, assuming people step up to do the development and validation?
syslinux is by default only used on the live media. Legacy installs today provision grub2. So moving them to live media would probably be less, but it won't solve the overall problem.
SYSLINUX is also used for PXE and a number of other boot methods in BIOS. The main deliverable we use it for is live media, but there are other things too. Most of that is thankfully documentation on how to use GRUB for the same thing.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Fri, Apr 08, 2022 at 12:41:22PM -0400, Robbie Harwood wrote:
Michel Alexandre Salim salimma@fedoraproject.org writes:
I sympathize with the change owners' position that detractors need to assume their good intentions, but I feel like the same needs to be assumed for community contributions,
That's not really a "position" so much as a restatement of the Fedora Project's code of conduct. If you feel that our comportment is not up to snuff, please provide specific feedback so we can improve. (Otherwise, a statement like that just comes across as propagating FUD.)
Apologies if this came across that way, I'm actually trying to calm waters here. I'm rather surprised I came across as propagating FUD...
As for specifics: - my general impression from reading this thread is this Change as originally written is too aggressive in its timeline, and too optimistic in assuming hardware, esp on the server side, is ready - let's ignore the unfortunate dispute over the "PR was disabled" issue, I think that was a red herring - as I stated, there are offers to help with getting syslinux replaced with GRUB. what I've not stated originally is Chris Murphy brought up protective MBR and switching all new installs to inst.gpt, which let us future proof new installations for when we do kill off legacy BIOS.
What people who want to help needs, though, is some sense that our contributions are welcome. I've been at the receiving end of being FUD-ed as having a 'hidden agenda', so I know how that feels, and I'm definitely not trying to do that.
What I'm trying to point out is that the perceived lack of contribution should not really be used as a reason to push this change right now:
- Neal pointed out he has been working on addressing this for a while, and have not put up a Change Proposal because he thought it was premature - if the Change Proposal becomes "we can't support legacy BIOS long term, it's deprecated, community contributions welcome to help define the timeline and milestones" - that would probably get more people contributing rather than "this is our really fast timeline to deprecate this". Plus as many have stated, immediately breaking new installation is not deprecation, so I feel all subsequent discussion has been unfortunately tainted by that
Best regards,
Michel Alexandre Salim salimma@fedoraproject.org writes:
- as I stated, there are offers to help with getting syslinux replaced with GRUB. what I've not stated originally is Chris Murphy brought up protective MBR and switching all new installs to inst.gpt, which let us future proof new installations for when we do kill off legacy BIOS.
What people who want to help needs, though, is some sense that our contributions are welcome.
(If you're looking for me to comment on proposals to change live media generation and installs, I can't really do that - that's Brian's and Jiri's areas of expertise.)
- Neal pointed out he has been working on addressing this for a while, and have not put up a Change Proposal because he thought it was premature
While Neal's contributions are as welcome as anyone else's, Neal is not a maintainer of (or regular contributor to) bootloader packages and it would be very strange for Neal to propose such a change without discussing it with us first. That said, if there was suggestion of such a proposal, I have missed it (which is very possible given the size of the thread at this point).
Be well, --Robbie
On Fri, Apr 8, 2022 at 2:23 PM Robbie Harwood rharwood@redhat.com wrote:
Michel Alexandre Salim salimma@fedoraproject.org writes:
- as I stated, there are offers to help with getting syslinux replaced with GRUB. what I've not stated originally is Chris Murphy brought up protective MBR and switching all new installs to inst.gpt, which let us future proof new installations for when we do kill off legacy BIOS.
What people who want to help needs, though, is some sense that our contributions are welcome.
(If you're looking for me to comment on proposals to change live media generation and installs, I can't really do that - that's Brian's and Jiri's areas of expertise.)
- Neal pointed out he has been working on addressing this for a while, and have not put up a Change Proposal because he thought it was premature
While Neal's contributions are as welcome as anyone else's, Neal is not a maintainer of (or regular contributor to) bootloader packages and it would be very strange for Neal to propose such a change without discussing it with us first. That said, if there was suggestion of such a proposal, I have missed it (which is very possible given the size of the thread at this point).
Alright, I'll bite. I am within my rights to propose any Change I want for Fedora Cloud, which I help steward with David Duncan.
For Fedora Cloud, we've been discussing what we want to support going forward. I added hybrid boot support[1] in Fedora Linux 35 specifically so that we can start working on adding Fedora Cloud to Azure, who prefers UEFI for its Hyper-V VMs[2], but also supports legacy BIOS. We decided to not propose a Change to deprecate BIOS support yet specifically because we needed to have conversations with the various VPSes that people *actually use Fedora* on before we do that[3]. I was completely thrown by this Change proposal because it threatens to poison the conversations that Fedora Cloud wants to have with its actual stakeholders for a less acrimonious transition.
As an aside, I examined the state of all release blocking Fedora deliverables, and something I noticed is that only the Workstation WG has Red Hatters actively engaged in it. That means that this Change comes with absolutely no understanding of the state of the world in Fedora across the various WGs and SIGs that deliver release-blocking artifacts. That in itself isn't necessarily a problem, but the fact that none of you are listening to us (David Duncan and myself for Cloud and KDE, Chris Murphy for Cloud and Workstation, and Peter Boy for Server) when we tell you this is too early is extremely tone-deaf.
None of us want to keep supporting BIOS forever, but we all have *real-world experience* saying that we can't do this yet. We're trying to find a way to meet halfway to simplify legacy BIOS support, but you're not listening to us. We've also been trying to tell you that there are *real problems* with Fedora's UEFI support that need fixing before we can cut off BIOS support, but you're not listening to us.
This thread has, at the time of my writing this post, has 269 posts across 62 individuals. It is the most active thread we've had since the switch to nano by default. However, unlike that change, almost every single respondent has brought up feedback in this discussion saying that we're not ready and providing examples of why we're not ready. However, you're *not listening*.
I understand you want to drop BIOS support before Fedora Linux 40 is branched into RHEL 10. Obviously you could drop it in RHEL 10 even if Fedora doesn't, but it'd be better to drop it in Fedora first and make sure everything is flushed out. I would be fine with us doing that if there was some expectation that the UEFI experience in Fedora Linux was going to improve to resolve the issues people have *now* by the time we get there.
And we can take incremental steps to get there, even now:
1. Switch Anaconda to default to GPT even on BIOS setups 2. Drop syslinux and use GRUB everywhere 3. Configure new installations to always do hybrid boot installations 4. Develop documentation and/or tooling to do MBR->GPT conversions and reconfigure for hybrid boot for existing systems
These are all reasonably achievable things we can do. And that gives us time to work our relationships with our stakeholders to prepare them for the day legacy BIOS support is gone from the entire Red Hat family of distributions. It also gives room for improving the UEFI experience so it's *at least* as good as the BIOS one, if not better. Right now, it's not. And it needs to be in order to maintain the momentum we have now where Fedora Linux adoption is growing by leaps and bounds over the last couple of years.
[1]: https://fedoraproject.org/wiki/Changes/FedoraCloudHybridBoot [2]: https://pagure.io/cloud-sig/issue/309 [3]: https://pagure.io/cloud-sig/issue/345
-- 真実はいつも一つ！/ Always, there's only one truth!
On Sun, Apr 10, 2022 at 10:27:25AM -0400, Neal Gompa wrote:
And we can take incremental steps to get there, even now:
- Switch Anaconda to default to GPT even on BIOS setups
- Drop syslinux and use GRUB everywhere
- Configure new installations to always do hybrid boot installations
- Develop documentation and/or tooling to do MBR->GPT conversions and
reconfigure for hybrid boot for existing systems
These are all reasonably achievable things we can do. And that gives us time to work our relationships with our stakeholders to prepare them for the day legacy BIOS support is gone from the entire Red Hat family of distributions. It also gives room for improving the UEFI experience so it's *at least* as good as the BIOS one, if not better. Right now, it's not. And it needs to be in order to maintain the momentum we have now where Fedora Linux adoption is growing by leaps and bounds over the last couple of years.
This is a very concrete actionable and achievable proposal. /me likes.
Zbyszek
Neal Gompa ngompa13@gmail.com writes:
Alright, I'll bite. I am within my rights to propose any Change I want for Fedora Cloud, which I help steward with David Duncan.
As, presumably, is anyone else?
As an aside, I examined the state of all release blocking Fedora deliverables, and something I noticed is that only the Workstation WG has Red Hatters actively engaged in it. That means that this Change comes with absolutely no understanding of the state of the world in Fedora across the various WGs and SIGs that deliver release-blocking artifacts. That in itself isn't necessarily a problem, but the fact that none of you are listening to us (David Duncan and myself for Cloud and KDE, Chris Murphy for Cloud and Workstation, and Peter Boy for Server) when we tell you this is too early is extremely tone-deaf.
None of us want to keep supporting BIOS forever, but we all have *real-world experience* saying that we can't do this yet. We're trying to find a way to meet halfway to simplify legacy BIOS support, but you're not listening to us. We've also been trying to tell you that there are *real problems* with Fedora's UEFI support that need fixing before we can cut off BIOS support, but you're not listening to us.
This thread has, at the time of my writing this post, has 269 posts across 62 individuals. It is the most active thread we've had since the switch to nano by default. However, unlike that change, almost every single respondent has brought up feedback in this discussion saying that we're not ready and providing examples of why we're not ready. However, you're *not listening*.
Okay, this is really important: just because I don't agree with you doesn't mean I'm not hearing what you say. You appear to be conflating the two things.
I hear your position that this is too soon. But I need you to hear what I'm saying too: community assistance is required to keep up the status quo, if that's how we want to go. If you think the best way to go is to vote this down, and have firmly made up your mind to vote it down, then vote it down! But do so with that knowledge.
I understand you want to drop BIOS support before Fedora Linux 40 is branched into RHEL 10.
No one has said anything at all about RHEL. As a member of the team responsible for RHEL's boot stack, I can say that most of our focus is at the moment on <=9, not >9.
Be well, --Robbie
Michel Alexandre Salim salimma@fedoraproject.org writes:
- as I stated, there are offers to help with getting syslinux replaced with GRUB
More generally, I'm concerned that folks think this'll help a lot more than it actually will. There's a tendency to think in terms of packages - they're contained units and therefore convenient to reason about. But just being in a container is not an indication of complexity or size. The obligatory example of this that is (I hope) generally understood is the kernel. One source package, wildly different complexity than anything else - to the point where it's more meaningful to talk about the workflows enabled, subsystems, etc. than the rpms themselves. I've mentioned this upthread as well, but this is the nature of the problem: it's not about *packages*, it's about *use case*.
Be well, --Robbie
On Fri, Apr 08, 2022 at 02:39:04PM -0400, Robbie Harwood wrote:
Michel Alexandre Salim salimma@fedoraproject.org writes:
- as I stated, there are offers to help with getting syslinux replaced with GRUB
More generally, I'm concerned that folks think this'll help a lot more than it actually will. There's a tendency to think in terms of packages
- they're contained units and therefore convenient to reason about. But
just being in a container is not an indication of complexity or size. The obligatory example of this that is (I hope) generally understood is the kernel. One source package, wildly different complexity than anything else - to the point where it's more meaningful to talk about the workflows enabled, subsystems, etc. than the rpms themselves. I've mentioned this upthread as well, but this is the nature of the problem: it's not about *packages*, it's about *use case*.
Right, not saying this is a viable long-term solution. But having everything being GRUB, *plus* using protective MBR, would allow us to not force people to reinstall when we finally kill off legacy BIOS.
* yes, we still need to figure out how to convert existing systems to * protective MBR plus GPT, but at least we won't be creating new legacy * installs that will require reinstallation
Best,
On 4/8/22 08:46, Jared Dominguez wrote:
On Thu, Apr 7, 2022, 19:46 Samuel Sieb <samuel@sieb.net mailto:samuel@sieb.net> wrote: This is not comparable to the 32-bit removal where it was only a few really old systems. This is going to affect decent systems that are less than 10 years old. I have a work HP laptop from 2012 that has "experimental" EFI support that really doesn't work well and possibly a newer one as well, but I can't check it right now.
I'm curious if you've updated your BIOS on that system. If it's really that bad, Microsoft (and HP customers) would have been on HP's case about fixing a bad user experience.
It was never intended to run as a UEFI system. The support is clearly marked as "experimental" in the BIOS settings. (And yes, I updated the BIOS.) That was my point. This is not an old, outdated system, but it doesn't have real UEFI support.
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 :)
In case you're interested in prior art:
* kiwi's code: https://github.com/OSInside/kiwi/blob/master/kiwi/bootloader/config/grub2.py * drakiso's code: http://gitweb.mageia.org/software/build-system/drakiso/tree/lib/MGA/DrakISO/...
The two above are from openSUSE and Mageia respectively, who have both made this change for their distributions.
-- 真実はいつも一つ！/ Always, there's only one truth!
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.
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 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.
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
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
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, 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
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 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 06, 2022 at 12:38:40PM +0000, Gary Buhrmaster wrote:
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.
I was wondering about whether this was possible (booting UEFI from BIOS) too. For reference, DUET is described here:
https://rodsbooks.com/bios2uefi/
Clover is described here:
https://github.com/CloverHackyColor/CloverBootloader
Rich.
On Thu, Apr 07, 2022 at 03:43:07PM +0100, Richard W.M. Jones wrote:
Clover is described here: https://github.com/CloverHackyColor/CloverBootloader
This is interesting. Seems like considerable up-front work, but a much cleaner possible future than completely dual paths.
Are there docs on this somewhere other than the Arch wiki? (Which, as usual, is very helpful!) -- https://wiki.archlinux.org/title/Clover
On Thu, Apr 7, 2022 at 6:05 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Apr 07, 2022 at 03:43:07PM +0100, Richard W.M. Jones wrote:
Clover is described here: https://github.com/CloverHackyColor/CloverBootloader
This is interesting. Seems like considerable up-front work, but a much cleaner possible future than completely dual paths.
Are there docs on this somewhere other than the Arch wiki? (Which, as usual, is very helpful!) -- https://wiki.archlinux.org/title/Clover
I don't think so? Some of the information for using DUET (which Clover is descended from) from the rEFInd developer might be useful, though: http://www.rodsbooks.com/bios2uefi/index.html
(As an aside, the rEFInd developer, Rod Smith, has a huge trove of user experience EFI documentation on his site!)
-- 真実はいつも一つ！/ Always, there's only one truth!
On Thu, Apr 7, 2022 at 5:05 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Apr 07, 2022 at 03:43:07PM +0100, Richard W.M. Jones wrote:
Clover is described here: https://github.com/CloverHackyColor/CloverBootloader
This is interesting. Seems like considerable up-front work, but a much cleaner possible future than completely dual paths.
I like it! I especially like that it combines all the bootloader code, up-to and including the initramfs, under one /boot partition. Please don't change that. I have many systems set up that way already and I think I could drop this on them *very* easily.
Just my 2¢.
On Thu, Apr 7, 2022 at 10:05 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Apr 07, 2022 at 03:43:07PM +0100, Richard W.M. Jones wrote:
Clover is described here: https://github.com/CloverHackyColor/CloverBootloader
This is interesting. Seems like considerable up-front work, but a much cleaner possible future than completely dual paths.
On my (still countably) infinite TODO list I had an item on it to spend more time looking at Clover to be able to boot (in UEFI mode) one of my older BIOS only Core 2 duo quad systems that I had picked up for pennies on the dollar at a local surplus store. At this point it is a question of whether I will find the time to do so or the system itself will finally die. Since the original placement (on my list), the Clover devs have substantially improved it to the point that a lot of the rough edges have been mitigated, although given all the various implementations of BIOS's there are still going to be edge cased (just as there are still rough edges with UEFI, especially the earliest implementations).
Are there docs on this somewhere other than the Arch wiki? (Which, as usual, is very helpful!) -- https://wiki.archlinux.org/title/Clover
As is typically the case, the Arch wiki is better than almost all other available docs.
On Friday, 08 April 2022 at 04:37, Gary Buhrmaster wrote:
On Thu, Apr 7, 2022 at 10:05 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Apr 07, 2022 at 03:43:07PM +0100, Richard W.M. Jones wrote:
Clover is described here: https://github.com/CloverHackyColor/CloverBootloader
This is interesting. Seems like considerable up-front work, but a much cleaner possible future than completely dual paths.
On my (still countably) infinite TODO list I had an item on it to spend more time looking at Clover to be able to boot (in UEFI mode) one of my older BIOS only Core 2 duo quad systems that I had picked up for pennies on the dollar at a local surplus store. At this point it is a question of whether I will find the time to do so or the system itself will finally die. Since the original placement (on my list), the Clover devs have substantially improved it to the point that a lot of the rough edges have been mitigated, although given all the various implementations of BIOS's there are still going to be edge cased (just as there are still rough edges with UEFI, especially the earliest implementations).
I'd be willing to lend a hand to adapting Clover on Fedora and testing booting with it on my 12yo BIOS-only Intel Atom machine.
Are there docs on this somewhere other than the Arch wiki? (Which, as usual, is very helpful!) -- https://wiki.archlinux.org/title/Clover
As is typically the case, the Arch wiki is better than almost all other available docs.
Indeed. How do they do it? ;)
Regards, Dominik
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
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
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
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.
There are other ways to create bootable media, right? Does everything need to be Koji+Lorax?
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
Neal Gompa wrote:
The pull request to delete the code for BIOS support in lorax means that we can't produce media with BIOS support at all once that's merged. They've tied dropping syslinux to dropping BIOS support entirely. It is also unclear that they'd take a contribution to rewire lorax to produce media with BIOS support using GRUB like we do for UEFI.
So the change is actually already being implemented without approval? This kind of forcing facts turns the whole change policy to the absurd.
As I understand it, dropping support in Lorax affects both livemedia-creator and livecd-creator, so the only way forward to build ISOs that actually boot would be to fork Lorax. Unless we can reuse some other distro's tools instead.
The liveinst part of Anaconda can be replaced with Calamares, but ISO composing (which can be done with (livemedia-creator) or without Anaconda (livecd-creator), but both code paths end up in Lorax eventually) is not in the scope of Calamares.
Kevin Kofler
Dne 08. 04. 22 v 6:46 Kevin Kofler via devel napsal(a):
Neal Gompa wrote:
The pull request to delete the code for BIOS support in lorax means that we can't produce media with BIOS support at all once that's merged. They've tied dropping syslinux to dropping BIOS support entirely. It is also unclear that they'd take a contribution to rewire lorax to produce media with BIOS support using GRUB like we do for UEFI.
So the change is actually already being implemented without approval?
Having implementation ready for approval is +, isn't it?
This kind of forcing facts turns the whole change policy to the absurd.
But it also needs to be merged first to have any real effect. The PR is in the change proposal.
Vít
As I understand it, dropping support in Lorax affects both livemedia-creator and livecd-creator, so the only way forward to build ISOs that actually boot would be to fork Lorax. Unless we can reuse some other distro's tools instead.
The liveinst part of Anaconda can be replaced with Calamares, but ISO composing (which can be done with (livemedia-creator) or without Anaconda (livecd-creator), but both code paths end up in Lorax eventually) is not in the scope of Calamares.
Kevin Kofler
devel mailing list -- devel@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 Fri, Apr 8, 2022, 00:48 Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote:
Neal Gompa wrote:
The pull request to delete the code for BIOS support in lorax means that we can't produce media with BIOS support at all once that's merged. They've tied dropping syslinux to dropping BIOS support entirely. It is also unclear that they'd take a contribution to rewire lorax to produce media with BIOS support using GRUB like we do for UEFI.
Neal, the change proposal already made it clear that this isn't just about syslinux, and this fact has been discussed over and over. Your speculation here and earlier in this thread on what would and would not be accepted just reads to me as inflammatory, especially when the ones actually doing development here have shown a clear willingness both in this thread and explicitly in the change proposal for collaboration and help with development.
So the change is actually already being implemented without approval? This
kind of forcing facts turns the whole change policy to the absurd.
An _unmerged_ pull request still in review that's tied to this change _proposal_.
As I understand it, dropping support in Lorax affects both
livemedia-creator and livecd-creator, so the only way forward to build ISOs that actually boot would be to fork Lorax. Unless we can reuse some other distro's tools instead.
The liveinst part of Anaconda can be replaced with Calamares, but ISO composing (which can be done with (livemedia-creator) or without Anaconda (livecd-creator), but both code paths end up in Lorax eventually) is not in the scope of Calamares.
Kevin Kofler
devel mailing list -- devel@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 Fri, Apr 08, 2022 at 06:46:30AM +0200, Kevin Kofler via devel wrote:
Neal Gompa wrote:
The pull request to delete the code for BIOS support in lorax means that we can't produce media with BIOS support at all once that's merged. They've tied dropping syslinux to dropping BIOS support entirely. It is also unclear that they'd take a contribution to rewire lorax to produce media with BIOS support using GRUB like we do for UEFI.
So the change is actually already being implemented without approval? This kind of forcing facts turns the whole change policy to the absurd.
No. It's just a PR, and actually it's currently in Draft state to indicate that it isn't ready to be merged. If I merge it without approval from the community then you can yell at me :)
As I understand it, dropping support in Lorax affects both livemedia-creator and livecd-creator, so the only way forward to build ISOs that actually boot would be to fork Lorax. Unless we can reuse some other distro's tools instead.
This does not effect livecd-creator, that is a totally separate project that I am no longer involved with. It would effect lorax built boot.iso and live iso's created with livemedia-creator. Possibly also the DVD's built by pungi.
The reason I wrote the PR was because, as I understand it, syslinux is going away soon. It was an easy patch to write, and I find it easier to discuss things when there is code present (or absent as in this case).
My *personal* opinion is we should not drop BIOS. I think BIOS will continue to haunt use for the forseeable future, there is just too much existing hardware that still works. But if the tools used to make it work aren't present I have to remove them.
So like I said yesterday, I'll look into switching to use grub2 for Fedora 37, assuming grub2 continues to support BIOS.
Brian
On Fri, Apr 8, 2022 at 11:14 AM Brian C. Lane bcl@redhat.com wrote:
The reason I wrote the PR was because, as I understand it, syslinux is going away soon. It was an easy patch to write, and I find it easier to discuss things when there is code present (or absent as in this case).
My *personal* opinion is we should not drop BIOS. I think BIOS will continue to haunt use for the forseeable future, there is just too much existing hardware that still works. But if the tools used to make it work aren't present I have to remove them.
So like I said yesterday, I'll look into switching to use grub2 for Fedora 37, assuming grub2 continues to support BIOS.
If switching from syslinux to GRUB isn't onerous, it's essentially an invisible change, i.e. new installations to BIOS systems is still possible. But also, it would give some breathing room to evaluate BIOS GRUB as a going-concern, versus clover. If we're looking at something like 2-3 years of BIOS support, that might favor sticking it out with BIOS GRUB. If it's much longer, that might favor using a UEFI emulator on BIOS systems to bring them forward.
What about all the MBR handling in the installer? The change proposal doesn't mention it. But if the ability to install to BIOS systems were to go away, that would presumably take MBR with it. So I'm wondering if it's viable to use BIOS GRUB instead of syslinux, should inst.gpt become the default? And then would inst.mbr go away? Or would it stick around for another cycle or two as a manual fallback? Or is it simple and static enough that it'll persist for a long time without rotting?
Hindsight being 20/20 I kinda wonder if we should have just bit the bullet on inst.gpt, because at least inst.mbr has been available this whole time.
Hi Brian,
On 4/8/22 19:14, Brian C. Lane wrote:
<snip>
So like I said yesterday, I'll look into switching to use grub2 for Fedora 37, assuming grub2 continues to support BIOS.
Thank you for looking into switching to using GRUB for the livecds.
If you have some test livecd img using grub instead of syslinux for BIOS booting and you wanted it tested on some more / older hw let me know and I'll test it on the BIOS-only machines which I have.
Regards,
Hans
On Fri, Apr 8, 2022 at 1:50 PM Hans de Goede hdegoede@redhat.com wrote:
Hi Brian,
On 4/8/22 19:14, Brian C. Lane wrote:
<snip>
So like I said yesterday, I'll look into switching to use grub2 for Fedora 37, assuming grub2 continues to support BIOS.
Thank you for looking into switching to using GRUB for the livecds.
If you have some test livecd img using grub instead of syslinux for BIOS booting and you wanted it tested on some more / older hw let me know and I'll test it on the BIOS-only machines which I have.
I've got one or two of them around here somewhere too if you need testing. :)
On Friday, 08 April 2022 at 19:14, Brian C. Lane wrote: [...]
So like I said yesterday, I'll look into switching to use grub2 for Fedora 37, assuming grub2 continues to support BIOS.
Thank you very much! From my side, I've found another BIOS-only machine in my junkyard and I'm willing to put both up for testing any changes and maybe even help write some code if time permits.
Regards, Dominik
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!
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 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 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 07/04/2022 10:43, Lennart Poettering wrote:
Do you think the user experience with grub was*good*? Turing complete language? Scripts that generate scripts that generate scripts?
+1. Current GRUB2 is a collection of hacks. Even the upstream abandoned it, and it currently maintained mainly in downstream.
Vitaly Zaitsev via devel devel@lists.fedoraproject.org writes:
On 07/04/2022 10:43, Lennart Poettering wrote:
Do you think the user experience with grub was*good*? Turing complete language? Scripts that generate scripts that generate scripts?
+1. Current GRUB2 is a collection of hacks. Even the upstream abandoned it, and it currently maintained mainly in downstream.
This is not reflective of the current state of affairs.
While we do maintain a large set of patches downstream, due to upstream being inactive for a while, today upstream is alive and very much not abandoned:
https://www.gnu.org/software/grub/ https://lists.gnu.org/archive/html/grub-devel/
Last release was June; plenty of commits since then. I regularly communicate with dkiper (who is the maintainer these days).
Be well, --Robbie
On 07/04/2022 18:10, Robbie Harwood wrote:
While we do maintain a large set of patches downstream, due to upstream being inactive for a while, today upstream is alive and very much not abandoned:
Why not upstream all those patches then?
On Fri, Apr 8, 2022 at 8:07 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 07/04/2022 18:10, Robbie Harwood wrote:
While we do maintain a large set of patches downstream, due to upstream being inactive for a while, today upstream is alive and very much not abandoned:
Why not upstream all those patches then?
It's not quite that simple. There are currently 214 patches on GRUB[1]. Some of those are backports of reviewed and merged patches, but a large chunk of them are feature development patches that are either in review or haven't been submitted because dependent patches are in review. Patch review is long, slow, and complex. It's even more so for GRUB. Top that with there being only one major committer for the upstream project right now (Daniel Kiper). I'm not fully aware of the dynamics of the GRUB project, so I don't know the reason for the lack of other committers. But needless to say, I know that Daniel considers it a top priority to eliminate the Red Hat GRUB fork by incorporating its changes into mainline because a large number of distributions use it instead of upstream due to the lack of responsiveness, feature development, and fixes present in the upstream code.
However, taking it all in wholesale without review is crazy because then nobody else knows how the code was developed and if it should go in as-is. That said, my personal opinion is that a couple of the folks who work on RH GRUB should be part of the project leadership in upstream GRUB and have commit access to maintain and manage this. That may already be in place, but I don't know for sure.
[1]: https://src.fedoraproject.org/rpms/grub2/tree/d17f80cfd556d8a582756ee393361f...
-- 真実はいつも一つ！/ Always, there's only one truth!
Vitaly Zaitsev via devel devel@lists.fedoraproject.org writes:
On 07/04/2022 18:10, Robbie Harwood wrote:
While we do maintain a large set of patches downstream, due to upstream being inactive for a while, today upstream is alive and very much not abandoned:
Why not upstream all those patches then?
I resent the implication that I'm not doing that.
The idea that one would show up with a decent-sized pile of patches and have an upstream merge them immediately sits somewhere between "naïve" and "a reason to vote no-confidence in upstream".
Be well, --Robbie
On Thu, Apr 07, 2022 at 10:43:02AM +0200, Lennart Poettering wrote:
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.
"barebones crappy one" is pretty strong. I'm too am interested in hearing what is so wrong with the sd-boot experience.
Zbyszek
On Sun, Apr 10, 2022 at 1:31 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Thu, Apr 07, 2022 at 10:43:02AM +0200, Lennart Poettering wrote:
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.
"barebones crappy one" is pretty strong. I'm too am interested in hearing what is so wrong with the sd-boot experience.
The problem with systemd-boot is it still has an interface. I prefer no interface for bootloaders.
I'm a bit frustrated that systemd-boot isn't signed, and apparently (I guess) shim hard codes GRUB as the next bootloader?
This portion of the thread maybe ought to be split out?
On Mo, 11.04.22 02:34, Chris Murphy (lists@colorremedies.com) wrote:
OK, I'll bite.
What are you missing in sd-boot, specifically?
Also, why would a boot menu need a particularly fancy user experience? It's a boot manager, not a web browser.
"barebones crappy one" is pretty strong. I'm too am interested in hearing what is so wrong with the sd-boot experience.
The problem with systemd-boot is it still has an interface. I prefer no interface for bootloaders.
Too much for some, too little for others ;-)
The UI it has is by default turned off and you only get it if you hold shift down or so at boot.
I mean, we do need some logic how you can pick an older kernel/edit kernel cmdline for debugging/recovery/testing reasons. And that's exactly what we offer, but not much more.
(And of course, you can hold W down to boot windows. But booting into windows on dual-boot systems should actually move into gdm or so, we provide all the basic building blocks to make this nice, except the UI for it is actually missing).
I'm a bit frustrated that systemd-boot isn't signed, and apparently (I guess) shim hard codes GRUB as the next bootloader?
That's mostly a political issue.
(We actually have some support in sd-boot to be installed inder the "grubx64.efi" name, to work around this political mess...)
Lennart
-- Lennart Poettering, Berlin
On Mon, Apr 11, 2022 at 3:02 AM Lennart Poettering mzerqung@0pointer.de wrote:
On Mo, 11.04.22 02:34, Chris Murphy (lists@colorremedies.com) wrote:
OK, I'll bite.
What are you missing in sd-boot, specifically?
Also, why would a boot menu need a particularly fancy user experience? It's a boot manager, not a web browser.
"barebones crappy one" is pretty strong. I'm too am interested in hearing what is so wrong with the sd-boot experience.
The problem with systemd-boot is it still has an interface. I prefer no interface for bootloaders.
Too much for some, too little for others ;-)
The UI it has is by default turned off and you only get it if you hold shift down or so at boot.
I mean, we do need some logic how you can pick an older kernel/edit kernel cmdline for debugging/recovery/testing reasons. And that's exactly what we offer, but not much more.
My comment was tongue in cheek, but yeah the "general case" in Fedora is either no UI or boot an older kernel. Hence hidden GRUB menu by default unless dual boot with Windows is detected (but due to Bitlocker and TPM measured boot, the GRUB menu's Windows entry increasingly won't work; where sd-boot has worked around this correctly with the UEFI bootnext variable, upstream GRUB hasn't committed to even recognizing the problem let alone a solution).
I'm a bit frustrated that systemd-boot isn't signed, and apparently (I guess) shim hard codes GRUB as the next bootloader?
That's mostly a political issue.
OK but it's true? I've got the story line correct? I'll start a separate thread because if it's true...
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.
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 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?
Robert Marcano via devel devel@lists.fedoraproject.org writes:
Is this change only related to install media support for booting with BIOS only? Would I be able to install newer Fedora releases using Legacy PXE on BIOS only machines?
The intent is to indicate that new legacy installations are not supported, regardless of how one gets there. Mechanically, there are few ways to actually *prevent* these installations[1] - rather, we send a message that this is on its way out (i.e., deprecated) and that it's time for users to consider migrating their setups.
So the direct answer is: yes, probably, if you're willing to work at it hard enough. But it wouldn't be supported.
Be well, --Robbie
1: Even if I wanted to, which I don't, it's not that hard to re-enable anything we might turn off just by doing local builds.
Am 07.04.22 um 18:14 schrieb Robbie Harwood:
Robert Marcano via devel devel@lists.fedoraproject.org writes:
Is this change only related to install media support for booting with BIOS only? Would I be able to install newer Fedora releases using Legacy PXE on BIOS only machines?
The intent is to indicate that new legacy installations are not supported, regardless of how one gets there. Mechanically, there are few ways to actually *prevent* these installations[1] - rather, we send a message that this is on its way out (i.e., deprecated) and that it's time for users to consider migrating their setups.
So the direct answer is: yes, probably, if you're willing to work at it hard enough. But it wouldn't be supported.
Your answer once more confirms my impression on Red Hat's current role in Fedora: Red Hat is abusing Fedora is not willing to contribute to the community and is striving to get rid of the community (similar to RHAT's management faults wrt. CentOS)
That said, should this change happen, I will probably drop using und supporting fedora and switch to a different flavor of Linux. It's apparently what RHAT wants.
Ralf
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.
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 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 Tue, Apr 5, 2022 at 4:54 PM 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.
I personally find the wording here extremely confusing, to the point where it might be classified as misleading. Usually, to "deprecate" something means that users get a grace period where they will be warned that the thing they're using will go away at some point in the future, and that it should no longer be used, if possible.
However, with the current proposal, you're *already removing* the ability to install Fedora in "non-UEFI mode". There would be zero grace period in which users would be warned "hey, you're using the installer for the old method, you might want to do it the new way instead".
As far as I see, with this proposal, the only "direct" way to get a F37+ non-UEFI system would be by upgrading from a previous release of Fedora? But users who do that would not receive any "hey, you installed your system in BIOS mode, this might not be supported for much longer, we recommend reinstalling it in UEFI mode, if possible" warning, either.
I also agree with other FESCo members who have chimed in in this thread: It seems too early to pull the plug here. If this was a "real" deprecation, with grace period and scary warning dialogs for users who still end up booting in BIOS mode, I'd be sympathetic to that. But in my opinion, this proposal as it is seems too aggressive at this point in time.
Fabio
On Thu, Apr 7, 2022 at 4:50 PM Fabio Valentini decathorpe@gmail.com wrote:
On Tue, Apr 5, 2022 at 4:54 PM 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.
I personally find the wording here extremely confusing, to the point where it might be classified as misleading. Usually, to "deprecate" something means that users get a grace period where they will be warned that the thing they're using will go away at some point in the future, and that it should no longer be used, if possible.
Yes, the word deprecate needs to be removed.
The reason why it's not worth arguing about is because there's no argument to be made for using this term. It's simply incorrect both in terms of etymology, but also how it gets used in the industry. Deprecation means "to express disapproval of" that's it. A circle is not a square, and saying it's not worth arguing about is absolutely true because no one can argue they're equivalent, even approximately.
On 4/5/22 22:52, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
== Summary == Make UEFI a hardware requirement for new Fedora installations on platforms that support it (x86_64). Legacy BIOS support is not removed, but new non-UEFI installation is not supported on those platforms. This is a first step toward eventually removing legacy BIOS support entirely.
== Owner ==
- Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří
Konečný]], [[User:bcl| Brian C. Lane]]
- Email: rharwood@redhat.com
== Detailed Description == UEFI is defined by a versioned standard that can be tested and certified against. By contrast, every legacy BIOS is unique. Legacy BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple) and on its way out. As it ages, maintainability has decreased, and
Probably it isn't a problem for some users, but I'm still having bad experience with UEFI on x86_64 now. Out of my 3 machines I only have 1 system that works fine with UEFI. And my parents' laptop was purchased 2 years ago and the UEFI firmware does not allow to boot anything other than Windows on UEFI mode (regardless of turning secure boot on or off) and I have to switch to BIOS mode to make Fedora work there. So in this situation, I think it's way too aggressive to accept the change - this will probably drive away some potential new users with decent laptop like my parents'.
the status quo of maintaining both stacks in perpetuity is not viable for those currently doing that work.
It is inevitable that legacy BIOS will be removed in a future release. To ease this transition as best we can, there will be a period (of at least one Fedora release) where it will be possible to boot using the legacy BIOS codepaths, but new installations will not be possible. While it would be easier for us to cut support off today, our hope is that this compromise position will make for a smoother transition. Additional support with issues during the transition would be appreciated.
While this will eventually reduce workload for boot/installation components (grub2 reduces surface area, syslinux goes away entirely, anaconda reduces surface area), the reduction in support burden extends much further into the stack - for instance, VESA support can be removed from the distro.
Fedora already requires a 2GHz dual core CPU at minimum (and therefore mandates that machines must have been made after 2006). Like the already accepted Fedora 37 change to retire ARMv7 support, the
I know ARMv7 is irrelevant here, but I feel ARMv7 never use BIOS in Fedora.
The dropping of ARMv7 support already renders most of my ARM devices unable to use new Fedora, which is a great pain and I have to switch to something else if I need to reinstall in the future. Similarly, if we drive BIOS users out of fresh installation, we have even more possibility of attracting less new users, which I feel isn't what Fedoraproject want to see.
hardware targeted tends to be rather underpowered by today’s standards, and the world has moved on from it. Intel stopped shipping the last vestiges of BIOS support in 2020 (as have other vendors, and Apple and Microsoft), so this is clearly the way things are heading - and therefore aligns with Fedora’s “First” objective.
== Feedback == Dropping legacy BIOS was previously discussed (but not proposed) in 2020: https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.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 Fri, Apr 08, 2022 at 10:14:19PM +0800, Zamir SUN wrote:
Probably it isn't a problem for some users, but I'm still having bad experience with UEFI on x86_64 now. Out of my 3 machines I only have 1 system that works fine with UEFI. And my parents' laptop was purchased 2 years ago and the UEFI firmware does not allow to boot anything other than Windows on UEFI mode (regardless of turning secure boot on or off) and I have to switch to BIOS mode to make Fedora work there. So in this situation, I think it's way too aggressive to accept the change - this will probably drive away some potential new users with decent laptop like my parents'.
I've encountered one such laptop - turning off secure boot was not enough, there's another option somewhere else for disabling key verification (IIRC).
I agree that this means dropping legacy BIOS is premature, and we should focus more on future-proofing our installations to make the transition easier in the future.
Cheers,
On Friday, 08 April 2022 at 16:14, Zamir SUN wrote: [...]
Probably it isn't a problem for some users, but I'm still having bad experience with UEFI on x86_64 now. Out of my 3 machines I only have 1 system that works fine with UEFI. And my parents' laptop was purchased 2 years ago and the UEFI firmware does not allow to boot anything other than Windows on UEFI mode (regardless of turning secure boot on or off) and I have to switch to BIOS mode to make Fedora work there. So in this situation, I think it's way too aggressive to accept the change - this will probably drive away some potential new users with decent laptop like my parents'.
Have you tried renaming your Fedora boot entry to "Windows Boot Manager"? I have one Sony laptop that boots only the boot entry with that exact name.
Regards, Dominik
On Sun, Apr 10, 2022 at 4:37 PM Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
On Friday, 08 April 2022 at 16:14, Zamir SUN wrote: [...]
Probably it isn't a problem for some users, but I'm still having bad experience with UEFI on x86_64 now. Out of my 3 machines I only have 1 system that works fine with UEFI. And my parents' laptop was purchased 2 years ago and the UEFI firmware does not allow to boot anything other than Windows on UEFI mode (regardless of turning secure boot on or off) and I have to switch to BIOS mode to make Fedora work there. So in this situation, I think it's way too aggressive to accept the change - this will probably drive away some potential new users with decent laptop like my parents'.
Have you tried renaming your Fedora boot entry to "Windows Boot Manager"? I have one Sony laptop that boots only the boot entry with that exact name.
I wonder if this would work with one of my old machines too. I've never thought to rename the boot entry in the firmware before...
On 4/10/22 16:10, Neal Gompa wrote:
On Sun, Apr 10, 2022 at 4:37 PM Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
On Friday, 08 April 2022 at 16:14, Zamir SUN wrote: [...]
Probably it isn't a problem for some users, but I'm still having bad experience with UEFI on x86_64 now. Out of my 3 machines I only have 1 system that works fine with UEFI. And my parents' laptop was purchased 2 years ago and the UEFI firmware does not allow to boot anything other than Windows on UEFI mode (regardless of turning secure boot on or off) and I have to switch to BIOS mode to make Fedora work there. So in this situation, I think it's way too aggressive to accept the change - this will probably drive away some potential new users with decent laptop like my parents'.
Have you tried renaming your Fedora boot entry to "Windows Boot Manager"? I have one Sony laptop that boots only the boot entry with that exact name.
I wonder if this would work with one of my old machines too. I've never thought to rename the boot entry in the firmware before...
about "Windows Boot Manager" efi entry required to boot: https://mjg59.dreamwidth.org/20187.html
the above happens too with the lenovo thinkcentre m91
On Sun, Apr 10, 2022 at 7:08 PM Gabriel Ramirez gabrielo@aekert.com wrote:
On 4/10/22 16:10, Neal Gompa wrote:
On Sun, Apr 10, 2022 at 4:37 PM Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
On Friday, 08 April 2022 at 16:14, Zamir SUN wrote: [...]
Probably it isn't a problem for some users, but I'm still having bad experience with UEFI on x86_64 now. Out of my 3 machines I only have 1 system that works fine with UEFI. And my parents' laptop was purchased 2 years ago and the UEFI firmware does not allow to boot anything other than Windows on UEFI mode (regardless of turning secure boot on or off) and I have to switch to BIOS mode to make Fedora work there. So in this situation, I think it's way too aggressive to accept the change - this will probably drive away some potential new users with decent laptop like my parents'.
Have you tried renaming your Fedora boot entry to "Windows Boot Manager"? I have one Sony laptop that boots only the boot entry with that exact name.
I wonder if this would work with one of my old machines too. I've never thought to rename the boot entry in the firmware before...
about "Windows Boot Manager" efi entry required to boot: https://mjg59.dreamwidth.org/20187.html
the above happens too with the lenovo thinkcentre m91
From the blog post:
For now, if you want to run Fedora[2] on these systems you're probably best off changing the firmware to perform a legacy boot.
*sigh*
Hi,
On 4/11/22 01:07, Gabriel Ramirez wrote:
On 4/10/22 16:10, Neal Gompa wrote:
On Sun, Apr 10, 2022 at 4:37 PM Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
On Friday, 08 April 2022 at 16:14, Zamir SUN wrote: [...]
Probably it isn't a problem for some users, but I'm still having bad experience with UEFI on x86_64 now. Out of my 3 machines I only have 1 system that works fine with UEFI. And my parents' laptop was purchased 2 years ago and the UEFI firmware does not allow to boot anything other than Windows on UEFI mode (regardless of turning secure boot on or off) and I have to switch to BIOS mode to make Fedora work there. So in this situation, I think it's way too aggressive to accept the change - this will probably drive away some potential new users with decent laptop like my parents'.
Have you tried renaming your Fedora boot entry to "Windows Boot Manager"? I have one Sony laptop that boots only the boot entry with that exact name.
I wonder if this would work with one of my old machines too. I've never thought to rename the boot entry in the firmware before...
about "Windows Boot Manager" efi entry required to boot: https://mjg59.dreamwidth.org/20187.html
the above happens too with the lenovo thinkcentre m91
Yes and some UEFI-s will only consider non USB disks to be bootable if they have a FAT ESP with EFI/Microsoft/Boot/bootmgfw.efi on there.
Some of them are hardcoded to boot that file (just put shim + grubia32.efi / grubx64.efi there), while others check for the file, but boot another path (which may also be hardcoded) see:
https://hansdegoede.dreamwidth.org/24232.html
For a couple of devices which I encountered which do this. I did not know about the "Windows Boot Manager" name being a thing too.
So yes so much for UEFI being a sensible standard...
Regards,
Hans
Ben Cotton bcotton@redhat.com writes:
https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
== Summary == Make UEFI a hardware requirement for new Fedora installations on platforms that support it (x86_64). Legacy BIOS support is not removed, but new non-UEFI installation is not supported on those platforms. This is a first step toward eventually removing legacy BIOS support entirely.
I want to add a few thoughts both from an EC2 perspective, and an Amazon Linux as a downstream of Fedora perspective.
Currently, nearly all EC2 instance types will boot by default with legacy-bios. All aarch64 instances are UEFI, and I'd find it unlikely that any new x86-64 instance type would not also support UEFI. But the default for all existing Intel and AMD instance types is legacy-bios. This is largely to preserve backwards compatibility, and at least for existing instance types, I cannot forsee this ever changing. You just don't want to needlessly break customers.
Relatively recently, UEFI started becoming an option for some non-aarch64 instance types, and can be selected either at instance launch time, or configured to be part of the AMI. See https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-boot.html
There are however a *lot* of instance types, a whole bunch of which are less likely to support UEFI - the documentation gives t2.xlarge as an example of one that only supports legacy-bios.
AMIs that don't run on all instance types tend to cause confusion, no matter how clear you document the limitations. It's only now that this is something that's even emerging as something that the EC2 APIs would assist in enforcing. In fact, in Amazon Linux 2022 we went for the decision that for aarch64 we'd require Graviton 2 and x86-64v2 as minimal requirements, and having AL2022 AMIs not boot on a1 instances types did surprise some people, even though we documented it.
With things like spot instances, there's a lot of customer demand for "the cheapest possible compute, doesn't matter what or where" to run things that aren't time critical.
Now, the interesting thing about Cloud images is that there isn't an installer. In fact, Amazon Linux doesn't have one and we don't package Anaconda anywhere. All users come from a disk image, which we create using separate tooling. Thus, from an AL perspective, if Anaconda were to stop supporting installing for legacy-bios, this wouldn't affect us at all.
However, we would have a big interest in having legacy-bios work well to boot the OS, likely for a decent number of years to come (however much I wish this wasn't the case).
I guess the interesting balance here is maintenance responsibility as well. I *very* much don't want any of this to read like a request for the community to maintain something that's primarily useful only to a specific vendor. There's a point where if it's functionality that's needed by a vendor, then said vendor has to maintain it, or be very involved in maintaining it.
(and for non-EC2 and non-Amazon-Linux input, I have at least one machine at home that run Fedora that don't have UEFI, a HP Microserver of a certain age. Now, maybe it's time for me to upgrade that hardware, but I bet there's a lot of folk who either don't want to do that, or cannot reasonably afford to)
-
Adam Jackson -
Alberto Abrao -
Andre Robatino -
Ben Beasley -
Ben Cotton -
Björn Persson -
Brian C. Lane -
Chris Adams -
Chris Murphy -
David Airlie -
David Both -
David Cantrell -
David Duncan -
Demi Marie Obenour -
Dominik 'Rathann' Mierzejewski -
Fabio Valentini -
Florian Weimer -
Gabriel Ramirez -
Gary Buhrmaster -
Gerd Hoffmann -
Gregory Bartholomew -
Hans de Goede -
Ian Pilcher -
Jared Dominguez -
Jason L Tibbitts III -
Javier Martinez Canillas -
Jeremy Linton -
John Boero -
Josh Boyer -
JT -
Justin Forbes -
Jóhann B. Guðmundsson -
Kevin Kofler -
laolux laolux -
Leigh Scott -
Lennart Poettering -
Luya Tshimbalanga -
majid hussain -
Marc Pervaz Boocha -
Mark Otaris -
Matthew Miller -
Michael Catanzaro -
Michel Alexandre Salim -
Neal Gompa -
Nikolay Nikolov -
Nícolas Wildner -
Peter Boy -
Peter Robinson -
PGNet Dev -
Rahul Sundaram -
Ralf Corsépius -
Randy Barlow -
Richard Hughes -
Richard Shaw -
Richard W.M. Jones -
Robbie Harwood -
Robert Marcano -
Samuel Sieb -
Sebastian Crane -
Simo Sorce -
stan -
Stewart Smith -
Thomas Schmitt -
Tom Hughes -
Vitaly Zaitsev -
Vít Ondruch -
Zamir SUN -
Zbigniew Jędrzejewski-Szmek