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
On Fri, Nov 17, 2023 at 10:08 PM Stephen Morris samorris@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
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.
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.
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
On Sat, Nov 18, 2023 at 7:16 AM Patrick O'Callaghan pocallaghan@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
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.
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@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
On 18/11/23 14:28, Jeffrey Walton wrote:
On Fri, Nov 17, 2023 at 10:08 PM Stephen Morris samorris@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@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
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.
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
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.
-
Jeffrey Walton -
John Pilkington -
Patrick O'Callaghan -
Samuel Sieb -
Stephen Morris -
Tim