7:38 a.m.
I was on unattended updates and Friday afternoon the Radeon RS780 machine rebooted into
minimal resolution mode and can no longer go to full HD resolution.
I put the disk into an old laptop with intel GPU where the DKMS modules amdgpu cannot
build properly, thus Radeon machines are screwed.
"/etc/udev/rules.d/70-amdgpu.rules:1 Invalid operator for GROUP."
was what the protocoll had to say.
7:44 a.m.
the broken kernel is
linux /vmlinuz-5.12.7-300.fc34.x86_64
while
linux /vmlinuz-5.12.5-300.fc34.x86_64
worked like a charm.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
1:37 p.m.
On 5/29/21 5:38 AM, eedio wrote:
I was on unattended updates and Friday afternoon the Radeon RS780
machine rebooted into minimal resolution mode and can no longer go to full HD resolution.
I put the disk into an old laptop with intel GPU where the DKMS modules amdgpu cannot
build properly, thus Radeon machines are screwed.
"/etc/udev/rules.d/70-amdgpu.rules:1 Invalid operator for GROUP."
was what the protocoll had to say.
Why are you using the amdgpu dkms? Don't the normal kernel drivers work?
2:45 p.m.
I'm glad you ask this question.
The answer is: I am using whatever Fedo34 installs. Whether "normal kernel
drivers" work, I have no idea.
If you give me a link to switch to those, I will give it a shot.
I am fairly, however, certain that amdgpu is an isolated issue in that particular kernel
update. Hope it helps to zero in on the cause.
2:47 p.m.
2:28 p.m.
On Mon, May 31, 2021 at 12:17 PM L 5 <lff(a)fedoraproject.org> wrote:
I'm glad you ask this question.
The answer is: I am using whatever Fedo34 installs. Whether "normal kernel
drivers" work, I have no idea.
Fedora 34 installations should never, under any circumstances, install
a driver that requires dkms. Packaging out of tree modules is against
fedora policy for a number of reasons. Certainly, there are a number
of users who have installed proprietary or outside of tree drivers
from 3rd party repositories, but rarely is the proprietary AMD driver
in that list, as the open source upstream driver tends to outperform
it in every way. Honestly, I was not even aware that they were still
making releases. Before trying to fix that driver, I would uninstall
it and compare the performance of the in-kernel drivers.
If you give me a link to switch to those, I will give it a shot.
I am fairly, however, certain that amdgpu is an isolated issue in that particular kernel
update. Hope it helps to zero in on the cause.
Third party drivers often can break on kernel rebases. Nvidia tends
to be pretty good about making sure their driver builds against the
latest upstream (released kernel, not development). Others can be
anywhere from good, to very far behind in this regard. By choosing to
remain outside of tree, or proprietary, there is no way for us to know
when they break, and there isn't anything that we can do when it
happens. The driver maintainer/distributor would be the first line of
support there.
Justin
12:57 a.m.
On Mon, 31 May 2021 14:28:58 -0500 astoundingly, Justin Forbes
<jmforbes(a)linuxtx.org> wrote:
On Mon, May 31, 2021 at 12:17 PM L 5 <lff(a)fedoraproject.org>
wrote:
Fedora 34 installations should never, under any circumstances,
install
a driver that requires dkms. Packaging out of tree modules is against
fedora policy for a number of reasons.
testing-kernel has amdgpu modifications, worth a try:
https://packages.stg.fedoraproject.org/pkgs/kernel/fedora-34-updates-test...
2:57 a.m.
New subject: Friday , May 28 unattended update broke amdgpu DKMS -- SOLVED!
On Mon, 31 May 2021 14:28:58 -0500 astoundingly, Justin Forbes
<jmforbes(a)linuxtx.org> wrote:
Third party drivers often can break on kernel rebases.
Thanks Justin!
Though all worked fine for quite a while, after your posting I removed the
amdgpu package, installed the testing kernel just for giggles, and stuff
worked.
Maybe the amdgpu package should point out to dnfdragora users that the
driver package amdgpu is "not needed" and more trouble than it is worth.
:-)
1076
days inactive
1079
days old
7 comments
5 participants
participants (5)
-
e -
eedio
-
Justin Forbes -
L 5 -
Samuel Sieb