On 15/12/2022 03:45, home user wrote:

I just did 'dnf upgrade' on a system with an old Dell monitor and an Android tv.  Graphics card is GT 710 running X11 in KDE.  The active screen switches during boot, so it's best to have both screens powered up at that time.

There have been lots of KDE-related updates since Nov 3, so the upgrade may take some time.  And allow several minutes to build the kmods before doing 'sudo systemctl reboot'

HTH John P

home user composed on 2022-12-15 14:17 (UTC-0700): > No one has yet answered my question: > Is what is currently in RPM Fusion non-free 36 updates everything I need > to really fix the problem for f36? > That should need only a yes or no answer. It may well be that no reader here who might have an authoritative answer and seeing your thread title has read the thread. The thread title does not suggest you have a package management issue, mush less and NVidia drivers issue.

It may well be that no reader here who might has an authoritative answer, or is willing to speculate publicly.

The facts that others have responded that they are using those drivers satisfactorily, and that others are not reporting trouble with rpmfusion's NVidia drivers currently suggests the answer would be yes if anyone were to post a direct answer.

Note that the vast majority of users ATI and AMD GPUs do not require non-FOSS drivers, and for Intel GPU users, no non-FOSS drivers exist, regardless of distro. Only NVidia among major GPU providers has a policy of withholding hardware specifications that FOSS driver writers require for optimal results[1] that indirectly imposes recurring kernel/driver mismatch problems for users of its products. If and when an opportunity to replace your GPU occurs you may wish to consider a different brand. Or, like some people do (e.g. me), use the FOSS drivers without concern that their GPU is capable of performing better. [1] NVidia has recently modified its policy, but it only affects its recent products.

On 15 Dec 2022, at 23:09, John Pilkington <johnpilk222(a)gmail.com&gt; wrote: On 15/12/2022 21:17, home user wrote: >> On 12/15/22 2:56 AM, John Pilkington wrote: >>> On 15/12/2022 03:45, home user wrote: >> [... snip ...] >> >> I just did 'dnf upgrade' on a system with an old Dell monitor and an Android tv. Graphics card is GT 710 running X11 in KDE. The active screen switches during boot, so it's best to have both screens powered up at that time. > I almost always have both monitors on when starting to boot. The only exceptions I can think of is when dealing with possible monitor or graphics card issues. >> There have been lots of KDE-related updates since Nov 3, so the upgrade may take some time. And allow several minutes to build the kmods before doing 'sudo systemctl reboot' > It's seems to have been true for a long time now that, after "dnf upgrade", the kmods build takes a long time. There seems to also be a process involving mandb that takes a long time. What I always do is watch ksysguard. Only once that shows negligible CPU activity and the cooling fans get slower and quieter, I reboot. I've also noticed that the shutdown part of reboot sometimes (recently: always!) takes quite long (minutes). >> HTH >> >> John P > No one has yet answered my question: > Is what is currently in RPM Fusion non-free 36 updates everything I need to really fix the problem for f36? > That should need only a yes or no answer. I have no way of knowing what idiosyncrasies your system may have. I said what works for me. I use 'atop' to judge when the builds have completed, and yes, recent shutdowns (but not today's) have also been affected by a delay timer.

I notice that my list of installed rpms includes a recent firmware update. I suppose that must be from rpmfusion, but I haven't checked. John _______________________________________________ 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

