Re: Updated 3 machines from 39 to 40, but on 4th machine get this error at end??

[John Pilkington]

On 19/05/2024 18:08, Michael D. Setzer II wrote:

On 19 May 2024 at 14:50, John Pilkington wrote:

Date sent:  Sun, 19 May 2024 14:50:55 +0100
Subject:Re: Updated 3 machines from 39 to 40, but on 4th
machine get this
error at end??
To: users@lists.fedoraproject.org
From:   John Pilkington 
Send reply to:  Community support for Fedora users



On 19/05/2024 09:48, Michael D. Setzer II via users wrote:

Error: Transaction test error:
file /usr/share/gir-1.0/GLib-2.0.gir conflicts between attempted
installs of glib2-devel-2.80.2-1.fc40.i686 and
glib2-devel-2.80.2-1.fc40.x86_64


# rpm -qa | grep glib2-devel
glib2-devel-2.78.6-1.fc39.x86_64
glib2-devel-2.78.6-1.fc39.i686

Don't know if other 3 machines had these installed or not?

Thanks for any recommendations??



Do you need the i686 package?


Turns out the i686 file wasn't being used by anything else, so
uninstalled it, and reran the upgrade, and it went thru fine.

Don't recall why it has both x86_64 and i686 version installed, or
why they earlier had no conflict together on 39, but now failed on
40?

Did find it stranger in rerunning the upgrade, it didn't have to
download any of files, but rpmkeys took just as long to run.

But wasn't sure uninstalling it would fix problem, so just thought
I'd check if might require something more.


I suppose you were using this:

https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline/

and it's likely that downloading with --allowerasing and/or 
--skip-broken would have gone ahead (Section 3).  But the document 
suggests a number of post-upgrade jobs, most of which ideally require 
careful thought before 'yes'  :-)



Thanks for quick reply.





I tried your rpm -qa line on one box, and worryingly got a db error:

error: rpmdbNextIterator: skipping h# 

which looks as if it has been fixed by rpm --rebuilddb.  The package
found was:

glib2-devel-2.80.2-1.fc40.x86_64

John P






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



++
  Michael D. Setzer II - Computer Science Instructor (Retired)
  mailto:mi...@guam.net
  mailto:msetze...@gmail.com
  mailto:msetze...@gmx.com
  Guam - Where America's Day Begins
  G4L Disk Imaging Project maintainer
  http://sourceforge.net/projects/g4l/
++




--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Updated 3 machines from 39 to 40, but on 4th machine get this error at end??

[John Pilkington]

On 19/05/2024 09:48, Michael D. Setzer II via users wrote:

Error: Transaction test error:
   file /usr/share/gir-1.0/GLib-2.0.gir conflicts between attempted
installs of glib2-devel-2.80.2-1.fc40.i686 and
glib2-devel-2.80.2-1.fc40.x86_64


# rpm -qa | grep glib2-devel
glib2-devel-2.78.6-1.fc39.x86_64
glib2-devel-2.78.6-1.fc39.i686

Don't know if other 3 machines had these installed or not?

Thanks for any recommendations??



Do you need the i686 package?

I tried your rpm -qa line on one box, and worryingly got a db error:

error: rpmdbNextIterator: skipping h# 

which looks as if it has been fixed by rpm --rebuilddb.  The package 
found was:


glib2-devel-2.80.2-1.fc40.x86_64

John P






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

Re: My Fedora 40 experiences

[John Pilkington]

On 18/05/2024 03:17, Stephen Morris wrote:

On 17/5/24 22:43, John Pilkington wrote:

On 17/05/2024 13:08, francis.montag...@inria.fr wrote:

Hi.

On Thu, 16 May 2024 23:04:21 +1000 Stephen Morris wrote:

On 16/5/24 21:33, George N. White III wrote:


Many users have had problems with the akmod-nvida install. For 
470xx the

module failed to compile. For newer cards, users sometimes end up with
unsigned drivers. This usually means they rebooted too quickly 
(during the

window after the module was compiled but before it was signed.).


Or before the depmod done by the postintall of the kmod-nvidia-KERNEL
RPM finishes.


I have had the reboot happen too too quickly before but in this case I
had no control over the reboot process, it happened automatically when
the installs were completed.


Right: more precisely as soon as dnf system-upgrade finishes.

As said earlier on this list:

   I made a proposal to prevent that:

 kmod failed to load after upgrade Fedora using dnf system-upgrade
 https://bugzilla.redhat.com/show_bug.cgi?id=2011120

   still waiting for approval.


This morning 'dnf upgrade' on one of my boxes installed the 
470.239.06-2 versions of akmod and kmod, while the other box, having 
the -1 nersions, said there was 'nothing to do';  then packagekit 
found them and did a preliminary reboot before install.  Both boxes 
now have the -2 versions installed and running.  The process does take 
several minutes - and I did an "akmods --rebuild --force" just to make 
sure.


F40 with plasma-workspace-x11 does seem to be working well now for me, 
and can use vdpau.
How did you get Xorg working with Plasma as I can't see any group in dnf 
to install that?


The path to where I am now has been complicated, mainly because my 
nvidia hardware is 'legacy' and its 470xx driver has not claimed to 
support Wayland.  Under Wayland all cpus max out, and keyboard/mouse are 
almost unusable.  YMMV.


dnf info plasma-workspace-x11

It's in the Fedora 'updates' repo.



The other thing I didn't like with the F40 upgrade was in F39 I had dnf 
configured to retain 5 kernels, but the F40 upgrade reset that back to 3.


My system has 450 MB /boot, space for only 2 kernels + rescue.


regards,
Steve



John P

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

Re: My Fedora 40 experiences

[John Pilkington]

On 17/05/2024 13:08, francis.montag...@inria.fr wrote:

Hi.

On Thu, 16 May 2024 23:04:21 +1000 Stephen Morris wrote:

On 16/5/24 21:33, George N. White III wrote:



Many users have had problems with the akmod-nvida install. For 470xx the
module failed to compile. For newer cards, users sometimes end up with
unsigned drivers. This usually means they rebooted too quickly (during the
window after the module was compiled but before it was signed.).


Or before the depmod done by the postintall of the kmod-nvidia-KERNEL
RPM finishes.


I have had the reboot happen too too quickly before but in this case I
had no control over the reboot process, it happened automatically when
the installs were completed.


Right: more precisely as soon as dnf system-upgrade finishes.

As said earlier on this list:

   I made a proposal to prevent that:

 kmod failed to load after upgrade Fedora using dnf system-upgrade
 https://bugzilla.redhat.com/show_bug.cgi?id=2011120

   still waiting for approval.


This morning 'dnf upgrade' on one of my boxes installed the 
470.239.06-2 versions of akmod and kmod, while the other box, having 
the -1 nersions, said there was 'nothing to do';  then packagekit found 
them and did a preliminary reboot before install.  Both boxes now have 
the -2 versions installed and running.  The process does take several 
minutes - and I did an "akmods --rebuild --force" just to make sure.


F40 with plasma-workspace-x11 does seem to be working well now for me, 
and can use vdpau.


John P



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

Re: My Fedora 40 experiences

[John Pilkington]

On 16/05/2024 12:33, George N. White III wrote:
On Thu, May 16, 2024 at 6:46 AM Stephen Morris > wrote:


I used dnf to system-upgrade to F40, which downloaded all the relevant
packages, and then I rebooted through dnf.


Did you do all the steps in 
>?


The restart updated all the packages and automatically rebooted when it
was finished.
When the grub menu was displayed after the reboot it was obvious that
the upgrade did not update the grub config as there was no entry to
boot
off the F40 installed kernel.
I booted to the display manager which I think is still gdm, and the
first thing I noticed there was the "plasma on xorg" selection had been
removed but the "Gnome on xorg" and "Gnome Classic on xorg" were still
there.
I selected the "Plasma" entry and booted into Plasma.
Having loaded Plasma I then went into the system entries menu and went
through all the options again, and it was obvious from this that the
display options I had configured with F39 had been wiped with F40. I
configured the display settings again and set the new HDR option as I
have a HDR monitor.
After the configuration changes I rebuilt the grub menus using
grub2-mkconfig to get a boot entry for the new kernel, and rebooted.
With the reboot from the new kernel, and for that matter any of the
older kernels, I got a message that the nvidia driver was not found and
it was falling back to the nouveau driver, I don't know how as the
nvidia driver was black listed in the grub menus.


Which nvidia driver was blacklisted (nouveau or nvidia-???)?  There have 
been
problems with older Nvidia cards.  Were you using nouveau on F39 or 
nvidia, and
how did you install the nvidia driver (there are multiple sites with 
different installers).
My old iMac uses 470xx from rpmfusion, which was initially in 
no-maintainer status
and required a simple patch to run on current kernels.  Last I check the 
driver was in

testing.

  From the display manager I loaded Plasma as I did after the first
upgrade boot, and Plasma displayed a black screen and never went any
further, irrespective of how long I left it for, and the only way I
could get out of that state was to use the physical reset button on the
computer.
On reboot, if I selected "Gnome" or "Gnome on Xorg", gnome would start
up quite happily, but logging out and starting Plasma would still hang
the computer.
So rebooting again to the display manager login screen, I used
ctrl+alt+F2 to switch to a terminal login process. Logging into the
terminal the first thing I did was use mokutil to check the uefi status
and it told me that uefi was disabled even though it was enabled in the
bios.
I checked whether the signing key was enrolled and it was, but the
system wasn't using the nvidia driver even though it was installed, and
a reinstall of kmod-nvidia and akmod-nvidia did nothing to alleviate
the
issue.


Many users have had problems with the akmod-nvida install.  For 470xx
the module failed to compile.  For newer cards, users sometimes end up
with unsigned drivers.  This usually means they rebooted too quickly 
(during

the window after the module was compiled but before it was signed.).

So I uninstalled the kmod-nvidia module, and did a force re-enroll of
the uefi signed key (potentially with a new key), and then rebooted to
go through the mokutil enrolment required at boot. This did not resolve
the Plasm start issue, so I loaded Gnome.
Once in Gnome I started Firefox Nightly to do some net searches to see
if I could find a solution, and the one thing that did happen at this
point was the boot did not display the "falling back to nouveau"
message, but the start of firefox displayed a message that a gpu
couldn't be found on pci. Looking for a resolution to this I found an
entry about, as part of installed nvidia drivers, to ensure the gpu
firmware was also installed.
So I did a dnf install nvidia-gpu-firmware which was then installed as
it hadn't been already.


If you had installed nvidia-??? from a 3rd party repo the Fedora firmware
package might not be required, but it is needed for nouveau.

After installing the firmware I rebooted and started Plasma, which
successfully started without issues, and when I checked the video
driver
it was finally using the nvidia driver.
This was a lot of work to resolve, and is the worst experience I've had
with any fedora system upgrade.


Blame Nvidia for forcing Fedora into convoluted workarounds instead of
helping make older hardware work on current kernels.

Rpmfusion is having difficulties finding volunteers to package software.
Fewer 

Re: /boot too small

[John Pilkington]

On 14/05/2024 08:54, Michal Schorm wrote:

Hi,

for an immediate workaround, remove the oldest kernel.
Here are the steps together with an example output:


1) List installed kernel-core packages:
# rpm -qa | grep kernel-core | sort
kernel-core-6.8.4-200.fc39.x86_64
kernel-core-6.8.6-200.fc39.x86_64
kernel-core-6.8.7-200.fc39.x86_64


2) Remove the oldest one
# dnf remove 
Dependencies resolved.

  PackageArch Version   Repository  Size

Removing:
  kernel-corex86_64   6.8.4-200.fc39@updates66 M
Removing dependent packages:
  kernel x86_64   6.8.4-200.fc39@updates 0
  kernel-modules x86_64   6.8.4-200.fc39@updates58 M
  kernel-modules-corex86_64   6.8.4-200.fc39@updates32 M
  kernel-modules-extra   x86_64   6.8.4-200.fc39@updates   2.4 M
Transaction Summary

Remove  5 Packages
Freed space: 159 M


3) profit
you have extra ~160 MB now.
System update should have enough space to install the new kernel now.


4)
Once finished, I'd recommend you to try to enlarge your /boot/
partition a bit (e.g. 100 - 500 MB ?) to avoid this problem
permanently.




Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat


I had the same problem a few days ago and did the same.  I
posted this reply but HyperKitty doesn't find it.  So..

But I installed f40 a few days ago, and today "dnf upgrade" installed 
kernel-6.8.8 but *not* vmlinuz-6.8.8, so booting failed.


My /boot partition is 450 GB, and I now have two bootable f40 kernels 
and a recent rescue kernel.  There's no room for another.  You probably 
don't have a "recovery" option.


I now have "installonly_limit=2" in /etc/dnf/dnf.conf, but a new "dnf 
upgrade" after that said there was "nothing to do".  What did work was ( 
while running 6.8.7):


sudo dnf remove kernel-core-6.8.8
sudo dnf upgrade

and then when "systemctl list-jobs" was clear, "sudo systemctl reboot"

I, too, would prefer to have a bigger /boot, but this info might help.

John P



--

On Tue, May 14, 2024 at 9:44 AM Patrick Dupre via users
 wrote:


Hello,

During an update, I get

Error Summary
-
Disk Requirements:
At least 7MB more space needed on the /boot filesystem.


How can I fix it without currently resizing /boot?
Thank

drwx--. 5 root root  4096 May 14 08:36 grub2
lrwxrwxrwx. 1 root root45 Mar  7 13:24 symvers-6.7.7-100.fc38.x86_64.xz 
-> /lib
/modules/6.7.7-100.fc38.x86_64/symvers.xz
-rw---. 1 root root  81850041 Mar  7 13:24 
initramfs-6.7.7-100.fc38.x86_64.img
-rw-r--r--. 1 root root269378 Mar  1 01:00 config-6.7.7-100.fc38.x86_64
-rw-r--r--. 1 root root   8851783 Mar  1 01:00 System.map-6.7.7-100.fc38.x86_64
-rwxr-xr-x. 1 root root  14794568 Mar  1 01:00 vmlinuz-6.7.7-100.fc38.x86_64
lrwxrwxrwx. 1 root root45 Feb 13 17:38 symvers-6.7.4-100.fc38.x86_64.xz 
-> /lib
/modules/6.7.4-100.fc38.x86_64/symvers.xz
-rw---. 1 root root  81905180 Feb 13 17:37 
initramfs-6.7.4-100.fc38.x86_64.img
-rw-r--r--. 1 root root269327 Feb  5 01:00 config-6.7.4-100.fc38.x86_64
-rw-r--r--. 1 root root   8850577 Feb  5 01:00 System.map-6.7.4-100.fc38.x86_64
-rwxr-xr-x. 1 root root  14806856 Feb  5 01:00 vmlinuz-6.7.4-100.fc38.x86_64
lrwxrwxrwx. 1 root root46 Jan 25 13:39 symvers-6.6.13-100.fc38.x86_64.xz 
-> /li
b/modules/6.6.13-100.fc38.x86_64/symvers.xz
-rw---. 1 root root  42503616 Jan 25 13:39 
initramfs-6.6.13-100.fc38.x86_64.img
-rw-r--r--. 1 root root266375 Jan 20 01:00 config-6.6.13-100.fc38.x86_64
-rw---. 1 root root   8786049 Jan 20 01:00 System.map-6.6.13-100.fc38.x86_64
-rwxr-xr-x. 1 root root  14676712 Jan 20 01:00 vmlinuz-6.6.13-100.fc38.x86_64
-rw-r--r--. 1 root root147744 Jan  7 01:00 memtest86+x64.bin
drwx--. 4 root root  4096 Jun 20  2023 efi
drwxr-xr-x. 2 root root  4096 Jun 20  2023 extlinux
-rw---. 1 root root 103940590 Jul 21  2022 
initramfs-0-rescue-c60d54440c4d444a9eb5a084a65edf40.img
-rwxr-xr-x. 1 root root  11802352 Jul 21  2022 
vmlinuz-0-rescue-c60d54440c4d444a9eb5a084a65edf40

drwxr-xr-x. 3 root root  4096 Jul 21  2022 loader
drwx--. 2 root root 16384 Jul 21  2022 lost+found


===
  Patrick DUPRÉ | | email: pdu...@gmx.com
===
--

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

Re: What is Castor ? Att.Jonathan Billings.

[John Pilkington]

On 10/05/2024 15:51, John Pilkington wrote:

On 10/05/2024 15:00, George N. White III wrote:
On Wed, May 8, 2024 at 5:13 PM John Pilkington <mailto:johnpilk...@gmail.com>> wrote:


    On 08/05/2024 20:13, Samuel Sieb wrote:
 > On 5/8/24 10:50 AM, John Pilkington wrote:
 >> The harware was working well, before my recent upgrades from f38,
 >> briefly to f39 and now to f40.  Then I was using the rpmfusion
    470xx
 >> builds of the nvidia legacy drivers.   Now the dual-boot box 
has no

 >> nvidia or nouveau rpms installed  (rpm -qa) although I suppose
    bits of
 >> config might remain;  inxi still finds nvidia traces:
 >
 > Nouveau is included with the kernel, it doesn't have its own 
package.


    xorg-x11-drv-nouveau is supplied by fedora, but I was told that the
    kernel driver was more up to date, so I removed the fformer.


I have a late 2012 iMac with Nvidia that was using 470xx.  I mostly 
use nouveau

with wayland, but do have xorg-x11-drv-nouveau.

There were issues with 470xx failing to build in F40 with the akmods 
install from
rpmfusion, but now there is a testing version that does install.  Some 
users have
success with the Nvidia installer. I have the rpmfusion-testing 
package installed

but haven't had time to test it.  I don't think it supports Wayland.



Thanks for your comment.  I posted later, in this thread but with a 
subject-line change. It does show in HyperKitty and I've put a link to 
it on the rpmfusion list.


I have just updated that, re the dual-boot box.  See below:

I have removed all nouveau packages and installed all *470xx" packages, 
which installed the new versions.  That gave HDMI and vga screens with 
their expected resolutions but essentially no user interactivity because 
active kwin_wayland runs all cpus at full throttle. Perhaps that's 'not 
supported'.


Ctrl/Alt/F3 still works, and I have 6.8.9 now.  That complained that 
there was "no space on /boot/efi/EFI/Linux/Fedora " (200 MB) but seems 
to run (with the same cpu runaway) after I deleted several f39 files.


I hope this doesn't offend any 'religious' beliefs.  Installing

plasma-workspace-x11

(in the updates repo but NOT supported by the Fedora KDE SIG)

and selecting "Desktop Session: Plasma (X11)" in the login screen, has 
apparently restored this system to a usable state.  At present password 
entry still has a sluggish keyboard.



The single-boot box is still running nouveau.



Cheers,

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: What is Castor ? Att.Jonathan Billings.

[John Pilkington]

On 10/05/2024 15:00, George N. White III wrote:
On Wed, May 8, 2024 at 5:13 PM John Pilkington <mailto:johnpilk...@gmail.com>> wrote:


On 08/05/2024 20:13, Samuel Sieb wrote:
 > On 5/8/24 10:50 AM, John Pilkington wrote:
 >> The harware was working well, before my recent upgrades from f38,
 >> briefly to f39 and now to f40.  Then I was using the rpmfusion
470xx
 >> builds of the nvidia legacy drivers.   Now the dual-boot box has no
 >> nvidia or nouveau rpms installed  (rpm -qa) although I suppose
bits of
 >> config might remain;  inxi still finds nvidia traces:
 >
 > Nouveau is included with the kernel, it doesn't have its own package.

xorg-x11-drv-nouveau is supplied by fedora, but I was told that the
kernel driver was more up to date, so I removed the fformer.


I have a late 2012 iMac with Nvidia that was using 470xx.  I mostly use 
nouveau

with wayland, but do have xorg-x11-drv-nouveau.

There were issues with 470xx failing to build in F40 with the akmods 
install from
rpmfusion, but now there is a testing version that does install.  Some 
users have
success with the Nvidia installer. I have the rpmfusion-testing package 
installed

but haven't had time to test it.  I don't think it supports Wayland.



Thanks for your comment.  I posted later, in this thread but with a 
subject-line change. It does show in HyperKitty and I've put a link to 
it on the rpmfusion list.


I have removed all nouveau packages and installed all *470xx" packages, 
which installed the new versions.  That gave HDMI and vga screens with 
their expected resolutions but essentially no user interactivity because 
active kwin_wayland runs all cpus at full throttle. Perhaps that's 'not 
supported'.


Ctrl/Alt/F3 still works, and I have 6.8.9 now.  That complained that 
there was "no space on /boot/efi/EFI/Linux/Fedora " (200 MB) but seems 
to run (with the same cpu runaway) after I deleted several f39 files.


The single-boot box is still running nouveau.

Cheers,

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

F40 dual-boot problem, was Re: What is Castor ? Att.Jonathan Billings.

[John Pilkington]

On 08/05/2024 21:57, Samuel Sieb wrote:

On 5/8/24 1:13 PM, John Pilkington wrote:

On 08/05/2024 20:13, Samuel Sieb wrote:

On 5/8/24 10:50 AM, John Pilkington wrote:
The harware was working well, before my recent upgrades from f38, 
briefly to f39 and now to f40.  Then I was using the rpmfusion 470xx 
builds of the nvidia legacy drivers.   Now the dual-boot box has no 
nvidia or nouveau rpms installed  (rpm -qa) although I suppose bits 
of config might remain;  inxi still finds nvidia traces:


Nouveau is included with the kernel, it doesn't have its own package.


xorg-x11-drv-nouveau is supplied by fedora, but I was told that the 
kernel driver was more up to date, so I removed the fformer.


xorg-x11-drv-nouveau is the xorg driver that uses (and requires) the 
kernel driver.  You need both.


llvmpipe means it's using software 3D rendering because it doesn't 
have a 3d hardware driver.


I don't think I want 3D


KDE/wayland uses 3D rendering.


   API: Vulkan v: 1.3.280 drivers: N/A surfaces: xcb,xlib,wayland


$ sudo dmesg | less

