Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Fri, Apr 8, 2022, 11:52 Neal Gompa wrote: > On Fri, Apr 8, 2022 at 11:47 AM Jared Dominguez wrote: > > > > > > > > > > On Thu, Apr 7, 2022, 19:46 Samuel Sieb wrote: > >> > >> On 4/7/22 14:51, Jared Dominguez wrote: > >> > On Thu, Apr 7, 2022 at 3:49 PM Samuel Sieb >> > <mailto:sam...@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. > If the experience is buggy with Windows too, HP probably has addressed that as previously stated, which is why I asked about how up-to-date Samuel's BIOS is. On several occasions I've seen complaints about firmware issues that are solved by updating. Firmware is software too. If not, that sounds like a big in Fedora and possibly Linux in general. Windows is the reference operating system for most personal computer manufacturers, whether we like it or not. Just because Dell is sometimes good at its job doesn't mean everyone > else is. The reality is that most aren't. > > [1]: > https://press.hp.com/us/en/press-releases/2021/hp-powers-real-time-collaboration-workflows.html > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedorapr
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Thu, Apr 7, 2022, 19:46 Samuel Sieb wrote: > On 4/7/22 14:51, Jared Dominguez wrote: > > On Thu, Apr 7, 2022 at 3:49 PM Samuel Sieb > <mailto:sam...@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. ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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 > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
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-le...@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 > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Thu, Apr 7, 2022 at 3:49 PM Samuel Sieb 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-le...@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 > -- Jared Dominguez (he/him) Software Engineering Manager New Platform Technologies Enablement team RHEL Workstation Engineering ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Thu, Apr 7, 2022 at 4:18 PM Florian Weimer wrote: > * Chris Murphy: > > > On Thu, Apr 7, 2022 at 2:54 AM Florian Weimer > wrote: > >> > >> * Chris Murphy: > >> > >> > On Tue, Apr 5, 2022 at 9:56 AM Florian Weimer > 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-le...@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 > -- Jared Dominguez (he/him) Software Engineering Manager New Platform Technologies Enablement team RHEL Workstation Engineering If I am emailing outside of business hours (mine or yours), it is my choice and does not mean I expect you to respond today. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Thu, Apr 7, 2022 at 11:09 AM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Wed, Apr 06, 2022 at 10:47:30AM -0400, Robbie Harwood wrote: > > majid hussain 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-le...@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 > -- Jared Dominguez (he/him) Software Engineering Manager New Platform Technologies Enablement team RHEL Workstation Engineering If I am emailing outside of business hours (mine or yours), it is my choice and does not mean I expect you to respond today. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Thu, Apr 7, 2022 at 4:58 AM Peter Boy wrote: > > > > Am 07.04.2022 um 00:25 schrieb Neal Gompa : > > > > 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-le...@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 > -- Jared Dominguez (he/him) Software Engineering Manager New Platform Technologies Enablement team RHEL Workstation Engineering If I am emailing outside of business hours (mine or yours), it is my choice and does not mean I expect you to respond today. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Thu, Apr 7, 2022 at 10:36 AM Neal Gompa wrote: > On Thu, Apr 7, 2022 at 10:03 AM Jared Dominguez wrote: > > > > > > > > On Thu, Apr 7, 2022 at 4:51 AM Dominik 'Rathann' Mierzejewski < > domi...@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 < > mcatanz...@gnome.org> > >> > wrote: > >> > > >> > > On Wed, Apr 6 2022 at 01:57:00 PM -0400, Neal Gompa > >> > > 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_roster_looking_to_challenge_the_us_cloud_dominance/ > > 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-le...@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 > -- Jared Dominguez (he/him) Software Engineering Manager New Platform Technologies Enablement team RHEL Workstation Engineering If I am emailing outside of business hours (mine or yours), it is my choice and does not mean I expect you to respond today. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Thu, Apr 7, 2022 at 4:51 AM Dominik 'Rathann' Mierzejewski < domi...@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 > > wrote: > > > > > On Wed, Apr 6 2022 at 01:57:00 PM -0400, Neal Gompa > > > 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-le...@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 > -- Jared Dominguez (he/him) Software Engineering Manager New Platform Technologies Enablement team RHEL Workstation Engineering If I am emailing outside of business hours (mine or yours), it is my choice and does not mean I expect you to respond today. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Wed, Apr 6, 2022 at 2:26 PM Michael Catanzaro wrote: > On Wed, Apr 6 2022 at 01:57:00 PM -0400, Neal Gompa > 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-limitations.html 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-le...@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 > -- Jared Dominguez (he/him) Software Engineering Manager New Platform Technologies Enablement team RHEL Workstation Engineering ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
he scene in the PC space in > > > 2011~2012 with Windows 8, and even to this day, there are sufficiently > > > buggy hardware platforms that Linux does not boot in UEFI mode: > > > https://twitter.com/VKCsh/status/1511132132885815307 > > > > > > I even have one such machine, an HP desktop machine that came with > > > Windows 8. My current desktop PC has problems booting Linux UEFI as > > > well, though I've done "clever" things to work around that. I don't > > > expect most users to be able to deal with that. Server platforms were > > > *worse* as they were slower to offer UEFI. The first time I was able > > > to get a server with UEFI was in 2014. > > > > > > Maybe I don't correctly understand the "Legacy BIOS support is not > > removed, but new non-UEFI installation is not supported on those > > platforms." quoted from the the change description, but if you have your > > system installed, it should keep working. You just keep updating. IOW as > > long as you don't reinstall the system, you are fine and you don't have > > to be concerned. > > > > If you really have a need to reinstall such machine, you'll take the F36 > > image and upgrade to F37+ and you should still be good. > > > > This is not a deprecation change, this is effectively a removal > change. By removing the packages and the tooling support for legacy > BIOS, it makes several scenarios (including recovery) harder. > Moreover, it puts the burden on people to figure out if their hardware > can boot and install Fedora when we clearly haven't reached a critical > mass yet for doing so, like we did when we finally removed the i686 > kernel build. > > I'm personally a fan of using UEFI instead of BIOS. Heck, I > implemented support for UEFI in Fedora's cloud images when other > people told me it was not possible, while preserving BIOS support. > I've been trying to figure out the roadmap for BIOS deprecation for a > year now, and the reason *I* didn't propose a Change yet is because I > have not sufficiently determined that it was reasonable to do so. > > I'm particularly upset about this Change because it feels like a > hostage change where the proposal owners blithely ignore what we're > saying as unimportant or irrelevant and abuse our principles to do > things that are clearly against what the community feels is right. > This strikes me as a very negative view of what we're trying to do. We're trying to figure out a timeline for deprecation and openly discuss, which is why this change proposal is here now. Support for legacy x86 boot is rapidly vanishing across the industry. Code is rotting in Fedora. The Red Hat team doing the work in the bootloader space doesn't have capacity for continuing support for legacy x86 boot anyway. We're attempting to communicate boundaries and available commitment and work in the community on a workable plan. This proposal includes a call for community assistance if there's sufficient desire to maintain the status quo longer. You are welcome to constructively help with that. Hearing accusations of folks, who are operating on good faith, engaging in "abuse" and executing a "hostage change" feels concerning to me. I have been trying in the background for years to try to figure out > solutions for usability problems in Fedora Linux on UEFI because *I > want our experience to be good there*. But it's extremely hard when: > > 1. Bugs and feature requests around UEFI related features are ignored > Per my reply to you yesterday, I would be grateful if you would list out examples here. This is the second time I've heard this, and it's not concrete enough for a constructive conversation on that topic. 2. The packages are locked down so there is no way for the community to help > 3. At various times, people have explicitly said "patches NOT welcome" > Robbie already responded to this, but I would like to add that if any of this ever actually becomes true, I would like to know so that I can address any such issue with this Red Hat team. From what I've seen, we very much welcome community involvement. In fact, we are collaborating on a daily basis with the bootloader community on grub2 and shim development. I'm angry because we're doing this without any real thought around the > consequences for the user experience, and we should not do that as a > premier Linux distribution. > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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 > -- Jared Dominguez (he/him) Software Engineering Manager New Platform Technologies Enablement team RHEL Workstation Engineering ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 8:51 PM Chris Murphy wrote: > On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton 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-le...@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 > -- Jared Dominguez (he/him) Software Engineering Manager New Platform Technologies Enablement team RHEL Workstation Engineering If I am emailing outside of business hours (mine or yours), it is my choice and does not mean I expect you to respond today. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 7:39 PM Chris Murphy wrote: > On Tue, Apr 5, 2022 at 3:08 PM Jared Dominguez 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-le...@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 > -- Jared Dominguez (he/him) Software Engineering Manager New Platform Technologies Enablement team RHEL Workstation Engineering ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
uired 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-le...@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 > -- Jared Dominguez (he/him) Software Engineering Manager New Platform Technologies Enablement team RHEL Workstation Engineering If I am emailing outside of business hours (mine or yours), it is my choice and does not mean I expect you to respond today. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022, 11:15 Neal Gompa wrote: > On Tue, Apr 5, 2022 at 10:54 AM 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: rharw...@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.org/thread/QBANCA2UAJ5ZSMDVVARLIYAJE66TYTCD/ > > > > 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:
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
On Thu, Jul 2, 2020 at 4:53 AM Benjamin Berg wrote: > On Wed, 2020-07-01 at 11:07 -0500, Michael Catanzaro wrote: > > So the last two times thermald was proposed (first as a F32 change > > proposal, then more recently to the Workstation WG) it was rejected on > > the grounds that it was not useful without dptfxtract installed. Now > > it's clear that everybody was mistaken about that, so seems it makes > > sense to reconsider. > > > > I have a couple questions. First, why is thermal management occurring > > in userspace? Can you please provide a technical explanation as to why > > the kernel is not the right place for this code? > > The thermal daemon has a bit of information: > > https://01.org/linux-thermal-daemon/documentation/introduction-thermal-daemon > > It lists the following reasons: > * A short time to market > * Proactively controlled temperature > * Use of existing kernel infrastructure > * A defined architecture, which can be easily enhanced. > > In general, I don't see a problem with moving some logic into > userspace. It is not like the kernel is in a much better position to > make decisions. It only is closer to the hardware from an architectural > point of view and will only be in a better position if decisions must > not be delayed (e.g. protecting the hardware from overheating). > It's also a design meant to mimic Intel's Windows implementation, which allows for more advanced control based on workloads as desired in some of the more advanced flavors of DPTF (i.e. not Passive). > On Wed, Jul 1, 2020 at 11:53 am, Richard W.M. Jones > > wrote: > > > Is there some background about why dptfxtract is proprietary? (I see > > > that it's a program provided by Intel.) Is it just because no one's > > > done the work to make a free equivalent or does it require some > > > secret/patented/whatever knowledge to work? > > > > I'm also interested in this question. In particular, since thermald and > > dptfxtract are both the same upstream, it seems really hostile to the > > open source community for thermald to perform better if you have this > > extra proprietary portion of the project installed. > > My interpretation is that, Intel is trying to protect their IP around > thermal management and how DPTF works in particular. > Some additional context: When I was at Dell, I helped push for Intel to start supporting more DPTF features on Linux in order for Dell to be able to ship Linux on our more thermally constrained mechanical designs. DPTF Passive 1.0 (and some other stuff? can't remember the state back then) was already supported by thermald. Due to Intel's IP concerns, we couldn't get an open source implementation of the userspace logic used for other DPTF policies, but we could get someone at Intel to write dptfxtract, which tries to make a smart interpretation of some of the otherwise unsupported (on Linux) tables and output tables that are usable on Linux. Unfortunately, I cannot share details of Intel's IP concerns due to NDA I'm still beholden to. Note however that dptfxtract wasn't meant to be a be-all-end-all but rather a solution to the immediate problem of Linux being behind in support DPTF, which is widely implemented by Intel-based laptops in the market. It was released with the understanding that it's an imperfect solution, and that is part of why it was made to be an _optional_ addition to thermald. I can't speak for Intel, but I trust that they'll come forward when they are ready to release to the community better Linux solutions for supporting DPTF. I suspect that would largely come as additions to thermald. > So, for me, the hostile part here is that we are dealing with a > hardware platform that contains components for which the manufacturer > is not willing to provide proper documentation. > > The thermald upstream on the other hand is trying to provide the best > possible experience while working under these imposed constraints. So > thermald will use all the information that it can get, and dptfxtract > allows exporting proprietary information encoded in the DPTF related > data stored in ACPI. > > Benjamin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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 > -- Jared Dominguez (he/him) Laptop/Desktop Hardware Enablement Manager RHEL Workstation Engineering ___ devel mailing list -- devel@
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
On Tue, Jun 30, 2020 at 3:41 PM Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > On 30.06.2020 19:43, Hans de Goede wrote: > > That is the first time I have heard that. Do you have a source for that ? > > https://github.com/intel/dptfxtract - no sources, only proprietary > binaries. > > The legal status of the extracted tables was discussed a few months ago > with members of the Fedora legal team. You can check archives. > Regardless of the legality of tables output from dptfxtract, that doesn't really address the fact that thermald, as is in Fedora 32 today (version 1.9.1 from December) doesn't have dptfxtract (nor do later versions bundle it) and results in an improvement in thermal behavior on supported systems without any thermal tables in /etc/thermald. -- Jared Dominguez (he/him) Laptop/Desktop Hardware Enablement Manager RHEL Workstation Engineering ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
On Tue, Jun 30, 2020 at 12:10 PM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:
> On 30.06.2020 17:57, Jared Dominguez wrote:
> > Something that needs to be cleared up here: thermald has existed for the
> > better part of a decade and long before dptfxtract existed.
>
> Thermald will not work without config being installed.
>
> You can remove all configs from /etc/thermald and try to start systemd
> unit. It will shutdown immediately.
>
(BTW, for some context, I was directly involved in the discussion at Dell
-- when I was one of the Linux leads there -- that resulted in someone at
Intel creating dptfxtract as a temporary solution until Intel's open source
folks could find a better solution for supporting DPTF Active policies. I
started at Red Hat in April and asked Benjamin to revisit this topic since
thermald is still incredibly useful without dptfxtract. Plus, a former
colleague at Dell noticed some Fedora users having issues that are solved
by using thermald (even without dptfxtract).)
thermald predates dptfxtract existing. dptfxtract exists to dynamically
pull OEM platform specific configs for only certain kinds of newer DPTF
tables. thermald still runs on most other Intel systems. For example, my
system only has /etc/thermald/thermal-cpu-cdev-order.xml inside
/etc/thermald, and that one xml file only contains this:
"""
rapl_controller
intel_pstate
intel_powerclamp
cpufreq
Processor
"""
I wouldn't consider the above file legally dubious.
After enabling thermald, it's definitely running:
$ rpm -q thermald
thermald-1.9.1-2.fc32.x86_64
$ systemctl status thermald
● thermald.service - Thermal Daemon Service
Loaded: loaded (/usr/lib/systemd/system/thermald.service; enabled;
vendor preset: disabled)
Active: active (running) since Tue 2020-06-30 13:01:50 EDT; 12min ago
Main PID: 296760 (thermald)
Tasks: 2 (limit: 18941)
Memory: 2.5M
CPU: 70ms
CGroup: /system.slice/thermald.service
└─296760 /usr/sbin/thermald --no-daemon --dbus-enable
--
Jared Dominguez (he/him)
Laptop/Desktop Hardware Enablement Manager
RHEL Workstation Engineering
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
On Tue, Jun 30, 2020 at 11:49 AM Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > On 30.06.2020 15:25, Ben Cotton wrote: > > Better thermal management and peak performance on Intel CPUs by > > including thermald in the default install. > > Good, but thermald is absolutely useless without configs. Configs can be > extracted from DPTF ACPI tables only with *proprietary* dptfextract > utility. > > Also Fedora cannot ship extracted by dptfextract configs due to their > legal status. > Something that needs to be cleared up here: thermald has existed for the better part of a decade and long before dptfxtract existed. dptfxtract exists to handle certain platforms that use DPTF Active. thermald supports many, many more platforms than that without the need for any closed-source tools. Additionally, with code that is queued in a thermald branch, we may not need dptfxtract for any use cases soon. -- Jared Dominguez (he/him) Laptop/Desktop Hardware Enablement Manager RHEL Workstation Engineering ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: [External] Re: Fedora+Lenovo
On Tue, May 5, 2020 at 8:25 PM Michel Alexandre Salim < mic...@michel-slm.name> wrote: > On 5/1/20 6:19 AM, Jared Dominguez wrote: > > First post here for me too. I'm chiming in both as a newly minted Red > > Hat guy and as a former Dell Linux person. :) I'm always a Linux person > > though and work with Mark as well as folks at other OEMs. > > Welcome! You won't happen to know if there's an effort to bring > first-class Fedora support to Dells too, would you? ;) > My lips would be sealed with two NDAs. ;) You'd have to ask my good friend Barton George. But I will say that Dell was the first major OEM to ship Linux and has been shipping RH(E)L on Dell Precision continuously for 21 years (in addition to Ubuntu for 12 continuous years). You're in good hands with Dell if you choose to buy their products. And if you're a ThinkPad person, well clearly the choice is easier! It's great to see so much competition in the Linux laptop space these days! > Cheers, > > -- > Michel Alexandre Salim > profile: https://keybase.io/michel_slm > chat via email: https://delta.chat/ > GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2 > -- Jared Dominguez (he/him) Laptop Hardware Enablement Manager RHEL Workstation Engineering ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: [External] Re: Fedora+Lenovo
First post here for me too. I'm chiming in both as a newly minted Red Hat guy and as a former Dell Linux person. :) I'm always a Linux person though and work with Mark as well as folks at other OEMs. On Fri, May 1, 2020, 08:54 Mark Pearson wrote: > Hi Vitaly > > From: Vitaly Zaitsev via devel > > Sent: Friday, May 1, 2020 7:05 AM > > > > On 01.05.2020 12:52, Peter Robinson wrote: > > > I bet this is actually the Intel Dynamic Platform and Thermal > > > Framework (DPTF) that's at fault here [1] and so while I'm sure Lenovo > > > can approach Intel and assist I'm not sure it's something they can fix > > > directly, on the plus side it looks like it's being reverse engineered > > > in general. > > > > This is definitely Lenovo's fault. I have also Dell XPS 13 and it works > > absolutely fine on GNU/Linux. Not throttling issues at all. > > > Afraid I somewhat disagree. I think we should have done more earlier, but > I don't think the root cause is ours. > > I have no idea how the Dell XPS 13 solves this issue (or if it had the > same > in the first place) but my understanding of the problem is needing the > adaptive > support from DPTF to detect between lap and desk mode. > There's some interesting mechanical work the mechanical engineers at Dell implemented. Look up "XPS 13 Mars Rover", which is super cool. Their fan and heat pipe solution on the current generation models is a big difference too. DPTF Adaptive Performance Policy is a tricky one for reasons I won't get into. There's currently no complete open source solution. Platforms that are dependent on it are also currently dependent on a closed source solution from Intel. Even Google chose to ship with a closed source DPTF Adaptive Performance Policy on some fanless Chromebook designs. Matthew Garrett has done some work on a reverse engineered implementation of Adaptive Performance, but it's still a work in progress as I remember. We have to meet some temperature safety requirements when the device is on > lap. Because Linux doesn't have support for that the device defaults to > the 'safer' > power setting and you see thermal throttling (and lower performance than > Windows). The new firmware does that lap/desk mode detection - and I'm > told > implementing that in the BIOS/EC firmware framework was non-trivial, It > was > done purely for Linux customers. The performance now for Linux users > should > be the same as for Windows users. > > I think if DPTF had been open-sourced the thermal throttling would have > been a > non-issue. I can't comment on why that hasn't happen - I think really > that's a > question for Intel. > Perhaps there are better solutions possible? They all get a bit vendor > specific and > I suspect would have been hard to upstream so firmware is a reasonable fix > in > my opinion. > Parts of DPTF Passive are implemented on Linux as open source, but Active and other newer stuff are where things get tricky. Mark > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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 > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
