subject:"need perm. fix for monitor\/display problem."

Re: need perm. fix for monitor/display problem.

2022-12-26 Thread home user


On 12/17/22 9:46 AM, home user wrote:

On 12/17/22 12:54 AM, Samuel Sieb wrote:

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.


I'll give that a try, and open a new thread if I think there's a 
problem.  Thank-you, Samuel.


To more fully close this, the "dnf update" done on Dec. 14 apparently 
also solved the long shutdown problem.  Shutdowns since then have been 
taking well under a minute.


I'll keep that ESC trick in mind.
___
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.

2022-12-18 Thread John Pilkington

On 17/12/2022 22:38, Barry wrote:

On 17 Dec 2022, at 17:47, home user 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.

I believe that if you reboot while mandb or akmod is running its fixed up as
the system boots.
I do not wait at all after dnf update and i have never seen a problem.
This has been reliable for many years on my experience on multiple systems.
I update approx 8 fedora systems every week like this.

Barry

Agreed. It usually works. But if it doesn't there's more to fix, in a
more difficult environment. The rpmfusion guide recommends waiting.

https://rpmfusion.org/Howto/NVIDIA

/!\ Please remember to wait after the RPM transaction ends, until the
kmod get built. This can take up to 5 minutes on some systems.

and this is worth a look too: https://rpmfusion.org/CommonBugs

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@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.

2022-12-17 Thread Barry



> On 17 Dec 2022, at 17:47, home user  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.

I believe that if you reboot while mandb or akmod is running its fixed up as 
the system boots.
I do not wait at all after dnf update and i have never seen a problem.
This has been reliable for many years on my experience on multiple systems.
I update approx 8 fedora systems every week like this.

Barry

> 
>> 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@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.

2022-12-17 Thread Joe Zeff


On 12/17/2022 01:03 PM, home user wrote:

Sorry,  That should be "dnf upgrade", not "dnf update".


Doesn't really matter as update is now just another name for upgrade.
___
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.

2022-12-17 Thread home user

On 12/17/22 11:03 AM, Bill C wrote:
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.

There are others in the Fedora users list much more knowledgeable about 
dnf than am I.  I leave it to them to answer.

On Sat, Dec 17, 2022, 1:01 PM Tom Horsley > 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".

My mistake: it's "dnf upgrade", not "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.

___
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.

2022-12-17 Thread Samuel Sieb


On 12/17/22 12:03, home user wrote:

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".


Those are equivalent.  It's an alias.
___
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.

2022-12-17 Thread home user


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".

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.

...

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.

2022-12-17 Thread Patrick O'Callaghan

On Sat, 2022-12-17 at 17:15 +, John Pilkington wrote:
> > > 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.

I often keep 'glances' running in a Yakuake drop-down terminal. I can
toggle it by hitting F12 and the rest of the time it's out of the way.
Any of the *top commands would work as well of course.

poc
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: need perm. fix for monitor/display problem.

2022-12-17 Thread Bill C

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  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.
> ___
> 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.

2022-12-17 Thread Tom Horsley

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.
___
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.

2022-12-17 Thread home user


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@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.

2022-12-17 Thread home user


On 12/17/22 10:14 AM, Patrick O'Callaghan wrote:


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?).


That's hard to know as you don't say what parameters you're interested
in. It's also unclear what "graphical output" means in this context.
Process status monitors are essentially columnar. You can use 'sar'
(system activity report) to generate data which can be graphed, but
that's not in real time.


By graphical output, I mean something very similar to ksysguard's graphs 
in its "System Load" tab.


The additional things that come to mind at the moment are graphs of I/O 
(hard drive) and GPU load.  Maybe thumb drive activity?  Maybe sound 
card load?  It would also be good to be able to switch between graphs of 
overall activity and activity for a specific selected process.


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.

2022-12-17 Thread John Pilkington


On 17/12/2022 16:44, home user wrote:

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?).


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.


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
___
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.

2022-12-17 Thread Patrick O'Callaghan

On Sat, 2022-12-17 at 09:44 -0700, home user wrote:
> 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?).

That's hard to know as you don't say what parameters you're interested
in. It's also unclear what "graphical output" means in this context.
Process status monitors are essentially columnar. You can use 'sar'
(system activity report) to generate data which can be graphed, but
that's not in real time.

A quick Google search shows 'sysmon', which has some graphical
elements, but it doesn't seem to be in the standard repos. See:

https://github.com/MatthiasSchinzel/sysmon

poc
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: need perm. fix for monitor/display problem. [solved]

2022-12-17 Thread home user

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

Last night, I ran "dnf upgrade" in a terminal as root.

It did about 750 items.

After the clean-up phase was done, it started the akmod processing
(compiling).

After a few minutes, still during the akmod work (based on the ksysguard
display), still in the "dnf upgrade" command (the terminal had not yet
given me a new command prompt), the screen went blank. I could hear the
cooling fans still surging. I waited about 15 minutes, and then turned
the tower off via the power button in the back.

