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.
Could the change owners update the proposal with some more information about when UEFI first started to appear and when legacy BIOS-only machines stopped being made? I understand it may not be possible to get exact and definitive information, but having a general idea of what Fedora's new hardware baseline will be with this proposal will be useful if we get other proposals (e.g. new x86_64 baseline) that propose dropping support for older machines.
The discussion on the list pretty comprehensively indicated that this is not the time to do this, so...
-1
Metadata Update from @ngompa: - Issue tagged with: meeting
I think we could and should discuss how to reduce our maintenance burden, but this proposal is not the way to do this.
Also, this is called "deprecate" but I disagree that what the change does is deprecation.
-1 It's too soon for this.
The Intel et al. 2020 dead-date is mentioned in the "detailed description". Intel evolved the spec themselves between 1998 and 2005 before opening it, so saying definitively "first" is tricky. We care about many of the changes between that and UEFI (2006), so it's tempting to pick that date, but Tiano (the reference open source implementation, used by at least libvirt/qemu, and originally an Intel project) actually predates that (2004). The first machine I can easily find that definitely used it is an Itanium from 2000, and by 2005 it'd become nigh-ubiquitous on Intel hardware.
Hopefully that's helpful. If there's some of that you'd like added, I'm happy to do so (especially if you have a suggestion on how to do it).
(edit: strike out thing that turns out not to have citation)
@rharwood Thanks, this is helpful. I think you can just add this paragraph to the change proposal.
The first machine I can easily find that definitely used it is an Itanium from 2000, and by 2005 it'd become nigh-ubiquitous on Intel hardware.
It doesn't actually seem to be the case that it was ubiquitous on Intel x86 hardware until about 2015. The first non-Mac x86 UEFI systems that actually supported booting in EFI mode started showing up years later. It was a big deal when UEFI came to the Windows world in 2012 with Windows 8. Even then, a lot of PCs only supported Windows 8 for UEFI or had half-broken UEFI firmware, doing all kinds of weird things (see the devel thread about it).
Back then, there was a ton of freaking out about it, because Microsoft also introduced Secure Boot. Red Hat wound up "saving the day" back then for Linux users. That solution was the Secure Boot Shim, which was introduced in Fedora Linux 18: https://fedoraproject.org/wiki/Features/SecureBoot
The first machine I can easily find that definitely used it is an Itanium from 2000, and by 2005 it'd become nigh-ubiquitous on Intel hardware. It doesn't actually seem to be the case that it was ubiquitous on Intel x86 hardware until about 2015. The first non-Mac x86 UEFI systems that actually supported booting in EFI mode started showing up years later. It was a big deal when UEFI came to the Windows world in 2012 with Windows 8. Even then, a lot of PCs only supported Windows 8 for UEFI or had half-broken UEFI firmware, doing all kinds of weird things (see the devel thread about it). Back then, there was a ton of freaking out about it, because Microsoft also introduced Secure Boot. Red Hat wound up "saving the day" back then for Linux users. That solution was the Secure Boot Shim, which was introduced in Fedora Linux 18: https://fedoraproject.org/wiki/Features/SecureBoot
This conflates: hardware implementation, software support and requirements, and UEFI with SecureBoot.
Sure, added (with slight modification to make it read in context) to Detailed Description.
The first machine I can easily find that definitely used it is an Itanium from 2000, and by 2005 it'd become nigh-ubiquitous on Intel hardware. It doesn't actually seem to be the case that it was ubiquitous on Intel x86 hardware until about 2015. The first non-Mac x86 UEFI systems that actually supported booting in EFI mode started showing up years later. It was a big deal when UEFI came to the Windows world in 2012 with Windows 8. Even then, a lot of PCs only supported Windows 8 for UEFI or had half-broken UEFI firmware, doing all kinds of weird things (see the devel thread about it). Back then, there was a ton of freaking out about it, because Microsoft also introduced Secure Boot. Red Hat wound up "saving the day" back then for Linux users. That solution was the Secure Boot Shim, which was introduced in Fedora Linux 18: https://fedoraproject.org/wiki/Features/SecureBoot This conflates: hardware implementation, software support and requirements, and UEFI with SecureBoot.
They all do matter in this context, because all of it was tied together in the first place. Broadly available functioning UEFI for x86 on non-Macs did not show up until it was part of the Windows 8 logo certification program in 2012. And getting Fedora itself to work on those was a real challenge for several years afterward. And for years, even folks like @mjg59 recommended people use legacy BIOS boot through the CSM instead of fighting buggy UEFI boot modes.
In practice, I can't say with any confidence that UEFI on Linux was workable for non-Macs until 2015~2017.
Again, this conflates hardware implementation with software implementation. The original question was purely about hardware with an eye toward "new hardware baseline" - not when Fedora/Linux started working against that baseline.
And in the context of this Change, that additional information matters, because it is the part that the community experiences. When we're considering this change, we have to consider that aspect because our project can't function if we are driving away our contributors because we can't run on their hardware.
You've already voted your decision, unless I'm missing something - are you planning to reconsider?
Nope. But I am laying out the context for the rest of the folks in here to vote on (if they haven't already).
Given you're not making your own decision, what you're doing is propaganda for your viewpoint and I'd appreciate it if you stopped since we can then both spend our time on other things.
I count the vote as rejected (+0,0,-5), however the issue is still tagged for meeting. Should I wait until next week or is this vote settled?
I think we can consider it settled, nobody has voted for the past few days, and we have a majority voting it down already.
I'm -1 to the proposal also as written.
Are the change owners open to the proposed BIOS-boot sig ? ie, the idea of dropping syslinux only, and pushing any bugs or issues with BIOS boot off to the sig? Is FESCo open to that? What conditions would need to have to tell such a SIG is active and maintaining things? Could we get a revised change with that added? (I suppose it would need to have a bunch of input from the BIOS-boot sig)
If the change owners aren't open to that, where does it leave us? Forbidding them from dropping BIOS support?
I suspect this does need more discussion, but I suppose the list is the best place for that.
Dropping the meeting tag on this.
Metadata Update from @ngompa: - Issue untagged with: meeting
Note that technically, we can only reject things:
So far, this has (+0,0,-6) which means it has no chance of being approved (unless people change their minds) but is not technically rejected yet.
https://docs.fedoraproject.org/en-US/fesco/#_ticket_policy
I'm -1 on this change. I think it's good to periodically evaluate the need to support legacy features, but based on the discussion it seems there is still a strong interest in continuing to support legacy BIOS.
This will be discussed at tomorrows meeting.
Metadata Update from @kevin: - Issue tagged with: meeting
As discussed in today's meeting, I'm processing this change as rejected. FESCo will ask BIOS sig to submit a new change with plans/responsibilities.
Metadata Update from @bcotton: - Issue untagged with: meeting - Issue tagged with: pending announcement
I would like any Fesco member that based their decision on now is not the right time to do this to provide an actual date/timeframe when they consider the time being right to do it.
There are still many BIOS-based PCs in the world and you should not rush the steps. I also like me with UEFI not going up normally on Linux (Grub can't boot) but if it stops permanently BIOS Support, then people will choose a system that works in Legacy mode. And I think that would be too hasty. Fedora should be between 40-50 but still after screening. It must be properly prepared and gradually separated. We are not ready for that yet!
Who are those we`s ? + We will never be ready if change proposal like this will never be accept.
What criteria are the fesco members claiming that now is not the time using to assess that?
As experts in your fields, elected to steer the distribution how long are you going to treat firmware security as an afterthought?
Is the plan having the distribution support devices which grant access to the most privileged code on a device, in which attackers would be free to pursue almost any malicious activity from stealing data, to establishing stealthy persistence, to permanently disabling devices and infrastructure indefinetly?
This ticket is not a public forum for discussion, but for FESCo members to vote and make their decision. If you have something to contribute to the discussion, please do so on the mailing list thread.
Nor was this intented for public discussion forums since the questions were directly, directed to fesco members voting but fine I will just file change proposal for deprecation of legacy bios from each release cycle from here on, it will yield the same result.
You don't have to be angry. This is a sensitive topic as you can see. And as I read it is rejected. But then later 2-3 releases are worth a try. It would be childish behavior if you made the suggestion at every release. I'm sorry I polluted this vote
I'm not angry thou I might appear that way, I'm just not a subtle person.
When I looked into running the change proposal 2 years ago there were technical reasons for not doing so now there are none and the fact is there will always be people that own and run old hw and those will always object to this change and then there are those in the industry that wont react until they have to ( be it the bios or something else it does not matter because those people dont like to do any work unless they have to and come up with any excuse for not having to do that work, usually lack of resources of some sort, manpower, lack of money whatever. ).
The proposal that @rharwood @jkonecny @bcl made was a perfectly reasonable start to nudge things into the right direction for the distribution so I ask once more when is the right time and why, surely the persons that voted no based on now was not the right time can answer that.
If that decitions was just based on "gut feeling" or "not the right direction the wind was blowing this time around" then obviously you need to run the change proposal each and every release cycle to see if the wind is blowing in the right direction that time and if not continue until it does.
I'm not angry thou I might appear that way, I'm just not a subtle person. When I looked into running the change proposal 2 years ago there were technical reasons for not doing so now there are none and the fact is there will always be people that own and run old hw and those will always object to this change and then there are those in the industry that wont react until they have to ( be it the bios or something else it does not matter because those people dont like to do any work unless they have to and come up with any excuse for not having to do that work, usually lack of resources of some sort, manpower, lack of money whatever. ). The proposal that @rharwood @jkonecny @bcl made was a perfectly reasonable start to nudge things into the right direction for the distribution so I ask once more when is the right time and why, surely the persons that voted no based on now was not the right time can answer that. If that decitions was just based on "gut feeling" or "not the right direction the wind was blowing this time around" then obviously you need to run the change proposal each and every release cycle to see if the wind is blowing in the right direction that time and if not continue until it does.
I see. Well, then the next cycle will need to be further supported. For example, I have UEFI in, but the installer doesn't work there, so I'm on an MBR.
I think you have to much faith in the installer as in I would not get any hopes up with regards to anything involving the installer since anything involving it, is an decision that must come from Red Hat.
Anaconda, is a RH owned project in the distribution and can practically be considered an closed source project from a (f)oss standpoint ( it even forces users to have bugzilla.redhat.com account [1] ) .
That has always been the case and will remain so until Red Hat has stopped investing in it then Red Hat will do it's classic PR stunt, throw it over the wall to Fedora to see if it sticks there ( move mailinglists and such ) and say here's our installer do what you want with it, so it does not look bad ( the noble gesture PR stunt of RH giving it's "internal" projects to the community ) but at that point RH has already alienated any contributors/contribution to those projects so the trajectory of those projects can never be met with anything but death.
FESCo has voted. If you want to continue to have conversation, please use the devel mailing list, not this ticket.
All you have to ask is what was the end result?
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/KCJCEQMHITAQUW4SMWU3AXIPZ65GSDSU/
Metadata Update from @churchyard: - Issue close_status updated to: Rejected - Issue status updated to: Closed (was: Open)
I see. Well, then the next cycle will need to be further supported. For example, I have UEFI in, but the installer doesn't work there, so I'm on an MBR. I think you have to much faith in the installer as in I would not get any hopes up with regards to anything involving the installer since anything involving it, is an decision that must come from Red Hat. Anaconda, is a RH owned project in the distribution and can practically be considered an closed source project from a (f)oss standpoint ( it even forces users to have bugzilla.redhat.com account [1] ) . That has always been the case and will remain so until Red Hat has stopped investing in it then Red Hat will do it's classic PR stunt, throw it over the wall to Fedora to see if it sticks there ( move mailinglists and such ) and say here's our installer do what you want with it, so it does not look bad ( the noble gesture PR stunt of RH giving it's "internal" projects to the community ) but at that point RH has already alienated any contributors/contribution to those projects so the trajectory of those projects can never be met with anything but death. "Report a new bug or a feature request at: https://bugzilla.redhat.com/" https://github.com/rhinstaller/anaconda
Hi, sorry for the off-topic but wanted to react on this. The reason why Anaconda have bugzilla the only open place for bug reports is that the Anaconda team had basically all the bug reports already there so there were not much benefit of having something else to track both places. If someone from the community will create a PR to implement reporting to GH issues the Anaconda team would be happy about that. The only issue is that we don't have a capacity to do these changes but as always patches are welcome (similar to the BTRFS support parts). Anaconda is definitely not closed project to the upstream changes.
Interesting a whitewash response with, we require PR from a community we never allowed to exist in the first place because we are resources starved ( perhaps Anaconda would have more resources if it had not been so closed to begin with or maybe just maybe it could have more resources if it formed a community upstream... ) anyways you do realize you are a) requesting a PR for going into Settings for the Anaconda repository on github and select the Issues checkbox there or b) File a PR against Red Hat issue tracker an issue tracker that Red Hat has never allowed anyone to submit changes to ( understandably so, clients, sensitive info etc. common sense really from infrastructure standpoint ) and then you name drop some "BTRFS support parts" which has literally no meaning to anyone reading this ( or at best limited scope of people ).
This is not a proper forum to have this discussion. Please stop.
Login to comment on this ticket.