On 12/15/22 4:07 PM, John Pilkington wrote: > > I have no way of knowing what idiosyncrasies your system may have. > > I said what works for me.   I use 'atop' to judge when the builds > have > completed, and yes, recent shutdowns (but not today's) have also > been > affected by a delay timer. (Do you mean "top"?  "man atop" finds no manual entry.) Looks like a good one for me to keep in mind if the graphical tools (my preference) don't work adequately.  Thank-you.

On 12/16/22 3:11 PM, Patrick O'Callaghan wrote: > $ dnf info atop > ... > Description  : An advanced interactive monitor for Linux-systems to > view the load on >               : system-level and process-level. >               : The command atop has some major advantages compared > to other >               : performance-monitors: >               :    - Resource consumption by all processes >               :    - Utilization of all relevant resources >               :    - Permanent logging of resource utilization >               :    - Highlight critical resources >               :    - Watch activity only >               :    - Watch deviations only >               :    - Accumulated process activity per user >               :    - Accumulated process activity per program > > See also htop, glances and several others. > > poc Is there something equivalent to atop that provides graphical output? The graphical system monitors that I have (e.g. ksysguard) produce nice displays, but don't offer all the parameters I'd like to see.  atop has more parameters, but no graphical display (or did I miss something?).

On 12/16/22 3:11 PM, Patrick O'Callaghan wrote: > $ dnf info atop > ... > Description  : An advanced interactive monitor for Linux-systems to > view the load on >               : system-level and process-level. >               : The command atop has some major advantages compared to > other >               : performance-monitors: >               :    - Resource consumption by all processes >               :    - Utilization of all relevant resources >               :    - Permanent logging of resource utilization >               :    - Highlight critical resources >               :    - Watch activity only >               :    - Watch deviations only >               :    - Accumulated process activity per user >               :    - Accumulated process activity per program > > See also htop, glances and several others. > > poc Is there something equivalent to atop that provides graphical output? The graphical system monitors that I have (e.g. ksysguard) produce nice displays, but don't offer all the parameters I'd like to see.  atop has more parameters, but no graphical display (or did I miss something?).

For some time now, I've seen another process/user "mandb" running at the same time as or after the akmod processes at the end of (sometimes after) "dnf update".

I'd there a difference in dnf upgrade and dnf distro-sync? There's a dnf update too. I usually erase a /var/cache/dnf to clean data.

On Sat, Dec 17, 2022, 1:01 PM Tom Horsley <horsley1953(a)gmail.com <mailto:horsley1953@gmail.com>> wrote: On Sat, 17 Dec 2022 10:45:38 -0700 home user wrote: > For some time now, I've seen another process/user "mandb" running at the > same time as or after the akmod processes at the end of (sometimes > after) "dnf update".

That's updating the man page database the "man" command uses. It only runs when something in the update modified or added man pages. I do usually wait for it to finish before rebooting, though I think it will try again later if it didn't get finished.

On 12/17/22 10:45 AM, home user wrote: > On 12/17/22 10:15 AM, John Pilkington wrote: > > ... > For some time now, I've seen another process/user "mandb" running at > the same time as or after the akmod processes at the end of (sometimes > after) "dnf update". Sorry,  That should be "dnf upgrade", not "dnf update".

On 17 Dec 2022, at 17:47, home user <mattisonw(a)comcast.net&gt; wrote: On 12/17/22 10:15 AM, John Pilkington wrote: > I run it in a konsole (KDE terminal) tab and see a screenful of data refreshed every 10 seconds. Mainly the interest here is on jobs run by user akmods. For me it's just a guide showing when the system should be able to boot without doing complex things while in an unfamiliar state. If you boot before then it should work, but the action will be more 'under cover'. Escape should reveal more. For some time now, I've seen another process/user "mandb" running at the same time as or after the akmod processes at the end of (sometimes after) "dnf update". That mandb process seems to be slow; it takes a few minutes; yet it uses only one CPU. I'm guessing it's an I/O intensive process, but I don't really know. It seems that that, too, apparently has to be watched to make sure it's done before rebooting.

> There were statements here when, 6.0.5 first caused problems, that the 5-to-6 transition was simply linux running out of fingers and toes. I liked the image, but the problem was, briefly, real. > John Bill. _______________________________________________ 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

> > See also htop, glances and several others. > > > > poc > > Is there something equivalent to atop that provides graphical > output? > The graphical system monitors that I have (e.g. ksysguard) produce > nice > displays, but don't offer all the parameters I'd like to see.  atop > has > more parameters, but no graphical display (or did I miss > something?). I run it in a konsole (KDE terminal) tab and see a screenful of data refreshed every 10 seconds.

On 12/16/22 10:33, home user wrote: > I shut down nightly.  So I do notice the long time.  I hear at least 3 > long surges of the cooling fans during shutdown.  But I don't know of > a way of knowing what's really going on (the screens are blank). > Since this is the first I've seen or heard anything of this in this > list, I assume this is not really a concern. You could try pressing ESC.  If the console is still functioning, it will show you what's going on.

On 15 Dec 2022, at 21:19, home user <mattisonw(a)comcast.net&gt; wrote: On 12/15/22 2:56 AM, John Pilkington wrote: > On 15/12/2022 03:45, home user wrote: [... snip ...] > I just did 'dnf upgrade' on a system with an old Dell monitor and an Android tv. Graphics card is GT 710 running X11 in KDE. The active screen switches during boot, so it's best to have both screens powered up at that time. I almost always have both monitors on when starting to boot. The only exceptions I can think of is when dealing with possible monitor or graphics card issues. > There have been lots of KDE-related updates since Nov 3, so the upgrade may take some time. And allow several minutes to build the kmods before doing 'sudo systemctl reboot' It's seems to have been true for a long time now that, after "dnf upgrade", the kmods build takes a long time. There seems to also be a process involving mandb that takes a long time. What I always do is watch ksysguard. Only once that shows negligible CPU activity and the cooling fans get slower and quieter, I reboot. I've also noticed that the shutdown part of reboot sometimes (recently: always!) takes quite long (minutes). > HTH > John P No one has yet answered my question: Is what is currently in RPM Fusion non-free 36 updates everything I need to really fix the problem for f36? That should need only a yes or no answer.

_______________________________________________ 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

On 16 Dec 2022, at 16:26, Joe Zeff <joe(a)zeff.us&gt; wrote: On 12/16/2022 02:10 AM, Barry wrote: [snip] > I always ask on the rpmfusion dev mailing list if the nvidia driver is an issue. > It is where the person maintaining the packages will see a query. Is there a reason that you don't use the akmod and get it built automagically?

[snip] _______________________________________________ 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

On 12/14/22 22:45, home user wrote:

> set /etc/dnf.conf to retain the kernels of several updates to give rpmfusion time to catch up to new kernels in a new major grouping. Can take a couple of weeks. [main] gpgcheck=1 installonly_limit=5 max_parallel_downloads=10 fastestmirror=True clean_requirements_on_remove=true keepcache=0 ----

I have a system with a gtx 610 which uses the even older 390xx drivers. Another uses the gt 710 with the 470xx drivers, both have been updated on rpmfusion for weeks. Upgrades to f37 went smoothly

home user composed on 2022-12-15 14:03 (UTC-0700): > ... installonly_limit= determines how many kernels dnf will keep installed when it is performing its excess installed kernels removal process. The idea is too allow a larger safety margin for your working 5.19 kernel before its removal would be attempted.

Alternatively, you could modify /etc/dnf/dnf.conf by entirely excluding kernels from being installed or removed by dnf: exclude=" kernel* " Using this option, dnf will pretend kernels don't exist for purposes of adding or removing. When you are ready to allow a kernel to be installed, remove the kernel from the exclude= line. I do that using a one character change in dnf.conf: exclude=" 0kernel* " Even when dnf.conf excludes kernels, kernels may still be added or removed using rpm directly.

> Alternatively, you could modify /etc/dnf/dnf.conf by entirely excluding kernels > from being installed or removed by dnf:

> exclude=" kernel* "

> Using this option, dnf will pretend kernels don't exist for purposes of adding or > removing. When you are ready to allow a kernel to be installed, remove the kernel > from the exclude= line. I do that using a one character change in dnf.conf:

> exclude=" 0kernel* "

> Even when dnf.conf excludes kernels, kernels may still be added or removed using > rpm directly.

Seems like neat tricks. Thank-you. But I hope you understand when I say that I hope I never need to use them!

I up mine to about 5. That way if there's a flurry of kernel updates (which has happened in the past) and one or more of them cause me a problem, I'll still have an older one to rely on.

The installonly limit affects *any* package that installs alongside previous installs, rather than as an upgrade that replaces it (how most updated program packages are handled). It doesn't only affect kernel installations.

Current kernel is up to 6.0.12 going from 6.0.5 to current has tracked without a problem of the drivers with rpmfusion. The change from 5 to 6 is the major kernel change where driver delays typically but not exclusively occur.

On 12/14/22 8:45 PM, home user wrote: (see bottom if needed) essential background review: * the Nov. 03 "dnf upgrade" that caused the display problem also upgraded the kernel from 5.19.16-200 to 6.0.5-200.fc36. * I've been using the 5.19.16-200 exclusively since then. * I've done no further dnf commands since Nov. 03. As recommended, I'll assume that the nvidia driver now in RPM Fusion non-free 36 updates is the needed fix. Question #1: When I do the fix, should I do it while booted in 5.19.16-200.fc36 or while booted in 6.0.5-200.fc36?

Question #2: Do I simply do (as root) "dnf upgrade" and then reboot, or do I need to do something else/more? If something else/more, then please spell out the proper steps.

thanks, Bill. > f36; workstation is 9 years old; dual boot (the other OS is the nearly > useless windows-7); dual monitor; stand-alone (not a part of a LAN, > WAN, etc.); I don't have other hardware to fall back on, not even a > cell phone; nvidia geforce gtx 660 graphics card; driver is from RPM > Fusion non-free. > > Note: I have no training or significant experience in sys. admin. > > original problem: > On Nov. 03, I did my weekly "dnf upgrade".  This resulted in only one > monitor working, and the display on that monitor looking fuzzy and > horizontally stretched out. > > diagnosis (from the Fedora users list): > The driver version installed by the "dnf upgrade" is not compatible > with the latest kernel and needs updating.  The kernel version was > 6.0.5-200.fc36.  The fixed nvidia 470 drivers were still in testing. > > work-around until fixed nvidia 470 drivers pass testing and reach > rpmfusion-nonfree-updates (from the Fedora users list): > 1. back-up the initrd being used before the Nov. 03 "dnf upgrade". > 2. use the kernel in use (5.19) before the Nov. 03 "dnf upgrade". > The recommended back-up was done on Nov. 04.  I've been using the 5.19 > kernel exclusively since then.  I have not run "dnf upgrade" since > Nov. 03. > > current situation: > I'm using the 5.19 kernel exclusively. > I have not run "dnf upgrade" since Nov. 03. > The RPM Fusion web site page > "https://mirror.fcix.net/rpmfusion/nonfree/fedora/updates/36/x86_64/repoview/index.html" now shows this... > --------------- > Latest packages: > >      2022-11-29: nvidia-settings-470xx-470.161.03-1.fc36 >      2022-11-29: akmod-nvidia-470xx-470.161.03-1.fc36 >      2022-11-29: kmod-nvidia-470xx-470.161.03-1.fc36 >      2022-11-29: xorg-x11-drv-nvidia-470xx-470.161.03-1.fc36 >      2022-11-29: xorg-x11-drv-nvidia-470xx-cuda-470.161.03-1.fc36 >      2022-11-29: xorg-x11-drv-nvidia-470xx-cuda-libs-470.161.03-1.fc36 >      2022-11-29: xorg-x11-drv-nvidia-470xx-devel-470.161.03-1.fc36 >      2022-11-29: xorg-x11-drv-nvidia-470xx-kmodsrc-470.161.03-1.fc36 >      2022-11-29: xorg-x11-drv-nvidia-470xx-libs-470.161.03-1.fc36 >      2022-11-29: xorg-x11-drv-nvidia-470xx-power-470.161.03-1.fc36 > (and other things not relevant to this issue) > --------------- > > The original problem left my workstation quite crippled.  It took a > lot of time and effort to research, construct, and post messages in > the original list thread.  I don't have other hardware to fall back > on, not even a cell phone.  Proceeding with the fix to the problem > strikes me as risky. > > first question: > Is what is currently in RPM Fusion non-free 36 updates everything I > need to really fix the problem for f36? > > Please don't jump the gun.  Just answer that first question.  If the > answer is positive, I'll follow up with more questions. > > further information: > Anyone wanting to view the original Nov. 03-04 thread, it's here: > "https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/thread/X6QCDYEIFO7DKZE5ENCHBCW776TC26WF/". > > Thank-you in advance. > Bill. _______________________________________________ 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

Question #1: When I do the fix, should I do it while booted in 5.19.16-200.fc36 or while booted in 6.0.5-200.fc36?