9:08 p.m.
Hi,
I used dnf system-upgrade to upgrade from F38 to F39. After the
upgrade when I booted into gdm to login and start KDE, the machine hung
on KDE startup into X11.
Thinking it might be an nvidia UEFI enrolment issue with the F39
nvidia drivers, I reset the machine and booted back into gdm.
I then used ctrl+alt+F2 to start a terminal interface. In that
terminal I went through the UEFI enrolment process but that said the
drivers were already enrolled.
I issued dmesg to see if there were any nvidia failure messages, of
which there none, but I did notice there were initialisation and what
looked like failure messages from Nouveau, but I don't understand why
there would be an Nouveau messages at all when Nouveau is blacklisted in
the kernel parameters in grub.
I then uninstalled all the nvidia drivers that were present. I then
used ctrl+alt+delete to reboot from the terminal. That process hung for
1.5 minutes waiting for a job stop (I don't remember what it was waiting
on), and, when the 1.5 minute timer finished it then hung waiting for
XWayland to shut down. Why was it waiting for XWayland to shut down when
I don't use Wayland, I only use X11?
On reboot, I started up KDE under Nouveau, which doesn't work
properly with my BENQ 4K monitor, it can't determine what the monitor
is, so doesn't run in the right resolutions, although it does honour the
display scaling specified when using the nvidia drivers (which do
recognise the monitor and set things up properly).
I reinstalled the nvidia drivers and a subsequent reboot then
booted into KDE with any issues (which is where I'm sending this email
from). Why did this freezing of the nvidia drivers happen, is it because
the F39 nvidia drivers don't work properly with an update and have to be
installed from scratch to work properly?
Also, after reinstalling the nvidia drivers, at the gdm login
screen the display manager selection options only showed "Gnome", "Gnome
Classic" and "Plasma/X11", where are the options for all of those to
swap them between Wayland and X11 if I want to, that were present in F38
before the upgrade to F39?
regards,
Steve
9:28 p.m.
On Fri, Nov 17, 2023 at 10:08 PM Stephen Morris
<samorris(a)netspace.net.au> wrote:
Hi,
I used dnf system-upgrade to upgrade from F38 to F39. After the
upgrade when I booted into gdm to login and start KDE, the machine hung
on KDE startup into X11.
Thinking it might be an nvidia UEFI enrolment issue with the F39
nvidia drivers, I reset the machine and booted back into gdm.
I then used ctrl+alt+F2 to start a terminal interface. In that
terminal I went through the UEFI enrolment process but that said the
drivers were already enrolled.
I issued dmesg to see if there were any nvidia failure messages, of
which there none, but I did notice there were initialisation and what
looked like failure messages from Nouveau, but I don't understand why
there would be an Nouveau messages at all when Nouveau is blacklisted in
the kernel parameters in grub.
I then uninstalled all the nvidia drivers that were present. I then
used ctrl+alt+delete to reboot from the terminal. That process hung for
1.5 minutes waiting for a job stop (I don't remember what it was waiting
on), and, when the 1.5 minute timer finished it then hung waiting for
XWayland to shut down. Why was it waiting for XWayland to shut down when
I don't use Wayland, I only use X11?
On reboot, I started up KDE under Nouveau, which doesn't work
properly with my BENQ 4K monitor, it can't determine what the monitor
is, so doesn't run in the right resolutions, although it does honour the
display scaling specified when using the nvidia drivers (which do
recognise the monitor and set things up properly).
I reinstalled the nvidia drivers and a subsequent reboot then
booted into KDE with any issues (which is where I'm sending this email
from). Why did this freezing of the nvidia drivers happen, is it because
the F39 nvidia drivers don't work properly with an update and have to be
installed from scratch to work properly?
Also, after reinstalling the nvidia drivers, at the gdm login
screen the display manager selection options only showed "Gnome", "Gnome
Classic" and "Plasma/X11", where are the options for all of those to
swap them between Wayland and X11 if I want to, that were present in F38
before the upgrade to F39?
A couple of thoughts in no particular order. I don't know how you
should move forward with your issues.
* The KDE spin uses Wayland, not X11.
* The KDE spin uses SDDM, not GDM.
* SecureBoot should be turned off if using tainted kernel drivers. Or,
you can cutover to driver signing. I usually turn off SecureBoot
because I don't like messing around with driver signing. In my case,
it usually is due to VirtualBox, not NVIDIA.
Jeff
6:15 a.m.
On Fri, 2023-11-17 at 22:28 -0500, Jeffrey Walton wrote:
A couple of thoughts in no particular order. I don't know how
you
should move forward with your issues.
* The KDE spin uses Wayland, not X11.
I use KDE with X11. You just have to select it on the login screen.
AFAIK KDE 6 will default to Wayland in an upcoming release, without
support for X11, but that isn't currently the case.
poc
11 a.m.
On Sat, Nov 18, 2023 at 7:16 AM Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
On Fri, 2023-11-17 at 22:28 -0500, Jeffrey Walton wrote:
> A couple of thoughts in no particular order. I don't know how you
> should move forward with your issues.
>
> * The KDE spin uses Wayland, not X11.
>
I use KDE with X11. You just have to select it on the login screen.
AFAIK KDE 6 will default to Wayland in an upcoming release, without
support for X11, but that isn't currently the case.
Oh, that's good news. I might have to poke around and try it.
I really miss "disable touchpad when mouse plugged in." libinput and
X11 provide it, Wayland does not.
Jeff
11:10 p.m.
On 18/11/23 14:28, Jeffrey Walton wrote:
On Fri, Nov 17, 2023 at 10:08 PM Stephen Morris
<samorris(a)netspace.net.au> wrote:
> Hi,
> I used dnf system-upgrade to upgrade from F38 to F39. After the
> upgrade when I booted into gdm to login and start KDE, the machine hung
> on KDE startup into X11.
> Thinking it might be an nvidia UEFI enrolment issue with the F39
> nvidia drivers, I reset the machine and booted back into gdm.
> I then used ctrl+alt+F2 to start a terminal interface. In that
> terminal I went through the UEFI enrolment process but that said the
> drivers were already enrolled.
> I issued dmesg to see if there were any nvidia failure messages, of
> which there none, but I did notice there were initialisation and what
> looked like failure messages from Nouveau, but I don't understand why
> there would be an Nouveau messages at all when Nouveau is blacklisted in
> the kernel parameters in grub.
> I then uninstalled all the nvidia drivers that were present. I then
> used ctrl+alt+delete to reboot from the terminal. That process hung for
> 1.5 minutes waiting for a job stop (I don't remember what it was waiting
> on), and, when the 1.5 minute timer finished it then hung waiting for
> XWayland to shut down. Why was it waiting for XWayland to shut down when
> I don't use Wayland, I only use X11?
> On reboot, I started up KDE under Nouveau, which doesn't work
> properly with my BENQ 4K monitor, it can't determine what the monitor
> is, so doesn't run in the right resolutions, although it does honour the
> display scaling specified when using the nvidia drivers (which do
> recognise the monitor and set things up properly).
> I reinstalled the nvidia drivers and a subsequent reboot then
> booted into KDE with any issues (which is where I'm sending this email
> from). Why did this freezing of the nvidia drivers happen, is it because
> the F39 nvidia drivers don't work properly with an update and have to be
> installed from scratch to work properly?
> Also, after reinstalling the nvidia drivers, at the gdm login
> screen the display manager selection options only showed "Gnome",
"Gnome
> Classic" and "Plasma/X11", where are the options for all of those to
> swap them between Wayland and X11 if I want to, that were present in F38
> before the upgrade to F39?
A couple of thoughts in no particular order. I don't know how you
should move forward with your issues.
* The KDE spin uses Wayland, not X11.
* The KDE spin uses SDDM, not GDM.
I originally installed F36 from a live DVD which installs a Gnome spin
with gdm. I then installed KDE by doing a dnf group install of Plasma
which still leaves GDM as the default Display Manager. I then upgraded
to F38 via dnf system-upgrade and then to F39 via dnf system-upgrade,
all of which leave gdm as the display manager. I can then boot into
Gnome (which I do infrequently) and KDE both in X11 by selecting the
appropriate menu option in a GDM, as indicated by Patrick in a
subsequent thread.
* SecureBoot should be turned off if using tainted kernel drivers.
Or,
you can cutover to driver signing. I usually turn off SecureBoot
because I don't like messing around with driver signing. In my case,
it usually is due to VirtualBox, not NVIDIA.
As my system is a tri-boot between Windows 11, Fedora 39 and Ubuntu
22.04, and Windows doesn't seem to work properly with UEFI disabled,
I've gone down the path of signing the nvidia drivers under Fedora and
Ubuntu, using separate passwords as I found using the same password
causes thing to not work properly.
regards,
Steve
Jeff
--
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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/users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
1:29 a.m.
Jeffrey Walton wrote:
> * SecureBoot should be turned off if using tainted kernel
drivers. Or,
> you can cutover to driver signing. I usually turn off SecureBoot
> because I don't like messing around with driver signing. In my case,
> it usually is due to VirtualBox, not NVIDIA.
Stephen Morris:
As my system is a tri-boot between Windows 11, Fedora 39 and Ubuntu
22.04, and Windows doesn't seem to work properly with UEFI disabled,
I've gone down the path of signing the nvidia drivers under Fedora and
Ubuntu, using separate passwords as I found using the same password
causes thing to not work properly.
UEFI is a hardware interface (simplifying that description quite a lot)
between the PC's hardware, firmware, and the OS before it boots, and
the control screens it gives you for you to configure things. It's an
update on the similiar, but more primitive, thing done with the old
BIOS.
Secure boot is a *separate* thing (though probably only exists on
systems with UEFI). It's to do with only booting up from signed
binaries (to verify that only authentic things can run, blocking any
fake things that have snuck in).
A problem with Secure Boot is that there are real and genuine things
you may want to use that are not signed (such as some graphics card
drivers). One solution to that is to sign them yourself, with a
signature that you let things know that *you* trust.
("Signed" in these contexts is to do with cryptographic keys.)
Though again, it could be that Windows won't boot without secure boot
options set, not UEFI being disabled (not that I've seen a motherboard
where you could disable UEFI and go back to BIOS). That and the TPM
hardware that's touted as being more fantastic than it really is.
As a home user you may feel that this security is kinda pointless, as
no-one else is going to touch your PC and sneak things in. And
anything nasty that does get in is going to get in by your own
behaviour doing unwise things, for which you're going to ignore and
disable any warnings not to do it. To that degree, that's true. And
the same can be said about AntiVirus, SELinux, file permissions and
ownership. But where such security features can help, is when you
start to do something unwise without realising it, it blocks you, and
you properly investigate the reasons.
--
uname -rsvp
Linux 3.10.0-1160.102.1.el7.x86_64 #1 SMP Tue Oct 17 15:42:21 UTC 2023 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
3:49 a.m.
On 19/11/2023 07:29, Tim via users wrote:
Jeffrey Walton wrote:
>> * SecureBoot should be turned off if using tainted kernel drivers. Or,
>> you can cutover to driver signing. I usually turn off SecureBoot
>> because I don't like messing around with driver signing. In my case,
>> it usually is due to VirtualBox, not NVIDIA.
Stephen Morris:
> As my system is a tri-boot between Windows 11, Fedora 39 and Ubuntu
> 22.04, and Windows doesn't seem to work properly with UEFI disabled,
> I've gone down the path of signing the nvidia drivers under Fedora and
> Ubuntu, using separate passwords as I found using the same password
> causes thing to not work properly.
>
UEFI is a hardware interface (simplifying that description quite a lot)
between the PC's hardware, firmware, and the OS before it boots, and
the control screens it gives you for you to configure things. It's an
update on the similiar, but more primitive, thing done with the old
BIOS.
Secure boot is a *separate* thing (though probably only exists on
systems with UEFI). It's to do with only booting up from signed
binaries (to verify that only authentic things can run, blocking any
fake things that have snuck in).
A problem with Secure Boot is that there are real and genuine things
you may want to use that are not signed (such as some graphics card
drivers). One solution to that is to sign them yourself, with a
signature that you let things know that *you* trust.
("Signed" in these contexts is to do with cryptographic keys.)
Though again, it could be that Windows won't boot without secure boot
options set, not UEFI being disabled (not that I've seen a motherboard
where you could disable UEFI and go back to BIOS). That and the TPM
hardware that's touted as being more fantastic than it really is.
As a home user you may feel that this security is kinda pointless, as
no-one else is going to touch your PC and sneak things in. And
anything nasty that does get in is going to get in by your own
behaviour doing unwise things, for which you're going to ignore and
disable any warnings not to do it. To that degree, that's true. And
the same can be said about AntiVirus, SELinux, file permissions and
ownership. But where such security features can help, is when you
start to do something unwise without realising it, it blocks you, and
you properly investigate the reasons.
In https://bugzilla.redhat.com/show_bug.cgi?id=2011120 I reported seeing
this problem on one system, but not on another. The one with the
problem, solved by reinstalling the rpmfusion 470xx packages. has dual
boot with Windows 10 - but the selection is made via the HP BIOS
immediately after power-up; the default is Windows, but if 'escaped' in
the first few seconds it offers other options, including UEFI boots of
Windows and Fedora. Choosing Fedora gives the normal grub screen.
It's inconvenient but it works and I haven't tried changing it 'for fear
of finding something worse'. Maybe I should add this info to the BZ.
Might it explain the different behaviour on Fedora version upgrade?
John P
3:48 a.m.
On 19/11/23 18:29, Tim via users wrote:
Jeffrey Walton wrote:
>> * SecureBoot should be turned off if using tainted kernel drivers. Or,
>> you can cutover to driver signing. I usually turn off SecureBoot
>> because I don't like messing around with driver signing. In my case,
>> it usually is due to VirtualBox, not NVIDIA.
Stephen Morris:
> As my system is a tri-boot between Windows 11, Fedora 39 and Ubuntu
> 22.04, and Windows doesn't seem to work properly with UEFI disabled,
> I've gone down the path of signing the nvidia drivers under Fedora and
> Ubuntu, using separate passwords as I found using the same password
> causes thing to not work properly.
>
UEFI is a hardware interface (simplifying that description quite a lot)
between the PC's hardware, firmware, and the OS before it boots, and
the control screens it gives you for you to configure things. It's an
update on the similiar, but more primitive, thing done with the old
BIOS.
Secure boot is a *separate* thing (though probably only exists on
systems with UEFI). It's to do with only booting up from signed
binaries (to verify that only authentic things can run, blocking any
fake things that have snuck in).
A problem with Secure Boot is that there are real and genuine things
you may want to use that are not signed (such as some graphics card
drivers). One solution to that is to sign them yourself, with a
signature that you let things know that *you* trust.
("Signed" in these contexts is to do with cryptographic keys.)
Though again, it could be that Windows won't boot without secure boot
options set, not UEFI being disabled (not that I've seen a motherboard
where you could disable UEFI and go back to BIOS).
The current motherboard I have and the previous one both allow UEFI to
be disabled and they also both provide a means to turn off secure boot
as well.
regards,
Steve
That and the TPM
hardware that's touted as being more fantastic than it really is.
As a home user you may feel that this security is kinda pointless, as
no-one else is going to touch your PC and sneak things in. And
anything nasty that does get in is going to get in by your own
behaviour doing unwise things, for which you're going to ignore and
disable any warnings not to do it. To that degree, that's true. And
the same can be said about AntiVirus, SELinux, file permissions and
ownership. But where such security features can help, is when you
start to do something unwise without realising it, it blocks you, and
you properly investigate the reasons.
11:11 p.m.
On 11/17/23 19:08, Stephen Morris wrote:
I reinstalled the nvidia drivers and a subsequent reboot then
booted into KDE with any issues (which is where I'm sending this email
from). Why did this freezing of the nvidia drivers happen, is it because
the F39 nvidia drivers don't work properly with an update and have to be
installed from scratch to work properly?
I think there was another thread about this. The akmods didn't run
properly during the update process.
3:05 a.m.
On 18/11/2023 05:11, Samuel Sieb wrote:
On 11/17/23 19:08, Stephen Morris wrote:
> I reinstalled the nvidia drivers and a subsequent reboot then
> booted into KDE with any issues (which is where I'm sending this email
> from). Why did this freezing of the nvidia drivers happen, is it
> because the F39 nvidia drivers don't work properly with an update and
> have to be installed from scratch to work properly?
I think there was another thread about this. The akmods didn't run
properly during the update process.
https://bugzilla.redhat.com/show_bug.cgi?id=2011120
10:54 p.m.
On 18/11/23 20:05, John Pilkington wrote:
On 18/11/2023 05:11, Samuel Sieb wrote:
> On 11/17/23 19:08, Stephen Morris wrote:
>> I reinstalled the nvidia drivers and a subsequent reboot then
>> booted into KDE with any issues (which is where I'm sending this
>> email from). Why did this freezing of the nvidia drivers happen, is
>> it because the F39 nvidia drivers don't work properly with an update
>> and have to be installed from scratch to work properly?
>
> I think there was another thread about this. The akmods didn't run
> properly during the update process.
https://bugzilla.redhat.com/show_bug.cgi?id=2011120
Thanks Samuel and John. I wasn't expecting this as I have both the
kmod-nvidia and akmod-nvidia packages installed so that I can use the
akmod packages as a backup if the binary packages haven't been updated
for new kernels when installed, so I was expected the kmod-nvidia driver
to just work.
As of the boot I've just done now the issue with the missing selections
in GDM has rectified itself.
regards,
Steve
--
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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/users@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
168
days inactive
180
days old
10 comments
6 participants
participants (6)
-
Jeffrey Walton -
John Pilkington -
Patrick O'Callaghan -
Samuel Sieb -
Stephen Morris -
Tim