On Wed, Jul 1, 2020 at 5:29 PM Jóhann B. Guðmundsson <johan...@gmail.com> wrote:
>
> On 1.7.2020 21:00, Neal Gompa wrote:
> > On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson
> > <johan...@gmail.com> 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.
--
真実はいつも一つ！/ 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
