Re: kernel locking (was: need perm. fix for)
home user composed on 2022-12-15 20:26 (UTC-0700): >> 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! That one byte difference is like a lock on the kids' toychest that either allows or prohibits the kids getting toys in or out, preserving status quo, or allowing changes to occur. I use this one always. I choose a safe time for kernel installation and removal. The kernel rarely requires changing coincident with other periodic updates, and it's my computer. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata ___ 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: need perm. fix for monitor/display problem.
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@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: need perm. fix for monitor/display problem.
As far as updates, I always use distro-sync. I am not sure how that differs from dnf upgrade. On Thu, Dec 15, 2022, 10:27 PM home user wrote: > On 12/15/22 3:04 PM, Felix Miata wrote: > > 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. > > If I understand you correctly, this is what allowed me to use the > work-around that you recommended on Nov. 3/4 - using the kernel from > before the Nov. 03 "dnf upgrade" that caused the trouble. Now I know > what controls that. Thank-you. > > > 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! > ___ > 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 > ___ 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: need perm. fix for monitor/display problem.
On Thu, 2022-12-15 at 14:03 -0700, home user wrote: > /etc/dnf/dnf.conf?... > -- > -bash.10[~]: cat /etc/dnf/dnf.conf > # see `man dnf.conf` for defaults and possible options > > [main] > gpgcheck=True > installonly_limit=3 > clean_requirements_on_remove=True > best=False > skip_if_unavailable=True > -bash.11[~]: > -- > Is your suggestion to edit the "installonly_limit" value? If yes, is my > current setting (3) of that value sufficient? 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. -- uname -rsvp Linux 3.10.0-1160.80.1.el7.x86_64 #1 SMP Tue Nov 8 15:48:59 UTC 2022 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: need perm. fix for monitor/display problem.
On 12/15/22 3:39 PM, Felix Miata wrote: 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. understood. yeah, I'm not a good writer. It may well be that no reader here who might has an authoritative answer, or is willing to speculate publicly. understood. 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. ok. 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. (responded to privately) I'll submit a separate post for the next question(s). ___ 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: need perm. fix for monitor/display problem.
On 12/15/22 3:04 PM, Felix Miata wrote: 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. If I understand you correctly, this is what allowed me to use the work-around that you recommended on Nov. 3/4 - using the kernel from before the Nov. 03 "dnf upgrade" that caused the trouble. Now I know what controls that. Thank-you. 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! ___ 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: Named keeps dying on me
ToddAndMargo via users writes: # cat /etc/resolv.conf nameserver 127.0.0.53 options edns0 trust-ad search . Ummm. This is not bind. This is, most likely, systemd-resolved. pgpjBPesEYtnH.pgp Description: PGP 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: need perm. fix for monitor/display problem.
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@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: hosting services [was Clearing DNS cache without rebooting]
On Thu, Dec 15, 2022 at 3:00 AM Tim via users wrote: > Tim: > >>> I keep meaning to change hosts, but finding someone else who actually > >>> says they use Apache (in my country) and doesn't have the worst website > >>> to navigate to look at features versus price, is a pain in the butt. Here in Nova Scotia we have a community network that operates as a non-profit proving low cost hosting for individuals and community organizations. There are many similar hosting organizations around the world, but they can be hard to find since they don’t have advertising budgets. The main drawback I have seen is that you may suffer collateral damage from fights between political factions who will file bogus takedown complaints against the “other” side of an issue, resulting in the domain appearing in blocklists. > — George N. White III > -- George N. White III ___ 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: Named keeps dying on me
On Thu, 15 Dec 2022 14:21:34 -0800 ToddAndMargo via users wrote: > Your in frustration, Has resolv.conf changed? Sometimes DHCP comes along on lease renewal and rewrites sutff. Somewhere there is a NetworkManager option to make it leave resolv.conf alone (always takes me an hour to find it though). Look at journalctl to see if named printed any useless messages before dying. I had lots of problems with named when the defaults were changed to insist on encrypted DNS and never really got it working reliably which is why I switched to dnsmasq (nice small man page for configuration instead of the 12,742 pages of bind config info :-). ___ 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: need perm. fix for monitor/display problem.
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. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata ___ 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: Named keeps dying on me
On 12/15/22 14:21, ToddAndMargo via users wrote: Hi All. FC37 bind-chroot-9.18.8-1.fc37.x86_64 I have a caching server configured. This is becoming a real pain in the ... Named can not be connected to after about five minutes. As of FC37 (no issue in FC36) # cat /etc/resolv.conf nameserver 127.0.0.53 options edns0 trust-ad search . And look what happens here: $ host gbis.com Host gbis.com not found: 2(SERVFAIL) Then if I throw a: $ host gbis.com 127.0.0.1 Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases: gbis.com has address 54.151.57.48 gbis.com mail is handled by 0 gbis.com. And now it starts working $ host gbis.com gbis.com has address 54.151.57.48 gbis.com mail is handled by 0 gbis.com. A ! Your in frustration, -T And I have to repeat the micky mouse every five minutes or so ___ 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
Named keeps dying on me
Hi All. FC37 bind-chroot-9.18.8-1.fc37.x86_64 I have a caching server configured. This is becoming a real pain in the ... Named can not be connected to after about five minutes. As of FC37 (no issue in FC36) # cat /etc/resolv.conf nameserver 127.0.0.53 options edns0 trust-ad search . And look what happens here: $ host gbis.com Host gbis.com not found: 2(SERVFAIL) Then if I throw a: $ host gbis.com 127.0.0.1 Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases: gbis.com has address 54.151.57.48 gbis.com mail is handled by 0 gbis.com. And now it starts working $ host gbis.com gbis.com has address 54.151.57.48 gbis.com mail is handled by 0 gbis.com. A ! Your in frustration, -T ___ 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: need perm. fix for monitor/display problem.
home user composed on 2022-12-15 14:03 (UTC-0700): > -bash.10[~]: cat /etc/dnf/dnf.conf > # see `man dnf.conf` for defaults and possible options > > [main] > gpgcheck=True > installonly_limit=3 > clean_requirements_on_remove=True > best=False > skip_if_unavailable=True > -bash.11[~]: > -- > Is your suggestion to edit the "installonly_limit" value? If yes, is my > current setting (3) of that value sufficient? 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. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata ___ 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: need perm. fix for monitor/display problem.
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@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: need perm. fix for monitor/display problem.
On 12/15/22 9:09 AM, Robert McBroom via users wrote: On 12/14/22 22:45, home user wrote: [... snip ...] 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 No such file... -- -bash.9[~]: cat /etc/dnf.conf cat: /etc/dnf.conf: No such file or directory -bash.10[~]: -- Do you mean /etc/dnf/dnf.conf?... -- -bash.10[~]: cat /etc/dnf/dnf.conf # see `man dnf.conf` for defaults and possible options [main] gpgcheck=True installonly_limit=3 clean_requirements_on_remove=True best=False skip_if_unavailable=True -bash.11[~]: -- Is your suggestion to edit the "installonly_limit" value? If yes, is my current setting (3) of that value sufficient? I am not clear on what you mean by "in a new major grouping". Has RPM Fusion already caught up to the current f36 kernel (6.0.5-200.fc36 or whatever is now current) in a way that fixes the problems I encountered on Nov. 03? 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 ___ 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
MuseScore 4.0
MuseScore is music composition and notation software, currently available from Fedora in the mscore package. Version 4.0 was just released. If anybody would like to try it out, it is available from this COPR: https://copr.fedorainfracloud.org/coprs/jjames/MuseScore4/. I do not intend to build for Fedora until some issues have been worked out. WARNING! WARNING! WARNING! DO NOT TRY THIS IN A WAYLAND SESSION. It will run for anywhere from a few seconds to a few minutes, then abruptly exit with a "Protocol error". Run an X session to try MuseScore 4.0. WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! Configuration for MuseScore 3.x and 4.x differs in some important respects. You may have to do a "factory reset" when switching versions. Run "mscore -R" or "mscore -F" if it won't start. This will clear out your list of recently opened scores, for example, so backup your configuration before you do this. WARNING! WARNING! WARNING! To try it out, run: sudo dnf copr enable jjames/MuseScore4 sudo dnf install musescore Please try the video export option, which has bitrotted upstream. I have attempted to update it for current ffmpeg. Please let me know if it does or does not work for you. If it works well, I will submit my patch upstream. Do this: "mscore --score-video -o filename.mp4", and optionally try the --resolution and --fps arguments. Run "mscore --help" for more information. This functionality does not seem to be available via the GUI. Upstream bundles fluidsynth, apparently for the sole purpose of implementing a caching soundfont loader that uses internal fluidsynth APIs. I have unbundled fluidsynth for this repository, which means there is no soundfont cache. If you switch soundfonts frequently, please let me know if the performance is acceptable. If you are familiar with the fluidsynth API and can implement a caching soundfont loader using only public APIs, please do so and submit it upstream. Several other products are bundled (beatroot-vamp, dtl, intervaltree, rtf2html, and KDDockWidgets). Each of them has either been altered by the MuseScore developers or, in the case of KDDockWidgets, internal APIs are used so extensively that I cannot see how to unbundle successfully. Thoughts on how any of these products might be unbundled are welcome. The COPR version makes a long-requested change: the package name changes from mscore to musescore. Let me know if you encounter any problems arising from that change. A new font package is needed to build version 4.0 for Fedora. I would appreciate a review from anybody who feels competent to review a font package: https://bugzilla.redhat.com/show_bug.cgi?id=2152347. There is a question about the appropriate foundry name. If you can help answer that question, please chime in. Regards, -- Jerry James http://www.jamezone.org/ ___ 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: need perm. fix for monitor/display problem.
On 12/14/22 22:45, home user wrote: 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. 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 ___ 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: need perm. fix for monitor/display problem.
On 15/12/2022 03:45, home user wrote: 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. 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 [john@HPFed ~]$ uname -r 6.0.12-200.fc36.x86_64 [john@HPFed ~]$ rpm -qa | grep -i nvidia nvidia-persistenced-520.56.06-1.fc36.x86_64 nvidia-texture-tools-2.1.2-3.fc36.x86_64 nvidia-gpu-firmware-20221109-144.fc36.noarch xorg-x11-drv-nvidia-470xx-libs-470.161.03-1.fc36.x86_64 xorg-x11-drv-nvidia-470xx-cuda-libs-470.161.03-1.fc36.x86_64 xorg-x11-drv-nvidia-470xx-kmodsrc-470.161.03-1.fc36.x86_64 nvidia-settings-470xx-470.161.03-1.fc36.x86_64 xorg-x11-drv-nvidia-470xx-470.161.03-1.fc36.x86_64 akmod-nvidia-470xx-470.161.03-1.fc36.x86_64 kmod-nvidia-470xx-470.161.03-1.fc36.x86_64 xorg-x11-drv-nvidia-470xx-cuda-470.161.03-1.fc36.x86_64 xorg-x11-drv-nvidia-470xx-power-470.161.03-1.fc36.x86_64 xorg-x11-drv-nvidia-470xx-devel-470.161.03-1.fc36.x86_64 kmod-nvidia-470xx-6.0.11-200.fc36.x86_64-470.161.03-1.fc36.x86_64 kmod-nvidia-470xx-6.0.10-200.fc36.x86_64-470.161.03-1.fc36.x86_64 kmod-nvidia-470xx-6.0.12-200.fc36.x86_64-470.161.03-1.fc36.x86_64 [john@HPFed ~]$ xrandr Screen 0: minimum 8 x 8, current 3040 x 1050, maximum 16384 x 16384 VGA-0 connected primary 1680x1050+0+0 (normal left inverted right x axis y axis) 433mm x 271mm 1680x1050 59.95*+ 1440x900 59.89 1280x1024 75.0260.02 1280x800 59.81 1280x720 60.00 1152x864 75.00 1024x768 75.0370.0760.00 800x600 75.0072.1960.3256.25 640x480 75.0072.8159.94 DVI-D-0 disconnected (normal left inverted right x axis y axis) HDMI-0 connected 1360x768+1680+0 (normal left inverted right x axis y axis) 708mm x 398
