On 1.7.2020 21:50, Neal Gompa wrote:
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.
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.
JBG
_______________________________________________
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