[    0.00] Command line: 
BOOT_IMAGE=(hd2,gpt2)/vmlinuz-6.8.8-300.fc40.x86_64 
root=/dev/mapper/fedora_localhost--live-root ro 
rd.driver.blacklist=nvidia modprobe.blacklist=nvidia nomodeset 
resume=/dev/mapper/fedora_localhost--live-swap 
rd.lvm.lv=fedora_localhost-live/root 
rd.lvm.lv=fedora_localhost-live/swap rhgb quiet 
rd.driver.blacklist=nvidia modprobe.blacklist=nvidia nomodeset


There are a lot of duplicates in that list.  If you include 
"nomodeset", then you'll be using the lowest common factor display 
options.  Is there a reason you don't want to use the rpmfusion 
drivers?  It appears that nouveau isn't working for your system, or 
else something is mixed up. You could check the logs for a previous 
boot that didn't work.


I have happily used the rpmfusion builds of 470xx until a few weeks 
ago; but it was said that wayland support was missing, and for some 
time akmods failed to build anyway.  I hoped to be able to use the 
reverse-engineered FOSS drivers.  And a few days ago, after reverting 
to 470xx, kwin_wayland appeared to be running 4 cpu cores at 90% and 
the mouse was unusable.


As far as I know, the NVidia drivers have had Wayland support for a long 
time.  That CPU usage is likely if you're using software 3D rendering. 
You need to sort out what you have installed.


