Re: crippling nvidia display issue.
On 4/14/24 17:21, Michael D. Setzer II via users wrote: So, not sure why it works with 6.7.x but not with 6.8.x. Something changed in the kernel and the NVidia driver needs to be changed to work with it. The driver is out of tree so it doesn't get fixed by the people making the change like the in tree drivers would. -- ___ 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: crippling nvidia display issue.
On 14 Apr 2024 at 18:50, John Pilkington wrote: Date sent: Sun, 14 Apr 2024 18:50:40 +0100 Subject:Re: crippling nvidia display issue. To: users@lists.fedoraproject.org From: John Pilkington Send reply to: Community support for Fedora users > On 14/04/2024 16:22, Michael D. Setzer II via users wrote: > > On 15 Apr 2024 at 0:29, Michael D. Setzer II via user wrote: > > >> > >> Just as an additional note. I have an older Acer notebook that has > >> an NVIDIA GT 650M that had been working fine with the > >> rpmfusion driver. Have BOINC using its GPU for a project. > >> After recent kernel upgrade, I noticed it was no longer working. > >> Tried reinstalling the rpm and it fails to build, so goes to fallback > >> of noveum? driver. Went to NVIDIA site, and downloaded what I > >> believe was the correct driver for the GT 650M, but it also fails to > >> build? Currently 17 timezones away from machine. In GMT -0700, > >> while machine is in GMT +1000, so accessing remotely via > >> TurboVNC. So, not sure if this is a kernel issue, or the driver issue, > >> but seems neither rpmfusiong or nvidia's driver will work any > >> longer? I've got other machines that have new nvidia cards, and > >> they are working with a different rpmfusing nvidia rpm. > >> > >> Perhaps I'm missing something. Thanks. Otherwise machines fully > >> updated with no issues. > >> > >> > > > > Was looking around, and found this info in > > /var/cache/akmods/nvidia-470xx > > > > Appears that it was working with 6.7.11 kernel but is now failing > > with 6.8.x > > > > 26183873 Apr 2 12:52 > > kmod-nvidia-470xx-6.7.11-200.fc39.x86_64-470.223.02-2.fc39.x86_ > > 64.rpm > > 14360178 Apr 2 12:52 > > 470.223.02-2-for-6.7.11-200.fc39.x86_64.log > >614649 Apr 10 15:32 > > 470.223.02-2-for-6.8.4-200.fc39.x86_64.failed.log > >616385 Apr 15 01:02 > > 470.223.02-2-for-6.8.5-201.fc39.x86_64.failed.log > > > > Thanks. > > I've dropped the initial posts in this thread.. When I posted on the > rpmfusion list, on 9 April, Sergio's response was: > Just an update. Used grubby to set the default kernel to 6.7.11, and ran akmods, so not BOINC sees the nvidia and is able to use the GPU... 26183873 Apr 2 12:52 kmod-nvidia-470xx-6.7.11-200.fc39.x86_64-470.223.02-2.fc39.x86_ 64.rpm 14360178 Apr 2 12:52 470.223.02-2-for-6.7.11-200.fc39.x86_64.log 614649 Apr 10 15:32 470.223.02-2-for-6.8.4-200.fc39.x86_64.failed.log 616385 Apr 15 01:02 470.223.02-2-for-6.8.5-201.fc39.x86_64.failed.log Now Acer notebook is running 6.7.11 kernel that works with the rpmfusing nvidia. uname -a Linux kevinacer.dyndns.org 6.7.11-200.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Mar 27 16:50:39 UTC 2024 x86_64 GNU/Linux $ cat /tmp/BOINC-output | grep GPU 15-Apr-2024 08:54:02 [---] CUDA: NVIDIA GPU 0: NVIDIA GeForce GT 650M (driver version 470.99, CUDA version 11.4, compute capability 3.0, 2000MB, 2000MB available, 730 GFLOPS peak) 15-Apr-2024 08:54:02 [---] OpenCL: NVIDIA GPU 0: NVIDIA GeForce GT 650M (driver version 470.223.02, device version OpenCL 3.0 CUDA, 2000MB, 2000MB available, 730 GFLOPS peak) So, not sure why it works with 6.7.x but not with 6.8.x. Have seen that Busybox also had an issue with some options no longer working with 6.8.x kernels. Said the 6.8.x dropped some things that cause the app to tail to build. > > > > a fix for nvidia 340x was posted today , > > for Fedora 40 we don't have these kmod nvidias because it fail to build > > with gcc14 . > > > > Please someone which have these graphics try fix it ASAP > > > > Thank you > > So one difficulty is probably a lack of rpmfusion devs with the affected > hardware... > > 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 ++ Michael D. Setzer II - Computer Science Instructor (Retired) mailto:mi...@guam.net mailto:msetze...@gmail.com mailto:msetze...@gmx.com Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ ++ -- ___ 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:
Re: how long does dnf system-upgrade take?
On 4/14/24 11:20, Tim via users wrote: Let's be clear, we're not talking about annoying changes to how the desktop looks, that can be put up with. But when you find essential software and/or hardware doesn't work anymore, or doesn't exist anymore, and support libraries are incompatible, that's a deal-breaker. It's a part of the reasons Linux gets minimal support with hardware (printers, graphics cards, scanners, whatever). Those manufacturers don't want to be dealing with ever-changing infrastructure where someone else is making all these changes. And there's every chance that by the time they've developed their gadget and software for it, a Linux distro has changed OSs twice. The only reason this is a problem for some manufacturers is because they want to keep it proprietary. Printers and scanners (and any other hardware) that use open standards or provide open-source drivers work great with Linux. Compare the difference between NVidia and AMD or Intel. How often do you see people having issues with AMD or Intel graphics compared to the never-ending issues with NVidia drivers? The same issue applies to proprietary software as described in the first quoted paragraph. -- ___ 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: how long does dnf system-upgrade take?
On 4/14/24 06:49, Fulko Hew wrote: Thanks for giving me the guts to do a brute force power cycle in the apparent middle of an upgrade in progress. (FYI. The upgrade to F39 also hung at the boot message, and it too needed a power-cycle to successfully boot.) If it's still at the boot message, then it hasn't actually started. When it gets to the update process, there will be messages saying that. -- ___ 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: how long does dnf system-upgrade take?
On Sun, 2024-04-14 at 09:49 -0400, Fulko Hew wrote: > Then in corporate life, I needed to ensure a stable development > environment. This is one of the big problems with computers in the work place. You may have single-task computers which you want to work, and not mess around with. You may have a need for particular jobs that will always work in a certain way. Things in development can take ages to complete, and that's just sorting out your own needs, never mind having to deal with a system changing as well. System updates can pull the rug out from under you. Computer systems with long life spans are essential in such environments, things that require replacing every 6 months or so are a real nuisance (to put it mildly). Let's be clear, we're not talking about annoying changes to how the desktop looks, that can be put up with. But when you find essential software and/or hardware doesn't work anymore, or doesn't exist anymore, and support libraries are incompatible, that's a deal-breaker. It's a part of the reasons Linux gets minimal support with hardware (printers, graphics cards, scanners, whatever). Those manufacturers don't want to be dealing with ever-changing infrastructure where someone else is making all these changes. And there's every chance that by the time they've developed their gadget and software for it, a Linux distro has changed OSs twice. > After F33, it became an issue that I didn't want to migrate because > I'd typically be losing functionality or user-convenience. > > During F33 to 34/35 migration I remember losing all of my KiCad > customizations for chips and connectors I had downloaded. > During this F35 to F39 migration, I've lost the convenience of a > Fedora supported FreeCAD. Addressing an issue someone else replied with: While one can try installing old software onto new systems, you often find it cannot be installed or run. It's not compatible. Even the newer idea of the big-blob appimage (and their ilk) that's mostly self-contained without relying (much) on system libraries, and one blob is supposed to work on various different distros can fail to work on different versions of an OS. So yes, change is a pain. In certain environments computers will never get updates. Once it's working, they'll keep it in that condition. It's not a problem with non-networked systems, but risky with networked ones. I have a very old Mac in that boat (changes stuffed things up). It's used for video editing with Final Cut Pro, and that's its sole task. I kept updating for a while, but it can't be any more. They limit the newest OS you can put on it. And somewhere along the way, one of the Final Cut Pro updates became very crashy, and no further updates fixed that issue, and it wasn't possible to go back to a prior version that was stable. > P.S. And with every upgrade, software just gets slower. I certainly noticed that with Windows. They seemed to just cobble patch upon patch, rather than replace borked things with working ones. I can't say I've *directly* encountered upgrade slowdowns with Linux software. Though I have in the sense that Gnome and KDE developers seem to think everyone has a PC with an insanely powerful graphics card and oodles of RAM to just run the desktop. I don't care about the damn desktop, it's applications I want to use. -- NB: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the list. The following system info data is generated fresh for each post: uname -rsvp Linux 6.2.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 11 16:51:53 UTC 2023 x86_64 -- ___ 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: crippling nvidia display issue.
On 14/04/2024 16:22, Michael D. Setzer II via users wrote: On 15 Apr 2024 at 0:29, Michael D. Setzer II via user wrote: Just as an additional note. I have an older Acer notebook that has an NVIDIA GT 650M that had been working fine with the rpmfusion driver. Have BOINC using its GPU for a project. After recent kernel upgrade, I noticed it was no longer working. Tried reinstalling the rpm and it fails to build, so goes to fallback of noveum? driver. Went to NVIDIA site, and downloaded what I believe was the correct driver for the GT 650M, but it also fails to build? Currently 17 timezones away from machine. In GMT -0700, while machine is in GMT +1000, so accessing remotely via TurboVNC. So, not sure if this is a kernel issue, or the driver issue, but seems neither rpmfusiong or nvidia's driver will work any longer? I've got other machines that have new nvidia cards, and they are working with a different rpmfusing nvidia rpm. Perhaps I'm missing something. Thanks. Otherwise machines fully updated with no issues. Was looking around, and found this info in /var/cache/akmods/nvidia-470xx Appears that it was working with 6.7.11 kernel but is now failing with 6.8.x 26183873 Apr 2 12:52 kmod-nvidia-470xx-6.7.11-200.fc39.x86_64-470.223.02-2.fc39.x86_ 64.rpm 14360178 Apr 2 12:52 470.223.02-2-for-6.7.11-200.fc39.x86_64.log 614649 Apr 10 15:32 470.223.02-2-for-6.8.4-200.fc39.x86_64.failed.log 616385 Apr 15 01:02 470.223.02-2-for-6.8.5-201.fc39.x86_64.failed.log Thanks. I've dropped the initial posts in this thread.. When I posted on the rpmfusion list, on 9 April, Sergio's response was: a fix for nvidia 340x was posted today , for Fedora 40 we don't have these kmod nvidias because it fail to build with gcc14 . Please someone which have these graphics try fix it ASAP Thank you So one difficulty is probably a lack of rpmfusion devs with the affected hardware... 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: how long does dnf system-upgrade take?
On Sun, Apr 14, 2024 at 9:49 AM Fulko Hew wrote: > On Sun, Apr 14, 2024 at 7:16 AM Patrick O'Callaghan > wrote: > Then it was back to are-install for F33 because it was a hardware > replacement, and Linux/Fedora does not have a one-true backup/restore > process that I have ever seen. [...] There may not be "one" backup/restore process, but there are several easy options. When I've done hw replacements my usual process is to use "dd" to create an image of the disk as it came from the factory (in case I ever want to use the Windows install it comes with), do another image of the source disk, and then "dd" the image to the new hw (this requires a suitable external USB drive or similar of course). If the new disk is larger I resize the LVs and file systems after the restore to take advantage of the additional space. You could do something similar using clonezilla. Or instead of "dd", you can use the appropriate dump/restore program for the file systems in question. [If you don't have a suitable external drive, I would think you could use a USB thumb drive and a live ISO to boot the target, and then do the backup/restore over a ssh pipe] > During this F35 to F39 migration, I've lost the convenience of a Fedora > supported FreeCAD. You can try installing the F38 package on F39 > And since Wayland isn't a full-function replacement for X11 yet, > I understand the next migration will break my remote X11 windows usage. > (And a remote desktop is not a replacement for remote windows.) From what I understand, Wayland will *never* be a full-function replacement for X11 as there are capabilities in X11 that Wayland considers to be security issues. But perhaps I have failed to properly understand Wayland. -- ___ 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: crippling nvidia display issue.
On 15 Apr 2024 at 0:29, Michael D. Setzer II via user wrote: To: Community support for Fedora users Date sent: Mon, 15 Apr 2024 00:29:38 +1000 Subject:Re: crippling nvidia display issue. Priority: normal Send reply to: mi...@guam.net, Community support for Fedora users From: "Michael D. Setzer II via users" Copies to: "Michael D. Setzer II" > On 14 Apr 2024 at 12:47, John Pilkington wrote: > > Date sent:Sun, 14 Apr 2024 12:47:57 +0100 > Subject: Re: crippling nvidia display issue. > From: John Pilkington > To: users@lists.fedoraproject.org > Send reply to:Community support for Fedora users > > > > On 12/04/2024 12:58, John Pilkington wrote: > > > On 12/04/2024 00:52, home user wrote: > > >> On 4/11/24 5:39 PM, Samuel Sieb wrote: > > >>> On 4/11/24 16:36, home user wrote: > > On 4/11/24 5:31 PM, Samuel Sieb wrote: > > > On 4/11/24 16:05, home user wrote: > > >> /tmp/akmodsbuild.2VNb1GB1/BUILD/nvidia-470xx-kmod-470.223.02/_kmod_build_6.8.4-100.fc38.x86_64/nvidia-drm/nvidia-drm-drv.c:748:40: > > >> error: 'DRM_UNLOCKED' undeclared here (not in a function); did you > > >> mean 'VM_LOCKED'? > > > > > > There has been a kernel change of some sort. The driver needs to > > > be updated to match the kernel. > > > > > > You will not get this driver to build on any newer kernels. > > > -- > > > > So realistically, my only practical choice is what Todd suggested, > > "to just switch to the stuff Nvidia provides directly"? > > >>> > > >>> Unless there's a hope of the rpmfusion package getting updated, it > > >>> looks like it. I'm not really familiar with akmods, but maybe you > > >>> could just update the source somehow. > > >> > > >> I'm not a systems administrator. I need someone to step me through > > >> the full switch in detail. > > >> Reminders: > > >> This is a dual boot (Fedora-38 and windows-7) stand-alone work > > >> station; it's 11 years old. > > >> I have only one old kernel, and no rescue kernel. > > >> The graphics card is an nvidia GeForce GTX 660. > > >> (anything else?) > > > > > > I have two systems affected by this, and have posted about it on the > > > rpmfusion and fedora-kde lists. I'm having trouble accessing the > > > rpmfusion archive, so maybe a comment here is in order. > > > > > > Both systems have GeForce GT 710 cards. This is low-spec, not for > > > gamers, and I've been using the rpmfusion 470xx drivers for years. I > > > upgraded from F38 to F39 around 2 weeks ago. > > > > > > AIUI we are moving from X11 graphics towards Wayland, which the nvidia > > > driver will not support; but nouveau might. So I've been trying it. > > > > > > On one box it's working acceptably, with VGA nad HDMI screens. > > > Single-boot F39. > > > > > > The other box is dual-boot with Windows 10. I can boot into Fedora only > > > with 'nomodeset', when I get a single screen HDMI 800x600 which seems > > > fine but limited. I can run MythTV frontend with --geometry > > > 720x504+40+20 > > > > > > The biggest worry is getting past a frozen boot, so I don't want to make > > > any recommendations. I have removed all the *nvidia* rpms except > > > nvidia-gpu-firmware, and installed nouveau-firmware from the > > > rpmfusion-nonfree-tainted repo. > > > > > > Maybe the rpmfusion team will make the old system work soon, or maybe > > > the even-older but just-updated 340xx driver would work. I'll try > > > living with what I have for now. > > > > After kernel and firmware updates today the behaviour of both systems, > > using nouveau, seems essentially unchanged from the report above. > > kernel now is 6.8.5-201.fc39.x86-64 > > > > If the 'nomodeset' is edited out in grub, a reboot of the dual-boot box > > still hangs almost immediately. > > > > I've removed the claim that mythleanfront works with mythbackend on the > > dual-boot box. I think that was mistaken, and a local permissions issue. > > > > > > HTH > > > > > > John P > > > > > > > > > > > -- > > Just as an additional note. I have an older Acer notebook that has > an NVIDIA GT 650M that had been working fine with the > rpmfusion driver. Have BOINC using its GPU for a project. > After recent kernel upgrade, I noticed it was no longer working. > Tried reinstalling the rpm and it fails to build, so goes to fallback > of noveum? driver. Went to NVIDIA site, and downloaded what I > believe was the correct driver for the GT 650M, but it also fails to > build? Currently 17 timezones away from machine. In GMT -0700, > while machine is in GMT +1000, so accessing remotely via > TurboVNC. So, not sure if this is a kernel issue, or the driver issue, > but seems neither rpmfusiong or nvidia's driver will work any > longer? I've got other machines that have new nvidia
Re: crippling nvidia display issue.
On 14 Apr 2024 at 12:47, John Pilkington wrote: Date sent: Sun, 14 Apr 2024 12:47:57 +0100 Subject:Re: crippling nvidia display issue. From: John Pilkington To: users@lists.fedoraproject.org Send reply to: Community support for Fedora users > On 12/04/2024 12:58, John Pilkington wrote: > > On 12/04/2024 00:52, home user wrote: > >> On 4/11/24 5:39 PM, Samuel Sieb wrote: > >>> On 4/11/24 16:36, home user wrote: > On 4/11/24 5:31 PM, Samuel Sieb wrote: > > On 4/11/24 16:05, home user wrote: > >> /tmp/akmodsbuild.2VNb1GB1/BUILD/nvidia-470xx-kmod-470.223.02/_kmod_build_6.8.4-100.fc38.x86_64/nvidia-drm/nvidia-drm-drv.c:748:40: > >> error: 'DRM_UNLOCKED' undeclared here (not in a function); did you > >> mean 'VM_LOCKED'? > > > > There has been a kernel change of some sort. The driver needs to > > be updated to match the kernel. > > > > You will not get this driver to build on any newer kernels. > > -- > > So realistically, my only practical choice is what Todd suggested, > "to just switch to the stuff Nvidia provides directly"? > >>> > >>> Unless there's a hope of the rpmfusion package getting updated, it > >>> looks like it. I'm not really familiar with akmods, but maybe you > >>> could just update the source somehow. > >> > >> I'm not a systems administrator. I need someone to step me through > >> the full switch in detail. > >> Reminders: > >> This is a dual boot (Fedora-38 and windows-7) stand-alone work > >> station; it's 11 years old. > >> I have only one old kernel, and no rescue kernel. > >> The graphics card is an nvidia GeForce GTX 660. > >> (anything else?) > > > > I have two systems affected by this, and have posted about it on the > > rpmfusion and fedora-kde lists. I'm having trouble accessing the > > rpmfusion archive, so maybe a comment here is in order. > > > > Both systems have GeForce GT 710 cards. This is low-spec, not for > > gamers, and I've been using the rpmfusion 470xx drivers for years. I > > upgraded from F38 to F39 around 2 weeks ago. > > > > AIUI we are moving from X11 graphics towards Wayland, which the nvidia > > driver will not support; but nouveau might. So I've been trying it. > > > > On one box it's working acceptably, with VGA nad HDMI screens. > > Single-boot F39. > > > > The other box is dual-boot with Windows 10. I can boot into Fedora only > > with 'nomodeset', when I get a single screen HDMI 800x600 which seems > > fine but limited. I can run MythTV frontend with --geometry > > 720x504+40+20 > > > > The biggest worry is getting past a frozen boot, so I don't want to make > > any recommendations. I have removed all the *nvidia* rpms except > > nvidia-gpu-firmware, and installed nouveau-firmware from the > > rpmfusion-nonfree-tainted repo. > > > > Maybe the rpmfusion team will make the old system work soon, or maybe > > the even-older but just-updated 340xx driver would work. I'll try > > living with what I have for now. > > After kernel and firmware updates today the behaviour of both systems, > using nouveau, seems essentially unchanged from the report above. > kernel now is 6.8.5-201.fc39.x86-64 > > If the 'nomodeset' is edited out in grub, a reboot of the dual-boot box > still hangs almost immediately. > > I've removed the claim that mythleanfront works with mythbackend on the > dual-boot box. I think that was mistaken, and a local permissions issue. > > > > HTH > > > > John P > > > > > > > -- Just as an additional note. I have an older Acer notebook that has an NVIDIA GT 650M that had been working fine with the rpmfusion driver. Have BOINC using its GPU for a project. After recent kernel upgrade, I noticed it was no longer working. Tried reinstalling the rpm and it fails to build, so goes to fallback of noveum? driver. Went to NVIDIA site, and downloaded what I believe was the correct driver for the GT 650M, but it also fails to build? Currently 17 timezones away from machine. In GMT -0700, while machine is in GMT +1000, so accessing remotely via TurboVNC. So, not sure if this is a kernel issue, or the driver issue, but seems neither rpmfusiong or nvidia's driver will work any longer? I've got other machines that have new nvidia cards, and they are working with a different rpmfusing nvidia rpm. Perhaps I'm missing something. Thanks. Otherwise machines fully updated with no issues. > ___ > 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: >
Re: how long does dnf system-upgrade take?
On Sun, Apr 14, 2024 at 7:16 AM Patrick O'Callaghan wrote: > On Sat, 2024-04-13 at 17:37 -0400, Fulko Hew wrote: > > > On Sat, 2024-04-13 at 13:29 -0700, Fulko Hew wrote: > > > > I don't update my Fedora systems unless I have a real need, > > > > so yesterday I started updating from F35 to F38 > > Just as an aside: leaving a two year old Fedora system without updating > is definitely not recommended. F35, F36 and F37 are all EOLed and don't > get even critical security updates. With F40 due for release soon, F38 > will also fall into that category in a month or two. > Thanks for giving me the guts to do a brute force power cycle in the apparent middle of an upgrade in progress. (FYI. The upgrade to F39 also hung at the boot message, and it too needed a power-cycle to successfully boot.) Now on to the philosophy issue. 'Why the delay in upgrades?' In the beginning (25+ years ago) there was no such thing as upgrades, only re-installs, so the process of reconfiguring and migrating private data and apps was tedious (on the order of days). So I wanted to avoid that. The pains were not worth the benefits. Then in corporate life, I needed to ensure a stable development environment. Upgrades still didn't exist, migrating whole development environments was a pain. But testing on other distributions and/or releases was relatively easy. (My longest gap, and most productive time, was deferring re-installs until it was F8 directly to F20) F25 to F26 was a successful migration/upgrade. Then it was back to are-install for F33 because it was a hardware replacement, and Linux/Fedora does not have a one-true backup/restore process that I have ever seen. (My first Unix was Xenix on a 286 and SCO allowed you to make an 'emergency boot floppy' and then restore a system from tape. It was a dirt simple one hour process to fully restore a system.) After F33, it became an issue that I didn't want to migrate because I'd typically be losing functionality or user-convenience. During F33 to 34/35 migration I remember losing all of my KiCad customizations for chips and connectors I had downloaded. During this F35 to F39 migration, I've lost the convenience of a Fedora supported FreeCAD. And since Wayland isn't a full-function replacement for X11 yet, I understand the next migration will break my remote X11 windows usage. (And a remote desktop is not a replacement for remote windows.) If you've read this far, thank you. I hope you appreciate my story. P.S. And with every upgrade, software just gets slower. -- ___ 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: crippling nvidia display issue.
On 12/04/2024 12:58, John Pilkington wrote: On 12/04/2024 00:52, home user wrote: On 4/11/24 5:39 PM, Samuel Sieb wrote: On 4/11/24 16:36, home user wrote: On 4/11/24 5:31 PM, Samuel Sieb wrote: On 4/11/24 16:05, home user wrote: /tmp/akmodsbuild.2VNb1GB1/BUILD/nvidia-470xx-kmod-470.223.02/_kmod_build_6.8.4-100.fc38.x86_64/nvidia-drm/nvidia-drm-drv.c:748:40: error: 'DRM_UNLOCKED' undeclared here (not in a function); did you mean 'VM_LOCKED'? There has been a kernel change of some sort. The driver needs to be updated to match the kernel. You will not get this driver to build on any newer kernels. -- So realistically, my only practical choice is what Todd suggested, "to just switch to the stuff Nvidia provides directly"? Unless there's a hope of the rpmfusion package getting updated, it looks like it. I'm not really familiar with akmods, but maybe you could just update the source somehow. I'm not a systems administrator. I need someone to step me through the full switch in detail. Reminders: This is a dual boot (Fedora-38 and windows-7) stand-alone work station; it's 11 years old. I have only one old kernel, and no rescue kernel. The graphics card is an nvidia GeForce GTX 660. (anything else?) I have two systems affected by this, and have posted about it on the rpmfusion and fedora-kde lists. I'm having trouble accessing the rpmfusion archive, so maybe a comment here is in order. Both systems have GeForce GT 710 cards. This is low-spec, not for gamers, and I've been using the rpmfusion 470xx drivers for years. I upgraded from F38 to F39 around 2 weeks ago. AIUI we are moving from X11 graphics towards Wayland, which the nvidia driver will not support; but nouveau might. So I've been trying it. On one box it's working acceptably, with VGA nad HDMI screens. Single-boot F39. The other box is dual-boot with Windows 10. I can boot into Fedora only with 'nomodeset', when I get a single screen HDMI 800x600 which seems fine but limited. I can run MythTV frontend with --geometry 720x504+40+20 The biggest worry is getting past a frozen boot, so I don't want to make any recommendations. I have removed all the *nvidia* rpms except nvidia-gpu-firmware, and installed nouveau-firmware from the rpmfusion-nonfree-tainted repo. Maybe the rpmfusion team will make the old system work soon, or maybe the even-older but just-updated 340xx driver would work. I'll try living with what I have for now. After kernel and firmware updates today the behaviour of both systems, using nouveau, seems essentially unchanged from the report above. kernel now is 6.8.5-201.fc39.x86-64 If the 'nomodeset' is edited out in grub, a reboot of the dual-boot box still hangs almost immediately. I've removed the claim that mythleanfront works with mythbackend on the dual-boot box. I think that was mistaken, and a local permissions issue. HTH 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: how long does dnf system-upgrade take?
On Sat, 2024-04-13 at 17:37 -0400, Fulko Hew wrote: > > On Sat, 2024-04-13 at 13:29 -0700, Fulko Hew wrote: > > > I don't update my Fedora systems unless I have a real need, > > > so yesterday I started updating from F35 to F38 Just as an aside: leaving a two year old Fedora system without updating is definitely not recommended. F35, F36 and F37 are all EOLed and don't get even critical security updates. With F40 due for release soon, F38 will also fall into that category in a month or two. 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
