Re: DNF Upgrade from F38 to F39 Issues
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.
OpenPGP_0x594338B1DE179AB2.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-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/users@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: DNF Upgrade from F38 to F39 Issues
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
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-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/users@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: DNF Upgrade from F38 to F39 Issues
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.
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-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/users@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: DNF Upgrade from F38 to F39 Issues
On 18/11/23 14:28, Jeffrey Walton wrote: On Fri, Nov 17, 2023 at 10:08 PM Stephen Morris 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-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/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue OpenPGP_0x594338B1DE179AB2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-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/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: DNF Upgrade from F38 to F39 Issues
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@lists.fedoraproject.org To unsubscribe send an email to users-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/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue OpenPGP_0x594338B1DE179AB2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-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/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: DNF Upgrade from F38 to F39 Issues
On Sat, Nov 18, 2023 at 7:16 AM Patrick O'Callaghan 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 -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-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/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: DNF Upgrade from F38 to F39 Issues
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 -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-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/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: DNF Upgrade from F38 to F39 Issues
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 -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-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/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: DNF Upgrade from F38 to F39 Issues
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. -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-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/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: DNF Upgrade from F38 to F39 Issues
On Fri, Nov 17, 2023 at 10:08 PM Stephen Morris 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 -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-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/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
DNF Upgrade from F38 to F39 Issues
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 OpenPGP_0x594338B1DE179AB2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-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/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