On the linux-only box I have nvidia-gpu-firmware installed.  It may 
not be loading (MythTV says vdpau isn't available) but that system 
currently does the jobs that I want.


My apologies, by the way, for what looks like a hijack.


Yes, you definitely should have started a new thread.


but it seems better to continue here.

On the dual-boot box I have done

"sudo dnf remove *nouveau*", which removed nouveau-firmware and 
xorg-x11-drv-nouveau


"sudo dnf install *470xx*", which pulled in the rpmfusion builds of the 
legacy nvidia driver and updated the kernel command line.  Wayland 
support has been said to start at series 490, which is why I had been 
looking at nouveau.


"sudo dnf upgrade" because things are moving quickly at present.

Now booting goes as expected, giving two screens at their expected 
resolution *BUT* the cursor movement is jerky, keyboard response is very 
slow, and "atop" shows 4 3GHz cores at 99%, for kwin_wayland. 
Ctrl/Alt/F3 is the only way to make progress.


Throughout this saga there have been fleeting complaints about the abrtd 
service.  It's the only one that "systemctl" lists in red.


Ctrl/Alt/F1 says the abrtd.service failed to start and lists Dependency 
issues for four abrtd services.  I haven't investigated more.


In some ways this is progress, but the system is less usable than the 
800x600 nouveau-only form.


{{{

$ inxi -GA

Graphics:
  Device-1: NVIDIA GK208B [GeForce GT 710] driver: nvidia v: 470.239.06
  Device-2: Chicony HP 720p HD Monitor Webcam driver: 
snd-usb-audio,uvcvideo type: USB
  Display: server: X.org v: 1.20.14 with: Xwayland v: 23.2.6 driver: X: 
loaded: nvidia
unloaded: fbdev,modesetting,nouveau,vesa gpu: 
nvidia,nvidia-nvswitch tty: 100x37 resolution:

1: 1360x768 2: 1920x1080
  API: EGL v: 1.5 drivers: kms_swrast,nvidia,swrast platforms: 
gbm,wayland,surfaceless,device
  API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: mesa v: 24.0.6 note: 
console (EGL sourced)
renderer: llvmpipe (LLVM 18.1.1 256 bits), NVIDIA GeForce GT 
710/PCIe/SSE2

  API: Vulkan v: 1.3.280 drivers: N/A surfaces: wayland
Audio:
  Device-1: Intel 6 Series/C200 Series Family High Definition Audio 
driver: snd_hda_intel

  Device-2: NVIDIA GK208 HDMI/DP Audio driver: snd_hda_intel
  Device-3: Chicony HP 720p HD Monitor Webcam driver: 
snd-usb-audio,uvcvideo type: USB
  Device-4: C-Media USB PnP Sound Device driver: 
hid-generic,snd-usb-audio,usbhid type: USB

  API: ALSA v: k6.8.8-300.fc40.x86_64 status: kernel-api
  Server-1: PipeWire v: 1.0.5 status: active

}}}
--
__

Re: What is Castor ? Att.Jonathan Billings.

[John Pilkington]

On 08/05/2024 20:13, Samuel Sieb wrote:

On 5/8/24 10:50 AM, John Pilkington wrote:
The harware was working well, before my recent upgrades from f38, 
briefly to f39 and now to f40.  Then I was using the rpmfusion 470xx 
builds of the nvidia legacy drivers.   Now the dual-boot box has no 
nvidia or nouveau rpms installed  (rpm -qa) although I suppose bits of 
config might remain;  inxi still finds nvidia traces:


Nouveau is included with the kernel, it doesn't have its own package.


xorg-x11-drv-nouveau is supplied by fedora, but I was told that the 
kernel driver was more up to date, so I removed the fformer.



ohn@FedWin4c1:~$ inxi -G
Graphics:
   Device-1: NVIDIA GK208B [GeForce GT 710] driver: N/A
   Display: wayland server: X.org v: 1.20.14 with: Xwayland v: 23.2.6
 compositor: kwin_wayland driver: X: loaded: nvidia


This is the xorg nvidia drive, but I assume it's not working if the 
kernel driver isn't loaded.


 unloaded: fbdev,modesetting,nouveau,vesa gpu: N/A resolution: 
800x600

   API: EGL v: 1.5 drivers: kms_swrast,swrast
 platforms: gbm,wayland,x11,surfaceless,device
   API: OpenGL v: 4.5 vendor: mesa v: 24.0.6 renderer: llvmpipe (LLVM 
18.1.1

 256 bits)


llvmpipe means it's using software 3D rendering because it doesn't have 
a 3d hardware driver.


I don't think I want 3D



   API: Vulkan v: 1.3.280 drivers: N/A surfaces: xcb,xlib,wayland


$ sudo dmesg | less

[    0.00] Command line: 
BOOT_IMAGE=(hd2,gpt2)/vmlinuz-6.8.8-300.fc40.x86_64 
root=/dev/mapper/fedora_localhost--live-root ro 
rd.driver.blacklist=nvidia modprobe.blacklist=nvidia nomodeset 
resume=/dev/mapper/fedora_localhost--live-swap 
rd.lvm.lv=fedora_localhost-live/root 
rd.lvm.lv=fedora_localhost-live/swap rhgb quiet 
rd.driver.blacklist=nvidia modprobe.blacklist=nvidia nomodeset


There are a lot of duplicates in that list.  If you include "nomodeset", 
then you'll be using the lowest common factor display options.  Is there 
a reason you don't want to use the rpmfusion drivers?  It appears that 
nouveau isn't working for your system, or else something is mixed up. 
You could check the logs for a previous boot that didn't work.



I have happily used the rpmfusion builds of 470xx until a few weeks ago; 
but it was said that wayland support was missing, and for some time 
akmods failed to build anyway.  I hoped to be able to use the 
reverse-engineered FOSS drivers.  And a few days ago, after reverting to 
470xx, kwin_wayland appeared to be running 4 cpu cores at 90% and the 
mouse was unusable.


On the linux-only box I have nvidia-gpu-firmware installed.  It may not 
be loading (MythTV says vdpau isn't available) but that system 
currently does the jobs that I want.


My apologies, by the way, for what looks like a hijack.

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: What is Castor ? Att.Jonathan Billings.

[John Pilkington]

On 08/05/2024 17:54, Roger Heflin wrote:

On Wed, May 8, 2024 at 5:09 AM John Pilkington  wrote:


On 08/05/2024 10:18, Tim via users wrote:

On Tue, 2024-05-07 at 17:36 -0400, Jonathan Billings wrote:

Some home router/gateways will remember the hostname a system used as
part of their network, and when handing out the same IP to a new
host, re-uses the saved hostname.


I've yet to come across a home gateway that handles name resolution,
they just dole out numerical IPs from their DHCP server, it also seems
to be a bit of a rarity for a client to accept a hostname that a DHCP
server does supply (if it does).  DHCP clients can also request the
DHCP server lets them use their own hostname, and that's often ignored,
too.

More often than not, a client would to a reverse DNS look-up on its
assigned IP to see what domain/hostname is associated with that IP
(which could be a DNS query, but first it looks in the hosts file).

Not everyone has a DNS server, or a configurable one, nor adjusts their
hosts file (often fighting with Network Mangler over it).  So:


Set your preferred hostname either in GNOME Settings (or whatever
DE’s settings) or with hostnamectl.


Which stores a setting somewhere naming itself consistently, whatever
IP address you get given.

This can get messy if you get assigned different numerical IPs from
time to time.


It occurs to me that my new 'dual-boot' problems with F40 KDE might be
related to this, but I'm not clear how I could test it.  I've posted
both here and on the kde list.

I have two screen-devices, HDMI tv and vga monitor.  By default booting
is to Windows, but 'escape' early on goes to an HP-provided
boot-selection sequence and grub.

Choosing "modesetting" starts booting with both screens active, but
freezes shortly after a cursor appears.

"nomodeset" gives a usable system, but with the vga screen never active
and final HDMI resolution fixed at 800x600.

Could this perhaps be a conflict of hostnames set at power-on and by Fedora?

John P


No.

Whatever the hostname is it really does not matter for booting or not.

The fact that nomodeset works tells me that the graphics driver in the
kernel is unable to handle your card and/or monitors in some critical
way.

What kind of vga/video card do you have?


Thanks, Tim and Roger, for both these replies.

The harware was working well, before my recent upgrades from f38, 
briefly to f39 and now to f40.  Then I was using the rpmfusion 470xx 
builds of the nvidia legacy drivers.   Now the dual-boot box has no 
nvidia or nouveau rpms installed  (rpm -qa) although I suppose bits of 
config might remain;  inxi still finds nvidia traces:


{{{

ohn@FedWin4c1:~$ inxi -G
Graphics:
  Device-1: NVIDIA GK208B [GeForce GT 710] driver: N/A
  Display: wayland server: X.org v: 1.20.14 with: Xwayland v: 23.2.6
compositor: kwin_wayland driver: X: loaded: nvidia
unloaded: fbdev,modesetting,nouveau,vesa gpu: N/A resolution: 800x600
  API: EGL v: 1.5 drivers: kms_swrast,swrast
platforms: gbm,wayland,x11,surfaceless,device
  API: OpenGL v: 4.5 vendor: mesa v: 24.0.6 renderer: llvmpipe (LLVM 18.1.1
256 bits)
  API: Vulkan v: 1.3.280 drivers: N/A surfaces: xcb,xlib,wayland


$ sudo dmesg | less

[0.00] Command line: 
BOOT_IMAGE=(hd2,gpt2)/vmlinuz-6.8.8-300.fc40.x86_64 
root=/dev/mapper/fedora_localhost--live-root ro 
rd.driver.blacklist=nvidia modprobe.blacklist=nvidia nomodeset 
resume=/dev/mapper/fedora_localhost--live-swap 
rd.lvm.lv=fedora_localhost-live/root 
rd.lvm.lv=fedora_localhost-live/swap rhgb quiet 
rd.driver.blacklist=nvidia modprobe.blacklist=nvidia nomodeset


Mose variations of this give a frozen system.

}}}

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: What is Castor ? Att.Jonathan Billings.

[John Pilkington]

On 08/05/2024 10:18, Tim via users wrote:

On Tue, 2024-05-07 at 17:36 -0400, Jonathan Billings wrote:

Some home router/gateways will remember the hostname a system used as
part of their network, and when handing out the same IP to a new
host, re-uses the saved hostname.


I've yet to come across a home gateway that handles name resolution,
they just dole out numerical IPs from their DHCP server, it also seems
to be a bit of a rarity for a client to accept a hostname that a DHCP
server does supply (if it does).  DHCP clients can also request the
DHCP server lets them use their own hostname, and that's often ignored,
too.

More often than not, a client would to a reverse DNS look-up on its
assigned IP to see what domain/hostname is associated with that IP
(which could be a DNS query, but first it looks in the hosts file).

Not everyone has a DNS server, or a configurable one, nor adjusts their
hosts file (often fighting with Network Mangler over it).  So:


Set your preferred hostname either in GNOME Settings (or whatever
DE’s settings) or with hostnamectl.


Which stores a setting somewhere naming itself consistently, whatever
IP address you get given.

This can get messy if you get assigned different numerical IPs from
time to time.


It occurs to me that my new 'dual-boot' problems with F40 KDE might be 
related to this, but I'm not clear how I could test it.  I've posted 
both here and on the kde list.


I have two screen-devices, HDMI tv and vga monitor.  By default booting 
is to Windows, but 'escape' early on goes to an HP-provided 
boot-selection sequence and grub.


Choosing "modesetting" starts booting with both screens active, but 
freezes shortly after a cursor appears.


"nomodeset" gives a usable system, but with the vga screen never active 
and final HDMI resolution fixed at 800x600.


Could this perhaps be a conflict of hostnames set at power-on and by Fedora?

John P



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

Re: Fedora 40 and nouveau

[John Pilkington]

On 07/05/2024 14:07, Andre Robatino wrote:

I have a very old computer with GeForce 6150SE nForce 430 integrated video. I had video trouble as 
well, had been using just "nomodeset" to work around it, but got 1024x768 pincushioned 
video on my old CRT with 1280x1024 as the maximum resolution. (This is just a backup machine now, 
that I normally just ssh into to do updates, so I could tolerate it.) The machine is dual boot with 
Windows 10 where I get normal 1280x1024 video. Probably Windows has a much bigger hardware database 
and is better able to work around quirky hardware. Anyway, with F40 it wouldn't boot to graphical 
at all, but I eventually found that adding "nomodeset vga=795" fixes the video and lets 
it come up in 1280x1024, without pincushioning, like in Windows. (I'm not able to change the video 
resolution as an ordinary user, in Settings, but I don't care since the resolution is optimal.) 
Both options are necessary. The video mode numbers are at 
https://en.wikipedia.org/wiki/VESA_BIOS_Extensions#Linux_video_mode_numbers
   . So try "nomodeset vga=XXX" where XXX is the desired mode.


Thank you for that - and ISTR that you had posted something similar 
earlier.   I have tried it, and variations on it, but any 
boot-to-completion still gives me 800x600.


I just tried playback of 1920x1080, and it was fine, but ffmpeg used 4 
cores all at 90%.  Letting the TV do the heavy lifting is better.


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: Fedora 40 and nouveau

[John Pilkington]

On 07/05/2024 05:12, Felix Miata wrote:

John Pilkington composed on 2024-05-06 12:32 (UTC+0100):


Both my old HP boxes have F40 up-to-date.  Both are connected to an HDMI
tv and vga monitor, but the one dual-booted with Windows has a fixed
800x600 screen size that appears only on the HDMI screen but lacks HDMI
audio.  I reinstalled the (Fedora provided) nouveau driver on both boxes
before these reboots.  The boot lines shown give running systems.  Most
variants that I have tried freeze sooner or later.



I still have no idea of how to pre-specify the devices that I want to use.


It's not clear to me whether you're trying to solve a video problem, an audio
problem, or both, or whether the answers apply to both hosts, or just one.



Good luck with your audio. Getting Linux audio to me is inexplicable hocus 
pocus.


Thank you for the various diagnostic quotes from your system.  My main 
reason for posting was to provide info about settings that worked for 
me, because I find testing of systems that fail to boot frustrating.


I have removed xorg-x11-drv-nouveau from the dual-boot box, and applied 
today's upgrades.  It still seems to need "nomodeset" to boot to a 
working system, still 800x600 and only on the HDMI screen, with line-out 
audio.  Specifying "modesetting" starts well, with both screens active 
in text mode; but then it jumps to graphical memory images, and shortly 
after the cursor appears it, and then the whole system, freezes.


Continuing

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

Fedora 40 and nouveau

[John Pilkington]

Both my old HP boxes have F40 up-to-date.  Both are connected to an HDMI 
tv and vga monitor, but the one dual-booted with Windows has a fixed 
800x600 screen size that appears only on the HDMI screen but lacks HDMI 
audio.  I reinstalled the (Fedora provided) nouveau driver on both boxes 
before these reboots.  The boot lines shown give rrunning systems.  Most 
variants that I have tried freeze sooner or later.


I still have no idea of how to pre-specify the devices that I want to use.

John P

{{{
The same packages are on both boxes:

[john@HPFed ~]$
[john@HPFed ~]$ rpm -qa | grep -i nouveau
nouveau-firmware-340.32-12.fc40.noarch
xorg-x11-drv-nouveau-1.0.17-7.fc40.x86_64
[john@HPFed ~]$
[john@HPFed ~]$
[john@HPFed ~]$
[john@HPFed ~]$ rpm -qa | grep -i nvidia
nvidia-gpu-firmware-20240410-1.fc40.noarch
[john@HPFed ~]$

===

This box works acceptably for me, but may not provide hardware 
acceleration or deinterlace.


[john@HPFed ~]$
[john@HPFed ~]$
[john@HPFed ~]$ sudo dmesg | grep -i nouveau
[sudo] password for john:
[0.00] Command line: 
BOOT_IMAGE=(hd0,msdos1)/vmlinuz-6.8.8-300.fc40.x86_64 
root=/dev/mapper/fedora-root ro rd.driver.blacklist=nvidia 
modprobe.blacklist=nvidia nouveau-drm.modeset=1 rd.lvm.lv=fedora/swap 
rd.lvm.lv=fedora/root rhgb quiet
[0.080150] Kernel command line: 
BOOT_IMAGE=(hd0,msdos1)/vmlinuz-6.8.8-300.fc40.x86_64 
root=/dev/mapper/fedora-root ro rd.driver.blacklist=nvidia 
modprobe.blacklist=nvidia nouveau-drm.modeset=1 rd.lvm.lv=fedora/swap 
rd.lvm.lv=fedora/root rhgb quiet

[6.251690] nouveau :01:00.0: vgaarb: deactivate vga console
[6.259071] nouveau :01:00.0: NVIDIA GK208B (b060b0b1)
[6.471713] nouveau :01:00.0: bios: version 80.28.a6.00.35
[6.478430] nouveau :01:00.0: fb: 1024 MiB DDR3
[7.506681] nouveau :01:00.0: DRM: VRAM: 1024 MiB
[7.506687] nouveau :01:00.0: DRM: GART: 1048576 MiB
[7.506691] nouveau :01:00.0: DRM: TMDS table version 2.0
[7.509397] nouveau :01:00.0: DRM: MM: using COPY for buffer copies
[7.519874] [drm] Initialized nouveau 1.4.0 20120801 for :01:00.0 
on minor 0

[7.717489] fbcon: nouveaudrmfb (fb0) is primary device
[7.864230] nouveau :01:00.0: [drm] fb0: nouveaudrmfb frame 
buffer device
[   26.289099] snd_hda_intel :01:00.1: bound :01:00.0 (ops 
nv50_audio_component_bind_ops [nouveau])

[john@HPFed ~]$
[john@HPFed ~]$
[john@HPFed ~]$
[john@HPFed ~]$
[john@HPFed ~]$ sudo dmesg | grep -i nvidia
[0.00] Command line: 
BOOT_IMAGE=(hd0,msdos1)/vmlinuz-6.8.8-300.fc40.x86_64 
root=/dev/mapper/fedora-root ro rd.driver.blacklist=nvidia 
modprobe.blacklist=nvidia nouveau-drm.modeset=1 rd.lvm.lv=fedora/swap 
rd.lvm.lv=fedora/root rhgb quiet
[0.080150] Kernel command line: 
BOOT_IMAGE=(hd0,msdos1)/vmlinuz-6.8.8-300.fc40.x86_64 
root=/dev/mapper/fedora-root ro rd.driver.blacklist=nvidia 
modprobe.blacklist=nvidia nouveau-drm.modeset=1 rd.lvm.lv=fedora/swap 
rd.lvm.lv=fedora/root rhgb quiet

[6.259071] nouveau :01:00.0: NVIDIA GK208B (b060b0b1)
[   26.293617] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input11
[   26.293770] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input12
[   26.293969] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input13
[   26.294042] input: HDA NVidia HDMI/DP,pcm=9 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input14

[john@HPFed ~]$

===

Dual-boot giving HDMI 800x600 window only and no HDMI audio.

john@FedWin4c1:~$
john@FedWin4c1:~$
john@FedWin4c1:~$ sudo dmesg | grep -i nouveau
john@FedWin4c1:~$
john@FedWin4c1:~$
john@FedWin4c1:~$
john@FedWin4c1:~$ sudo dmesg | grep -i nvidia
[0.00] Command line: 
BOOT_IMAGE=(hd2,gpt2)/vmlinuz-6.8.8-300.fc40.x86_64 
root=/dev/mapper/fedora_localhost--live-root ro 
rd.driver.blacklist=nvidia modprobe.blacklist=nvidia nomodeset 
resume=/dev/mapper/fedora_localhost--live-swap 
rd.lvm.lv=fedora_localhost-live/root 
rd.lvm.lv=fedora_localhost-live/swap rhgb quiet 
rd.driver.blacklist=nvidia modprobe.blacklist=nvidia nomodeset
[0.00] Kernel command line: 
BOOT_IMAGE=(hd2,gpt2)/vmlinuz-6.8.8-300.fc40.x86_64 
root=/dev/mapper/fedora_localhost--live-root ro 
rd.driver.blacklist=nvidia modprobe.blacklist=nvidia nomodeset 
resume=/dev/mapper/fedora_localhost--live-swap 
rd.lvm.lv=fedora_localhost-live/root 
rd.lvm.lv=fedora_localhost-live/swap rhgb quiet 
rd.driver.blacklist=nvidia modprobe.blacklist=nvidia nomodeset
[   20.370975] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input9
[   20.371114] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input10
[   20.371229] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input11
[   20.371315] input: HDA 

Re: How to increase size of /boot partition

[John Pilkington]

On 03/05/2024 18:52, richard emberson wrote:

Just today I upgraded from 39 to 40 but there was an issue:
dnf told me I needed some 800k more space in my /boot partition to proceed.
I had two kernels in /boot so I dnf removed those associated with the older
of the two kernels. I then successfully upgraded.
I fear the next time I do a dnf update which includes a new kernel I will
be told, again, that there is not enough space in my /boot partition.

So, how can I increase the size of the /boot partition? Many partitions,
like /tmp, are bigger than they need to be.

Here is what how the /sda disk is organized.
$ lsblk
NAME  MAJ:MIN RM   SIZE RO TYPE  
MOUNTPOINTS

sda 8:0    0 223.6G  0 disk
├─sda1  8:1    0   250M  0 part  /boot
├─sda2  8:2    0 105.5G  0 part
│ └─luks-a2ebb2b0-527d-47f3-83ef-e5908805f31d
│ 253:3    0 105.5G  0 crypt /ssd
├─sda3  8:3    0  97.7G  0 part
│ └─luks-35719a97-5898-4420-9a56-1576ffdc6db3
│ 253:1    0  97.7G  0 crypt /
├─sda4  8:4    0 1K  0 part
├─sda5  8:5    0   9.8G  0 part
│ └─luks-5ee2ed8e-4bdf-43e1-adb0-34a70610a77f
│ 253:2    0   9.8G  0 crypt /tmp
└─sda6  8:6    0   9.8G  0 part
   └─luks-03c06df8-f9b9-4f0d-847e-79a7ed527888
   253:0    0   9.8G  0 crypt [SWAP]

$ df -h
Filesystem  Size  Used Avail Use% Mounted on
/dev/dm-1    96G   22G   70G  25% /
devtmpfs    4.0M 0  4.0M   0% /dev
tmpfs    16G 0   16G   0% /dev/shm
tmpfs   6.3G  1.8M  6.3G   1% /run
/dev/sda1   237M  179M   42M  82% /boot
/dev/dm-2   9.5G  260K  9.0G   1% /tmp
/dev/dm-3   104G  193M   99G   1% /ssd
/dev/dm-4   1.9T  1.2T  630G  66% /home
/dev/dm-5   1.7T  903G  736G  56% /data1
/dev/dm-6    20G   12G  6.9G  63% /var
tmpfs   3.2G  152K  3.2G   1% /run/user/1000


Thanks for any help give.

I realize one way is to backup /home and then reinstall Fedora but
1) that seems like a lot of work and
2) it would mean that the machine in question would then have to
use Wayland rather than Xorg.

Richard


This isn't a direct reply to your question:  IIUC you need to run a 
'live' image to do that.


But I installed f40 a few days ago, and today "dnf upgrade" installed 
kernel-6.8.8 but *not* vmlinuz-6.8.8, so booting failed.


My /boot partition is 450 GB, and I now have two bootable f40 kernels 
and a recent rescue kernel.  There's no room for another.  You probably 
don't have a "recovery" option.


I now have "installonly_limit=2" in /etc/dnf/dnf.conf, but a new "dnf 
upgrade" after that said there was "nothing to do".  What did work was ( 
while running 6.8.7):


sudo dnf remove kernel-core-6.8.8
sudo dnf upgrade

and then when "systemctl list-jobs" was clear, "sudo systemctl reboot"

I, too, would prefer to have a bigger /boot, but this info might help.

John P


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

Re: System upgrades. Where is the / filesystem?

[John Pilkington]

On 01/05/2024 15:51, Felix Miata wrote:

John Pilkington composed on 2024-05-01 09:31 (UTC+0100):


I'm not aware of any snapshots, and suspect that Felix has a quicker way
of finding the relevant 'freespace' than waiting for dnf's version to
appear.  Perhaps it's shown during the 'rpm --force' installs?  I have
around 3400 packages.


Math is required. Unless your packages cache is elsewhere than on an extX /
filesystem, do:

df /

Did it yet increase by as much as the amount of additional freespace required 
that
dnf system-upgrade first reported? If no, upgrade and remove another large rpm
from the filesystem, and check again. Repeat until the number has become large
enough. This only works as intended with a real remove, not with some file 
manager
that moves to trash instead of actually removing. I use only mc or fcl or 
various
cmdline utils for file management, never Dolphin or Thunar or any other GUI file
manager.

Also, if you added kernel* to dnf.conf skip list, you can remove it from the
cache. DNF pretends everything in the skip list does not exist. The 5 raw 6.8.7 
or
6.8.5 rpms are well upwards of 100MB. When time comes that upgrade has otherwise
completed, kernel* must be removed from the skip list to allow dnf to upgrade to
the current kernel.


Thank you for this, and for earlier posts that I found elsewhere.  The 
system is now updated to f40 and seems to be running well.  I didn't 
have to use rpm installs from the cache in /var/lib/dnf/system-update.


I think the effective change was to add

"exclude kernel* linux-firmware* java*  libreoffice* "

to /etc/dnf/dnf.conf, before repeating everything from the preliminary

"sudo dnf upgrade--refresh" and applying "--allowerasing --skip-broken" 
in the download.


I suppose a "sudo dnf clean all" had helped too: 88 files removed. 
After the download KDiskFree reported 3.9 GB free in /, and dnf said 
that was the total package size.  "df / " said 4093160 blocks.  After 
the reboot I removed the excludes, ran dnf upgrade again, and installed 
locally built MythTV rpms.


That's an account of what I did.  I'm afraid it comes with no guarantees.

John P



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

Re: System upgrades. Where is the / filesystem?

[John Pilkington]

On 01/05/2024 00:54, Gordon Messmer wrote:

On 2024-04-30 10:58 AM, John Pilkington wrote:
(fedoraforum) has a suggestion of trimming the journalctl log, but 
neither that nor any other space-clearing actions that I have tried 
has made any difference.



Have you made snapshots of your system volume, or installed any 
applications that might create snapshots (something like timeshift or 
snapper)?


If your filesystem has snapshots, deleting files will not free up space 
until you also remove the snapshots that contain those files.


Thank you for this, and to Felix for his instructions too.

I'm not aware of any snapshots, and suspect that Felix has a quicker way 
of finding the relevant 'freespace' than waiting for dnf's version to 
appear.  Perhaps it's shown during the 'rpm --force' installs?  I have 
around 3400 packages.


I decided to try fixing the issues on the already upgraded f40 box first...

Thanks again,

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

System upgrades. Where is the / filesystem?

[John Pilkington]

Hi all:  I have two old systems (with old nVidia graphics), recently 
upgraded from f38 to f39 and both at present using nouveau.  One was 
OK-ish, the other had screen-recognition and HDMI-audio issues, and I 
thought it might be worth trying the more-mainstream f40.


Now the main problem is with the previously OK (single-boot) box, which 
reports after the download and dnf-testing that


"At least 446 MB more space (is) needed on the / filesystem".

Google (fedoraforum) has a suggestion of trimming the journalctl log, 
but neither that nor any other space-clearing actions that I have tried 
has made any difference.  KDiskFree shows multi-GB space on all except 
current /boot and a hopefully inactive remnant of another, much 
older/boot with a different mount point.  Both of those have sizes 
around 450 MB and free space around 150 MB.  TTBOMK only the current 
6.8.7 f39 kernel and its rescue version are installed.


Suggestions?  Thanks.

John P




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

Re: Unable to do F40 Live Workstation install on machine with very old graphics

[John Pilkington]

On 27/04/2024 04:28, Felix Miata wrote:

Andre Robatino composed on 2024-04-27 02:49 (UTC):


I have an old machine from 2008 with very old integrated graphics (GeForce 
6150SE nForce 430). Up to and including F39, I was able to do a Live 
Workstation install simply by using the nomodeset boot option. With F40 that no 
longer works - it fails to come up in graphical. I ended up doing a netinstall, 
but it came up in text mode instead of graphical, and suggested VNC, which I 
was able to use to do a graphical install (necessary since I wanted to preserve 
/home, requiring custom partitioning). After installation, it turns out that by 
replacing gdm with another display manager (I used lxdm), I could even use 
GNOME, though screen locking, which requires gdm, doesn't work - not a big deal.


# inxi -GSaz --zl --hostname
System:
   Host: mcp61 Kernel: 6.6.23-1-longterm arch: x86_64 bits: 64 compiler: gcc
 v: 13.2.1 clocksource: tsc avail: acpi_pm parameters: root=LABEL=
 ipv6.disable=1 net.ifnames=0 noresume consoleblank=0 preempt=full
 mitigations=off
   Desktop: KDE Plasma v: 5.27.10 tk: Qt v: 5.15.12 info: frameworks
 v: 5.115.0 wm: kwin_x11 dm: 1: KDM 2: XDM Distro: openSUSE Tumbleweed
 20240403
Graphics:
   Device-1: NVIDIA C61 [GeForce 6150SE nForce 430] vendor: Micro-Star MSI
 driver: nouveau v: kernel non-free: series: 304.xx
 status: legacy (EOL~2017-09-xx) last: release: 304.137 kernel: 4.13
 xorg: 1.19 arch: Curie process: 90-130nm built: 2003-2013 ports:
 active: VGA-1 empty: none bus-ID: 00:0d.0 chip-ID: 10de:03d0
 class-ID: 0300
   Display: x11 server: X.Org v: 21.1.11 with: Xwayland v: 23.2.4
 compositor: kwin_x11 driver: X: loaded: modesetting dri: nouveau
 gpu: nouveau display-ID: :0 screens: 1
   Screen-1: 0 s-res: 1680x1050 s-dpi: 108 s-size: 395x246mm (15.55x9.69")
 s-diag: 465mm (18.32")
   Monitor-1: VGA-1 model: Dell P2213 serial:  built: 2012
 res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2 size: 473x296mm (18.62x11.65")
 diag: 558mm (22") ratio: 16:10 modes: max: 1680x1050 min: 720x400
   API: EGL v: 1.5 hw: drv: nvidia nouveau platforms: device: 0 egl: 1.4
 drv: nouveau device: 1 drv: swrast gbm: egl: 1.4 drv: nouveau surfaceless:
 egl: 1.4 drv: nouveau x11: egl: 1.4 drv: nouveau inactive: wayland
   API: OpenGL v: 4.5 compat-v: 2.1 vendor: mesa v: 24.0.3 glx-v: 1.4
 direct-render: yes renderer: NV4C device-ID: 10de:03d0 memory: 115.2 MiB
 unified: no
#
I've never tried Fedora on my old beast. It's functional in Debian 12 as well as
openSUSE TW and Leap, but if you diligently search the web, you're likely to 
find
confirmation that the 6150SE was likely the most troublesome and/or lowest value
GeForce NVidia ever put to market. If you wish to keep that PC useful, I suggest
finding a better GPU to install, even if that means it must be PCI rather than
PCIe. I have a similar aged P4D with a passively cooled GeForce 8400 PCI that 
does
a respectable job for something so old and inexpensive, and better than my 
6150SE.


I would like to follow this up, but in relation to my two old boxes 
running F39 with the low-end nvidia GT710 cards.


The single-boot box is now running acceptably with the nouveau driver.

The dual-boot box doesn't boot straight into graphics mode, pausing 
while waiting to exit the plymouth screen and hanging after failing to 
start abrtd.service.


ctrl-alt-F2 allows login, and plasmastart-wayland gives a 800x600 
plasma screen and starts wifi.  I haven't yet found a bootline that does 
better than this.  Mostly the system just freezes.


I had installed the updated rpmfusion 340xx packages, without useful 
results, before trying the updated 470xx.  There are still references to 
a 340xx config in the Xorg log.


I hadn't used inxi before.  Maybe posting the results will reveal 
something...


{{{
2024041130 BST
Single-boot

#inxi -GSaz --zl --hostname

System:
  Host: HPFed Kernel: 6.8.7-200.fc39.x86_64 arch: x86_64 bits: 64
compiler: gcc v: 2.40-14.fc39 clocksource: hpet avail: acpi_pm
parameters: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-6.8.7-200.fc39.x86_64
root=/dev/mapper/fedora-root ro rd.driver.blacklist=nvidia
modprobe.blacklist=nvidia nouveau-drm.modeset=1 rd.lvm.lv=fedora/swap
rd.lvm.lv=fedora/root rhgb quiet
  Desktop: KDE Plasma v: 5.27.11 tk: Qt v: 5.15.12 info: frameworks
v: 5.115.0 wm: kwin_x11 vt: 2 dm: SDDM Distro: Fedora Linux 39 
(Thirty Nine)

Graphics:
  Device-1: NVIDIA GK208B [GeForce GT 710] vendor: Micro-Star MSI
driver: nouveau v: kernel non-free: series: 470.xx+
status: legacy-active (EOL~2024-09-xx) arch: Fermi 2 code: GF119/GK208
process: TSMC 28nm built: 2010-2016 pcie: gen: 1 speed: 2.5 GT/s 
lanes: 8

ports: active: HDMI-A-1,VGA-1 empty: DVI-D-1 bus-ID: 01:00.0
chip-ID: 10de:128b class-ID: 0300 temp: 45.0 C
  Device-2: Conexant Systems (Rockwell) Geniatech T230 DVB-T2 TV Stick
driver: dvb_usb_dvbsky type: USB rev: 2.0 speed: 

Re: crippling nvidia display issue.

[John Pilkington]

On 15/04/2024 20:02, home user wrote:

On 4/11/24 11:19 AM, home user wrote:

After a few days of being seriously side-tracked, I can try to get back 
to this.


Those who explained the kernel numbering: thank-you.

(f-38; stand-alone work station; nvidia graphics card; dual monitor; 
kmod 4xx driver)


I just finished doing a "dnf upgrade" as a prerequisite step to 
upgrading from f-38 to f-39.
There were no hints of any problems.  The kernel and the graphics 
driver were replaced during this "dnf upgrade".

The akmods did finish before I rebooted.
The shutdown took 5 minutes because it ran akmods (a second time?!).
During the boot-up, there was a message that it was failing back to 
nouveau.
The display is not working properly; only one monitor is being used 
and everything is oversized in the display.
I am not comfortable proceeding with the f-38 to f-39 upgrade with the 
work station in this condition.


Important: I have only one old kernel.  I have no rescue kernel.

How do I get this workstation working properly?


A. nvidia's proprietary drivers.

There's
1.
(Thomas)
I finally just nuked all the RPMFusion packages and downloaded the 
drivers directly from https://www.nvidia.com/download/index.aspx and 
ran the installer from there. It works fine again.


(Todd)

I can tell you that building the 2 or 3 nvidia 470xx packages
works well for the later 6.7 and current 6.8 kernels.


and there's
2.
(John)
AIUI we are moving from X11 graphics towards Wayland, which the nvidia 
driver will not support...


(Michael)
So, not sure if this is a kernel issue, or the driver issue, but seems 
neither rpmfusiong or nvidia's driver will work any longer?


These seem to me to be inconsistent with each other.  What am I missing?

B. nvidia and Fedora.

 From posts in this thread, I gather that
1. nvidia users can no longer use Fedora, and
2. Fedora users can no longer use nvidia.
Is this correct?



I don't think your summaries are correct.   But although technical fixes 
may exist for the immediate problems the situation at rpmfusion looks 
more difficult.  See this Bugzilla and in particular Comment 5.


https://bugzilla.rpmfusion.org/show_bug.cgi?id=6904

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

Re: crippling nvidia display issue.

[John Pilkington]

On 14/04/2024 16:22, Michael D. Setzer II via users wrote:

On 15 Apr 2024 at 0:29, Michael D. Setzer II via user wrote:




Just as an additional note. I have an older Acer notebook that has
an NVIDIA GT 650M that had been working fine with the
rpmfusion driver. Have BOINC using its GPU for a project.
After recent kernel upgrade, I noticed it was no longer working.
Tried reinstalling the rpm and it fails to build, so goes to fallback
of noveum? driver. Went to NVIDIA site, and downloaded what I
believe was the correct driver for the GT 650M, but it also fails to
build? Currently 17 timezones away from machine. In GMT -0700,
while machine is in GMT +1000, so accessing remotely via
TurboVNC. So, not sure if this is a kernel issue, or the driver issue,
but seems neither rpmfusiong or nvidia's driver will work any
longer? I've got other machines that have new nvidia cards, and
they are working with a different rpmfusing nvidia rpm.

Perhaps I'm missing something. Thanks. Otherwise machines fully
updated with no issues.




Was looking around, and found this info in
/var/cache/akmods/nvidia-470xx

Appears that it was working with 6.7.11 kernel but is now failing
with 6.8.x

26183873 Apr  2 12:52
kmod-nvidia-470xx-6.7.11-200.fc39.x86_64-470.223.02-2.fc39.x86_
64.rpm
14360178 Apr  2 12:52
470.223.02-2-for-6.7.11-200.fc39.x86_64.log
   614649 Apr 10 15:32
470.223.02-2-for-6.8.4-200.fc39.x86_64.failed.log
   616385 Apr 15 01:02
470.223.02-2-for-6.8.5-201.fc39.x86_64.failed.log

Thanks.


I've dropped the initial posts in this thread..  When I posted on the 
rpmfusion list, on 9 April, Sergio's response was:




a fix for nvidia 340x was posted today , 
for Fedora 40 we don't have these kmod nvidias because it fail to build

with gcc14 .

Please someone which have these graphics try fix it ASAP 

Thank you 


So one difficulty is probably a lack of rpmfusion devs with the affected 
hardware...


John P

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

Re: crippling nvidia display issue.

[John Pilkington]

On 12/04/2024 12:58, John Pilkington wrote:

On 12/04/2024 00:52, home user wrote:

On 4/11/24 5:39 PM, Samuel Sieb wrote:

On 4/11/24 16:36, home user wrote:

On 4/11/24 5:31 PM, Samuel Sieb wrote:

On 4/11/24 16:05, home user wrote:

/tmp/akmodsbuild.2VNb1GB1/BUILD/nvidia-470xx-kmod-470.223.02/_kmod_build_6.8.4-100.fc38.x86_64/nvidia-drm/nvidia-drm-drv.c:748:40:
 error: 'DRM_UNLOCKED' undeclared here (not in a function); did you mean 
'VM_LOCKED'?


There has been a kernel change of some sort.  The driver needs to 
be updated to match the kernel.


You will not get this driver to build on any newer kernels.
--


So realistically, my only practical choice is what Todd suggested, 
"to just switch to the stuff Nvidia provides directly"?


Unless there's a hope of the rpmfusion package getting updated, it 
looks like it.  I'm not really familiar with akmods, but maybe you 
could just update the source somehow.


I'm not a systems administrator.  I need someone to step me through 
the full switch in detail.

Reminders:
This is a dual boot (Fedora-38 and windows-7) stand-alone work 
station; it's 11 years old.

I have only one old kernel, and no rescue kernel.
The graphics card is an nvidia GeForce GTX 660.
(anything else?)


I have two systems affected by this, and have posted about it on the 
rpmfusion and fedora-kde lists.  I'm having trouble accessing the 
rpmfusion archive, so maybe a comment here is in order.


Both systems have GeForce GT 710 cards.  This is low-spec, not for 
gamers, and I've been using the rpmfusion 470xx drivers for years.  I 
upgraded from F38 to F39 around 2 weeks ago.


AIUI we are moving from X11 graphics towards Wayland, which the nvidia 
driver will not support; but nouveau might.  So I've been trying it.


On one box it's working acceptably, with VGA nad HDMI screens. 
Single-boot F39.


The other box is dual-boot with Windows 10.  I can boot into Fedora only 
with 'nomodeset', when I get a single screen HDMI 800x600 which seems 
fine but limited.  I can run MythTV frontend with --geometry 
720x504+40+20


The biggest worry is getting past a frozen boot, so I don't want to make 
any recommendations.  I have removed all the *nvidia* rpms except 
nvidia-gpu-firmware, and installed nouveau-firmware from the 
rpmfusion-nonfree-tainted repo.


Maybe the rpmfusion team will make the old system work soon, or maybe 
the even-older but just-updated 340xx driver would work.  I'll try 
living with what I have for now.


After kernel and firmware updates today the behaviour of both systems, 
using nouveau, seems essentially unchanged from the report above. 
kernel now is 6.8.5-201.fc39.x86-64


If the 'nomodeset' is edited out in grub, a reboot of the dual-boot box 
still hangs almost immediately.


I've removed the claim that mythleanfront works with mythbackend on the 
dual-boot box.  I think that was mistaken, and a local permissions issue.


HTH

John P




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

Re: crippling nvidia display issue.

[John Pilkington]

On 12/04/2024 00:52, home user wrote:

On 4/11/24 5:39 PM, Samuel Sieb wrote:

On 4/11/24 16:36, home user wrote:

On 4/11/24 5:31 PM, Samuel Sieb wrote:

On 4/11/24 16:05, home user wrote:

/tmp/akmodsbuild.2VNb1GB1/BUILD/nvidia-470xx-kmod-470.223.02/_kmod_build_6.8.4-100.fc38.x86_64/nvidia-drm/nvidia-drm-drv.c:748:40:
 error: 'DRM_UNLOCKED' undeclared here (not in a function); did you mean 
'VM_LOCKED'?


There has been a kernel change of some sort.  The driver needs to be 
updated to match the kernel.


You will not get this driver to build on any newer kernels.
--


So realistically, my only practical choice is what Todd suggested, 
"to just switch to the stuff Nvidia provides directly"?


Unless there's a hope of the rpmfusion package getting updated, it 
looks like it.  I'm not really familiar with akmods, but maybe you 
could just update the source somehow.


I'm not a systems administrator.  I need someone to step me through the 
full switch in detail.

Reminders:
This is a dual boot (Fedora-38 and windows-7) stand-alone work station; 
it's 11 years old.

I have only one old kernel, and no rescue kernel.
The graphics card is an nvidia GeForce GTX 660.
(anything else?)


I have two systems affected by this, and have posted about it on the 
rpmfusion and fedora-kde lists.  I'm having trouble accessing the 
rpmfusion archive, so maybe a comment here is in order.


Both systems have GeForce GT 710 cards.  This is low-spec, not for 
gamers, and I've been using the rpmfusion 470xx drivers for years.  I 
upgraded from F38 to F39 around 2 weeks ago.


AIUI we are moving from X11 graphics towards Wayland, which the nvidia 
driver will not support; but nouveau might.  So I've been trying it.


On one box it's working acceptably, with VGA nad HDMI screens. 
Single-boot F39.


The other box is dual-boot with Windows 10.  I can boot into Fedora only 
with 'nomodeset', when I get a single screen HDMI 800x600 which seems 
fine but limited.  I can run MythTV frontend with --geometry 
720x504+40+20, and mythleanfront on an Android tv.


The biggest worry is getting past a frozen boot, so I don't want to make 
any recommendations.  I have removed all the *nvidia* rpms except 
nvidia-gpu-firmware, and installed nouveau-firmware from the 
rpmfusion-nonfree-tainted repo.


Maybe the rpmfusion team will make the old system work soon, or maybe 
the even-older but just-updated 340xx driver would work.  I'll try 
living with what I have for now.


HTH

John P


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

Re: After having updated nvidia drivers, cannot start obs

[John Pilkington]

On 30/03/2024 16:55, Joe Zeff wrote:

On 03/30/2024 10:43 AM, francis.montag...@inria.fr wrote:

Have you wait for akmods to compile the nvidia kernel modules before
rebooting ?


Unless things have changed considerably since I used those drivers, the 
akmod module runs at boot, and checks to see if it needs to do anything. 
  If it does, it rebuilds the kmod; if not, it simply exits.  Running it 
after an update and before reboot is just making sure it gets done and 
can be skipped if you don't mind the extra few seconds during boot.  I 
never bothered and never had any problems letting them do their jobs as 
they were designed to do.


The rpmfusion nvidia howto says it may take 5 minutes to build.  That's 
a long time to wait with no obvious progress during a reboot.  It's much 
more comfortable to wait until the builds (maybe for several kernels) 
are complete before triggering the reboot. And ISTR that graphically 
selecting a restart early can give problems too.


systemctl show-jobs can show progress, and then systemctl reboot.

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

Re: NVIDIA RPM DNF Update Issue?

[John Pilkington]

On 03/12/2023 12:37, Michael D. Setzer II wrote:

On 3 Dec 2023 at 10:06, John Pilkington wrote:

Date sent:  Sun, 3 Dec 2023 10:06:32 +
Subject:Re: NVIDIA RPM DNF Update Issue?
From:   John Pilkington 
To: users@lists.fedoraproject.org
Send reply to:  Community support for Fedora users



On 03/12/2023 09:46, John Pilkington wrote:

On 02/12/2023 23:39, Michael D. Setzer II via users wrote:


Finally got it working, but tried lots of info from different pages,
and would get all kinds of different messages.
Cleared out everything, and tried things until this seems to have
run completely and is now showing the Nvidia GPU being used.



NVIDIA-Linux-x86_64-545.29.06.run

That script ran and had no issues, and BOINC is using it, and was
getting stat of 4,000 per day with 6 CPUs, but now with .9 CPU +
GPU is already up to 8,000 and only been about 1/2 day.




So, just a matter of finding right installation process.


So, where did you find it?


My guess is that it's from

https://boinc.berkeley.edu/wiki/Installing_BOINC_on_Fedora

which /does/ refer to Fedora 37...

Site I used??
https://www.nvidia.com/download/driverResults.aspx/216530/en-us/
Gave then

Linux x64 (AMD64/EM64T) Display Driver
  
Version: 	545.29.06

Release Date:   2023.11.22
Operating System:   Linux 64-bit
Language:   English (US)
File Size:  309.67 MB

Just did exact same thing, and gives different link??

Is where I got it after going thru an earlier nvidia page that had
one select OS and card info.

https://www.nvidia.com/Download/index.aspx?lang=en-us
GeForce
GeForce 10 series
GeForce GTX 1070
Linux 64-bit
Production Branch
English (US)


https://www.nvidia.com/Download/driverResults.aspx/213194/en-us

Linux x64 (AMD64/EM64T) Display Driver
  
Version: 	535.129.03

Release Date:   2023.10.31
Operating System:   Linux 64-bit
Language:   English (US)
File Size:  325.83 MB

So, not clear why it switched drivers??
Will stick with the newer one that I got earlier??
At moment the statistics was running at 4,000 before, and at
moment is showing current days status at 15,000 so far.
So major improvement in processing speed.



OK, thanks for that info, and I'm glad that SETI is back up to speed for 
you.


But it might be worth noting the contents of (again)

https://rpmfusion.org/Howto/NVIDIA

and specifically the section 'Recover from NVIDIA installer'

which warns that:

The NVIDIA binary driver installer overwrite(s) some configuration and 
libraries.


...which may still be true  :-)

Regards,

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: NVIDIA RPM DNF Update Issue?

[John Pilkington]

On 03/12/2023 09:46, John Pilkington wrote:

On 02/12/2023 23:39, Michael D. Setzer II via users wrote:


Finally got it working, but tried lots of info from different pages,
and would get all kinds of different messages.
Cleared out everything, and tried things until this seems to have
run completely and is now showing the Nvidia GPU being used.



NVIDIA-Linux-x86_64-545.29.06.run

That script ran and had no issues, and BOINC is using it, and was
getting stat of 4,000 per day with 6 CPUs, but now with .9 CPU +
GPU is already up to 8,000 and only been about 1/2 day.




So, just a matter of finding right installation process.


So, where did you find it?


My guess is that it's from

https://boinc.berkeley.edu/wiki/Installing_BOINC_on_Fedora

which /does/ refer to Fedora 37...





Thanks to all that replied.

--
___
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: NVIDIA RPM DNF Update Issue?

[John Pilkington]

On 02/12/2023 23:39, Michael D. Setzer II via users wrote:


Finally got it working, but tried lots of info from different pages,
and would get all kinds of different messages.
Cleared out everything, and tried things until this seems to have
run completely and is now showing the Nvidia GPU being used.



NVIDIA-Linux-x86_64-545.29.06.run

That script ran and had no issues, and BOINC is using it, and was
getting stat of 4,000 per day with 6 CPUs, but now with .9 CPU +
GPU is already up to 8,000 and only been about 1/2 day.




So, just a matter of finding right installation process.


So, wwhere did you find it?


Thanks to all that replied.

--
___
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: NVIDIA RPM DNF Update Issue?

[John Pilkington]

On 01/12/2023 05:57, Michael D. Setzer II via users wrote:



Forgot to add info. In working to get it originally working, had
following instruction from only page that actually worked and
ended up with these packages being installed.

rpm -qa | grep -i nvidia
xorg-x11-drv-nvidia-kmodsrc-535.129.03-2.fc38.x86_64
akmod-nvidia-535.129.03-1.fc38.x86_64
nvidia-driver-cuda-libs-545.23.08-1.fc37.x86_64
nvidia-driver-libs-545.23.08-1.fc37.x86_64
nvidia-driver-545.23.08-1.fc37.x86_64
nvidia-kmod-common-545.23.08-1.fc37.noarch
kmod-nvidia-latest-dkms-545.23.08-1.fc37.x86_64



This is a strange mix of updated fc37 and older fc38 packages.  Do you 
have the fc37 repo enabled?


https://rpmfusion.org/Howto/NVIDIA

sudo dnf install akmod-nvidia  xorg-x11-drv-nvidia-cuda

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


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

Re: weekly patches crippled my display.

[John Pilkington]

On 23/11/2023 22:25, Samuel Sieb wrote:

On 11/23/23 12:52, home user wrote:

On 11/23/23 1:43 PM, Samuel Sieb wrote:

On 11/23/23 12:02, home user wrote:

(f38; home workstation; dual monitor;
using nvidia 4xx kmod and akmod from rpmfusion)

A short while ago, I did my weekly patches.  After rebooting, only 
one monitor is displaying anything, and then with a large, wide 
font.  I saw no indication of trouble during the "dnf upgrade". The 
boot messages go by fast, but I think I saw something about a 
missing module, and nouveau being used.


I'm not a sys.admin., and the display is very limited.  What's the 
cause of these problems, and how do I fix things?


Try running "sudo akmods" and see if there are any errors.
--
I've rebooted to the previous kernel.  Does that matter?  Running 
under that older kernel, I get this:

-
-bash.1[~]: akmods
Checking kmods exist for 6.5.10-200.fc38.x86_64    [  OK  ]
Building and installing nvidia-470xx-kmod  [FAILED]
Building rpms failed; see 
/var/cache/akmods/nvidia-470xx/470.223.02-1-for-6.5.10-200.fc38.x86_64.failed.log for details


Hint: Some kmods were ignored or failed to build or install.
You can try to rebuild and install them by by calling
'/usr/sbin/akmods --force' as root.

Checking kmods exist for 6.5.12-200.fc38.x86_64    [  OK  ]
Building and installing nvidia-470xx-kmod  [FAILED]
Building rpms failed; see 
/var/cache/akmods/nvidia-470xx/470.223.02-1-for-6.5.12-200.fc38.x86_64.failed.log for details


Hint: Some kmods were ignored or failed to build or install.
You can try to rebuild and install them by by calling
'/usr/sbin/akmods --force' as root.

-bash.2[~]:
-
1. Do I need to re-do this under the new kernel?


I think it will compile against any kernels that need it.  Which kernel 
are you running and which one do you need?



2. Should I do what the output above says?


Check the log to see why it's failing.  It might be a kernel change that 
breaks the module.  You could try forcing it and see what happens.


I have just done the same kernel update with the same nvidia driver, and 
had no problem.  Building the driver modules will go on long after dnf 
quits, if you don't try to boot immediately, and that seems to me to be 
a safer option than hoping it will complete during the reboot.  But of 
course the log might reveal *why* your build failed...

--

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

Re: DNF Upgrade from F38 to F39 Issues

[John Pilkington]

On 19/11/2023 07:29, Tim via users wrote:

Jeffrey Walton wrote:

* SecureBoot should be turned off if using tainted kernel drivers. Or,
you can cutover to driver signing. I usually turn off SecureBoot
because I don't like messing around with driver signing. In my case,
it usually is due to VirtualBox, not NVIDIA.


Stephen Morris:

As my system is a tri-boot between Windows 11, Fedora 39 and Ubuntu
22.04, and Windows doesn't seem to work properly with UEFI disabled,
I've gone down the path of signing the nvidia drivers under Fedora and
Ubuntu, using separate passwords as I found using the same password
causes thing to not work properly.



UEFI is a hardware interface (simplifying that description quite a lot)
between the PC's hardware, firmware, and the OS before it boots, and
the control screens it gives you for you to configure things.  It's an
update on the similiar, but more primitive, thing done with the old
BIOS.

Secure boot is a *separate* thing (though probably only exists on
systems with UEFI).  It's to do with only booting up from signed
binaries (to verify that only authentic things can run, blocking any
fake things that have snuck in).

A problem with Secure Boot is that there are real and genuine things
you may want to use that are not signed (such as some graphics card
drivers).  One solution to that is to sign them yourself, with a
signature that you let things know that *you* trust.

("Signed" in these contexts is to do with cryptographic keys.)

Though again, it could be that Windows won't boot without secure boot
options set, not UEFI being disabled (not that I've seen a motherboard
where you could disable UEFI and go back to BIOS).  That and the TPM
hardware that's touted as being more fantastic than it really is.

As a home user you may feel that this security is kinda pointless, as
no-one else is going to touch your PC and sneak things in.  And
anything nasty that does get in is going to get in by your own
behaviour doing unwise things, for which you're going to ignore and
disable any warnings not to do it.  To that degree, that's true.  And
the same can be said about AntiVirus, SELinux, file permissions and
ownership.  But where such security features can help, is when you
start to do something unwise without realising it, it blocks you, and
you properly investigate the reasons.


In https://bugzilla.redhat.com/show_bug.cgi?id=2011120 I reported seeing 
this problem on one system, but not on another.  The one with the 
problem, solved by reinstalling the rpmfusion 470xx packages. has dual 
boot with Windows 10 - but the selection is made via the HP BIOS 
immediately after power-up;  the default is Windows, but if 'escaped' in 
the first few seconds it offers other options, including UEFI boots of 
Windows and Fedora.  Choosing Fedora gives the normal grub screen.


It's inconvenient but it works and I haven't tried changing it 'for fear 
of finding something worse'.  Maybe I should add this info to the BZ. 
Might it explain the different behaviour on Fedora version upgrade?


John P



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

Re: DNF Upgrade from F38 to F39 Issues

[John Pilkington]

On 18/11/2023 05:11, Samuel Sieb wrote:

On 11/17/23 19:08, Stephen Morris wrote:
 I reinstalled the nvidia drivers and a subsequent reboot then 
booted into KDE with any issues (which is where I'm sending this email 
from). Why did this freezing of the nvidia drivers happen, is it 
because the F39 nvidia drivers don't work properly with an update and 
have to be installed from scratch to work properly?


I think there was another thread about this.  The akmods didn't run 
properly during the update process.



https://bugzilla.redhat.com/show_bug.cgi?id=2011120
--
___
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: Upgrading to Fedora 38: more comments

[John Pilkington]

On 15/10/2023 15:27, John Pilkington wrote:
My recent posts were about 'just in case' precautions before a system 
upgrade.  I now appear to have a working upgraded system.  It wasn't 
trouble-free and I didn't use the live workstation download.


The system uses the rpmfusion nvidia 470xx video drivers, which build 
modules locally via akmods.  Booting the F38 system with the 
kernel-6.5.6-200.fc38 did not complete, but kernel-6.5.6-100.fc37 seemed 
fine.


Eventually, running the F37 kernel, I "sudo dnf reinstall"ed all the 
rpmfusion 470xx packages *and* the kernel*6.5.6-200.fc38 packages and 
waited for the jobs to complete.  Booting to F38 seems ok now.  The 
problems were similar to, but worse than, those seen in earlier 
upgrades.  There's a related bugzilla.


https://bugzilla.redhat.com/show_bug.cgi?id=2011120


I just upgraded another similar system, F37 to F38, both KDE/X11.  No 
problems seen, so no need for package reinstalls.  :-)


John P


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

Upgrading to Fedora 38: more comments

[John Pilkington]

My recent posts were about 'just in case' precautions before a system 
upgrade.  I now appear to have a working upgraded system.  It wasn't 
trouble-free and I didn't use the live workstation download.


The system uses the rpmfusion nvidia 470xx video drivers, which build 
modules locally via akmods.  Booting the F38 system with the 
kernel-6.5.6-200.fc38 did not complete, but kernel-6.5.6-100.fc37 seemed 
fine.


Eventually, running the F37 kernel, I "sudo dnf reinstall"ed all the 
rpmfusion 470xx packages *and* the kernel*6.5.6-200.fc38 packages and 
waited for the jobs to complete.  Booting to F38 seems ok now.  The 
problems were similar to, but worse than, those seen in earlier 
upgrades.  There's a related bugzilla.


https://bugzilla.redhat.com/show_bug.cgi?id=2011120

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

Re: Upgrading to Fedora 38: Misleading 'verify' instructions

[John Pilkington]

On 15/10/2023 01:23, Jonathan Billings wrote:

On Oct 14, 2023, at 14:06, John Pilkington  wrote:


I have done several system upgrades in the past.  This time I thought 
I would take the suggested precautions and download the workstation .iso


On trying to verify the download, using

https://fedoraproject.org/en/workstation/download/

I got a report that "17 lines are improperly formatted".  So I worried 
and did it again.  Same result.


This is BZ 733561, opened in 2011 and NOTABUG.  Isn't it time that 
this was mentioned in the 'helpful' warning suggestion?


I agree that the wording in the instructions could be better.

The CHECKSUM file has a GPG signature and the sha256sum of ISO, so the 
sha256sum command will give a warning that there are improperly 
formatted lines (the GPG signature). But, as the instructions say: “If 
the output states that the file is valid, then it's ready to use!”


That's fine.  But the response doesn't say that the file is valid, only 
that there is a formatting problem.  The documentation is misleading, 
and has been for years.


It would be nice if there was a way to make sha256sum ignore the GPG 
key, but you should:


1.) make sure the GPG signature is valid.
2.) look to see if it says the file you downloaded is OK and ignore the 
warning about improperly formatted lines, since you know from the 
previous step that those lines are ok.


--
Jonathan Billings


___
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: Upgrading to Fedora 38: Misleading 'verify' instructions

[John Pilkington]

Resending to list:

On 14/10/2023 21:28, Barry Scott wrote:




On 14 Oct 2023, at 19:06, John Pilkington  wrote:

I have done several system upgrades in the past.  This time I thought I would 
take the suggested precautions and download the workstation .iso

On trying to verify the download, using

https://fedoraproject.org/en/workstation/download/

I got a report that "17 lines are improperly formatted".  So I worried and did 
it again.  Same result.


What exactly did you do that got this error message?
How can I reproduce this?

Barry



This is BZ 733561, opened in 2011 and NOTABUG.  Isn't it time that this was 
mentioned in the 'helpful' warning suggestion?



The page quoted above is reached from the 'Warning' box in

https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline/

Click the download ikon for the AMD/x86_64 .iso and wait for it to 
finish.  Then click the adjacent 'Verify' button and execute the 
commands given, from the Downloads folder.




John P

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

Upgrading to Fedora 38: Misleading 'verify' instructions

[John Pilkington]

I have done several system upgrades in the past.  This time I thought I 
would take the suggested precautions and download the workstation .iso


On trying to verify the download, using

https://fedoraproject.org/en/workstation/download/

I got a report that "17 lines are improperly formatted".  So I worried 
and did it again.  Same result.


This is BZ 733561, opened in 2011 and NOTABUG.  Isn't it time that this 
was mentioned in the 'helpful' warning suggestion?


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

Re: Boot failure with 6.3.4-101.fc37

[John Pilkington]

On 06/06/2023 19:03, John Pilkington wrote:

On 06/06/2023 18:46, Steve Underwood wrote:

On 02/06/2023 23:54, John Pilkington wrote:

On 02/06/2023 21:49, Robert McBroom via users wrote:

On 5/31/23 15:47, John Pilkington wrote:

On 31/05/2023 20:21, John Pilkington wrote:

On 31/05/2023 18:39, home user wrote:

On 5/31/23 10:20 AM, Barry Scott wrote:






When there's a new kernel I usually let the akmods build finish 
before 'systemctl reboot'.  Usually the shutdown.service doesn't 
then delay the shutdown.


Today I didn't see the akmods build after installation.  On 
'systemctl reboot' the shutdown.service ran for 5 minutes before 
getting to the (blue HP) bootscreen and eventually hanging.


Simple answer:  it has been ok but now seems unpredictable.

The system has been through many version upgrades.  nvidia 470xx.


I just tried 'sudo akmods --force' and it failed.  An updated package

nvidia-470xx-kmod-470.182.03-2.fc37

was placed in testing on 27 May.  I haven't tried it yet. 


fails to compile on f38 kernel 6.3.4


No problem now for me in f37 with that kmod package and 6.3.4-101


Is anyone else using nVidia's CUDA repo with Fedora 37? They are still 
on driver 530.30.02, which doesn't seem to work with the 6.3 kernels. 
RPMfusion is on 540.41.03, and I assume their RPMs have been tested to 
work with Linux 6.3.x. However, I've had problems mixing RPMfusion and 
nVidia's CUDA RPMs, so I'd rather not be pushed to use the RPMfusion 
ones.


Regards,

Steve


I don't see a need to mix repos.  My 470xx packages, including cuda, 
come from epmfusion.  But I don't knowingly use cuda.


Sorry, there's a typo:  rpmfusion


___
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: Boot failure with 6.3.4-101.fc37

[John Pilkington]

On 06/06/2023 18:46, Steve Underwood wrote:

On 02/06/2023 23:54, John Pilkington wrote:

On 02/06/2023 21:49, Robert McBroom via users wrote:

On 5/31/23 15:47, John Pilkington wrote:

On 31/05/2023 20:21, John Pilkington wrote:

On 31/05/2023 18:39, home user wrote:

On 5/31/23 10:20 AM, Barry Scott wrote:






When there's a new kernel I usually let the akmods build finish 
before 'systemctl reboot'.  Usually the shutdown.service doesn't 
then delay the shutdown.


Today I didn't see the akmods build after installation.  On 
'systemctl reboot' the shutdown.service ran for 5 minutes before 
getting to the (blue HP) bootscreen and eventually hanging.


Simple answer:  it has been ok but now seems unpredictable.

The system has been through many version upgrades.  nvidia 470xx.


I just tried 'sudo akmods --force' and it failed.  An updated package

nvidia-470xx-kmod-470.182.03-2.fc37

was placed in testing on 27 May.  I haven't tried it yet. 


fails to compile on f38 kernel 6.3.4


No problem now for me in f37 with that kmod package and 6.3.4-101


Is anyone else using nVidia's CUDA repo with Fedora 37? They are still 
on driver 530.30.02, which doesn't seem to work with the 6.3 kernels. 
RPMfusion is on 540.41.03, and I assume their RPMs have been tested to 
work with Linux 6.3.x. However, I've had problems mixing RPMfusion and 
nVidia's CUDA RPMs, so I'd rather not be pushed to use the RPMfusion ones.


Regards,

Steve


I don't see a need to mix repos.  My 470xx packages, including cuda, 
come from epmfusion.  But I don't knowingly use cuda.



___
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: Boot failure with 6.3.4-101.fc37

[John Pilkington]

On 02/06/2023 21:49, Robert McBroom via users wrote:

On 5/31/23 15:47, John Pilkington wrote:

On 31/05/2023 20:21, John Pilkington wrote:

On 31/05/2023 18:39, home user wrote:

On 5/31/23 10:20 AM, Barry Scott wrote:






When there's a new kernel I usually let the akmods build finish 
before 'systemctl reboot'.  Usually the shutdown.service doesn't then 
delay the shutdown.


Today I didn't see the akmods build after installation.  On 
'systemctl reboot' the shutdown.service ran for 5 minutes before 
getting to the (blue HP) bootscreen and eventually hanging.


Simple answer:  it has been ok but now seems unpredictable.

The system has been through many version upgrades.  nvidia 470xx.


I just tried 'sudo akmods --force' and it failed.  An updated package

nvidia-470xx-kmod-470.182.03-2.fc37

was placed in testing on 27 May.  I haven't tried it yet. 


fails to compile on f38 kernel 6.3.4


No problem now for me in f37 with that kmod package and 6.3.4-101
___
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: Boot failure with 6.3.4-101.fc37

[John Pilkington]

On 31/05/2023 20:21, John Pilkington wrote:

On 31/05/2023 18:39, home user wrote:

On 5/31/23 10:20 AM, Barry Scott wrote:




On 31 May 2023, at 16:02, home user  wrote:

"Job akmods-shutdown.service/stop running".


That is likely to be because it is compiling the new nvidia drivers.

I use a script to do my updates that waits for all systemd jobs to 
stop before rebooting.


You can see the jobs with:

$ systemctl list-jobs

After installing new nvidia RPMs from rpmfusion there is always a job 
running for a

while.

Once that any jobs complete the reboot is fast to shutdown and fast 
to startup

(as the nvidia drivers are all built and ready to install).


That only explains the long shutdown for the first shutdown after 
doing an upgrade.  Surely, the nvidia drivers don't need to be 
compiled during every shutdown!  I upgrade once per week.  I shutdown 
every day, sometimes more than once a day.  The long 
akmods-shutdown.service happens with every shutdown.


John: Is your long shutdown happening with every shutdown, or only the 
first after an upgrade?


When there's a new kernel I usually let the akmods build finish before 
'systemctl reboot'.  Usually the shutdown.service doesn't then delay the 
shutdown.


Today I didn't see the akmods build after installation.  On 'systemctl 
reboot' the shutdown.service ran for 5 minutes before getting to the 
(blue HP) bootscreen and eventually hanging.


Simple answer:  it has been ok but now seems unpredictable.

The system has been through many version upgrades.  nvidia 470xx.


I just tried 'sudo akmods --force' and it failed.  An updated  package

nvidia-470xx-kmod-470.182.03-2.fc37

was placed in testing on 27 May.  I haven't tried it yet.
___
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: Boot failure with 6.3.4-101.fc37

[John Pilkington]

On 31/05/2023 18:39, home user wrote:

On 5/31/23 10:20 AM, Barry Scott wrote:




On 31 May 2023, at 16:02, home user  wrote:

"Job akmods-shutdown.service/stop running".


That is likely to be because it is compiling the new nvidia drivers.

I use a script to do my updates that waits for all systemd jobs to 
stop before rebooting.


You can see the jobs with:

$ systemctl list-jobs

After installing new nvidia RPMs from rpmfusion there is always a job 
running for a

while.

Once that any jobs complete the reboot is fast to shutdown and fast to 
startup

(as the nvidia drivers are all built and ready to install).


That only explains the long shutdown for the first shutdown after doing 
an upgrade.  Surely, the nvidia drivers don't need to be compiled during 
every shutdown!  I upgrade once per week.  I shutdown every day, 
sometimes more than once a day.  The long akmods-shutdown.service 
happens with every shutdown.


John: Is your long shutdown happening with every shutdown, or only the 
first after an upgrade?


When there's a new kernel I usually let the akmods build finish before 
'systemctl reboot'.  Usually the shutdown.service doesn't then delay the 
shutdown.


Today I didn't see the akmods build after installation.  On 'systemctl 
reboot' the shutdown.service ran for 5 minutes before getting to the 
(blue HP) bootscreen and eventually hanging.


Simple answer:  it has been ok but now seems unpredictable.

The system has been through many version upgrades.  nvidia 470xx.
___
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

Boot failure with 6.3.4-101.fc37

[John Pilkington]

After dnf upgrade today, abrtd.service failed to start, with dependency 
failures for abrt:  ccoredumpctl, kernelpanic detection and kernel log 
watcher.


Booting the previous kernel also hung for 10s of seconds but seems ok. 
6.2.15-200.fc37


systemctl reboot hangs for 5 minutes with akmods, presumably from 
rpmfusion for nvidia, before entering the reboot.

___
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: blkid fully broken too chroot has losen sense in addition fstab has received an update not smart and luckily locate works with type the button star

[John Pilkington]

On 18/05/2023 20:49, Mike Wright wrote:

On 5/18/23 05:21, Dorian ROSSE wrote:

Hello everybody and the team fedora,


blkid fully broken too chroot has losen sense in addition fstab has 
received an update not smart so it has losen a lot of part and luckily 
locate works without type the button star finally thanks you in 
advance to repair whole,


Have a nice week,

Regards.


Portez ce vieux whisky au juge blond qui fume sur son île intérieure, à 
côté de l'alcôve ovoïde, où les bûches se consument dans l'âtre, ce qui 
lui permet de penser à la cænogenèse de l'être dont il est question dans 
la cause ambiguë entendue à Moÿ, dans un capharnaüm qui, pense-t-il, 
diminue çà et là la qualité de son œuvre.


Merci



Thanks, wikipedia:

https://fr.wikipedia.org/wiki/Portez_ce_vieux_whisky_au_juge_blond_qui_fume


___
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: Switching nvidia GPU cards - can multiple driver versions co-exist?

[John Pilkington]

On 13/02/2023 15:27, Roger Heflin wrote:

If the new card is supported with the 470 driver then I would replace
the card while the 470 driver is running.

Then do the upgrade.

Both drivers have the same name so you will not be able to have both
installed and built in /lib/modules at the same time.


My /lib/modules/ has nvidia modules identified by

extra/nvidia-470xx/ .XXX.ko.xz

so it should be able to make the distinction.


On Mon, Feb 13, 2023 at 8:05 AM Jon LaBadie  wrote:


After about 12 years of service my GPU card is starting
to act up.  It seems to shut down so no video on my
monitor, even the virtual consoles.  System is up and
functioning as I can access it via ssh.  Sometimes this
state is accompanied by the fan running at high speed
though the card is not overheating.

The old card uses nvidia's 470 series of drivers while
its replacement will use the 525 series.

Can I pre-install the 525 packages so they are present
when I reboot after I install the new hardware?  I.e.
can both series be installed without consequence?

Thanks,
jon

--
Jon H. LaBadie  jo...@jgcomp.com
___
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

___
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: Nvidia in F37

[John Pilkington]

On 25/01/2023 18:05, GianPiero Puccioni wrote:



I'll instal kmod-nvidia and probably it will fix the problem; maybe when 
I am up to speed with a kernel with headers I'll  decide if I want it or 
not...


Thanks for the help.

G


The rpmfusion users list had this two days ago:

Fedora 37
-
Pushed to testing:
nvidia-kmod-525.85.05-1.fc37
nvidia-modprobe-525.85.05-1.fc37
nvidia-open-kmod-525.85.05-1.fc37
nvidia-persistenced-525.85.05-1.fc37
nvidia-settings-525.85.05-1.fc37
nvidia-xconfig-525.85.05-1.fc37
xorg-x11-drv-nvidia-525.85.05-1.fc37

Usually they would be pushed to stable after a few days.

John P


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

Re: Nvidia in F37

[John Pilkington]

On 25/01/2023 15:44, stan via users wrote:

On Wed, 25 Jan 2023 10:59:10 +0100
GianPiero Puccioni  wrote:


Hi,

I just update from F35 to F37 and everything is fine except I noticed
that instead of the Nvidia from RPMFusion it is using nouveau.
In fact the nvidia module is missing and wasn't built by akmod.

I think the problem is that it started with kernel 6.1.7 which is
very recent but it seems it's missing the kernel-headers -the most
recent in the repositories is 6.1.5- and akmod needs that.

There is something strange going on or I just should wait for the
headers to appear? Or maybe install 6.1.5 and use that?


The headers are only updated when the kernel interface changes now.
This has been the case for many releases of fedora.  What I am saying
is that the problem is not the headers, so you can eliminate it from
your list of possibilities.


man akmods  ?


___
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: cifs problem? was Re: Black screens with rpmfusion nvidia 470xx and 6.0.16.fc36

[John Pilkington]

kernel-6.0.18-200.fc36 and kernel-6.0.18-399.fc37 were pushed to stable 
6 hours ago.  I installed for fc36 last night from the updates page.  No 
problem in booting and none have been seen overnight.


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

Re: cifs problem? was Re: Black screens with rpmfusion nvidia 470xx and 6.0.16.fc36

[John Pilkington]

Maybe this is https://bugzilla.kernel.org/show_bug.cgi?id=216895, 
referred to in this current thread:


Re: Fedora 37 hangs after graphical login

I have two cifs mounting lines in /etc/fstab; only one has the 
hardware connected.




I have cifs... vers=3.0,

//192.168.1.XX/Public /mnt/nas1a cifs 
credentials=,iocharset=utf8,gid=1000,uid=1000,vers=3.0,file_mode=0777,dir_mode=0777 0 0


Here is a 'journalctl' output from, first, 6.0.16 (which hung) and then 
6.0.15, which completed.  Maybe it will help.  Or perhaps just wait for 
6.0.18...



nas1a is on the network, nas2a is not.  The main difference here appears 
to be that with 6.0.16 sddm is not being called.


{{{


[john@HPFed ~]$ sudo journalctl --since 2023-01-07 | grep  -A 20 nas2a
Jan 07 10:04:44 HPFed systemd[1]: Mounting mnt-nas2a.mount - /mnt/nas2a...
Jan 07 10:04:44 HPFed systemd[1]: Starting rpc-statd-notify.service - 
Notify NFS peers of a restart...
Jan 07 10:04:44 HPFed systemd[1]: iscsi.service: Unit cannot be reloaded 
because it is inactive.

Jan 07 10:04:45 HPFed sm-notify[1304]: Version 2.6.2 starting
Jan 07 10:04:45 HPFed systemd[1]: Started rpc-statd-notify.service - 
Notify NFS peers of a restart.
Jan 07 10:04:45 HPFed audit[1]: SERVICE_START pid=1 uid=0 
auid=4294967295 ses=4294967295 subj=kernel msg='unit=rpc-statd-notify 
comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? 
terminal=? res=success'

Jan 07 10:04:45 HPFed kernel: FS-Cache: Loaded
Jan 07 10:04:45 HPFed kernel: Key type dns_resolver registered
Jan 07 10:04:46 HPFed kernel: Key type cifs.spnego registered
Jan 07 10:04:46 HPFed kernel: Key type cifs.idmap registered
Jan 07 10:04:46 HPFed kernel: CIFS: Attempting to mount 
\\192.168.1.209\Public
Jan 07 10:04:51 HPFed chronyd[1041]: Selected source 83.151.207.133 
(2.fedora.pool.ntp.org)
Jan 07 10:04:51 HPFed chronyd[1041]: System clock TAI offset set to 37 
seconds
Jan 07 10:04:52 HPFed mount[1305]: mount error(113): could not connect 
to 192.168.1.209Unable to find suitable address.
Jan 07 10:04:52 HPFed kernel: CIFS: VFS: Error connecting to socket. 
Aborting operation.
Jan 07 10:04:52 HPFed kernel: CIFS: VFS: cifs_mount failed w/return code 
= -113
Jan 07 10:04:52 HPFed kernel: CIFS: Attempting to mount 
\\192.168.1.67\Public
Jan 07 10:04:52 HPFed systemd[1]: mnt-nas2a.mount: Mount process exited, 
code=exited, status=32/n/a
Jan 07 10:04:52 HPFed systemd[1]: mnt-nas2a.mount: Failed with result 
'exit-code'.
Jan 07 10:04:52 HPFed systemd[1]: Failed to mount mnt-nas2a.mount - 
/mnt/nas2a.
Jan 07 10:04:52 HPFed systemd[1]: Dependency failed for remote-fs.target 
- Remote File Systems.
Jan 07 10:04:52 HPFed systemd[1]: remote-fs.target: Job 
remote-fs.target/start failed with result 'dependency'.
Jan 07 10:04:52 HPFed systemd[1]: Starting systemd-user-sessions.service 
- Permit User Sessions...
Jan 07 10:04:52 HPFed systemd[1]: Finished systemd-user-sessions.service 
- Permit User Sessions.
Jan 07 10:04:52 HPFed audit[1]: SERVICE_START pid=1 uid=0 
auid=4294967295 ses=4294967295 subj=kernel 
msg='unit=systemd-user-sessions comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jan 07 10:04:52 HPFed audit[1]: SERVICE_START pid=1 uid=0 
auid=4294967295 ses=4294967295 subj=kernel msg='unit=atd comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jan 07 10:04:52 HPFed systemd[1]: Started atd.service - Deferred 
execution scheduler.

Jan 07 10:04:52 HPFed systemd[1]: Started crond.service - Command Scheduler.
Jan 07 10:04:52 HPFed audit[1]: SERVICE_START pid=1 uid=0 
auid=4294967295 ses=4294967295 subj=kernel msg='unit=crond 
comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? 
terminal=? res=success'
Jan 07 10:04:52 HPFed systemd[1]: Starting plymouth-quit-wait.service - 
Hold until boot process finishes up...
Jan 07 10:04:52 HPFed systemd[1]: Starting plymouth-quit.service - 
Terminate Plymouth Boot Screen...

Jan 07 10:04:52 HPFed systemd[1]: Mounted mnt-nas1a.mount - /mnt/nas1a.
Jan 07 10:04:52 HPFed systemd[1]: Received SIGRTMIN+21 from PID 346 
(plymouthd).
Jan 07 10:04:52 HPFed systemd[1]: Received SIGRTMIN+21 from PID 346 
(plymouthd).
Jan 07 10:04:52 HPFed systemd[1]: Finished plymouth-quit-wait.service - 
Hold until boot process finishes up.
Jan 07 10:04:52 HPFed audit[1]: SERVICE_START pid=1 uid=0 
auid=4294967295 ses=4294967295 subj=kernel msg='unit=plymouth-quit-wait 
comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? 
terminal=? res=success'
Jan 07 10:04:52 HPFed systemd[1]: Finished plymouth-quit.service - 
Terminate Plymouth Boot Screen.
Jan 07 10:04:52 HPFed audit[1]: SERVICE_START pid=1 uid=0 
auid=4294967295 ses=4294967295 subj=kernel msg='unit=plymouth-quit 
comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? 
terminal=? res=success'

Jan 07 10:04:52 HPFed crond[1357]: (CRON) STARTUP (1.5.7)
Jan 07 10:04:52 HPFed crond[1357]: (CRON) INFO (RANDOM_DELAY will be 
scaled with factor 

cifs problem? was Re: Black screens with rpmfusion nvidia 470xx and 6.0.16.fc36

[John Pilkington]

On 08/01/2023 13:58, Stephen Morris wrote:

On 8/1/23 21:26, John Pilkington wrote:

On 08/01/2023 02:10, Stephen Morris wrote:

On 8/1/23 12:59, Samuel Sieb wrote:

On 1/7/23 17:24, Stephen Morris wrote:
I've attached ~/.local/share/xorg/Xorg.0.log (my Xorg doesn't write 
its log to /var/log) as the end of my log file is completely 
different to what you are showing. I also don't have an xorg.conf 
file as I can get the 4K resolution I run with without the need for 
any specific specifications. The only configuration file in 
xorg.conf.d is the one for the keyboard.


By default, Xorg doesn't run as root any more, so it can only write 
logs to the user directory.
I only included that specification for where my Xorg.0.log file is 
located because John was indicating that his Xorg.0.log is being 
written to /var/log.


regards,
Steve



Maybe this is https://bugzilla.kernel.org/show_bug.cgi?id=216895, 
referred to in this current thread:


Re: Fedora 37 hangs after graphical login

I have two cifs mounting lines in /etc/fstab; only one has the 
hardware connected.
I have a cifs mount and nfs mount in my /etc/fstab to the same network 
device that is not always accessible because of the power saving 
function in the device. In earlier versions of Fedora if the device was 
not accessible the boot process used to hang and I would have to boot 
into Windows (where I also had it mounted on a drive mapping) to get 
explorer to activate the device and then boot into Fedora to get a 
successful boot. So far I haven't had this issue occur, but this may be 
because I mount the nfs interface first, or because in the cifs 
definition I use the _netdev parameter which as I understand it is 
supposed to ignore the mount if the network device is unavailable. What 
I also haven't done yet is isolate the invalid parameter when I change 
the definition to use smb3 instead of cifs (smb3 supercedes cifs).


regards,
Steve



I have cifs... vers=3.0,

//192.168.1.XX/Public /mnt/nas1a cifs 
credentials=,iocharset=utf8,gid=1000,uid=1000,vers=3.0,file_mode=0777,dir_mode=0777 
0 0




Thanks,

John P

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

___
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: Black screens with rpmfusion nvidia 470xx and 6.0.16.fc36

[John Pilkington]

On 08/01/2023 02:10, Stephen Morris wrote:

On 8/1/23 12:59, Samuel Sieb wrote:

On 1/7/23 17:24, Stephen Morris wrote:
I've attached ~/.local/share/xorg/Xorg.0.log (my Xorg doesn't write 
its log to /var/log) as the end of my log file is completely 
different to what you are showing. I also don't have an xorg.conf 
file as I can get the 4K resolution I run with without the need for 
any specific specifications. The only configuration file in 
xorg.conf.d is the one for the keyboard.


By default, Xorg doesn't run as root any more, so it can only write 
logs to the user directory.
I only included that specification for where my Xorg.0.log file is 
located because John was indicating that his Xorg.0.log is being written 
to /var/log.


regards,
Steve



Maybe this is https://bugzilla.kernel.org/show_bug.cgi?id=216895, 
referred to in this current thread:


Re: Fedora 37 hangs after graphical login

I have two cifs mounting lines in /etc/fstab; only one has the hardware 
connected.


Thanks,

John P

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

Re: Black screens with rpmfusion nvidia 470xx and 6.0.16.fc36

[John Pilkington]

On 07/01/2023 03:30, Stephen Morris wrote:

On 6/1/23 22:22, John Pilkington wrote:
Heads up. After today's updates I get black unresponsive screens.  OK 
in 6.0.15
I'm using the nvidia 525.60.11 driver from 
rpmfusion-nonfree-nvidia-driver and there is no issue with kernel 6.0.16.


regards,
Steve



Thanks.  It's still the same for me after another dnf upgrade run. 
Using KDE, it boots and continues for some time after password entry, 
but then stays unresponsive. No light shows after Caps Lock key, and no 
mouse pointer or action.  6.0.15 works.


/var/log/Xorg.0.log looks similar for both.   For info, here's the end:

[   201.742] (--) NVIDIA(GPU-0): DELL 2009W (CRT-0): connected
[   201.742] (--) NVIDIA(GPU-0): DELL 2009W (CRT-0): 400.0 MHz maximum 
pixel clock

[   201.742] (--) NVIDIA(GPU-0):
[   201.742] (--) NVIDIA(GPU-0): DFP-0: disconnected
[   201.742] (--) NVIDIA(GPU-0): DFP-0: Internal TMDS
[   201.742] (--) NVIDIA(GPU-0): DFP-0: 330.0 MHz maximum pixel clock
[   201.742] (--) NVIDIA(GPU-0):
[   201.787] (--) NVIDIA(GPU-0): SONY TV (DFP-1): connected
[   201.787] (--) NVIDIA(GPU-0): SONY TV (DFP-1): Internal TMDS
[   201.787] (--) NVIDIA(GPU-0): SONY TV (DFP-1): 340.0 MHz maximum 
pixel clock

[   201.787] (--) NVIDIA(GPU-0):
[   217.638] (II) NVIDIA(0): Setting mode "HDMI-0: nvidia-auto-select 
@1360x768 +0+0 {ViewPortIn=1360x768, ViewPortOut=1360x768+0+0}"

[   217.739] (II) NVIDIA(0): Setting mode "NULL"
[   217.783] (II) NVIDIA(0): Setting mode "VGA-0: nvidia-auto-select 
@1680x1050 +0+30 {ViewPortIn=1680x1050, ViewPortOut=1680x1050+0+0}"
[   217.825] (II) NVIDIA(0): Setting mode "VGA-0: nvidia-auto-select 
@1680x1050 +0+30 {ViewPortIn=1680x1050, ViewPortOut=1680x1050+0+0}, 
HDMI-0: 1920x1080_50 @1920x1080 +1680+0 {ViewPortIn=1920x1080, 
ViewPortOut=1920x1080+0+0}"


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

Black screens with rpmfusion nvidia 470xx and 6.0.16.fc36

[John Pilkington]

Heads up. After today's updates I get black unresponsive screens.  OK in 
6.0.15

___
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: Perl Help (Possibly OT)

[John Pilkington]

On 05/01/2023 17:35, Patrick O'Callaghan wrote:

On Thu, 2023-01-05 at 08:27 -0700, Sbob wrote:

All;


I have dusted off my perl books, I need a simple mail script to send
an
email with a local attachment, I have tried various NET:SMTP examples
but cannot get it to work. Anyone have a working example you can
share
of a simple email script that will se my email service credentials
and
allow me to attach a zip file to the outgoing email?


$ dnf info sendemail
Last metadata expiration check: 4:23:59 ago on Thu 05 Jan 2023 13:10:20 GMT.
Available Packages
Name : sendemail
Version  : 1.56
Release  : 11.fc37
Architecture : noarch
Size : 35 k
Source   : sendemail-1.56-11.fc37.src.rpm
Repository   : fedora
Summary  : Lightweight command line SMTP e-mail client
URL  : http://caspian.dotconf.net/menu/Software/SendEmail/
License  : GPLv2+
Description  : SendEmail is a lightweight, completely command line based, SMTP 
e-mail
  : client. It was designed to be used in bash scripts, batch 
files, Perl
  : programs and web sites, but is also quite useful in many other 
contexts.
  :
  : SendEmail is written in Perl and is unique in that it requires 
no special
  : modules. It has a straight forward interface, making it very 
easy to use.

poc


Read the package name.  It's not 'sendmail'

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

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

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

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

1. back-up the initrd being used before the Nov. 03 "dnf upgrade".
2. use the kernel in use (5.19) before the Nov. 03 "dnf upgrade".
The recommended back-up was done on Nov. 04.  I've been using the 5.19 
kernel exclusively since then.  I have not run "dnf upgrade" since 
Nov. 03.


current situation:
I'm using the 5.19 kernel exclusively.
I have not run "dnf upgrade" since Nov. 03.
The RPM Fusion web site page
"https://mirror.fcix.net/rpmfusion/nonfree/fedora/updates/36/x86_64/repoview/index.html;
 now shows this...
---
Latest packages:

 2022-11-29: nvidia-settings-470xx-470.161.03-1.fc36
 2022-11-29: akmod-nvidia-470xx-470.161.03-1.fc36
 2022-11-29: kmod-nvidia-470xx-470.161.03-1.fc36
 2022-11-29: xorg-x11-drv-nvidia-470xx-470.161.03-1.fc36
 2022-11-29: xorg-x11-drv-nvidia-470xx-cuda-470.161.03-1.fc36
 2022-11-29: xorg-x11-drv-nvidia-470xx-cuda-libs-470.161.03-1.fc36
 2022-11-29: xorg-x11-drv-nvidia-470xx-devel-470.161.03-1.fc36
 2022-11-29: xorg-x11-drv-nvidia-470xx-kmodsrc-470.161.03-1.fc36
 2022-11-29: xorg-x11-drv-nvidia-470xx-libs-470.161.03-1.fc36
 2022-11-29: xorg-x11-drv-nvidia-470xx-power-470.161.03-1.fc36
(and other things not relevant to this issue)
---

The original problem left my workstation quite crippled.  It took a 
lot of time and effort to research, construct, and post messages in 
the original list thread.  I don't have other hardware to fall back 
on, not even a cell phone.  Proceeding with the fix to the problem 
strikes me as risky.


first question:
Is what is currently in RPM Fusion non-free 36 updates everything I 
need to really fix the problem for f36?


Please don't jump the gun.  Just answer that first question.  If the 
answer is positive, I'll follow up with more questions.


further information:
Anyone wanting to view the original Nov. 03-04 thread, it's here:
"https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/thread/X6QCDYEIFO7DKZE5ENCHBCW776TC26WF/;.

Thank-you in advance.
Bill.


___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

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

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

[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 

Re: Youtube Videos Don't Play in Fedora

[John Pilkington]

You have repeated many times that removing pulseaudio would remove 
gnome-shell.


Suggested workarounds have been

 'rpm -e --nodeps pulseaudio' followed by 'dnf install pipewire'

and the perhaps more mainstream

 'dnf swap pipewire pulseaudio  --allowerasing'

Any comment?

John P


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

Re: Youtube Videos Don't Play in Fedora

[John Pilkington]

On 05/12/2022 22:31, Stephen Morris wrote:

On 2/12/22 21:47, Tim via users wrote:

On Fri, 2022-12-02 at 19:45 +1100, Stephen Morris wrote:

I've disabled the pipewire service and the wireplumber service, but I
still get issues where some videos will play and when I go to play the
next video it won't play without me switching my device between analogue
and digital, in which case it then plays. I'm also getting an issue at
the moment where pulse manager keeps crashing. I might try a reinstall
of all pulseaudio packages if I can, and see if that improves things.
I can't uninstall either application as uninstallation of both
applications want to uninstall Gnome Shell which is protected from
uninstalling.

There's that dnf swap command which is supposed to take care of
replacing one package with the other.  It ought to avoid the system
wanting to remove Gnome.

e.g. dnf swap pulseaudio pipewire (or something very much like that).

Considering pulseaudio is being deprecated, maybe you should try seeing
if pipewire works better for you.
I also tried "sudo dnf swap pulseaudio pipewire" and that failed because 
of a number of pulsaudio-module packages causing conflicts, which I 
removed each time the command failed, until it got to a conflict on 
pulseaudio-module-bluetooth which cannot be removed because it wants to 
remove gnome-shell. Pipewire also has an equivalent module that wants to 
remove gnome-shell if it is uninstalled, so it looks like both packages 
have been deliberately designed to not be able to be removed because of 
gnome-shell.

A remove of gnome-shell has been banned from being allowed to happen.

regards,
Steve



I have not tried it in this context, and don't know if it carries risks, 
but maybe


sudo rpm -e --nodeps pulseaudio

followed by

sudo dnf install pipewire

would avoid that problem?

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

Re: Wrong screen resolution (1024x768) after upgrade

[John Pilkington]

On 11/11/2022 11:17, Frédéric wrote:

Hi,

Back home. This morning, I just upgraded my system with dnf upgrade
(so I still did not installed the nvidia proprietary driver). I
obtained the new kerner 6.0.7. I rebooted and here am I again with my
wrong screen resolution...

# grep veau /etc/modprobe.d/*
returns nothing

I rebuilt initrds although the file was already there for 6.0.7:
# dracut -f

# lsmod | grep veau
returns nothing

# inxi -GSaz --zl --hostname
https://paste.centos.org/view/0496bee0

# inxi -C --vs
https://paste.centos.org/view/97d00d79

/var/log/Xorg.0.log:
https://paste.centos.org/view/355ead1b

I see strange things:
[23.494] (EE) Failed to load module "nv" (module does not exist, 0)
[23.628] (EE) [drm] Failed to open DRM device for pci::01:00.0: -19
[23.628] (EE) open /dev/dri/card0: No such file or directory
[23.628] (WW) Falling back to old probe method for modesetting
[23.628] (EE) open /dev/dri/card0: No such file or directory
[23.634] (EE) open /dev/fb0: No such file or directory
[23.634] (EE) Screen 0 deleted because of no matching config section.
[23.634] (II) UnloadModule: "modesetting"
[23.634] (EE) Screen 0 deleted because of no matching config section.

but also
[23.492] (II) LoadModule: "nouveau"
[23.492] (II) Loading /usr/lib64/xorg/modules/drivers/nouveau_drv.so

which seems to indicate that nouveau is used.

Thanks for your help!

F


Today's email from rpmfusion does not show any pushes to the nonfree 
stable repo.  I suggest:


Boot the  5.16 kernel and install akmod470xx

or reinstall nouveau

or dnf --enablerepo epmfusion-nonfree-updates-testing install akmod470xx

or wait until the push-to-stable happens and update

These are ideas, probably not the exact commands.

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: Wrong screen resolution (1024x768) after upgrade

[John Pilkington]

On 07/11/2022 12:32, Frédéric wrote:

As John Pilkington said in another thread (monitor/display problem):

   
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/message/6OJJUVYSELK24XWKZBKZ6N7WR2AMQQ7N/

   390xx went into the testing repo on 3 Nov

Have you tried this 390.154-3 version ?


Not yet. I have never used testing. Thank you for your explaination on
how to do it. If it is still in testing on Friday when I go back home,
I will test it. Otherwise, the normal update may be enough.

Thanks

F


In fact I did my installation of the 470xx update from 'testing' using 
the dnfdragora GUI, not from the command line;  but by Friday the move 
to the 'stable' repo will probably have happened.


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: Wrong screen resolution (1024x768) after upgrade

[John Pilkington]

On 06/11/2022 22:42, John Pilkington wrote:

On 06/11/2022 20:12, Frédéric wrote:

Thank you all for your answers. However, I completely removed the
nvidia driver so I guess this can be excluded from the issue.
I still have the wrong screen resolution (1024x768) instead of full HD
(1920x1080) and do not know what to do. I update the system everyday
but nothing changes.
I don't know what to do. If anyone has an idea, that would help.
Thanks,
F


I don't use the 390xx driver, but try this:

sudo dnf --enablerepo=rpmfusion-nonfree-updates-testing \
install akmod-nvidia-390xx xorg-x11-drv-nvidia-390xx    \
xorg-x11-drv-nvidia-drv-390xx


Sorry, a typo.  The last one, which you may not need, should have been

xorg-x11-drv-nvidia-cuda-390xx



HTH

John P

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

Re: Wrong screen resolution (1024x768) after upgrade

[John Pilkington]

On 06/11/2022 20:12, Frédéric wrote:

Thank you all for your answers. However, I completely removed the
nvidia driver so I guess this can be excluded from the issue.
I still have the wrong screen resolution (1024x768) instead of full HD
(1920x1080) and do not know what to do. I update the system everyday
but nothing changes.
I don't know what to do. If anyone has an idea, that would help.
Thanks,
F


I don't use the 390xx driver, but try this:

sudo dnf --enablerepo=rpmfusion-nonfree-updates-testing \
install akmod-nvidia-390xx xorg-x11-drv-nvidia-390xx\
xorg-x11-drv-nvidia-drv-390xx

HTH

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

Re: monitor/display problem.

[John Pilkington]

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 next update of the nvidia 470 drivers will probably be to
fix this issue, it should be okay to do so.  If you want to avoid
updates until certain, you could use
dnf -x [nvidia driver]
so it doesn't update.


How will I know when the proper updated NVidia 470 drivers reach
rpmfusion-nonfree-updates?

You could go to the website and look at the versions in their
repositories, or subscribe to their mailing list at rpmfusion.org.  They
send out emails with pending updates.

See a new 470 driver with dnf update. No 390 for legacy nvidia card as yet.


390xx went into the testing repo on 3 Nov

___
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: monitor/display problem.

[John Pilkington]

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 a one-monitor display, but on the other monitor. 
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:

-
M
[    **] (2 of 3) Job plymouth-quit-wait.ser…tart 
running (1min 17s / no limit)

M
[   ***] (2 of 3) Job 
plymouth-quit-wait.ser…tart running (1min 17s / no limit)

M
[  *** ] (3 of 3) Job 
akmods.service/start running (1min 18s / no limit)

M
[ ***  ] (3 of 3) Job 
akmods.service/start running (1min 18s / no limit)

M
[  OK  ] Finished akmods.service[0…all new kmods 
from akmod packages.
 Starting nvidia-fallback.s… nouveau as nvidia did 
not load...
[  OK  ] Finished nvidia-fallback.s…to nouveau as 
nvidia did not load.

  Starting gdm.service - GNOME Display Manager...
[  OK  ] Started gdm.service - GNOME Display 
Manager.

-
(first and last lines are for context only)
I can't memorize fast enough, but I did notice during the last boot 
lines very much like (or identical to?) the lines above that mentioned 
"nvidia".


What is the problem?
More important, how do I fix it?

thanks,
Bill.


Your post doesn't show which versions of kernel and nvidia driver you 
were running before the problem, but others have had difficulty with the 
kernel 6 and the rpmfusion 390xx and 470xx drivers.


There are new versions of both of these in the rpmfusion nonfree updates 
testing repo.  The 470xx testing version works for me.


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

Re: Wrong screen resolution (1024x768) after upgrade

[John Pilkington]

On 01/11/2022 07:23, Stephen Morris wrote:

On 1/11/22 09:37, Joe Zeff wrote:

On 10/31/2022 03:51 PM, Barry Scott wrote:
I found that to wipe the nvidia driver and then reinstall it takes a 
number of steps.


Removing them all can be done in one step:

sudo dnf remove *nvidia*
I've also found that sudo dnf remove akmod-nvidia kmod-nvidia also 
removes all the nvidia files and all the associated dependencies.


regards,
Steve



HTH, HAND.


I haven't wanted to use nouveau recently, although IIRC it will now be 
activated as a fallback.  But in the past I had the impression that only 
the last-installed driver would behave properly. If you want nouveau, 
try reinstalling it.


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

Re: Wrong screen resolution (1024x768) after upgrade

[John Pilkington]

On 31/10/2022 14:53, stan via users wrote:

On Mon, 31 Oct 2022 11:37:43 +0100
Frédéric  wrote:


I tried to reinstall the nvidia drivers from rpmfusion:
$ sudo dnf install xorg-x11-drv-nvidia-390xx akmod-nvidia-390xx

I still have the same issue on the screen resolution and here is the
output of the commands:

$ lspci|grep VGA
01:00.0 VGA compatible controller: NVIDIA Corporation GF116M [GeForce
GT 560M] (rev a1)

$ cat /proc/cmdline
BOOT_IMAGE=(hd0,msdos1)/vmlinuz-6.0.5-200.fc36.x86_64
root=UUID=4aab7630-84b2-4eae-9c5e-804ff8657b7f ro rhgb quiet
rd.driver.blacklist=nouveau modprobe.blacklist=nouveau
nvidia-drm.modeset=1

$ cat /etc/sysconfig/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rd.driver.blacklist=nouveau
modprobe.blacklist=nouveau nvidia-drm.modeset=1 rhgb quiet
rd.driver.blacklist=nouveau modprobe.blacklist=nouveau
nvidia-drm.modeset=1"
GRUB_DISABLE_RECOVERY="true"



GRUB_ENABLE_BLSCFG=true


Is there anything in the journal?
journalctl -r
to look at messages in reverse order from the current time or
journalctl -b 0
to pick up the last boot messages.  If it is failing to set a
resolution that it previously had no trouble with, there should be some
kind of warning or error, I think.

If you remove the rpmfusion nvidia drivers, and then enable nouveau,
and reboot, does the resolution work.

It shouldn't matter, but are you booting into text or gui, and what is
your desktop?

I did a quick search on your device and linux kernel and didn't find
anything, so it shouldn't be related to the kernel update.  But, what
happens if you boot an older kernel?


I'm on F36 with the rpmfusion 470xx driver, and saw the same lower 
screen resolution on reboot with the 6.0.5 kernel.  The previous 5.19.16 
kernel still booted as before.


A new version of 470xx in rpmfusion nonfree testing was announced around 
midnight and I now have its kmod and akmod installed.  atop showed 
several cycles of akmods activity.  After they appeared to have 
finished, a 'systemctl reboot'  has delivered a system that seems to be 
ok.


There were reports from dracut-shutdown of 'failure to perform cleanup', 
and akmods-shutdown.service took longer than might have been expected 
given the earlier akmods activity.


Wait for a 390xx update?

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

Re: Nvidia refresh rate.

[John Pilkington]

On 02/08/2022 09:53, GianPiero Puccioni wrote:

On 01/08/2022 21:26, John Pilkington wrote:

On 31/07/2022 13:07, GianPiero Puccioni wrote:

Hi,

I want to decrease the refrash rate of the video to use less battery 
but I am

having difficulties...

I have F35 with KDE on a Dell G15 with Nvidia GA107M [GeForce RTX 
3050 Ti

Mobile], the RPMFusion drivers and a  1920x1080  resolution (native).

In the "system settings-display" There is the possibility to change 
refresh from
120Hz to 60Hz but it doesn't stick; I change it and "apply" but if I 
change
screen and go back to "display" it's again at 120Hz, I tried 
"nvidia-settings"

but it has only info, not settings.
The program "xrandr" reports
    1920x1080    120.00*+  59.97    59.96    59.93

Is this the problem 59.97 not 60?

Any suggestions?

G


Resending to list:

I think I may have seen something like this in the past, with the gui 
reporting a possible refresh rate as an integer but not reinterpreting 
that as the appropriate floating point value when trying to use it as 
a setting.


Have you tried setting with  xrandr?

xrandr --output  --rate 59.97

looks as if it might help, if I knew what to put as 

And the archlinux xrandr wiki looks as if it could be useful.



As xrandr reports
eDP-1 connected primary 1920x1080+0+0 (normal left inverted right x axis 
y axis)    1920x1080    120.00*+  59.97    59.96    59.93


I used "xrandr --output eDP-1 --mode 1920x1080 -r 59.97"
the answer, after a couple of second of black screen(scary!)
xrandr: Configure crtc 0 failed

I did it as root but maybe I need some kind of permission?

G


I suppose it might be worth trying the other values given by xrandr.

nVidia used to allocate whole-number labels to non-integer frame rates, 
but that was years ago and much has changed since then.  This ref was 
authoritative at the time, in a TV context, and might perhaps suggest 
something:


 https://www.mythtv.org/wiki/User_Manual:JudderFree

I don't know if you are using Wayland or X11, and what difference that 
might make.  This is probably the official nVidia reference document for 
your driver, and most of it will apply to the rpmfusion build.  It's not 
easy reading and I haven't seen an obvious fix for your problem.


http://us.download.nvidia.com/XFree86/Linux-x86_64/515.57/README/wayland-issues.html

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Nvidia refresh rate.

[John Pilkington]

On 31/07/2022 13:07, GianPiero Puccioni wrote:

Hi,

I want to decrease the refrash rate of the video to use less battery but 
I am

having difficulties...

I have F35 with KDE on a Dell G15 with Nvidia GA107M [GeForce RTX 3050 Ti
Mobile], the RPMFusion drivers and a  1920x1080  resolution (native).

In the "system settings-display" There is the possibility to change 
refresh from

120Hz to 60Hz but it doesn't stick; I change it and "apply" but if I change
screen and go back to "display" it's again at 120Hz, I tried 
"nvidia-settings"

but it has only info, not settings.
The program "xrandr" reports
    1920x1080    120.00*+  59.97    59.96    59.93

Is this the problem 59.97 not 60?

Any suggestions?

G


Resending to list:

I think I may have seen something like this in the past, with the gui 
reporting a possible refresh rate as an integer but not reinterpreting 
that as the appropriate floating point value when trying to use it as a 
setting.


Have you tried setting with  xrandr?

xrandr --output  --rate 59.97

looks as if it might help, if I knew what to put as 

And the archlinux xrandr wiki looks as if it could be useful.

John P




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

Re: VLC could not decode the format "h264" (H264 - MPEG-4 AVC (part 10))

[John Pilkington]

On 31/07/2022 17:56, Javier Perez wrote:


Hi
Just upgraded from F35 to F36.
What plugin do I have to add in order to play this codec?


I'm still with F35 and vlc has no trouble with this codec, the standard 
for DVB-T2 broadcasting here.


rpm -qa | grep -i vlc shows vlc and vlc-core, both at 3.0.17.2-1

IIRC vlc doesn't use external codecs.  I don't think ffmpeg is required.

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

Re: akmods issue

[John Pilkington]

On 06/07/2022 13:07, Neal Becker wrote:
Speaking of nvidia and akmods, I just had an issue this morning.  On my 
server I'm using nvidia proprietary driver from rpmfusion.  Apparently 
it was updated (automatically) last night and when I tried to run 
experiments on the gpu this morning I got the dreaded version mismatch 
between the kernel driver and cuda library (or something).


I tried rebooting but that didn't fix the issue.

I tried running akmods manually but it didn't find anything to build.  
The man page for akmods was unhelpful, and looking in /lib/modules 
wasn't useful because you can't see the version numbers on the modules 
to see that everything is updated.


Finally I tried rebooting a 2nd time on the theory that the akmod got 
run and the driver built on the first reboot, but too late - the old 
driver had already loaded.


Surprise, that worked.  So what's going on?  It looks like akmod is run 
too late and  2 reboots are needed to get the new driver built and loaded?


I checked
sudo systemctl status akmods
● akmods.service - Builds and install new kmods from akmod packages
      Loaded: loaded (/usr/lib/systemd/system/akmods.service; enabled; 
vendor preset: enabled)

      Active: active (exited) since Wed 2022-07-06 07:32:31 EDT; 28min ago
     Process: 1166 ExecStart=/usr/sbin/akmods --from-init (code=exited, 
status=0/SUCCESS)

    Main PID: 1166 (code=exited, status=0/SUCCESS)
         CPU: 215ms

Jul 06 07:32:29 nbecker8 systemd[1]: Starting Builds and install new 
kmods from akmod packages...
Jul 06 07:32:31 nbecker8 akmods[1166]: Checking kmods exist for 
5.18.9-100.fc35.x86_64[  OK  ]
Jul 06 07:32:31 nbecker8 systemd[1]: Finished Builds and install new 
kmods from akmod packages.


Any ideas?



Well, I'm still on Fedora 35 and the 470xx nvidia driver from rpmfusion. 
 Rebooting after a kernel upgrade is still giving nouveau and lower 
screen resolution than expected.  sudo depmod -ae, followed by sudo 
systemctl reboot, has worked for me.


https://rpmfusion.org/CommonBugs

John P

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

Re: F36 kernel (packaging) problems?

[John Pilkington]

On 27/05/2022 09:13, Barry wrote:




On 27 May 2022, at 08:25, Adrian Sevcenco  wrote:

On 26.05.2022 10:43, John Pilkington wrote:

On 26/05/2022 07:56, Adrian Sevcenco wrote:
Hi! I have a very strange situation after i updated my system to 
fedora 36:
the new 5.17.9-300.fc36.x86_64 does not boot or at least cannot 
start my monitor (i get on the monitor "no signal received")

while the identical fedora 35 one worrks 5.17.9-200.fc35.x86_64

having an nvidia card, i checked that i have kmods for both kernels
root@hal: entries # rpm -qa | grep kmod-nvidia
akmod-nvidia-515.43.04-1.fc36.x86_64
kmod-nvidia-5.17.9-200.fc35.x86_64-515.43.04-1.fc36.x86_64
kmod-nvidia-5.17.9-300.fc36.x86_64-515.43.04-1.fc36.x86_64

and my GRUB_CMD_LINE looks like this:
GRUB_CMDLINE_LINUX="acpi_osi='Windows 2013' 
acpi_enforce_resources=lax iommu=soft iomem=relaxed quiet 
mitigations=off libahci.ignore_sss=1 root=/dev/md1 rootfstype=ext4 
selinux=0 rd.plymouth=0 plymouth.enable=0 rd.auto rd.md=1 rd.dm=1 
rd.lvm=0 rd.luks=0 rd.vconsole.font=ter-v32n KEYTABLE=us 
LANG=en_US.UTF-8 rd.driver.blacklist=nouveau modprobe.blacklist=nouveau"


any idea why f36 kernel would not work and how can i troubleshoot this?

Thanks a lot!
Adrian
There was a similar thread earlier this month.  Try depmod, or dnf 
reinstall the nvidia packages.


thanks a lot! i'm not sure if "reinstall nvidia packages" meant the 
exact words or just rebuilding (with reinstalling) the kmod (generated 
by akmod) ... but it did not worked .. (including any version of 
depmod command)


i even tried to give up nvidia drivers (and just use nouveau) but 
plasma crashes in a loop and does not start at all
horrendous experience especially that i do not know what i will be 
doing in the future because i cannot stay with the f35 kernel...


See https://rpmfusion.org/CommonBugs 
<https://rpmfusion.org/CommonBugs> it has the issue listed and the fix.

I hit the same issue and the listed depmod command fixed it for me.

Reinstall does not work and is not expected to.

Barry



Thanks!
Adrian


I started and saved this draft before Barry's reply above.  I hadn't 
then found the rpmfusion 'CommonBugs' page or the BZ.  I'll post this 
because in one case depmod didn't work for me and the reinstall 
apparently did...


I had assumed that you were using the rpmfusion packages and that 
nouveau was running X11.


I have only F35 and expect to stay with that for some months.  My 
"reinstall" was based on https://rpmfusion.org/Howto/NVIDIA, and for 
recent cards (Current GeForce/Quadro/Tesla) the equivalent would probably be


{{{

sudo dnf reinstall xorg-x11-drv-nvidia  akmod-nvidia
sudo dnf reinstall xorg-x11-drv-nvidia-cuda
sudo systemctl reboot

}}}

Good luck!

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 kernel (packaging) problems?

[John Pilkington]

On 26/05/2022 07:56, Adrian Sevcenco wrote:

Hi! I have a very strange situation after i updated my system to fedora 36:
the new 5.17.9-300.fc36.x86_64 does not boot or at least cannot start my 
monitor (i get on the monitor "no signal received")

while the identical fedora 35 one worrks 5.17.9-200.fc35.x86_64

having an nvidia card, i checked that i have kmods for both kernels
root@hal: entries # rpm -qa | grep kmod-nvidia
akmod-nvidia-515.43.04-1.fc36.x86_64
kmod-nvidia-5.17.9-200.fc35.x86_64-515.43.04-1.fc36.x86_64
kmod-nvidia-5.17.9-300.fc36.x86_64-515.43.04-1.fc36.x86_64

and my GRUB_CMD_LINE looks like this:
GRUB_CMDLINE_LINUX="acpi_osi='Windows 2013' acpi_enforce_resources=lax 
iommu=soft iomem=relaxed quiet mitigations=off libahci.ignore_sss=1 
root=/dev/md1 rootfstype=ext4 selinux=0 rd.plymouth=0 plymouth.enable=0 
rd.auto rd.md=1 rd.dm=1 rd.lvm=0 rd.luks=0 rd.vconsole.font=ter-v32n 
KEYTABLE=us LANG=en_US.UTF-8 rd.driver.blacklist=nouveau 
modprobe.blacklist=nouveau"


any idea why f36 kernel would not work and how can i troubleshoot this?

Thanks a lot!
Adrian


There was a similar thread earlier this month.  Try depmod, or dnf 
reinstall the nvidia packages.


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

Re: nvidia driver disabled ion F36 upgrade?

[John Pilkington]

On 15/05/2022 15:21, Barry wrote:




On 14 May 2022, at 09:15, Barry Scott  wrote:

I have been using the nvidia driver from rpmfusion on f35 without problem.

Just upgraded to F36 and its using nouveau.

There is a nvidia-fallback service that ran and did the modprobe nouveau.
(Nice that this is here as a fallback)

Anyone know why the rpmfusion driver is not automatically loaded after
the upgrade?


If I had read the rpmfusion common issues then I would have learned that
I needed to do a depmod -ae to get things working. Thanks to Leigh who
Appointed me to the docs.

All the code and modules had been built for the kernel, but  depmod does
not happen for some upgrades.

Barry



Barry

I just had a similar experience upgrading from F34 to F35 using the dnf 
plugin.  The rpmfusion nvidia-470xx driver packages (for GT710 cards) 
were upgraded and installed, but nouveau was active after the reboot, 
and the low screen resolution could not be reset.  Both systems are ok 
now, in X11, but one needed reinstallation of the packages quoted for 
'Legacy GeForce 600/700' at https://rpmfusion.org/Howto/NVIDIA.


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

Re: fractional scaling in Fedora 36

[John Pilkington]

On 14/05/2022 13:38, Anil Felipe Duggirala wrote:


On Sat, May 14 2022 at 11:33:17 AM +0930, Tim via users 
 wrote:

On Fri, 2022-05-13 at 08:47 -0500, Anil Felipe Duggirala wrote:

My questions: 1. Is there another way to enable fractional
scaling? (Gnome and Wayland) 

In my opinion scaling is a bad hack to avoid properly sizing a GUI to 
the current screen resolution and dimensions, and produced no end of 
rendering side effects when I messed with it in the past. 


Hello Tim.
I don't know what you mean by "end of rendering".


"no end of"  means "very many" or "a lot of" :-)



Have you tried simply setting appropriate font sizes? 


That is what Ive done so far. I installed gnome-tweaks and set the font 
"scaling factor" to 1.20. And chose appropriate font size in apps like 
CLion.
I will continue to play with fonts to see if that works. My eyesight is 
not the best right now.
My screen is scaled at 200% at this point. Using no scaling would be 
impossible I think. This is a 4k resolution on a 15 inch screen.


thank you,


___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Updating F32 (with Nvidia drivers) and startup hangs.

[John Pilkington]

On 02/01/2022 14:43, Ed Greshko wrote:

On 02/01/2022 20:15, John Pilkington wrote:
My reply was intended to give some evidence about what the rpmfusion 
packages provided, and to hint, in response to the preceding post, 
that it might give a complete version of the cuda set.   I posted a 
list of installed nvidia packages earlier, but have not yet found a 
way of pointing straight to that post in the HyperKitty archive.  So 
here's another block of text.  A few of the packages are, I suppose, 
not really relevant to the precise topic.  The 'command line' ones are 
products of the akmod process.


Thanks for that explanation.  I must have missed the list you posted 
earlier.




== 


 Package Architecture   Version    Repository  Size
== 


Removing:
 akmod-nvidia-470xx    x86_64 
3:470.94-1.fc34    @rpmfusion-nonfree-updates  22 k
 kmod-nvidia-470xx x86_64 
3:470.94-1.fc34    @rpmfusion-nonfree-updates   0
 kmod-nvidia-470xx-5.15.10-100.fc34.x86_64 x86_64 
3:470.94-1.fc34    @@commandline  44 M
 kmod-nvidia-470xx-5.15.11-100.fc34.x86_64 x86_64 
3:470.94-1.fc34    @@commandline  44 M
 kmod-nvidia-470xx-5.15.12-100.fc34.x86_64 x86_64 
3:470.94-1.fc34    @@commandline  44 M
 nvidia-persistenced   x86_64 
3:495.46-1.fc34    @rpmfusion-nonfree-updates  50 k
 nvidia-settings-470xx x86_64 
3:470.94-1.fc34    @rpmfusion-nonfree-updates 4.6 M
 nvidia-texture-tools  x86_64 
2.1.2-1.fc34   @fedora 1.2 M
 xorg-x11-drv-nvidia-470xx x86_64 
3:470.94-1.fc34    @rpmfusion-nonfree-updates  55 M
 xorg-x11-drv-nvidia-470xx-cuda    x86_64 
3:470.94-1.fc34    @rpmfusion-nonfree-updates 4.7 M
 xorg-x11-drv-nvidia-470xx-cuda-libs   x86_64 
3:470.94-1.fc34    @rpmfusion-nonfree-updates 138 M
 xorg-x11-drv-nvidia-470xx-devel   x86_64 
3:470.94-1.fc34    @rpmfusion-nonfree-updates  46
 xorg-x11-drv-nvidia-470xx-kmodsrc x86_64 
3:470.94-1.fc34    @rpmfusion-nonfree-updates  24 M
 xorg-x11-drv-nvidia-470xx-libs    x86_64 
3:470.94-1.fc34    @rpmfusion-nonfree-updates 322 M
 xorg-x11-drv-nvidia-470xx-power   x86_64 
3:470.94-1.fc34    @rpmfusion-nonfree-updates 2.3 k

Removing unused dependencies:
 egl-wayland   x86_64 
1.1.7-1.fc34   @updates  58 k


I don't have  nvidia-texture-tools, xorg-x11-drv-nvidia-470xx-power or 
xorg-x11-drv-nvidia-470xx-devel installed.


In checking them out they seem unnecessary in my use case.  But it is 
good to know of the existence of

nvidia-texture-tools and xorg-x11-drv-nvidia-470xx-power



I have no idea how useful they might be.  I think I installed them via 
dnfdragora, the graphical UI for dnf, after a search for nvidia-related 
packages.  But it needs a working graphical environment, and creating 
its cache feels very slow...

___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Updating F32 (with Nvidia drivers) and startup hangs.

[John Pilkington]

On 02/01/2022 11:42, Ed Greshko wrote:

On 02/01/2022 19:07, John Pilkington wrote:

On 02/01/2022 09:39, francis.montag...@inria.fr wrote:


Hi

On Sat, 01 Jan 2022 13:26:47 -0700 Jerry James wrote:


On Sat, Jan 1, 2022 at 1:07 PM  wrote:

Can you confirm that you need CUDA and not only the nvidia drivers ?


If yes, I suggest to not use the rpmfusion repositories since they 
don't

provide CUDA. See below.



They don't?  Then what are the xorg-x11-drv-nvidia-cuda and
xorg-x11-drv-nvidia-cuda-libs packages provided by rpmfusion?


This is only the CUDA driver. It may not be sufficient for this purpose.

Installing them takes less than 2 M of disk space. The full cuda 6.3 G


Running F34, and using the packages from rpmfusion, I just tried

dnf erase \*nvidia\*

It offered to remove 16 packages, freeing 681 M.  I typed n.



It isn't clear if you are saying this a problem or just informational.

In my case, I get only 12 and they all seem rational.

Removing:
  akmod-nvidia-470xx   x86_64 3:470.94-1.fc35 
@rpmfusion-nonfree-updates  22 k

  kmod-nvidia-470xx-5.15.10-200.fc35.x86_64
   x86_64 3:470.94-1.fc35 
@@commandline  103 M

  kmod-nvidia-470xx-5.15.11-200.fc35.x86_64
   x86_64 3:470.94-1.fc35 
@@commandline  103 M

  kmod-nvidia-470xx-5.15.12-200.fc35.x86_64
   x86_64 3:470.94-1.fc35 
@@commandline  103 M
  nvidia-persistenced  x86_64 3:495.46-1.fc35 
@rpmfusion-nonfree-updates  50 k
  nvidia-settings-470xx    x86_64 3:470.94-1.fc35 
@rpmfusion-nonfree-updates 4.5 M

  xorg-x11-drv-nvidia-470xx
   x86_64 3:470.94-1.fc35 
@rpmfusion-nonfree-updates  55 M

  xorg-x11-drv-nvidia-470xx-cuda
   x86_64 3:470.94-1.fc35 
@rpmfusion-nonfree-updates 4.7 M

  xorg-x11-drv-nvidia-470xx-cuda-libs
   x86_64 3:470.94-1.fc35 
@rpmfusion-nonfree-updates 138 M

  xorg-x11-drv-nvidia-470xx-kmodsrc
   x86_64 3:470.94-1.fc35 
@rpmfusion-nonfree-updates  24 M

  xorg-x11-drv-nvidia-470xx-libs
   x86_64 3:470.94-1.fc35 
@rpmfusion-nonfree-updates 322 M

Removing unused dependencies:
  egl-wayland  x86_64 1.1.9-3.fc35    @updates

Freed space: 856 M



My reply was intended to give some evidence about what the rpmfusion 
packages provided, and to hint, in response to the preceding post, that 
it might give a complete version of the cuda set.   I posted a list of 
installed nvidia packages earlier, but have not yet found a way of 
pointing straight to that post in the HyperKitty archive.  So here's 
another block of text.  A few of the packages are, I suppose, not really 
relevant to the precise topic.  The 'command line' ones are products of 
the akmod process.



{{{

[root@HPFed john]# dnf erase *nvidia*
No match for argument: nvidia-bug-report.log.gz
No packages marked for removal.
Dependencies resolved.
Nothing to do.
Complete!
[root@HPFed john]# dnf erase \*nvidia\*
Dependencies resolved.
==
 Package   Architecture 
  VersionRepository 
 Size

==
Removing:
 akmod-nvidia-470xxx86_64 
  3:470.94-1.fc34@rpmfusion-nonfree-updates 
 22 k
 kmod-nvidia-470xx x86_64 
  3:470.94-1.fc34@rpmfusion-nonfree-updates 
  0
 kmod-nvidia-470xx-5.15.10-100.fc34.x86_64 x86_64 
  3:470.94-1.fc34@@commandline 
 44 M
 kmod-nvidia-470xx-5.15.11-100.fc34.x86_64 x86_64 
  3:470.94-1.fc34@@commandline 
 44 M
 kmod-nvidia-470xx-5.15.12-100.fc34.x86_64 x86_64 
  3:470.94-1.fc34@@commandline 
 44 M
 nvidia-persistenced   x86_64 
  3:495.46-1.fc34@rpmfusion-nonfree-updates 
 50 k
 nvidia-settings-470xx x86_64 
  3:470.94-1.fc34@rpmfusion-nonfree-updates 
4.6 M
 nvidia-texture-tools  x86_64 
  2.1.2-1.fc34   @fedora 
1.2 M
 xorg-x11-drv-nvidia-470xx x86_64 
  3:470.94-1.fc34@rpmfusion-nonfree-updates 
 55 M
 xorg-x11-drv-nvidia-470xx-cudax86_64 
  3:470.94-1.fc34@rpmfusion-nonfree-updates 
4.7 M
 xorg-x11-drv-nvidia-470xx-cuda-libs   x86_64 
  3:470.94-1.fc34@rpmfusion-nonfree-updates 
138 M
 xorg-x11-drv-nvidia-470xx-devel   x86_64 
  3:470.94-1.fc34@rpmfusion-nonfree

Re: Updating F32 (with Nvidia drivers) and startup hangs.

[John Pilkington]

On 02/01/2022 09:39, francis.montag...@inria.fr wrote:


Hi

On Sat, 01 Jan 2022 13:26:47 -0700 Jerry James wrote:


On Sat, Jan 1, 2022 at 1:07 PM  wrote:

Can you confirm that you need CUDA and not only the nvidia drivers ?



If yes, I suggest to not use the rpmfusion repositories since they don't
provide CUDA. See below.



They don't?  Then what are the xorg-x11-drv-nvidia-cuda and
xorg-x11-drv-nvidia-cuda-libs packages provided by rpmfusion?


This is only the CUDA driver. It may not be sufficient for this purpose.

Installing them takes less than 2 M of disk space. The full cuda 6.3 G


Running F34, and using the packages from rpmfusion, I just tried

dnf erase \*nvidia\*

It offered to remove 16 packages, freeing 681 M.  I typed n.

Regards,

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

Re: Updating F32 (with Nvidia drivers) and startup hangs.

[John Pilkington]

On 01/01/2022 17:52, Fulko Hew wrote:
I'm not sure where the problem lies, so I'll start out with where I'm 
coming from...


I built a machine 2 years ago to support the Folding@Home project
using F32 and an Nvidia 2060 card.

It's been running non-stop ever since.
But I want to update the system to the latest and greatest release and 
drivers

(since it appears that my old? CUDA drivers have stopped working with F@H)

So first I updated all my packages using dnf and attempted a reboot
(into the new kernel) and that's where the first problem appeared.
The boot process hangs with the last message on the screen being
"Notify NFS peers of a restart"

(I don't have any NFS configured on this machine.)

So I rebooted with my old working kernel and examined /var/log/messages
and I see:
Jan  1 12:36:10 localhost sh[972]: (bad exit status: 2)
Jan  1 12:36:10 localhost sh[4378]: Error! Bad return status for module 
build on kernel: 5.11.22-100.fc32.x86_64 (x86_64)
Jan  1 12:36:10 localhost sh[4378]: Consult 
/var/lib/dkms/nvidia/440.82/build/make.log for more information.


Looking at that file, I see a variety of errors basically telling me there's
incompatibilities between the stuff Nvidia uses to get itself 'linked 
in' at boot

time, and what the kernel is now providing.

If I can't get to a GUI screen to be able to fetch and install newer 
NVIDIA drivers

how can I get my system updated?

Suggestions welcome.
TIA
Fulko



There have been several posts in the last few days arising from the 
shift of some nvidia cards to 'legacy' status.  Cards supported by the 
470 series driver but not by 495 now have to add the 470xx tag to the 
rpmfusion package name.


The GTX2060 is listed as supported by 495, but there won't be F32 
packages for it.  It would probably be best to upgrade to F35 (or F34) 
to get them; that process now seems to be straightforward and reliable.


I found that the rpmfusion cuda package was not installed by the default 
akmod build process; "dnf install xorg-x11-drv-nvidia-cuda"  should work 
for you.


HTH

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

Re: urgent problem: "NVIDIA kernel module missing..." [SOLVED]

[John Pilkington]

On 31/12/2021 23:01, home user wrote:

On 12/30/21 2:36 PM, home user wrote:

(f34)

I'm using my old windows-7 box to do e-mail.

I did my weekly patches ("dnf upgrade") an hour ago.  After rebooting, 
after the rightmost rectangle turns white, I get the message "NVIDIA 
kernel module missing. Falling back to nouveau.". A few seconds later, 
the 3 rectangles turn orange.  Then the screens go black and nothing 
further happens.  I have to use the reset button on the top of the 
tower.  The behavior is the same no matter which of the 3 grub menu 
Fedora entries I choose.  No luck with the rescue mode (f30).  I do 
have an f31 live USB stick, but that has no e-mail client.


How do I get my f34 working properly?  All I have to work with is 
windows-7 (this is a dual-boot workstation) and the f31 live USB 
stick. Please keep in mind that I'm a "home user" with no sys.admin. 
training. My sys.admin. skills are *very* basic.


Ed's solution,
removing the old driver (dnf erase *nvidia*), then
installing the correct driver (dnf install akmod-nvidia-470xx)
worked.

The problem arose when my weekly patches updated the working driver with 
a newer one that does not support my NVIDIA Corporation GK106 [GeForce 
GTX 660] graphics card.


I thank Ed for his time and effort on this issue.

I've marked this thread "SOLVED".

Yes, but the biggest problem for an isolated user will be getting from a 
black boot screen to the starting point.  Quoting from Ed:


You can boot and when the kernel selection comes up type "e" and then 
add "3" to to linux line and the "control-X"


Or, boot normally and use "control-Alt-F3" to get to a terminal. This 
may or may not work for you.


Use lspci and find the line the line for nvidia or use "lspci | grep -i 
nvidia"



John P


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

Re: f35 and NVIDIA entanglement

[John Pilkington]

On 31/12/2021 01:47, Robert McBroom via users wrote:

On 12/30/21 07:29, John Pilkington wrote:

On 29/12/2021 20:31, John Pilkington wrote:



I have a GT710 in F34.  It was running the rpmfusion default driver, 
in the 470 series but without the 470xx label.  Earlier this week 
'dnf update' wanted to install 495, the new (unlabelled) default 
which does not support that card, but I didn't accept.


Then the kde 'software updater' widget showed updates, but with a red 
dot.  It looked as if I could tick-to-disable just the nvidia 
updates, so I did and went ahead;  the driver updates happened anyway.



Without rebooting I tried

    dnf install --allowerasing akmod-nvidia-470xx

which ran the usual tests and started to go ahead, but then reported 
a file conflict.


So  I tried

    sudo rpm -e --nodeps xorg-x11-drv-nvidia-libs

followed by

    sudo dnf install --allowerasing akmod-nvidia-470xx kmod-nvidia-470xx

which all worked.

    sudo systemctl reboot

  then rebooted as normal, but NVDEC tv decoding was not available 
until I also did


    sudo dnf install xorg-x11-drv-nvidia-470xx-cuda

HTH

John P

Here's the current status of that installation.  I tried to erase the 
only 495.46 package there, but it wanted to take the cuda package 
below it too.  Maybe I only need the cuda-libs.


{{{

[john@HPFed packaging]$ rpm -qa | grep -i nvidia
nvidia-texture-tools-2.1.2-1.fc34.x86_64
xorg-x11-drv-nvidia-470xx-libs-470.94-1.fc34.x86_64
xorg-x11-drv-nvidia-470xx-kmodsrc-470.94-1.fc34.x86_64
nvidia-settings-470xx-470.94-1.fc34.x86_64
xorg-x11-drv-nvidia-470xx-470.94-1.fc34.x86_64
akmod-nvidia-470xx-470.94-1.fc34.x86_64
kmod-nvidia-470xx-470.94-1.fc34.x86_64
kmod-nvidia-470xx-5.15.10-100.fc34.x86_64-470.94-1.fc34.x86_64
kmod-nvidia-470xx-5.15.11-100.fc34.x86_64-470.94-1.fc34.x86_64
xorg-x11-drv-nvidia-470xx-cuda-libs-470.94-1.fc34.x86_64
xorg-x11-drv-nvidia-470xx-devel-470.94-1.fc34.x86_64
xorg-x11-drv-nvidia-470xx-power-470.94-1.fc34.x86_64
nvidia-persistenced-495.46-1.fc34.x86_64
xorg-x11-drv-nvidia-470xx-cuda-470.94-1.fc34.x86_64
[john@HPFed packaging]$

}}}
___ 


John

Are you saying you have a graphical desktop with the current rpmfusion 
drivers for the gt710?


Yes, it appears to be working as before, and I don't expect problems 
with future updates.  But Ed's instructions in the other thread don't 
require 'oddities' like rpm -e --nodeps and dnf --sllowerasing.



___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: urgent problem: "NVIDIA kernel module missing..."

[John Pilkington]

On 30/12/2021 21:36, home user wrote:

(f34)

I'm using my old windows-7 box to do e-mail.

I did my weekly patches ("dnf upgrade") an hour ago.  After rebooting, 
after the rightmost rectangle turns white, I get the message "NVIDIA 
kernel module missing. Falling back to nouveau.". A few seconds later, 
the 3 rectangles turn orange.  Then the screens go black and nothing 
further happens.  I have to use the reset button on the top of the 
tower.  The behavior is the same no matter which of the 3 grub menu 
Fedora entries I choose.  No luck with the rescue mode (f30).  I do have 
an f31 live USB stick, but that has no e-mail client.


How do I get my f34 working properly?  All I have to work with is 
windows-7 (this is a dual-boot workstation) and the f31 live USB stick. 


Please keep in mind that I'm a "home user" with no sys.admin. training. 
My sys.admin. skills are *very* basic.


I think you may still be able to boot an earlier kernel.  Then see my 
posts earlier today.  You probably need the 470xx series driver, which 
was the default until earlier this week.


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

Re: f35 and NVIDIA entanglement

[John Pilkington]

On 29/12/2021 20:31, John Pilkington wrote:



I have a GT710 in F34.  It was running the rpmfusion default driver, in 
the 470 series but without the 470xx label.  Earlier this week 'dnf 
update' wanted to install 495, the new (unlabelled) default which does 
not support that card, but I didn't accept.


Then the kde 'software updater' widget showed updates, but with a red 
dot.  It looked as if I could tick-to-disable just the nvidia updates, 
so I did and went ahead;  the driver updates happened anyway.



Without rebooting I tried

    dnf install --allowerasing akmod-nvidia-470xx

which ran the usual tests and started to go ahead, but then reported a 
file conflict.


So  I tried

    sudo rpm -e --nodeps xorg-x11-drv-nvidia-libs

followed by

    sudo dnf install --allowerasing akmod-nvidia-470xx kmod-nvidia-470xx

which all worked.

    sudo systemctl reboot

  then rebooted as normal, but NVDEC tv decoding was not available until 
I also did


    sudo dnf install xorg-x11-drv-nvidia-470xx-cuda

HTH

John P

Here's the current status of that installation.  I tried to erase the 
only 495.46 package there, but it wanted to take the cuda package below 
it too.  Maybe I only need the cuda-libs.


{{{

[john@HPFed packaging]$ rpm -qa | grep -i nvidia
nvidia-texture-tools-2.1.2-1.fc34.x86_64
xorg-x11-drv-nvidia-470xx-libs-470.94-1.fc34.x86_64
xorg-x11-drv-nvidia-470xx-kmodsrc-470.94-1.fc34.x86_64
nvidia-settings-470xx-470.94-1.fc34.x86_64
xorg-x11-drv-nvidia-470xx-470.94-1.fc34.x86_64
akmod-nvidia-470xx-470.94-1.fc34.x86_64
kmod-nvidia-470xx-470.94-1.fc34.x86_64
kmod-nvidia-470xx-5.15.10-100.fc34.x86_64-470.94-1.fc34.x86_64
kmod-nvidia-470xx-5.15.11-100.fc34.x86_64-470.94-1.fc34.x86_64
xorg-x11-drv-nvidia-470xx-cuda-libs-470.94-1.fc34.x86_64
xorg-x11-drv-nvidia-470xx-devel-470.94-1.fc34.x86_64
xorg-x11-drv-nvidia-470xx-power-470.94-1.fc34.x86_64
nvidia-persistenced-495.46-1.fc34.x86_64
xorg-x11-drv-nvidia-470xx-cuda-470.94-1.fc34.x86_64
[john@HPFed packaging]$

}}}
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: f35 and NVIDIA entanglement

[John Pilkington]

On 29/12/2021 18:17, Robert McBroom via users wrote:
My system has a NVIDIA GEFORCE GT 710 video card. It was working with 
f33 and rpmfusion drivers. Updating to f35 installed a driver that was 
for cards newer than the 710. Tried reverting to the 470.86 driver. All 
I could get was a blank screen. Cleared the rpmfusion driver and tried 
the NVIDIA binary 470.86 driver. The install seemed to go well but 
restart gets only a blank screen. Same with the newer 470.94 driver.


Now trying to use nouveau.

Ran the sequence

rm -f /usr/lib{,64}/libGL.so.* /usr/lib{,64}/libEGL.so.*
rm -f /usr/lib{,64}/xorg/modules/extensions/libglx.so
dnf reinstall xorg-x11-server-Xorg mesa-libGL mesa-libEGL libglvnd\*
mv /etc/X11/xorg.conf /etc/X11/xorg.conf.saved

The nouveau module did not load.

Went to /lib64/xorg/modules/drivers and ran

modprobe nouveau

lsmod|grep nouveau

shows

nouveau  2404352  0
mxm_wmi    16384  1 nouveau
video  57344  1 nouveau
i2c_algo_bit   16384  1 nouveau
drm_ttm_helper 16384  1 nouveau
ttm    81920  2 drm_ttm_helper,nouveau
drm_kms_helper    311296  1 nouveau
drm   630784  4 drm_kms_helper,drm_ttm_helper,ttm,nouveau
wmi    36864  4 hp_wmi,wmi_bmof,mxm_wmi,nouveau

ran

dracut -f

to update initramfs and did restart

graphical start does not connect to the server

System still trying to load nvidia instead of nouveau. Noted that 
/etc/X11/xorg.conf was still that installed by nvidia. My systems with 
ati cards do not have xorg.conf changed the name. startx still 
unsuccessful.


The Xorg.0.log file resulting is attached.

What can I do to get the system to give me a graphical desktop?



I have a GT710 in F34.  It was running the rpmfusion default driver, in 
the 470 series but without the 470xx label.  Earlier this week 'dnf 
update' wanted to install 495, the new (unlabelled) default which does 
not support that card, but I didn't accept.


Then the kde 'software updater' widget showed updates, but with a red 
dot.  It looked as if I could tick-to-disable just the nvidia updates, 
so I did and went ahead;  the driver updates happened anyway.



Without rebooting I tried

   dnf install --allowerasing akmod-nvidia-470xx

which ran the usual tests and started to go ahead, but then reported a 
file conflict.


So  I tried

   sudo rpm -e --nodeps xorg-x11-drv-nvidia-libs

followed by

   sudo dnf install --allowerasing akmod-nvidia-470xx kmod-nvidia-470xx

which all worked.

   sudo systemctl reboot

 then rebooted as normal, but NVDEC tv decoding was not available until 
I also did


   sudo dnf install xorg-x11-drv-nvidia-470xx-cuda

HTH

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

Re: F34 kernel-devel drpm checksum mismatch

[John Pilkington]

On 30/11/2021 19:23, Samuel Sieb wrote:

On 11/30/21 03:26, John Pilkington wrote:
For several recent kernel updates, dnf has complained about this but 
has updated as normal.  I've just noticed that the package name looks 
strange, too.  Should it get a BZ?


/var/cache/dnf/updates-1eb77e9f45b4391a/packages/kernel-devel-5.15.4-101.fc34_5.15.5-100.fc34.x86_64.drpm: 
md5 mismatch of result


What do you think is strange about the package name?  It's a deltarpm 
file, so it shows the versions that are involved.


kernel-devel-5.15.4-101.fc34_5.15.5-100.fc34.x86_64.drpm
The package name is "kernel-devel" and this is the delta between 
versions "5.15.4-101.fc34" and "5.15.5-100.fc34".


The mismatch can be caused by one of the files getting changed on the 
system.  Then the delta won't apply correctly and the result won't match 
what is expected.


Yes, I realised after sending that a 'diff' has two sources.  I had 
thought it worth reporting as something persistent.  I don't know of any 
reason for a 'change on the system'.


Thanks.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

F34 kernel-devel drpm checksum mismatch

[John Pilkington]

For several recent kernel updates, dnf has complained about this but has 
updated as normal.  I've just noticed that the package name looks 
strange, too.  Should it get a BZ?


FWIW, I think this is needed by the rpmfusion nVidia packages.  :-)

Thanks,

John P

{{{
Downloading Packages:
(1/6): kernel-5.15.5-100.fc34.x86_64.rpm 
92 kB/s |  14 kB 00:00
(2/6): kernel-devel-5.15.4-101.fc34_5.15.5-100.fc34.x86_64.drpm 
   3.1 MB/s | 3.0 MB 00:00
(3/6): kernel-modules-extra-5.15.5-100.fc34.x86_64.rpm 
   3.4 MB/s | 2.0 MB 00:00
(4/6): exfatprogs-1.1.3-1.fc34.x86_64.rpm 
   684 kB/s |  62 kB 00:00
(5/6): kernel-modules-5.15.5-100.fc34.x86_64.rpm 
   3.6 MB/s |  32 MB 00:09
(6/6): kernel-core-5.15.5-100.fc34.x86_64.rpm 
   2.4 MB/s |  35 MB 00:14
/var/cache/dnf/updates-1eb77e9f45b4391a/packages/kernel-devel-5.15.4-101.fc34_5.15.5-100.fc34.x86_64.drpm: 
md5 mismatch of result

Some packages were not downloaded. Retrying.
kernel-devel-5.15.5-100.fc34.x86_64.rpm 
   5.3 MB/s |  15 MB 00:02


}}}
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: NVIDIA Legacy drivers

[John Pilkington]

On 29/11/2021 15:44, Fulko Hew wrote:



On Mon, Nov 29, 2021 at 10:01 AM Bob Marcan > wrote:


Why we just don't buy any hardware which have Nvidia?
If they ignore us, we can do the same.
What is wrong with AMD video, except it works out of the box? :-)


Because there is no CUDA support?


___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

This thread started because the OP was having problems trying to keep an 
old nVidia card working on upgrading to F35.  IIRC he succeeded using 
the RPMfusion packages.  It may take some effort, and some people have 
quasi-religious objections.  I doubt that Fedora will adopt nVidia, but 
there is a existing user base.


___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: NVIDIA Legacy drivers

[John Pilkington]

On 25/11/2021 17:46, Joe Zeff wrote:

On 11/25/21 3:08 AM, Tim via users wrote:

I don't think so, unless you're trying to be funny.  We don't have to
do any of this pallaver for other several other graphics chipsets,
audio chipsets, USB chipsets, WiFi, etc.  The system figures it out for
us.  It was one of the great features of Linux of an install often
"just working" without any user jiggery pokery.


Don't blame Linux for that, blame nVidia for not providing either 
drivers or the chipset's specs so that drivers can be written by OSS 
programmers.  If you must use nVidia but don't want to do what's needed 
to install the drivers, try Ubuntu because they automate the 
installation of the binary blob drivers.


I suppose I have to recognise that as a lone user my perspective will 
differ from that of sysadmins responsible for a whole zoo of systems. 
Although the RPMfusion packages don't offer automatic card recognition, 
my impression is that installation of a specific driver by dns is 
usually straightforward.  I have no 'special interest' in this.


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

Re: Message threading on this list

[John Pilkington]

On 25/11/2021 19:38, Gordon Messmer wrote:

On 11/23/21 14:06, John Pilkington wrote:
I'm used to reading messages in order of time of arrival.  Threaded 
display in Thunderbird, or the presentation of the archive by 
Hyperkitty, doesn't do this



Right... Hyperkitty also shows messages in threaded mode, where replies 
are grouped in the list next to the message they are a reply *to*.  Both 
of those applications are behaving as intended.


In Thunderbird, you might prefer to "Sort By > Subject" and "Sort By > 
Group by sort".  Or (and perhaps more likely), you'd prefer Conversation 
View:


https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/ 



Thank you for that link.  I hadn't been aware of that possibility.  But 
I was really thinking of the Hyperkitty display, which appears as the 
archive default.  Having a too-large local mailbox I don't often use it, 
and its multiple endpoints seemed less than ideal.

___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: NVIDIA Legacy drivers

[John Pilkington]

On 25/11/2021 10:08, Tim via users wrote:

Tim:

See my prior email about "why should we have to do this, it's the
computer."

In all seriousness, if a distro wants people to use it, don't make
them do deep forensics to figure out how to install drivers.  The
computer should be doing this analysis for you.



John Pilkington:

I think you misunderstand the way open source works.


I don't think so, unless you're trying to be funny.  We don't have to
do any of this pallaver for other several other graphics chipsets,
audio chipsets, USB chipsets, WiFi, etc.  The system figures it out for
us.  It was one of the great features of Linux of an install often
"just working" without any user jiggery pokery.



That's obviously desirable. But *someone* needs to do the work to make 
it happen.  Who?  For what reward?  If you want to use a card that will 
cost you multi$$,  it just may be worth Reading the Manual - once.

___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: NVIDIA Legacy drivers

[John Pilkington]

On 25/11/2021 03:31, Tim via users wrote:

On Wed, 2021-11-24 at 20:11 +, John Pilkington wrote:

NVIDIA has several driver series, each of which has different
hardware support. To determine which driver you need to install,
you'll first need to find your graphics card model.


See my prior email about "why should we have to do this, it's the
computer."

In all seriousness, if a distro wants people to use it, don't make them
do deep forensics to figure out how to install drivers.  The computer
should be doing this analysis for you.
  


I think you misunderstand the way open source works.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: NVIDIA Legacy drivers

[John Pilkington]

On 24/11/2021 14:43, Jonathan Billings wrote:

I know the ELrepo nvidia packages (for RHEL) have a nvidia-detect 
package (and corresponding yum plug-in) that makes it easy to install 
the appropriate package, giving you some automation.


http://elrepo.org/tiki/nvidia-detect 

Perhaps someone needs to port this over to Fedora, dnf, and rpmfusion?



I Posted this link earlier.  It's not a difficult google; but here it is 
again.  I've copied the equivalent section, and expanded a link within 
it but anyone hoping to use the rpmfusion packages for nvidia really 
ought to be aware of this page.  I'm not sure about Wayland, though...


https://rpmfusion.org/Howto/NVIDIA#Determining_your_card_model

{{{

Determining your card model

NVIDIA has several driver series, each of which has different hardware 
support. To determine which driver you need to install, you'll first 
need to find your graphics card model.


If you don't know it, open a Terminal (Applications > System Tools > 
Terminal) and type:


/sbin/lspci | grep -e VGA

You can also check the supported chips section:

https://download.nvidia.com/XFree86/Linux-x86_64/495.44/README/supportedchips.html

and see which series is recommended for you card, then install the 
appropriate driver series. Please remember that you need additional 
steps for optimus.


}}}

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

Re: Message threading on this list

[John Pilkington]

On 23/11/2021 22:26, Samuel Sieb wrote:

On 11/23/21 14:06, John Pilkington wrote:
I'm used to reading messages in order of time of arrival.  Threaded 
display in Thunderbird, or the presentation of the archive by 
Hyperkitty, doesn't do this; the current thread about NVIDIA drivers 
is utterly disjointed in both, with recent posts buried at random 
partway up the display.  Is there a fix?


You can't use threaded mode in Thunderbird then, because there's no way 
to do what you want.  You have to sort only by date.  You might be able 
to keep a topic together by also sorting by subject, but I don't know 
how those two sorting options would interact.


I do sort by date, because that's the way conversations work.  The other 
views just confuse matters.  It's worse than top posting.

___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Message threading on this list

[John Pilkington]

I'm used to reading messages in order of time of arrival.  Threaded 
display in Thunderbird, or the presentation of the archive by 
Hyperkitty, doesn't do this; the current thread about NVIDIA drivers is 
utterly disjointed in both, with recent posts buried at random partway 
up the display.  Is there a fix?


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

Re: NVIDIA Legacy drivers

[John Pilkington]

On 23/11/2021 14:17, Tim Evans wrote:

On 11/22/21 19:32, Ed Greshko wrote:

Actually, the exclude was needed when the akmod-nvidia-340xx package 
was in the rpmfusion-nonfree-updates-testing.  Without the
exclude the akmod-nvidia-340xx would get downgraded to the broken 
version.


I just removed the exclude from my configuration which confirms the 
package was moved to stable.


And a check on a system without nvidia hardware.

[root@f35k ~]# dnf list available | grep akmod-nvidia-340xx
akmod-nvidia-340xx.x86_64 1:340.108-15.fc35 rpmfusion-nonfree-updates

Which is the "fixed" version for the newer kernels.


Guess I am misunderstanding 'exclude.'  Without it here, what's to 
prevent future updates from installing the >340xx versions that don't 
support my card, and that I just de-installed? Thanks.


According to the nVidia 'Advanced driver search', the GT730 is supported 
by the driver series from 390 to 470.  I have the GT710 in F34 with 470.


https://www.nvidia.com/Download/Find.aspx?lang=en-us

Instructions from Rpmfusion are copied below.  If, as shown, you specify 
470xx, that should stick.


{{{
Legacy GeForce 600/700

Supported on current stable Xorg server release.

/!\ This serie is the current default for fedora releases up to Fedora 34.

This driver is suitable for any NVIDIA Kepler GPU found between 2012 and 
2014


dnf update -y
sudo dnf install xorg-x11-drv-nvidia-470xx akmod-nvidia-470xx
sudo dnf install xorg-x11-drv-nvidia-470xx-cuda #optional for cuda up to 
11.4 support


/!\ 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 then 'sudo systemctl reboot'

HTH

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

Re: NVIDIA Legacy drivers

[John Pilkington]

On 22/11/2021 19:52, Tim Evans wrote:

On 11/13/21 11:10, Ed Greshko wrote:


To switch back to nouveau, just "dnf erase akmod-nvidia-39xx".

This will revert the changes to the linux boot parameters.


# dnf remove akmod-nvidia-470.74-1.fc35.x86_64
Dependencies resolved.
 


  Package Arch   Version Repository     Size
 


Removing:
  akmod-nvidia    x86_64 3:470.74-1.fc35 @rpmfusion-nonfree 
     22 k

Removing unused dependencies:
  akmods  noarch 0.5.6-28.fc35   @fedora     37 k
  debugedit   x86_64 5.0-2.fc35  @fedora    190 k
  fakeroot    x86_64 1.26-4.fc35 @updates    152 k
  fakeroot-libs   x86_64 1.26-4.fc35 @updates    133 k
  http-parser x86_64 2.9.4-5.fc35    @fedora    100 k
  kmodtool    noarch 1-43.fc35   @fedora     18 k
  koji    noarch 1.26.1-1.fc35   @updates    712 k
  libgit2 x86_64 1.1.0-5.fc35    @fedora    1.1 M
  python3-gssapi  x86_64 1.6.14-2.fc35   @fedora    1.9 M
  python3-koji    noarch 1.26.1-1.fc35   @updates    1.5 M
  python3-progressbar2    noarch 3.53.2-2.fc35   @fedora    208 k
  python3-pygit2  x86_64 1.6.1-1.fc35    @fedora    860 k
  python3-requests-gssapi noarch 1.2.3-3.fc35    @fedora     54 k
  python3-rpmautospec noarch 0.2.5-1.fc35    @fedora     74 k
  python3-utils   noarch 2.5.6-3.fc35    @fedora    798 k
  rpm-build   x86_64 4.17.0-1.fc35   @fedora    142 k
  rpmdevtools noarch 9.5-2.fc35  @fedora    219 k
  xorg-x11-drv-nvidia-kmodsrc x86_64 3:495.44-4.fc35 
@rpmfusion-nonfree-updates


     26 M
  zstd    x86_64 1.5.0-2.fc35    @fedora    1.9 M

Transaction Summary
 


Remove  20 Packages

Freed space: 36 M
Is this ok [y/N]: n

Looks like a lot of stuff to be removed.

The 4.95 version that came down with FC35 does not support my GeForce GT 
730.  Did a dnf downgrade to version 470.x, but that's not working with 
F35 kernel--auto-fallback to Nouveau. And, as noted this looks like a 
lot of stuff to be removed to get rid of the driver altogether. Stuff 
looks a little flaky--Thunderbird came up in a window the size of a 
postage stamp, but maximizing it made it ok.


Advice? Thanks.


Here's the obvious 'official' link.  I'm not sure how much of it you 
need to read...


https://rpmfusion.org/Howto/NVIDIA#Uninstall_the_NVIDIA_driver
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: NVIDIA Legacy drivers

[John Pilkington]

On 15/11/2021 17:03, Robert McBroom via users wrote:

Haven't tried rpmfusion in a long time as patches or upgrades have 
usually been available before their updates to a new kernel.


I have no recent experience with the 390 series, but normally a driver 
from rpmfusion will build *on your system* when the kernel is updated.




Will try.
rpmFusion drivers are 390.144-1. They make on kernel-5.14.16. See if F35 
upgrade will go.

___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: capabilities of softwares on fedora vs on developper's platform

[John Pilkington]

On 20/10/2021 11:12, François Patte wrote:

Le 2021-10-20 11:37, Patrick O'Callaghan a écrit :

On Wed, 2021-10-20 at 10:26 +0200, François Patte wrote:


Bonjour,

I am wondering why fedora packagers limit the capabilities of
softwares:

I installed blender from fedora repo (f34) version 2.93.5. It is
impossible to enable the graphical acceleration of my graphic card
(nvidia GeForce GTX 1050 Ti).

I went to blender official site and got the same version of blender
and graphical acceleration is set without any problem.

Why this difference?


Which Nvidia driver are you using? The Nouveau driver almost certainly
doesn't support this feature. The non-free binary Nvidia one might do
so (I haven't checked) but that's not an official Fedora package. You
need to get it from RPMfusion.


I use nvidia driver from rpmfusion and this feature is enabled when I 
use blender from blender site but not from

  /pub/linux/fedora/linux/updates/34/Everything/x86_64/Packages/

on fedora mirrors.

I posted recently on the rpmfusion list about using nvidia-settings in 
KDE plasma under Wayland and X11.   X11 seems largely ok;  Wayland says 
it can't find the display, but then still uses it.


I later found a thread on a similar topic on this list.   Doesn't 
explain the difference you see between the two builds of blender but 
might be related.


https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/thread/VLAAUDCPVYBPI2QHNTFWZA455VVEIQ3T/

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