On 11/3/22 3:51 PM, home user wrote:
This problem was solved by the "dnf upgrade" that I did on Dec. 14.
Details can be viewed in the follow-up thread "need perm. fix for
monitor/display problem.", launched on Dec. 14.
My thanks to everyone who tried to help.
(f36)
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 o
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'
> 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 showin
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
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 Sa
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,
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 "
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
> > displa
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 "m
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 w
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
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
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 advant
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.
> > : T
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 th
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
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
: p
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
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
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.
> 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 t
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 shutdo
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, the
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
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 fir
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 mea
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]
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
> 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
> 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 activ
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
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 k
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
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
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 worki
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 du
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
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[~]:
> --
> I
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 sc
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
install
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; dr
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;
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.
On 11/3/22 3:51 PM, home user wrote:
This had to be tabled for a while, until the RPM Fusion fixed nvidia
driver was released. Your memory of this can be refreshed using the
fedora HYPERKITTY archive of the thread here:
"https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.
On 06/11/2022 04:57, Robert McBroom via users wrote:
On 11/5/22 14:30, stan via users wrote:
On Fri, 4 Nov 2022 12:27:21 -0600
home user wrote:
Am I correct in assuming that I should not do weekly patches until
the proper updated NVidia 470 drivers reach rpmfusion-nonfree-updates?
Since the n
On 11/5/22 14:30, stan via users wrote:
On Fri, 4 Nov 2022 12:27:21 -0600
home user wrote:
Am I correct in assuming that I should not do weekly patches until
the proper updated NVidia 470 drivers reach rpmfusion-nonfree-updates?
Since the next update of the nvidia 470 drivers will probably
On Fri, 4 Nov 2022 12:27:21 -0600
home user wrote:
> Am I correct in assuming that I should not do weekly patches until
> the proper updated NVidia 470 drivers reach rpmfusion-nonfree-updates?
Since the next update of the nvidia 470 drivers will probably be to
fix this issue, it should be okay
On 11/3/22 10:05 PM, Felix Miata wrote:
home user composed on 2022-11-03 21:42 (UTC-0600):
...
initramfs-5.19.16-100.fc35.x86_64.img was either installed or updated when you
did
your customary periodic updates to F35. initramfs-5.19.16-200.fc36.x86_64.img
was
created later when you did your
home user composed on 2022-11-03 21:42 (UTC-0600):
> What I have is
> -rw---. 1 root root 33824169 Oct 20 09:47
> initramfs-5.19.16-100.fc35.x86_64.img
> -rw---. 1 root root 35051075 Oct 20 11:19
> initramfs-5.19.16-200.fc36.x86_64.img
> -rw---. 1 root root 35452743 Nov 3 13:02
>
On 11/3/22 8:48 PM, Felix Miata wrote:
home user composed on 2022-11-03 20:29 (UTC-0600):
Felix Miata wrote:
home user composed on 2022-11-03 19:02 (UTC-0600):
...
1-Backup the initrd for 5.19.
According to the man page for initrd, it should be in "/dev" and/or "/".
But using "ls -a"
home user composed on 2022-11-03 20:29 (UTC-0600):
> Felix Miata wrote:
>> home user composed on 2022-11-03 19:02 (UTC-0600):
> ...
>> 1-Backup the initrd for 5.19.
> According to the man page for initrd, it should be in "/dev" and/or "/".
> But using "ls -a", I don't see initrd in either pla
On 11/03/2022 04:59 PM, home user wrote:
How do I determine which kernel I'm using now?
uname -r
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https
On 11/3/22 7:20 PM, Felix Miata wrote:
home user composed on 2022-11-03 19:02 (UTC-0600):
...
1-Backup the initrd for 5.19.
According to the man page for initrd, it should be in "/dev" and/or "/".
But using "ls -a", I don't see initrd in either place. The "whereis"
command only find a co
home user composed on 2022-11-03 19:02 (UTC-0600):
> What specifically do I need to install?
> "dnf install [what?]" and re-boot.
> Is there anything else I need to do?
It still boots the 5.19 kernel OK, right?
1-Backup the initrd for 5.19.
2-Boot only the 5.19 kernel until such time as updated
On 11/3/22 3:51 PM, home user wrote:
(f36)
...
A few have asked about kernel and driver versions. I've been trying to
grope through logs to get answers. The logs are being split in strange
ways, ways not matching the dates on which the dnf commands were run,
making this both difficult and
On 11/3/22 4:58 PM, Jerry James wrote:
On Thu, Nov 3, 2022 at 4:45 PM home user wrote:
I do not see any such logs in the gnome "logview" tool (which is where I
see the boot and dnf logs). Where are the akmod logs?
/var/cache/akmods/nvidia
Nothing there...
-
bash.3[nvidia]: ls -a
. ..
On 11/3/22 15:59, home user wrote:
On 11/3/22 4:25 PM, Felix Miata wrote:
home user composed on 2022-11-03 15:51 (UTC-0600):
...
Were you previously using a 5.19 kernel and the new kernel is a 6.0?
The problem
is NVidia's proprietary driver isn't working, and the fallback driver
is too crude
On 03/11/2022 21:51, home user wrote:
(f36)
Good afternoon,
A short while ago, I did my weekly patches (dnf upgrade), and then
re-booted. Just before that, the workstation display (dual monitor) was
fine. After the reboot, only one display works. If I switch the monitor
cables, I still get
On 11/3/22 4:25 PM, Felix Miata wrote:
home user composed on 2022-11-03 15:51 (UTC-0600):
...
Were you previously using a 5.19 kernel and the new kernel is a 6.0? The problem
is NVidia's proprietary driver isn't working, and the fallback driver is too
crude
to support more than one display or m
On Thu, Nov 3, 2022 at 4:45 PM home user wrote:
> I do not see any such logs in the gnome "logview" tool (which is where I
> see the boot and dnf logs). Where are the akmod logs?
/var/cache/akmods/nvidia
--
Jerry James
http://www.jamezone.org/
___
use
On 11/3/22 3:59 PM, Barry wrote:
On 3 Nov 2022, at 21:53, home user wrote:
[... snip ...]
[K[ [0;31m*[0;1;31m*[0m[0;31m* [0m] (3 of 3) Job akmods.service/start
running (1min 18s / no limit)
M
[K[ [0;31m*[0;1;31m*[0m[0;31m* [0m] (3 of 3) Job akmods.service/start
running (1m
home user composed on 2022-11-03 15:51 (UTC-0600):
...
> This leads me to think that the problem is not with the monitors. The
> display in the one monitor looks a little fuzzy and stretched out
> horizontally. I also notice at the end of the boot log the following lines:
...
> What is the prob
Barry composed on 2022-11-03 21:59 (UTC):
> Seems that you want to use the nvidia driver but it is not compiled and so
> the fallback nouveau is used.
> Guess nouveau does not support 2 monitors.
Nouveau supports 2 monitors, but not when NVidia drivers interfere by
blacklisting
nouveau, which
> On 3 Nov 2022, at 21:53, home user wrote:
>
> (f36)
>
> Good afternoon,
>
> A short while ago, I did my weekly patches (dnf upgrade), and then re-booted.
> Just before that, the workstation display (dual monitor) was fine. After
> the reboot, only one display works. If I switch the mon
(f36)
Good afternoon,
A short while ago, I did my weekly patches (dnf upgrade), and then
re-booted. Just before that, the workstation display (dual monitor) was
fine. After the reboot, only one display works. If I switch the monitor
cables, I still get a one-monitor display, but on the othe
66 matches
Mail list logo