After a short while, the grub menu came up with a new entry
(6.0.12-200.fc36.x86_64) on the top. I let the workstation boot up that
new kernel by default. No problems. I quick-tried a few things (xv,
Firefox, a youtube video in Firefox, LibreOffice, VLC, a large weather
satellite image in Firefox). Everything seemed fine. I powered down
for the night.

This morning, so far, no problems.

I don't know what happened last night with the screen blanking, but not
noticing any further problems, I'm labelling this thread "solved".

I thank everyone who tried to help for their time, effort, and patience.

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.

Re: need perm. fix for monitor/display problem.

2022-12-17 Thread home user


On 12/17/22 12:54 AM, Samuel Sieb wrote:

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.


I'll give that a try, and open a new thread if I think there's a 
problem.  Thank-you, Samuel.

___
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.

2022-12-17 Thread home user


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?).

___
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.

2022-12-17 Thread home user


On 12/16/22 12:01 PM, Robert McBroom via users wrote:


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.


That gives me more confidence in assuming that what's in RMP Fusion is 
what I need.  Thank-you Robert.

___
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.

2022-12-16 Thread Samuel Sieb


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.

___
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.

2022-12-16 Thread Samuel Sieb


On 12/15/22 19:55, home user wrote:

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?


Do it from the working kernel.  That way there's no chance of it getting 
removed during the upgrade.

___
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.

2022-12-16 Thread Barry



> On 16 Dec 2022, at 16:26, Joe Zeff  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?

That is how the nvidia akmod stuff is set up. I do no manual steps for nvidia.
It checks on boot if there are modules for all skmods and build if missing.

Barry

> [snip]
> ___
> 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.

2022-12-16 Thread Patrick O'Callaghan

On Fri, 2022-12-16 at 11:33 -0700, home user wrote:
> 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.

$ 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
___
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.

2022-12-16 Thread Tim via users

On Fri, 2022-12-16 at 10:21 +, John Pilkington wrote:
> I prefer to let the akmods complete before rebooting, and have found in 
> the past that 'sudo systemctl reboot' was more reliable after nvidia 
> updates than the usual reboot from the GUI.

Surely if you did it from the command line, there'd be an obvious
finish to the process (an inability to issue new commands until it's
finished)?  Is there no "finished" indicator from the GUI?  That would
seem to be a very bad idea.

-- 

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.

2022-12-16 Thread Robert McBroom via users



On 12/15/22 16:03, home user wrote:

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?


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.

___
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.

2022-12-16 Thread home user


On 12/15/22 8:32 PM, Tim via users wrote:


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.


I haven't run into that yet.  As in the current situation, I first hold 
off patching until I hear that the problem is fixed.  But it's good to 
know what you suggest should a problem drag out.  Thank-you Tim.



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.


ok.  Thank-you, Tim.
___
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.

2022-12-16 Thread home user


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.


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.


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.

___
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.

2022-12-16 Thread Joe Zeff


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@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.

2022-12-16 Thread John Pilkington

On 16/12/2022 03:55, home user wrote:

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?

It was my understanding that 6.0.5 gives you problems. I would start
from the current best operational version.

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.

I prefer to let the akmods complete before rebooting, and have found in
the past that 'sudo systemctl reboot' was more reliable after nvidia
updates than the usual reboot from the GUI. But things change, and
YMMV. Good luck!

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):

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.

Thank-you in advance.
Bill.

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.

2022-12-16 Thread Barry



> On 15 Dec 2022, at 23:09, John Pilkington  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 use a script that does dnf update followed by an immediate reboot.
On reboot akmod builds the nvidia kmod, installs it, only then brings up the 
login screen.
No need to watch for the system to be quite.

Barry
> 
> 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
___
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.

2022-12-16 Thread Barry



> On 15 Dec 2022, at 21:19, 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 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.

Barry
> ___
> 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.

2022-12-15 Thread home user

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.

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.

work-around until fixed nvidia 470 drivers pass testing and reach
rpmfusion-nonfree-updates (from the Fedora users list):

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.

Thank-you in advance.
Bill.

Re: need perm. fix for monitor/display problem.

2022-12-15 Thread Bill C

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.

2022-12-15 Thread Tim via users

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.

2022-12-15 Thread home user


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.

2022-12-15 Thread home user


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: need perm. fix for monitor/display problem.

2022-12-15 Thread John Pilkington


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: need perm. fix for monitor/display problem.

2022-12-15 Thread Felix Miata

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: need perm. fix for monitor/display problem.

2022-12-15 Thread Felix Miata

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.

2022-12-15 Thread home user


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.

2022-12-15 Thread home user


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

Re: need perm. fix for monitor/display problem.

2022-12-15 Thread Robert McBroom via users

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):

---
Latest packages:

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.

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

Re: need perm. fix for monitor/display problem.

2022-12-15 Thread John Pilkington


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

need perm. fix for monitor/display problem.

2022-12-14 Thread home user

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.

work-around until fixed nvidia 470 drivers pass testing and reach
rpmfusion-nonfree-updates (from the Fedora users list):

---
Latest packages:

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.

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

43 matches

Mail list logo