Re: The future of legacy BIOS support in Fedora.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 1, 2020 at 6:45 PM Jóhann B. Guðmundsson <johannbg@xxxxxxxxx> wrote:
>
> On 1.7.2020 21:50, Neal Gompa wrote:
> > On Wed, Jul 1, 2020 at 5:29 PM Jóhann B. Guðmundsson <johannbg@xxxxxxxxx> wrote:
> >> On 1.7.2020 21:00, Neal Gompa wrote:
> >>> On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson
> >>> <johannbg@xxxxxxxxx> wrote:
> >>>> On 1.7.2020 16:10, Solomon Peachy wrote:
> >>>>> On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote:
> >>>>>> I'm currently using BIOS, grub, grub2 basically everywhere, even on
> >>>>>> fresh new machines,
> >>>>> This won't be the case for much longer; Intel will finally drop CSM
> >>>>> ("BIOS") support this year.
> >>>>>
> >>>>> Even putting that aside, for the past several years CSM/BIOS has been
> >>>>> slowly bitrotting due to a lack of real testing, as the last few Windows
> >>>>> releases have mandated use of UEFI for preinstalled systems, plus the
> >>>>> EOLing of Windows 7 and (especially) XP.
> >>>> AMD is "strongly" recommending UEFI for the windows [1]
> >>>>
> >>>> So Apple dropped CSM in 2006
> >>>>
> >>>> Intel in 2020
> >>>>
> >>>> AMD is against it's use
> >>>>
> >>>> Windows has moved on with the curve...
> >>>>
> >>> That's great and all, but of all the cloud providers, only Microsoft's
> >>> Azure / Hyper-V platform actually requires UEFI support. Nobody else
> >>> even supports it! Okay, AWS only supports it for AArch64, but not x86.
> >>>
> >>> KVM guys here are still recommending BIOS.
> >>>
> >>> We still can't use NVIDIA proprietary drivers on UEFI because Fedora's
> >>> kernel configuration is too strict for that. I personally consider it
> >>> a good thing, but that's a problem for others.
> >>>
> >>> Fix all the other problems we have with UEFI environments before
> >>> suggesting we drop "legacy BIOS".
> >>>
> >>> It's absolutely shameful that despite us being first to the UEFI
> >>> Secure Boot support, we *still* can't get things working fully in that
> >>> environment. And frankly, from what I can tell from all the people
> >>> involved: nobody cares except for the couple of people who ask every
> >>> few months why we can't have the NVIDIA driver signed and auto-trusted
> >>> so it works. I know every time I ask, people respond with "it's not
> >>> that simple" and more mumbles of Koji architecture problems.
> >>>
> >>> At this point, I personally don't want to see this proposal *ever*
> >>> come up again unless somebody cares about fixing the user experience
> >>> with UEFI.
> >> Based on the feedback here there are atleast 5 - 10 years before we can
> >> even consider removing it so no worries this wont come up again for a
> >> looong time but hopefully there are other areas we can improve upon
> >> which helps us improve the overall UEFI experience in Fedora etc.
> >>
> >> Perhaps it's not that people dont care and more that they are unaware of
> >> those problems  I mean I personally was unaware of those problem and
> >> probably whole lot of other people here as well so could you list in
> >> more detail what exactly those user experience problems with UEFI are
> >> that you are aware of and we can try to compile a todo list to work with.
> >>
> > I suspect you may not be aware because nobody ever bothered to bubble
> > it up to you.
> >
> > I think most people are satisfied with the situation, but I'm not. I
> > despise NVIDIA, but guess what, there's no choice in the marketplace
> > anymore. Everyone ships NVIDIA GPUs, even with AMD CPUs on laptops.
> > And no laptop lets you swap GPUs like you can on desktops.
> >
> > Red Hat probably doesn't care because most server users are not using
> > UEFI yet. That proportion goes down a lot as people transition from on
> > premises to AWS. So this doesn't hurt their partnership with NVIDIA
> > where they tacitly encourage proprietary kernel module usage at scale.
> >
> > Since KVM in RHEL doesn't support UEFI properly either, nobody is
> > seriously looking at the issues caused by multiplexing NVIDIA GPUs and
> > exposing them into virtual machines running in UEFI Secure Boot,
> > because this just doesn't happen there. I've tried it on my Fedora
> > systems, they don't work.
> >
> > On the desktop side, most PC makers shipping Linux are turning UEFI or
> > UEFI Secure Boot off, which lets the NVIDIA driver work. But if you're
> > shipping Secure Boot on by default, as I suspect Lenovo will with
> > their Linux laptops, then the NVIDIA drivers will simply fail to
> > function.
> >
> > Nouveau obviously works (for some definition of works...), but because
> > NVIDIA is awful, it is not a useful driver like amdgpu is.
> >
> > The Fedora Koji Build System is not capable of building kernel module
> > packages and signing them so that they are trusted. The Koji Build
> > System *itself* does not make it easy to offer this functionality in
> > the same way that other build systems (like SUSE's OBS) do. Moreover,
> > we rely on RPM Fusion to build the driver package, which is fine,
> > except nobody can get RPM Fusion's Koji system to sign the driver
> > correctly and have the Fedora kernel trust the RPM Fusion certificate
> > automatically. Nor is there a straightforward way for packages to get
> > installed and have their signatures trusted so that kernel modules
> > that are properly signed will work.
> >
> > The core of it is that nobody cares. It comes up at least once or
> > twice every development cycle in the Workstation Working Group
> > meetings, but there's nothing we can do. Sometimes I'll get bullshit
> > answers from people. Sometimes they'll just say stuff about security.
> > Sometimes they'll say something about it being NVIDIA's problem.
> >
> > Nobody wants to say it, so I will: nobody cares. All of these problems
> > are fixable, just nobody with power wants to fix them.
> >
> >
> Well I whole heartily agree with you assessment that we need fix all
> problems that we can with UEFI environments and up to this point we have
> done piss poor job of it and based on the feedback on this thread I
> suspect there are other usability issues that we are unaware of, other
> than the one you are pointing out.
>
> I mean there is one thing that PC makers are shipping hardware which
> seemingly have this turned on or off at random and novice end user just
> use it since they dont know any better and another when *experience*
> users deliberately go into their bios to disable UEFI and as I said I
> suspect there is something more going on than it's all due to nvidia GPU.
>

I'm fairly certain there are other issues, but that's the most popular
one that gets brought up, so it remains at the forefront of my
attention.



-- 
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux