Tue, 27 Aug 2024 21:06:23 -0500 "David C. Rankin" <drankinatty@gmail.com> :

On 8/27/24 8:13 PM, bent fender wrote:

...

My nvidia gt640 video card is temporarily re-installed after the AMD card went kaput. The TW install and Live DVD's both boot but end up with a black screen after the last HDMI symbol appears. The DVD continues reading but the prog is unaware that I can't see anything. I thought that the installers and Live media could work with any card. What are my options to recover the installation and use it with this card UFN?

Well,

If you can boot to a text console or boot a recovery/install disk and chroot your current install, you can uninstall the current nvidiaXXX drivers from the command line. The nvidia drivers blacklist nouveau which prevents that module from loading. I suspect that is where the live CD went south.

After uninstalling the current nvidia drivers, your box should boot to graphics mode. Or if not, just use text mode.

If you are on TW with the 6.10 kernel, you will either need to patch the driver from the official repo, or install the kernel-devel (kernel source) and add the following temporary repo that has the nvidia driver patched for 6.10:

https://download.opensuse.org/repositories/home:/drankinatty:/branches:/home...

(buildservice)

https://build.opensuse.org/package/show/home:drankinatty:branches:home:ligur...

When you install the driver, it will build the patched module against the kernel source. Reboot and you should be good to go.

If you are not on TW with the 6.10 kernel, then simply uninstalling your current nvidia drivers should do it. With the 6.9 kernel or earlier, you can then just simply load the G05 drivers from the official nvidia repo and be good.

-- David C. Rankin, J.D.,P.E.

Yes, I remember 6.10 giving problems and me using 6.9 for what seemed like many months. The last grub ritual was done with Yast from TW and probably with kernel 6.10 removed already because the boot menu gives only these choices - 6.9.3-1 - 6.9.3-1 recovery - 6.9.1-1 - 6.9.1-1 recovery I have two backup images made with dd - tw-2024-05-07-vbox.dd - tw-2024-06-04.dd Somewhere along the line I got ticked off and scrounged up an older AMD card, the last time I ran TW (and Artix without systemd) was with that AMD card. Then the AMD card packed up so I reinstalled the old nvidia gt640 interim. Since then neither TW nor Artix boot, both get only as far as a last HDMI icon on the monitor. I've tried so many things with the TW partition that it's prbably totally borked by now, though I could recover it from stored backups to the dates shown. My Slackware, Devuan, and VoidLinux installs which never used nvidia drivers at all (if that's what the problem is) all boot without issues. I thought my best shot would come from booting a TW DVD and doing an upgrade but the DVD's don't boot either so even a chroot has to be done from Slackware, a last Mohican that still lets you log in at cLi level. THIS is what I don't understand, why would an installer want to use any proprietary driver at all when an alternative avails (if that's what the problem is)? So what I think I should try is recover the TW partition, then chroot from Slackware and TRY to edit what needs editing so that nouveau gets used on the next boot, which is a few fathoms over my head. I did chroot and try to install the last nvidia 'run' driver file but I don't think it helped any (NVIDIA-Linux-x86_64-470.256.02.run). All this time I bought a new AMD card which prevented my box from booting at all, returned it, bought the same form another store, same deal. Got into all manner of TS and arguments over that all to no avail. Another option is to wait (another 6 months?) until the suse DVD's do manage to boot into any hardware known to man, something I always thought was a *firm Linux forte* :-)

Wed, 28 Aug 2024 08:53:32 -0400 Felix Miata <mrmazda@earthlink.net> :

bent fender composed on 2024-08-28 06:13 (UTC-0400):

...

Somewhere along the line I got ticked off and scrounged up an older AMD card, the last time I ran TW (and Artix without systemd) was with that AMD card. Then the AMD card packed up so I reinstalled the old nvidia gt640 interim. Since then neither TW nor Artix boot, both get only as far as a last HDMI icon on the monitor.

The above is not true, my bad: they boot but the monitor goes black after the HDMI icon appears on it. I suppose that's where a GUI log-in would begin being shown.

...

I've tried so many things with the TW partition that it's prbably totally borked by now, though I could recover it from stored backups to the dates shown.

...

My Slackware, Devuan, and VoidLinux installs which never used nvidia drivers at all (if that's what the problem is) all boot without issues. I thought my best shot would come from booting a TW DVD and doing an upgrade but the DVD's don't boot either so even a chroot has to be done from Slackware, a last Mohican that still lets you log in at cLi level. THIS is what I don't understand, why would an installer want to use any proprietary driver at all when an alternative avails (if that's what the problem is)?

...

So what I think I should try is recover the TW partition, then chroot from Slackware and TRY to edit what needs editing so that nouveau gets used on the next boot, which is a few fathoms over my head. I did chroot and try to install the last nvidia 'run' driver file but I don't think it helped any

Perhaps you can avoid your trouble booting installation media by not using it. Instead, download linux and initrd for NET installation from http://download.opensuse.org/tumbleweed/repo/oss/boot/x86_64/loader/ and put them in a Grub stanza. This is how I start most installations, main exception being when no disk in system contains a working Grub already. Once stanza is constructed and placed, starting installer is a snap. Initial configurations can be included on the stanza's linu line, such as for network. https://en.opensuse.org/SDB:Linuxrc has these instructions.

All that is over my head for now

Have you tried appending plymouth.enable=0 to your installed system's or installation media's boot menu linu line, and dropping quiet and splash=silent from them?

This didn't change anything: break into grub shell with 'c' set root=(hd0,14) linux /boot/vmlinuz plymouth.enable=0 root=/dev/sda14 initrd /boot/initrd boot

I'm not getting black screens here, except for background color for login and bash prompts on vttys. -- Evolution as taught in public schools is, like religion, based on faith, not based on science.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

My problem when trying to boot my installed TW is maybe not with the nvidia driver as much as with its absence; the last card configured having been AMD but now booting with an nvidia card. All this liturgy about removing a driver and installing the correct one before rebooting after a card-change is dead in the water when a card just packs up and the only option becomes to go with another one (no one that I know of keeps two identical cards around!) For the Instalation or Live dvd's it's another story, the problem there would seem to be kernel 6.10 and nvidia drivers but even then (and I'm way overextending my familiarity here) with bothering with any proprietary driver instead of nouveau.

On 8/28/24 5:13 AM, bent fender wrote:

All this time I bought a new AMD card which prevented my box from booting at all, returned it, bought the same form another store, same deal. Got into all manner of TS and arguments over that all to no avail. Another option is to wait (another 6 months?) until the suse DVD's do manage to boot into any hardware known to man, something I always thought was a*firm Linux forte* :-)

Ahh, Now it makes sense. You put a nvidia card in a system with AMD drivers installed without removing the AMD drivers. You box was trying to load AMD drivers, finding not AMD card and turning titsup. You want to uninstall the AMD drivers, make sure the nouveau driver is installed (or go ahead and install the G05 drivers) and then reboot. I've seen Carlos' post and others about choosing AMD over Nvidia. No thank you. AMD burned all bridges with me when it suddenly considered all 1800 (and earlier) cards "legacy" cards and dropped (removed, deleted, destroyed) Linux support for fglrx. That killed it for me. I can still load a Nvidia driver for an Nvidia Riva-TNT card from the 90's if I want. People complain about Nvidia, but it has far better support for its older cards than AMD does. All the drivers are there -- you just may have to patch and build them. AMD support for older cards is "nonexistent". If you have a laptop with a fancy older AMD card - no acceleration - period. Boot your TW box to text mode (or run the install disk and chroot) and remove the AMD driver, install nouveau and/or kernel-devel and Nvidia, and reboot. If you just want to be done with the Nvidia driver issue for the 6.10, install kernel-devel, add the repository I provided and do a zypper in --from "that-repo" (or just download the repo files and do "zypper in --old-package *.rpm") and reboot. Kernel updates with 6.10 will then be handled automatically from that point forward with dracut triggering a driver build for you via dkms. Once you make friends with how the Nvidia driver is used to build kernel modules for your box, you never have to worry about it again. It is then just a day or two after Linus releases a new kernel before the patch is worked out for the Archlinux package and that can be used with openSUSE -- verbatim I was happy to find. The 1-2 day patch scramble always works with the 535 driver patch being prepared, usually from: https://gitlab.com/herecura/packages/nvidia-535xx-utils e.g. https://gitlab.com/herecura/packages/nvidia-535xx-utils/-/blob/d1199ffe128f5... which usually works as is for the 470 driver (G05 driver in suse terms) and then it is backported to the 390 (G04) driver -- usually at: https://aur.archlinux.org/packages/nvidia-390xx-utils Once the kernel patches are prepared, they can just be added to the buildservice project for the G03-G05 driver (with an updated open-source driver release from Nvidia if needed) and the packages built to support the new kernel. All that has been done for the 6.10 kernel, it's just a mystery why nobody at openSUSE has updated the official openSUSE NVidia repo yet -- it is their responsibility as the NVidia site clearly lays out, NVidia just hosts the driver packages for openSUSE, but openSUSE has to update them. Oh well, someday, somebody will do it. I don't know who is responsible for doing that, the current 6.9 kernel drivers just contain, e.g.: Name : nvidia-gfxG04-kmp-default Version : 390.157_k6.9.7_1 Release : 43.3 Architecture: x86_64 Install Date: (not installed) Group : System/Kernel Size : 68400525 License : SUSE-NonFree Signature : RSA/SHA512, Mon 15 Jul 2024 02:50:40 PM CDT, Key ID b1d0d788db27fd5a Source RPM : nvidia-gfxG04-390.157-43.3.nosrc.rpm Build Date : Wed 03 Jul 2024 05:44:45 AM CDT Build Host : reproducible Vendor : obs://build.suse.de/Proprietary:X11:Drivers URL : https://www.nvidia.com/object/unix.html Summary : NVIDIA graphics driver kernel module for GeForce 400 series and newer Description : This package provides the closed-source NVIDIA graphics driver kernel module for GeForce 400 series and newer GPUs. Distribution: Proprietary:X11:Drivers / openSUSE_Tumbleweed Here is to hope that somebody will get nudged and update the drivers to save all the TW nvidia card owners the grief. My card is in a laptop -- I have little choice... -- David C. Rankin, J.D.,P.E.

On 8/28/24 2:05 PM, Felix Miata wrote:

...

the nouveau driver The above is a fallacy:

1-every openSUSE kernel package "set" contains*a* nouveau module (driver) named nouveau.ko. This module is required by all NVidia GPUs that are neither older than ancient, or too new, for nouveau support, and not using NVidia's proprietary drivers. I used the term "set" above because in Leap, instead of in kernel-<type>, nouveau.ko is provided by optional package kernel-<type>-extra.

Some package it, some provide it -- either way the intent was just to make sure it's there. I'd never looked for it on opensuse specifically. I know on Arch it's a package. I looked on my TW install, and I have: libdrm_nouveau2-2.4.122-1.1.x86_64 libvdpau_nouveau-24.1.3-1699.393.pm.1.x86_64 but it's not something I explicitly installed. Good to know it's always there. -- David C. Rankin, J.D.,P.E.

bent fender composed on 2024-08-29 22:04 (UTC-0400):

Actually I shoulkd reply with this to the kind soul who gave me hints about chrooting in response

Wed, 28 Aug 2024 15:05:32 -0400 Felix Miata composed:

...

David C. Rankin composed on 2024-08-28 13:05 (UTC-0500):

...

...

the nouveau driver

...

The above is a fallacy: ... ... ... Felix Miata

Still no cigar

The TW DVD still don't work and my TW install still don't boot

see Message ID: <oqOdnQJ2Nssfukz7nZ2dnZfqn_idnZ2d@giganews.com>

Was whatever that points to supposed to help us help you? I can't find any way to see what it contains. What happens if you try to boot TW by appending either 3 and/or nomodeset to Grub's linu line? If 3 eventually makes a shell login prompt available on any of the ttys, then this should be fixable. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

Wed, 28 Aug 2024 13:05:55 -0500 "David C. Rankin" <drankinatty@gmail.com> :

On 8/28/24 5:13 AM, bent fender wrote:

...

All this time I bought a new AMD card which prevented my box from booting at all, returned it, bought the same form another store, same deal. Got into all manner of TS and arguments over that all to no avail. Another option is to wait (another 6 months?) until the suse DVD's do manage to boot into any hardware known to man, something I always thought was a*firm Linux forte* :-)

Ahh,

Now it makes sense. You put a nvidia card in a system with AMD drivers installed without removing the AMD drivers. You box was trying to load AMD drivers, finding not AMD card and turning titsup.

You want to uninstall the AMD drivers, make sure the nouveau driver is installed (or go ahead and install the G05 drivers) and then reboot.

I've seen Carlos' post and others about choosing AMD over Nvidia. No thank you. AMD burned all bridges with me when it suddenly considered all 1800 (and earlier) cards "legacy" cards and dropped (removed, deleted, destroyed) Linux support for fglrx. That killed it for me.

I can still load a Nvidia driver for an Nvidia Riva-TNT card from the 90's if I want. People complain about Nvidia, but it has far better support for its older cards than AMD does. All the drivers are there -- you just may have to patch and build them. AMD support for older cards is "nonexistent". If you have a laptop with a fancy older AMD card - no acceleration - period.

Boot your TW box to text mode (or run the install disk and chroot) and remove the AMD driver, install nouveau and/or kernel-devel and Nvidia, and reboot.

If you just want to be done with the Nvidia driver issue for the 6.10, install kernel-devel, add the repository I provided and do a zypper in --from "that-repo" (or just download the repo files and do "zypper in --old-package *.rpm") and reboot. Kernel updates with 6.10 will then be handled automatically from that point forward with dracut triggering a driver build for you via dkms.

Once you make friends with how the Nvidia driver is used to build kernel modules for your box, you never have to worry about it again. It is then just a day or two after Linus releases a new kernel before the patch is worked out for the Archlinux package and that can be used with openSUSE -- verbatim I was happy to find. The 1-2 day patch scramble always works with the 535 driver patch being prepared, usually from:

https://gitlab.com/herecura/packages/nvidia-535xx-utils

e.g.

https://gitlab.com/herecura/packages/nvidia-535xx-utils/-/blob/d1199ffe128f5...

which usually works as is for the 470 driver (G05 driver in suse terms) and then it is backported to the 390 (G04) driver -- usually at:

https://aur.archlinux.org/packages/nvidia-390xx-utils

Once the kernel patches are prepared, they can just be added to the buildservice project for the G03-G05 driver (with an updated open-source driver release from Nvidia if needed) and the packages built to support the new kernel.

All that has been done for the 6.10 kernel, it's just a mystery why nobody at openSUSE has updated the official openSUSE NVidia repo yet -- it is their responsibility as the NVidia site clearly lays out, NVidia just hosts the driver packages for openSUSE, but openSUSE has to update them.

Oh well, someday, somebody will do it. I don't know who is responsible for doing that, the current 6.9 kernel drivers just contain, e.g.:

Name : nvidia-gfxG04-kmp-default Version : 390.157_k6.9.7_1 Release : 43.3 Architecture: x86_64 Install Date: (not installed) Group : System/Kernel Size : 68400525 License : SUSE-NonFree Signature : RSA/SHA512, Mon 15 Jul 2024 02:50:40 PM CDT, Key ID b1d0d788db27fd5a Source RPM : nvidia-gfxG04-390.157-43.3.nosrc.rpm Build Date : Wed 03 Jul 2024 05:44:45 AM CDT Build Host : reproducible Vendor : obs://build.suse.de/Proprietary:X11:Drivers URL : https://www.nvidia.com/object/unix.html Summary : NVIDIA graphics driver kernel module for GeForce 400 series and newer Description : This package provides the closed-source NVIDIA graphics driver kernel module for GeForce 400 series and newer GPUs. Distribution: Proprietary:X11:Drivers / openSUSE_Tumbleweed

Here is to hope that somebody will get nudged and update the drivers to save all the TW nvidia card owners the grief. My card is in a laptop -- I have little choice...

I'm not going to comment on what is a monumental fubar but in my case TW was my go2 system and I did all my grub deploy-boot-code chores from it with Yast. I haven't been able to boot it for months so my other systems that continue working like a charm without nvidia drivers regardless of the card used I have to boot manually because booting them with a grub menu that's months old also started falling apart. You had issues with AMD cards and I cannot debate that as I never had any AMD card for any length of time but I did spend interminable hours downloading nvidia drivers from the nvidia web site at speed slower than a derad dog and in the case of an outrfit like them I never for a moment believed that slowness to be anything but intentional. Even if it was not, I'm done with nvidia. It could be that I'll have to can AMD as well, their level of support in the case of two $550 cards in recent weeks has left me wondering if they're still doing it in the foliage of trees! But this isn't really an answer to your response for which I thank you; I'm studying what I must to get on top of this freakin' mess and that'll take a little more time and revolve around chrooting into TW from Slackware and maybe getting usb-wifi to work to then run yast to establish noveau in charge and redo all the boot stuff :-)

On 2024-08-28 20:05, David C. Rankin wrote:

On 8/28/24 5:13 AM, bent fender wrote:

...

  I've seen Carlos' post and others about choosing AMD over Nvidia. No thank you. AMD burned all bridges with me when it suddenly considered all 1800 (and earlier) cards "legacy" cards and dropped (removed, deleted, destroyed) Linux support for fglrx. That killed it for me.

That's ancient lore. AMD has since "embraced" open source, and you do not need to load proprietary drivers. The default drivers included in the distribution work very well. I have nothing to do, it just works. Even in 3D games. On the other hand, I have an old computer with an old NVidia card which has been dropped support by NVidia, meaning the proprietary driver will not work at all, and Nouveau works "more or less". -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)

Fri, 30 Aug 2024 16:31:15 -0500 "David C. Rankin" <drankinatty@gmail.com> :

On 8/30/24 8:12 AM, Carlos E. R. wrote:

...

On the other hand, I have an old computer with an old NVidia card which has been dropped support by NVidia, meaning the proprietary driver will not work at all, and Nouveau works "more or less".

They will work -- it just takes putting them together. Now your point is perfectly valid - unless somebody patches and builds the package for the old nvidia card -- they do not work. But, my point is that nvidia still supplies the binary blob to enable those cards to work. You can simply download it.

By contrast, AMD does NOT provide any way to make the older cards work with fglrx -- period. No here's the old driver, you make it work -- no nothing.

It is funny to look back at these issues and marvel at how much time has gone by. The fglrx issue was probably somewhere around 2005-2007 just as compiz was hitting mainstream. To think that nearly two-decades have gone by, my kids that enjoyed the Tux Potatohead game are now all grown and out of the house.

Time really does fly...

-- David C. Rankin, J.D.,P.E.

Linux is about 30 year old boxes still running, my card is only 12! The issue isn't only purely technical, one aspect being that when a driver problem becomes this complex and complicated (regardless of the politics) handling it should not be dumped on the users. My other perspective hails from the *interminable hours* I've spent trying to download huge drivers with a slomo internet connection and having to try 4 or 5 times because the nvidia server would time me out. NEVER AGAIN will I tolerate another nvidia product in my house. But I do still have this GT640 fanless 8gb card with which I am 'otherwise' very happy, it does what I need or have a use for while AMD makes nothing comparable. I will probably give it away when I buy an AMD card one but it still has to work until then and even beyond for a new owner (probably one of my grandchildren).

On 2024-08-30 23:31, David C. Rankin wrote:

On 8/30/24 8:12 AM, Carlos E. R. wrote:

...

On the other hand, I have an old computer with an old NVidia card which has been dropped support by NVidia, meaning the proprietary driver will not work at all, and Nouveau works "more or less".

They will work -- it just takes putting them together. Now your point is perfectly valid - unless somebody patches and builds the package for the old nvidia card -- they do not work. But, my point is that nvidia still supplies the binary blob to enable those cards to work. You can simply download it.

By contrast, AMD does NOT provide any way to make the older cards work with fglrx -- period. No here's the old driver, you make it work -- no nothing.

Yes, but AMD changed policy. It no longer happens. Now the driver is open sourced and comes with the distribution without downloading any external driver. There are proprietary drivers, but I do not need them. 3D games work. On the other hand, my old nvidia card no longer works with the proprietary nvidia driver. One day it stopped being supported. And without the proprietary driver, things like games do not work.

It is funny to look back at these issues and marvel at how much time has gone by. The fglrx issue was probably somewhere around 2005-2007 just as compiz was hitting mainstream. To think that nearly two-decades have gone by, my kids that enjoyed the Tux Potatohead game are now all grown and out of the house.

Time really does fly...

-- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)

On 2024-09-01 00:44, Masaru Nomiya wrote:

Hello,

In the Message;

Subject : Re: nvidia g05 or nouveau in TW Live/Install? Message-ID : <d8de5e6a-26d5-41cc-84ee-a64951cd7465@telefonica.net> Date & Time: Sat, 31 Aug 2024 14:35:05 +0200

[CER] == "Carlos E. R." <robin.listas@telefonica.net> has written:

[...] CER> On the other hand, my old nvidia card no longer works with the CER> proprietary nvidia driver. One day it stopped being CER> supported. And without the proprietary driver, things like games CER> do not work.

There is a reason why nvidia is ending support. If an user is going to continue to use something that is no longer supported, shouldn't he check the reasons why?

Simply the computer and the card was over ten year old, simple as that. Nvidia decided to no longer support that particular card. I had been using that computer for many years, and one day I had to remove the proprietary driver, and eventually buy another computer⁽¹⁾ I have that computer in storage, so finding out exact details needs finding a table and connecting it. (1) The motherboard was limited to 8GiB, and I needed more; the machine was swapping. Also VMware stopped supporting that processor. Ie, I had three big reasons for replacing the machine. Then two years ago, I put it to service again as a computer for guests on another location, temporarily. Ah, the card was this one: https://www.msi.com/Graphics-Card/N9500GTMD1GOCD2/Specification -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)

Sat, 31 Aug 2024 09:55:49 +0900 Masaru Nomiya <nomiya@lake.dti.ne.jp> :

Hello,

In the Message;

Subject : Re: nvidia g05 or nouveau in TW Live/Install? Message-ID : <20240828061316.be19ddf0f80d5976cf4f6fc0@trixtar.org> Date & Time: Wed, 28 Aug 2024 06:13:16 -0400

[BF] == bent fender <slowroller@trixtar.org> has written:

[...] BF> So what I think I should try is recover the TW partition, then BF> chroot from Slackware and TRY to edit what needs editing so that BF> nouveau gets used on the next boot, which is a few fathoms over my BF> head. I did chroot and try to install the last nvidia 'run' driver file BF> but I don't think it helped any BF> (NVIDIA-Linux-x86_64-470.256.02.run). [...]

Please show the result of;

$ mokutil --sb-state

# zypper install mokutil # mokutil --sb-state "EFI variables are not supported on this system" :-(

Best Regards.

--- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "Japan was the future but it's stuck in the past"

-- Rupert Wingfield-Hayes (BBC) --

Fri, 30 Aug 2024 20:28:06 -0500 "David C. Rankin" <drankinatty@gmail.com> :

On 8/28/24 5:13 AM, bent fender wrote:

...

So what I think I should try is recover the TW partition, then chroot from Slackware and TRY to edit what needs editing so that nouveau gets used on the next boot, which is a few fathoms over my head. I did chroot and try to install the last nvidia 'run' driver file but I don't think it helped any (NVIDIA-Linux-x86_64-470.256.02.run).

Yikes - NO,

it was a longshot :-)

The .run file is the binary blob that "has to be patched". That is what I patched in the links to the repo I provided. You really have 2 options - both from chroot. The first step below applies regardless whether you do 2) or not.

1) chroot and remove all nvidia packages and any AMD driver packages, reboot and let nouveau load; or

did that, no change, and as discussed with Ted Felix the DVD don't work either and that has nothing to do with what's on the drives.

2) chroot and install the nvidia files from the repo I provided, dracut will trigger the patching and nvidia module build from the .run file.

It may come to this but I'm reluctant because I don't intend to keep this card for long and the only systems that have survived this entire still rolling episode are the ones that never used any nvidia crap

That's basically what the nvidia packages are regardless of whether you get them from the official repo (not yet with the kernel-6.10.patch) or from my repo with it. You install the packages, and on install and all further kernel updates, the module build is triggered by dracut and dkms builds the nvidia driver for the kernel. The reason you can't build or load the nvidia driver is when dracut triggers the module build, the kernel-6.10.path (that's the actual patch file name) is missing. It is included in the packages I provide the link to.

That whale is getting eaten -- slowly -- one bite at a time...

-- David C. Rankin, J.D.,P.E.

Sat, 31 Aug 2024 03:53:03 -0500 "David C. Rankin" <drankinatty@gmail.com> :

On 8/30/24 10:10 PM, bent fender wrote:

...

It may come to this but I'm reluctant because I don't intend to keep this card for long and the only systems that have survived this entire still rolling episode are the ones that never used any nvidia crap

Yep,

But that's part of eating the whale, installing/uninstalling is nothing more than a zypper rm <pkgnames> or rpm -e <pkgnames>. Takes about 3 minutes either way. If it comes to that, don't worry about the temporary status of the card, just install, test, uninstall if it goes to hell.

Now if we were still building everything from source to install it -- then I'd be more hesitant, just for the sheer about of time some builds take... But with packages, just chroot and go.

I also am having a hard time understanding why the installer isn't running. That should have a compatible set of drivers and kernel regardless. Do you have any other video card in your bone-pile you can throw in and test? The installer really should just do its thing unless you are telling it to boot the installed system -- then you are back to the same issues. But the installer itself should launch to a gui with its basic drivers.

Good luck. You have fought the good fight on this one...

-- David C. Rankin, J.D.,P.E.

It ain't over till the fat lady sings, it's morning here as I begin another blessed day with half an hour of coffee poured on my laptop, I'll resume molesting the desktop again in the evening as usual. I do have another used AMD card with a 6-pin aux-power plug that my PSU cannot cater to, I have ordered some molex-to-6 and molex-to-8 adapters though. A dealer 'gave' me this one (which should be a red flag) as a replacement for another old AMD that packed up and led to the return of the old gt640, last try this new old AMD just gave one long and three short beeps which I must say was a huge improvement over two new ones returned to the stores they came from weeks ago. The part that worries ME is where a user with a home on a another drive to which a link points in /home doesn't work as it did the last time I had a working TW. Ubuntu-Studio did something similar to me last year with one of its package handling horrors that wouldn't either. Ubuntu is gone now. Later :-)

Sat, 31 Aug 2024 14:59:21 +0200 "Carlos E. R." <robin.listas@telefonica.net> :

On 2024-08-31 13:16, bent fender wrote:

...

Sat, 31 Aug 2024 03:53:03 -0500 "David C. Rankin" <> :

...

It ain't over till the fat lady sings, it's morning here as I begin another blessed day with half an hour of coffee poured on my laptop, I'll resume molesting the desktop again in the evening as usual. I do have another used AMD card with a 6-pin aux-power plug that my PSU cannot cater to, I have ordered some molex-to-6 and molex-to-8 adapters though. A dealer 'gave' me this one (which should be a red flag) as a replacement for another old AMD that packed up and led to the return of the old gt640, last try this new old AMD just gave one long and three short beeps which I must say was a huge improvement over two new ones returned to the stores they came from weeks ago.

The part that worries ME is where a user with a home on a another drive to which a link points in /home doesn't work as it did the last time I had a working TW. Ubuntu-Studio did something similar to me last year with one of its package handling horrors that wouldn't either. Ubuntu is gone now. Later :-)

I meant gone from MY computers (hint)

The card I am currently using is a MSI Radeon RX589, which was relatively cheap.

Telcontar:~ # inxi -G Graphics: Device-1: AMD Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] driver: amdgpu v: kernel Display: x11 server: X.Org v: 1.21.1.4 with: Xwayland v: 22.1.5 driver: X: loaded: amdgpu unloaded: fbdev,modesetting,vesa dri: radeonsi gpu: amdgpu resolution: 1920x1080~60Hz API: OpenGL v: 4.6 Mesa 22.3.5 renderer: AMD Radeon RX 580 Series (polaris10 LLVM 15.0.7 DRM 3.49 5.14.21-150500.55.73-default) Telcontar:~ #

Thank you I have a radion ATI p/n 7122284000G(043A1D) that may or may not work (waiting for a 6-pin connector) One of my sons has offered another old AMD, no data yet. The one installed: my old fanless nvidia gt640 https://www.zotac.com/download/files/styles/w1024/public/product_gallery/gra... I have no issues with buying a good AMD, when I bought the nvidia it wasn't cheap by any 2012 standard. One problem is that they all have 2-3 fans while I'm on the warpath against noise, I might find other solutions involving novel cooling methods. It's on hold, as is a totally ECC box for the simple reason that the market is too confusing, dishonest, and not transparent enough.

-- Cheers / Saludos,

Carlos E. R. (from 15.5 x86_64 at Telcontar)

Sat, 31 Aug 2024 12:44:11 +0900 Masaru Nomiya <nomiya@lake.dti.ne.jp> :

Hello,

In the Message;

Subject : Re: nvidia g05 or nouveau in TW Live/Install? Message-ID : <fee85465-ef85-4e51-9401-7c3359ff3402@gmail.com> Date & Time: Fri, 30 Aug 2024 20:28:06 -0500

[DCR] == "David C. Rankin" <drankinatty@gmail.com> has written:

DCR> On 8/28/24 5:13 AM, bent fender wrote: DCR> > So what I think I should try is recover the TW partition, then DCR> > chroot from Slackware and TRY to edit what needs editing so that DCR> > nouveau gets used on the next boot, which is a few fathoms over my DCR> > head. I did chroot and try to install the last nvidia 'run' driver file DCR> > but I don't think it helped any DCR> > (NVIDIA-Linux-x86_64-470.256.02.run).

DCR> Yikes - NO,

DCR> The .run file is the binary blob that "has to be DCR> patched". That is what I patched in the links to the repo I DCR> provided. You really have 2 options - both from chroot. [...] ]...] DCR> That whale is getting eaten -- slowly -- one bite at a time...

He has got another issue with the video driver.

Ben, please show ths resuls of;

Thanks for chiming in :-)

$ inxi -b

I think I did this with a really-booted TW using kernel arguments 3 and nomodeset (as opposed to a chrooted one): System: Host: localhost.localdomain Kernel: 6.10.5-1-default arch: x86_64 bits: 64 Desktop: KDE Plasma v: 6.1.4 Distro: openSUSE Tumbleweed 20240829 Machine: Type: Desktop Mobo: ASUSTeK model: Crosshair IV Formula v: Rev 1.xx serial: MB-1234567890 BIOS: American Megatrends v: 3029 date: 10/09/2012 CPU: Info: 8-core AMD FX-8150 [MCP] speed (MHz): avg: 2037 min/max: 1400/3600 Graphics: Device-1: NVIDIA GK107 [GeForce GT 640] driver: N/A Display: x11 server: X.Org v: 21.1.12 with: Xwayland v: 24.1.2 driver: X: loaded: nouveau,vesa unloaded: fbdev,modesetting failed: nv gpu: N/A resolution: 1920x1080 API: OpenGL v: 4.5 vendor: mesa v: 24.1.3 renderer: llvmpipe (LLVM 18.1.8 256 bits) Network: Device-1: Marvell Yukon Optima 88E8059 [PCIe Gigabit Ethernet with AVB] driver: sky2 Device-2: Linksys AE6000 802.11a/b/g/n/ac Wireless Adapter [MediaTek MT7610U] driver: mt76x0u type: USB Drives: Local Storage: total: 9.27 TiB used: 1.95 TiB (21.1%) Info: Memory: total: 16 GiB available: 15.6 GiB used: 1.35 GiB (8.6%) Processes: 266 Uptime: 0h 1m Shell: Bash inxi: 3.3.35 I also DL'd and burned openSUSE-Tumbleweed-DVD-x86_64-Snapshot20240829-Media.iso openSUSE-Tumbleweed-KDE-Live-x86_64-Snapshot20240829-Media.iso openSUSE-Tumbleweed-NET-x86_64-Snapshot20240829-Media.iso checksums all good, each burn verified no errors Every way I could try behaved essentially the same: after a brief command line run the HDMI symb olappears and after that nothing but a blank screen. If I select some degrading options 'like' F3 console 1920x1080 F5 kernekl safe setting or NOACPI F6 driver NO then I might get graphic sliders showing "Loading basic drivers..." etc and THAT folowed by a blank black screen One one run (I think it might have been on the installed system and not one of the DVD's) I got a last command line read something like "start plymouth....". Someone already accused plymouth of being THE real culprit. A questions I cannot resist: why try for a GUI *at all* for things like rescue net install check media boot linux system ????? It would be much smarter to promt the user to insert a blank USB stick at the beginning that will be formatted fat and unto which the entire startup will be written! In addition there should be a back button at every 'station' with screen shots saved out to the same place. My 2 cents. This whole horror-show has been going on since March of last spring!

On 8/31/24 7:55 PM, bent fender wrote:

Host: localhost.localdomain Kernel: 6.10.5-1-default arch: x86_64

Nvidia will NOT work without the patched driver.... 6.10.5-1-default ^^ Chroot and install kernel source (the kernel-devel rpm), then Just copy the files from the repo I gave a link to into the chroot into some temp directory, Then while chrooted, change to the temp directory with the 7 nvidia rpms and do: $ sudo rpm -Uvh --old-package *.rpm Let dracut do its thing, then Just reboot back into that system. Nvidia drivers should be ready to go. -- David C. Rankin, J.D.,P.E.

On 8/31/24 10:41 PM, Masaru Nomiya wrote:

Isn't it with the patched driver in it?

Not unless opensuse is hiding it's patched driver somewhere. There are no drivers patched for the 6.10 kernel available from opensuse: https://download.nvidia.com/opensuse/tumbleweed/x86_64/ That "official" repository is only patched through the 6.9 kernel. -- David C. Rankin, J.D.,P.E.

Hello, In the Message; Subject : Re: nvidia g05 or nouveau in TW Live/Install? Message-ID : <87h6b0hsqf.wl-nomiya@lake.dti.ne.jp> Date & Time: Sun, 01 Sep 2024 14:02:00 +0900 [MN] == Masaru Nomiya <nomiya@lake.dti.ne.jp> has written: [...] MN> Sorry, but I thought he had installed what you indicated. MN> You are right, he is talking about DVD-based. MN> If that's the case, then he is mistaken. MN> I mean, there is no G05 files on the DVD, but he says it is running on MN> G05. MN> The DVD is trying to run on nouveau. MN> Ben, please show the results of; MN> $ cat /var/log/Xorg.0.log | grep -B 8 LoadModule I'm going out now, so I'll write. Please try this; At the boot screen of DVD; 1. Press the e key to enter Edit Entry mode. 2. In the window that opens, add the following to the end of the third linux entry section from the bottom noaccel=1 3. Press F10 key. How about this? Best Regards. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "Japan was the future but it's stuck in the past" -- Rupert Wingfield-Hayes (BBC) --

Hello, I was able to return home unexpectedly early. In the Message; Subject : 50% BINGO Re: nvidia g05 or nouveau in TW Live/Install? Message-ID : <20240901063010.6ca248cf88a598d27a8d5485@trixtar.org> Date & Time: Sun, 1 Sep 2024 06:30:10 -0400 [BF] == bent fender <slowroller@trixtar.org> has written: BF> Sun, 01 Sep 2024 18:19:02 +0900 BF> Masaru Nomiya <nomiya@lake.dti.ne.jp> : [...] MN> > Please try this; MN> > At the boot screen of DVD; MN> > 1. Press the e key to enter Edit Entry mode. MN> > 2. In the window that opens, add the following to the end of the MN> > third linux entry section from the bottom MN> > noaccel=1 MN> > 3. Press F10 key. MN> > How about this? BF> Booting the install DVD BF> ======================= BF> Alone it produced no cigar; however BF> "3 noaccel=1 nomodeset" BF> got the installer up proper with a GUI. I havent done an install or an BF> upgrade with it though. After all, it's nouveau. nomodeset..? BF> Booting the hard drive installation BF> =================================== BF> same results as with just "3 nomodeset" or with a chroot. BF> Still cannot log-in if home folder is on a data partition BF> NOT mounted undedr /home but as data and linked to. In the case of nouveau, it is like this. modeset=0 <-- enable = modeset modeset=1 <-- disable = nomodeset Best Regards & Good Night. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "Distinguish between what is meaningful to me and what is meaningless, and forget what is meaningless to me. This is where individuality comes into play. This is a function that computer cannot perform." -- Shigehiko Toyama (in Japanes) --

bent fender composed on 2024-09-01 14:12 (UTC-0400):

Sun, 01 Sep 2024 19:56:43 +0900 Masaru Nomiya composed:

...

In the case of nouveau, it is like this.

...

modeset=0 <-- enable = modeset

...

modeset=1 <-- disable = nomodeset

1=yes=enable. 0=no=disable. KMS=Kernel Mode Setting if KMS=disabled, then graphics=crippled

those two don't seem to work, nomodeset does.

I must have misread something somewhere, I was under the impression that the nouveau driver gave everything the nviodia driver did but with less finesse, including acceleration. As it is I'm not getting 1920x1080 either, I'd like to get at least that resolution.

1024x768 is the usual limit when KMS is disabled by nouveau.modeset=0 or nomodeset or anything else intended to cripple graphics output. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

Hello, In the Message; Subject : Re: 50% BINGO Re: nvidia g05 or nouveau in TW Live/Install? Message-ID : <20240901141223.5ef05adb619a0ce3b9cc5141@trixtar.org> Date & Time: Sun, 1 Sep 2024 14:12:23 -0400 bent fender <slowroller@trixtar.org> has written: BF> Sun, 01 Sep 2024 19:56:43 +0900 BF> Masaru Nomiya <nomiya@lake.dti.ne.jp> : MN> > In the case of nouveau, it is like this. MN> > modeset=0 <-- enable = modeset MN> > MN> > modeset=1 <-- disable = nomodeset BF> those two don't seem to work, nomodeset does. Sorry, I made a mistake. Thanks, Felix. BF> I must have misread something somewhere, I was under the impression BF> that the nouveau driver gave everything the nviodia driver did but with BF> less finesse, including acceleration. As it is I'm not getting BF> 1920x1080 either, I'd like to get at least that resolution. I sent a mail with ” .....?” that I did not understand the meaning of the nomodeset parameter. The nomodeset parameter only means that the font size and resolution settings are not left to the video driver. However, in your email, nouveau offers a resolution of 1920x1080. In the Message; Subject : Re: nvidia g05 or nouveau in TW Live/Install? Message-ID : <20240831205523.9996dbf907b43c515281b2a3@trixtar.org> Date & Time: Sat, 31 Aug 2024 20:55:23 -0400 [BF] == bent fender <slowroller@trixtar.org> has written: [...] BF> Display: x11 server: X.Org v: 21.1.12 with: Xwayland v: 24.1.2 BF> driver: X: loaded: nouveau,vesa unloaded: fbdev,modesetting failed: nv BF> gpu: N/A resolution: 1920x1080 [...] In other words, in your case, it is wrong to use the nomodeset parameter. So why do you use it? Furthermore, you have disabled acceleration with noaccel=1, which is the only way to avoid your problem. --- ┏━━┓彡 Masaru Nomiya mail-to: m.nomiya+suse @ gmail.com ┃＼／彡 ┗━━┛ "In the Americas and Europe, excluding South Korea, smartphone addiction among youth is not as serious as alcoholism or drug addiction and is not of high concern." 　　 -- Chosun Online --

Hello, In the Message; Subject : Re: 50% BINGO Re: nvidia g05 or nouveau in TW Live/Install? Message-ID : <395c8484-7965-0920-3114-8f6bfd329bd6@earthlink.net> Date & Time: Sun, 1 Sep 2024 20:50:48 -0400 [FM] == Felix Miata <mrmazda@earthlink.net> has written: FM> Masaru Nomiya composed on 2024-09-02 09:31 (UTC+0900): MN> > The nomodeset parameter only means that the font size and resolution MN> > settings are not left to the video driver. FM> That included "only" makes the statement wrong. [...] You are right, but I used it to make it easier for him to understand. I'll leave the rest to you. Best Regards. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "Japan was the future but it's stuck in the past" -- Rupert Wingfield-Hayes (BBC) --

Hello, In the Message; Subject : Re: 50% BINGO Re: nvidia g05 or nouveau in TW Live/Install? Message-ID : <20240901214323.d27be278d245854580f4f166@trixtar.org> Date & Time: Sun, 1 Sep 2024 21:43:23 -0400 [BF] == bent fender <slowroller@trixtar.org> has written: BF> Mon, 02 Sep 2024 09:31:32 +0900 BF> Masaru Nomiya <nomiya@lake.dti.ne.jp> : [...] MNBF> > However, in your email, nouveau offers a resolution of 1920x1080. MN> > In the Message; MN> > Subject : Re: nvidia g05 or nouveau in TW Live/Install? MN> > Message-ID : <20240831205523.9996dbf907b43c515281b2a3@trixtar.org> MN> > Date & Time: Sat, 31 Aug 2024 20:55:23 -0400 MN> > [BF] == bent fender <slowroller@trixtar.org> has written: MN> > [...] MN> BF> Display: x11 server: X.Org v: 21.1.12 with: Xwayland v: 24.1.2 MN> BF> driver: X: loaded: nouveau,vesa unloaded: fbdev,modesetting failed: nv MN> BF> gpu: N/A resolution: 1920x1080 [...] BF> I meant I'd like to have 1920x1080 nouvea is offering, but you are cancelling with nomodeset parameter. [...] MN> > Furthermore, you have disabled acceleration with noaccel=1, which is MN> > the only way to avoid your problem. BF> YOU suggested THAt one I think :-)) Yes, I showed you how to use live DVD. BF> Based on suggestions by *others* there are three arguments that "my BF> highness" has added to the kernel line at present BF> 3 noaccel=1 nomodeset Three? I suggested noaccel=1, but who suggested 3 and nomodeset? I have no idea about 3. If you set nomodeset, nouveau module is not loaded, then no GUI. Try with noaccell=1 only. Best Regards. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "Microsoft is overhauling its cybersecurity strategy, called the Secure Future Initiative, to incorporate key security features into its core set of technology platforms and cloud services. " -- Microsoft overhauls cyber strategy to finally embrace security by default --

On 9/1/24 8:43 PM, bent fender wrote:

If I remove noaccel=1 then I do get the WM but no GUI after log-in, just a solirary mouse arrow jumping about in the darknes.

There is something amiss beyond your basic driver issue. I can only speculate. Is there any chance you have on-board video on your motherboard that could have gotten enabled by default when your AMD card was removed? (or some other oddness causing the video system to fight over who is in charge?)

If I remove nomodeset I get what removing 3 does.

With the above contorsions at least I get a GUI that I can use as long as I'm not the usual user and as long as I don't want internet.

That is the best SECURITY FEATURE -- no chance of malware from a remote host :) I'd take a trip though the bios settings just to make sure there isn't anything funny that got flipped. It also wouldn't hurt to post the output of: # dmidecode to https://paste.opensuse.org You can save the output to a file with: # dmidecode > /tmp/dmidecode.txt and then upload /tmp/dmidecode.txt Also you have sddm for the display manager, what desktops do you have installed? Just KDE? What plymouth rpms are installed: $ rpm -qa | grep plymouth | sort What does $ cat /proc/cmdline show? That will add some additional information to the mix. Also double check the modules: $ lsmod | grep "nvidia\|nouveau" We will go from there. -- David C. Rankin, J.D.,P.E.

Hello, In the Message; Subject : Re: 50% BINGO Re: nvidia g05 or nouveau in TW Live/Install? Message-ID : <20240902065635.7d33bf97f8f9bd8a6d2e3c78@trixtar.org> Date & Time: Mon, 2 Sep 2024 06:56:35 -0400 [BF] == bent fender <slowroller@trixtar.org> has written: [...] BF> I don't know how many times I've reset BIOS to defaults, I'll look at BF> these tonight. Just spent 2 hours trying to get the Live DVD going but BF> it seems to have a DVD read error although the cretaion included BF> verification at every step! The check-media module requires a BF> graphical screen for some reason but the screen just goes black. I BF> couldn't get the install DVD going either without ending up with a BF> corrupt screen. Ran out of time! 1. inset DVD to drive 2. run # dd if=/dev/sr0 of=/dev/null bs=1M count=1000 oflag=direct Does the execution of the dd command produce any errors? Best Regards & Good Night. --- ┏━━┓彡 Masaru Nomiya mail-to: m.nomiya+suse @ gmail.com ┃＼／彡 ┗━━┛ "In the Americas and Europe, excluding South Korea, smartphone addiction among youth is not as serious as alcoholism or drug addiction and is not of high concern." 　　 -- Chosun Online --

Hello, In the Message; Subject : Re: 50% BINGO Re: nvidia g05 or nouveau in TW Live/Install? Message-ID : <813249680.2851362.1725322290242@mail.yahoo.com> Date & Time: Tue, 3 Sep 2024 00:11:30 +0000 (UTC) [RW] == Robert Webb via openSUSE Users <users@lists.opensuse.org> has written: RW> On Mon, 02 Sep 2024 20:47:05 +0900, Masaru Nomiya <nomiya@lake.dti.ne.jp> wr[...] MN> >     1. inset DVD to drive MN> >     2. run MN> >       # dd if=/dev/sr0 of=/dev/null  bs=1M count=1000  oflag=direct MN> > Does the execution of the dd command produce any errors? RW> If there are possible disk errors, then a memory test is called RW> for, also. Good advice, but all I asked for was a DVD drive check. I think no RES is the reply. Best Regards. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "Japan was the future but it's stuck in the past" -- Rupert Wingfield-Hayes (BBC) --

Mon, 02 Sep 2024 20:47:05 +0900 Masaru Nomiya <nomiya@lake.dti.ne.jp> :

1. inset DVD to drive 2. run # dd if=/dev/sr0 of=/dev/null bs=1M count=1000 oflag=direct

I'll check out the Live DVD tomorrow but the headache is gone

Tue, 03 Sep 2024 12:49:25 +0900 Masaru Nomiya <nomiya@lake.dti.ne.jp> :

Hello,

In the Message;

Subject : RESOLVED {nvidia JUNKED} ...Re: 50% BINGO Re: nvidia g05 or nouveau in TW Live/Install? Message-ID : <20240902231721.b71b97b919e102831c00b216@trixtar.org> Date & Time: Mon, 2 Sep 2024 23:17:21 -0400

[BF] == bent fender <slowroller@trixtar.org> has written:

BF> Mon, 02 Sep 2024 20:47:05 +0900 BF> Masaru Nomiya <nomiya@lake.dti.ne.jp> :

MN> > 1. inset DVD to drive MN> > 2. run MN> > # dd if=/dev/sr0 of=/dev/null bs=1M count=1000 oflag=direct

BF> I'll check out the Live DVD tomorrow but the headache is gone

No, it's just for a DVD drive check.

Oh yeah? Well I've learned something again :-) # dd if=/dev/sr0 of=/dev/null bs=1M count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB, 1000 MiB) copied, 187.391 s, 5.6 MB/s It's a Samsung USB external; what do you expect when you travel with a big gun?

Even if it is not a GUI, media check can be done as follows;

1. # yast ( <-- NOT yast2)

2. Software -- > Media Check

Best Regards.

--- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "To hire for skills, firms will need to implement robust and intentional changes in their hiring practices ― and change is hard."

-- Employers don’t practice what they preach on skills-based hiring --

Hello, In the Message; Subject : DVD testing [WAS: Re: RESOLVED {nvidia JUNKED} ...Re: 50% BINGO Re: nvidia g05 or nouveau in TW Live/Install?] Message-ID : <c4e7f390-2778-4ade-8910-65c52f901fe1@telefonica.net> Date & Time: Tue, 3 Sep 2024 21:18:39 +0200 [CER] == "Carlos E. R." <robin.listas@telefonica.net> has written: [...] MN>>> No, it's just for a DVD drive check. BF>> Oh yeah? Well I've learned something again :-) CER> It just copies 1000MiB of the DVD to null. If there is a read CER> error, it will sa so. CER> You can copy the entire DVD to test it all, just remove the CER> "count" part. It's not a copy. Read the thread again to see what I'm letting him do. In addition, he didn't do another test. Best. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "Microsoft is overhauling its cybersecurity strategy, called the Secure Future Initiative, to incorporate key security features into its core set of technology platforms and cloud services. " -- Microsoft overhauls cyber strategy to finally embrace security by default --

Hello, In the Message; Subject : Re: DVD testing [WAS: Re: RESOLVED {nvidia JUNKED} ...Re: 50% BINGO Re: nvidia g05 or nouveau in TW Live/Install?] Message-ID : <d3ebddec-c9d4-4a04-9c63-f8a2ed37b6b7@telefonica.net> Date & Time: Wed, 4 Sep 2024 03:50:48 +0200 [CER] == "Carlos E. R." <robin.listas@telefonica.net> has written: [...] MN> > It's not a copy. MN> > Read the thread again to see what I'm letting him do. CER> I have been following the entire thread. CER> You are having him do a "dd" copy of the first gigabyte of the CER> DVD to null. That's done to test the DVD hardware and media. CER> dd if=/dev/sr0 of=/dev/null bs=1M count=1000 oflag=direct CER> You also asked to use yast in text mode to do an autocheck of CER> the installation media. A checksum test. Right. You would know that it's suspicious to talk about a live DVD when there is a read error. If he has an external DVD drive and /dev/sr0 means he doesn't have an internal DVD drive.... Best Regards. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "Maddox hopes that empowering users to pick their own algorithms will get them to think more about what’s involved in making them. " -- Bluesky's Custom Algorithms Could Be the Future of Social Media --

Hello, In the Message; Subject : Re: DVD testing [WAS: Re: RESOLVED {nvidia JUNKED} ...Re: 50% BINGO Re: nvidia g05 or nouveau in TW Live/Install?] Message-ID : <62e89131-275d-44fb-9bba-901b6caad79f@telefonica.net> Date & Time: Wed, 4 Sep 2024 13:09:10 +0200 [CER] == "Carlos E. R." <robin.listas@telefonica.net> has written: [...] MN> > If he has an external DVD drive and /dev/sr0 means he doesn't have an MN> > internal DVD drive.... CER> Huh? CER> In my case, I have an internal Blue Ray drive, and it is named sr0. cer@Telcontar:~> l /dev/dvd CER> lrwxrwxrwx 1 root root 3 Sep 4 12:46 /dev/dvd -> sr0 CER> cer@Telcontar:~> cer@Telcontar:~> l /dev/sr0 CER> brw-rw----+ 1 root cdrom 11, 0 Sep 4 12:46 /dev/sr0 CER> cer@Telcontar:~> It's same as mine, but Bens'; In the Message; Subject : Re: RESOLVED {nvidia JUNKED} ...Re: 50% BINGO Re: nvidia g05 or nouveau in TW Live/Install? Message-ID : <20240903143132.58a306e7d26818c86eafd387@trixtar.org> Date & Time: Tue, 3 Sep 2024 14:31:32 -0400 [BF] == bent fender <slowroller@trixtar.org> has written: [...] BF> Oh yeah? Well I've learned something again :-) BF> # dd if=/dev/sr0 of=/dev/null bs=1M count=1000 <---- Here!! BF> 1000+0 records in BF> 1000+0 records out BF> 1048576000 bytes (1.0 GB, 1000 MiB) copied, 187.391 s, 5.6 MB/s BF> It's a Samsung USB external; what do you expect when you travel with a BF> big gun? This means that there is no internal drive..... Best Regards & Good Night. --- ┏━━┓彡 Masaru Nomiya mail-to: m.nomiya+suse @ gmail.com ┃＼／彡 ┗━━┛ "In the Americas and Europe, excluding South Korea, smartphone addiction among youth is not as serious as alcoholism or drug addiction and is not of high concern." 　　 -- Chosun Online --

Wed, 04 Sep 2024 12:03:49 +0900 Masaru Nomiya <nomiya@lake.dti.ne.jp> :

Hello,

In the Message;

Subject : Re: DVD testing [WAS: Re: RESOLVED {nvidia JUNKED} ...Re: 50% BINGO Re: nvidia g05 or nouveau in TW Live/Install?] Message-ID : <d3ebddec-c9d4-4a04-9c63-f8a2ed37b6b7@telefonica.net> Date & Time: Wed, 4 Sep 2024 03:50:48 +0200

[CER] == "Carlos E. R." <robin.listas@telefonica.net> has written:

[...] MN> > It's not a copy. MN> > Read the thread again to see what I'm letting him do.

CER> I have been following the entire thread.

CER> You are having him do a "dd" copy of the first gigabyte of the CER> DVD to null. That's done to test the DVD hardware and media.

CER> dd if=/dev/sr0 of=/dev/null bs=1M count=1000 oflag=direct

CER> You also asked to use yast in text mode to do an autocheck of CER> the installation media. A checksum test.

Right.

You would know that it's suspicious to talk about a live DVD when there is a read error.

If he has an external DVD drive and /dev/sr0 means he doesn't have an internal DVD drive....

I'm a little confused about all this... - I had an issue with the Live TW dvd NB. dvd's get corrupted if a fly unloads on them so it's NOTHING unusual. If I haven't seen this a thousand times then I never have. I just take out the dvd and rub it on my T-shirt. Guru-level wisdom even says to rub it (now let no one 'go off' on any tangent here) linearly and not in more circular like patterns which leave scratches more likely to derail the read. - you suggested two tests to try - I did the dd one and the result was negative - I haven't done the other yet because I haven't had time NB. I will do that tonight and I have a hunch that all tests will prove negative because as I have suspected since the beginning my problem's roots are in the nvidia card/driver drawer and nowhere else, a dilemma that is now terminated as far as I'm concerned.

Best Regards.

--- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "Maddox hopes that empowering users to pick their own algorithms will get them to think more about what’s involved in making them. "

-- Bluesky's Custom Algorithms Could Be the Future of Social Media --

On 9/2/24 5:56 AM, bent fender wrote:

I don't know how many times I've reset BIOS to defaults, I'll look at these tonight. Just spent 2 hours trying to get the Live DVD going but it seems to have a DVD read error although the cretaion included verification at every step! The check-media module requires a graphical screen for some reason but the screen just goes black. I couldn't get the install DVD going either without ending up with a corrupt screen. Ran out of time!

I wish you luck, I've never had this much fun trying to get graphics going. Not even in the Mandrake days. (when you had to set the modelines for your CRT Monitor in xorg.conf that was based on the particular hsync- and hsyn+ and vsync values for your 500 lb monitor :) -- David C. Rankin, J.D.,P.E.

Sun, 1 Sep 2024 22:35:58 -0500 "David C. Rankin" <drankinatty@gmail.com> :

On 9/1/24 8:43 PM, bent fender wrote:

...

If I remove noaccel=1 then I do get the WM but no GUI after log-in, just a solirary mouse arrow jumping about in the darknes.

There is something amiss beyond your basic driver issue. I can only speculate. Is there any chance you have on-board video on your motherboard that could have gotten enabled by default when your AMD card was removed? (or some other oddness causing the video system to fight over who is in charge?)

...

If I remove nomodeset I get what removing 3 does.

With the above contorsions at least I get a GUI that I can use as long as I'm not the usual user and as long as I don't want internet.

That is the best SECURITY FEATURE -- no chance of malware from a remote host :)

I'd take a trip though the bios settings just to make sure there isn't anything funny that got flipped. It also wouldn't hurt to post the output of:

# dmidecode

to https://paste.opensuse.org

You can save the output to a file with:

# dmidecode > /tmp/dmidecode.txt

and then upload /tmp/dmidecode.txt

Also you have sddm for the display manager, what desktops do you have installed? Just KDE?

What plymouth rpms are installed:

$ rpm -qa | grep plymouth | sort

What does

$ cat /proc/cmdline

show?

That will add some additional information to the mix. Also double check the modules:

$ lsmod | grep "nvidia\|nouveau"

We will go from there.

-- David C. Rankin, J.D.,P.E.

*Thanks for all your help*, I had a decision to make and I made it. My son wanted to borrow my lawn-mower and truck to take it with so I said "WHY OF COURSE MY SON, BTW THAT OLD AMD GPU YOU PROMISSED ME...". Twenty minutes later I took out the nvidia and am now enjoying these nice pinkish whites that the AMD 5700 is spoiling me with. If you or any dev want the fanless gt640 just send me a postal address to ship it to and it's yours or his or hers. First come first served, I'll junk it in a week.

Sun, 1 Sep 2024 07:00:29 -0400 bent fender <slowroller@trixtar.org> :

Sun, 1 Sep 2024 06:30:10 -0400 bent fender <slowroller@trixtar.org> :

...

Sun, 01 Sep 2024 18:19:02 +0900 Masaru Nomiya <nomiya@lake.dti.ne.jp> :

...

Hello,

In the Message;

Subject : Re: nvidia g05 or nouveau in TW Live/Install? Message-ID : <87h6b0hsqf.wl-nomiya@lake.dti.ne.jp> Date & Time: Sun, 01 Sep 2024 14:02:00 +0900

[MN] == Masaru Nomiya <nomiya@lake.dti.ne.jp> has written:

[...] MN> Sorry, but I thought he had installed what you indicated.

MN> You are right, he is talking about DVD-based.

MN> If that's the case, then he is mistaken. MN> I mean, there is no G05 files on the DVD, but he says it is running on MN> G05.

MN> The DVD is trying to run on nouveau.

MN> Ben, please show the results of;

MN> $ cat /var/log/Xorg.0.log | grep -B 8 LoadModule

I'm going out now, so I'll write.

Please try this;

At the boot screen of DVD;

1. Press the e key to enter Edit Entry mode.

2. In the window that opens, add the following to the end of the third linux entry section from the bottom

noaccel=1

3. Press F10 key.

How about this?

Booting the install DVD ======================= Alone it produced no cigar; however

"3 noaccel=1 nomodeset"

got the installer up proper with a GUI. I havent done an install or an upgrade with it though.

Booting the hard drive installation =================================== same results as with just "3 nomodeset" or with a chroot. Still cannot log-in if home folder is on a data partition NOT mounted undedr /home but as data and linked to.

Forgot to append

on one of the HD boots as above there was a file

/run/initramfs/rdsosreport.txt

which I saved to "/" but I fear that was virtual / and not disk root :-(

So now I have kernel arguments "noaccel=1 nomodeset" Why is this preventing a GUI login? Once I log in as root I can call sddm and IT brings up the GUI, why do I have to call sddm? Another snag: no shutdown or restart, gotta do a hard reset.

On 9/1/24 9:14 AM, bent fender wrote:

Another snag: no shutdown or restart, gotta do a hard reset.

Patrick had another solution better than removing all the plymouth rpms:

I just disable plymouth on kernel boot line and shutdown/restart work fine.

That's another alternative. Pick your poison... -- David C. Rankin, J.D.,P.E.

Sun, 1 Sep 2024 22:14:18 -0400 Felix Miata <mrmazda@earthlink.net> :

bent fender composed on 2024-09-01 06:30 (UTC-0400):

...

Still cannot log-in if home folder is on a data partition NOT mounted undedr /home but as data and linked to.

This sounds like could be a disparity between UIDs/GIDs in /etc/passwd output,

Yes, it happens when the data drive doesn't get mounted for any reason. Then I usually mount it manually and all works as it should.

on /home/* without any filesystem mounted upon it, and those on the filesystem you wish mounted to /home/. Mount that filesystem somewhere other than /home/, then doing the following:

tail /etc/passwd (*)

Why tail, that lists only the last 10 lines, no?

ls -dn /home/ ls -n /home/ ls -n /mountpoint-of-data-filesystem/

Compare output of these to see if the username and groupnames correctly correlate among those outputs for each existing regular user that needs a GUI login to work.

* If relevant username/groupname do not appear in tail output, simply scan the file with any file viewer for the relevant username(s) and groupname(s) applicable for/to the needed comparison.

I'll have to be clearer paraphrasing my setup: - all users are members of group g (1999) - one data drive is mounted in fstab @ /data all users and group: rwx, others: r - some users' homes are under /home such as home/u0 - some users' homes are links like /home/ux pointing to /data/ux/Tw (in the case of Tumbleweed). In my Slackware system for example /home/ux points to /data/ux/sLk and so on - all those users that are actually me have links like /data/ux/0 pointing to /data/ux/zero hosting for example my Sylpheed folders so that it doesn't matter which distro I boot using which desktop my email always works in the same folder. There are other similira rigs for common dolphinrc and like configs. Some apps are conviviality-hogs and resist such efforts so they will soon get dumped, Mozila leading the way because Pan (like many others) is not problematic. Ubuntu's snap or whaaaateeevr was also a conviviality-hog and refused to allow this so Ubuntu-Studio also got dumped. The only difference that I see as being unusual is that the /home/ux link pointing to /data/ux/Tw belongs to ux and group g as opposed to the normal root and root. I don't know how this came about but it is sometimes hard to link /data/ux/Tw into /home/ux (I do all such tweaks in dolphin-super-u). My system has been working very well and still does with the other distros but has hit some new twist maybe related to the TW issues or to 'keyboard-confusion' :-)

-- Evolution as taught in public schools is, like religion, based on faith, not based on science.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Mon, 2 Sep 2024 00:19:32 -0400 Felix Miata <mrmazda@earthlink.net> :

bent fender composed on 2024-09-01 23:36 (UTC-0400):

...

Sun, 1 Sep 2024 22:14:18 -0400 Felix Miata composed:

...

...

bent fender composed on 2024-09-01 06:30 (UTC-0400):

...

...

...

Still cannot log-in if home folder is on a data partition NOT mounted undedr /home but as data and linked to.

...

...

This sounds like could be a disparity between UIDs/GIDs in /etc/passwd output,

...

Yes, it happens when the data drive doesn't get mounted for any reason. Then I usually mount it manually and all works as it should.

...

...

on /home/* without any filesystem mounted upon it, and those on the filesystem you wish mounted to /home/. Mount that filesystem somewhere other than /home/, then doing the following:

...

...

tail /etc/passwd (*)

...

Why tail, that lists only the last 10 lines, no?

If you have more than 10 users, capture the relevant data however else you please, like appending -25 to tail. Egrep them all by names if you want. Most systems don't have a whole lot of ordinary users, and most are usually in some portion of the file's tail.

The only reason I asked was in case there might be a syntax rule requiring other than any line order. I always manually move what I need to see first up front, such as groups in /etc/group & users in /etc/paswd

...

...

ls -dn /home/ ls -n /home/ ls -n /mountpoint-of-data-filesystem/

-n means long list owner and group by numerical values instead of customary strings produced by -l.

...

...

Compare output of these to see if the username and groupnames correctly correlate among those outputs for each existing regular user that needs a GUI login to work.

...

...

* If relevant username/groupname do not appear in tail output, simply scan the file with any file viewer for the relevant username(s) and groupname(s) applicable for/to the needed comparison.

...

I'll have to be clearer paraphrasing my setup:

...

- all users are members of group g (1999)

To be clear, my proposal was all about numbers, nothing to do with permissions. Now that we know all users are in same 1999 group, it cuts in half the amount of data needing evaluation. If you already know there are no conflicts caused by mismatches of numeric UIDs among files, directories and passwd files, then this is pointless. OTOH... -- Evolution as taught in public schools is, like religion, based on faith, not based on science.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

bent fender composed on 2024-09-02 23:03 (UTC-0400):

I had two unfounded suspicions about two possibilities one of which hit pay dirt minutes ago. Somewhere in all this struggle & strife I issued

# systemctl set-default multi-user.target

to be able to log in as root at least and then call SDDM. THAT's when logging in as UserMe died. I'm saying this because (on a hunch as I said) as soon as I reverted with

# systemctl set-default graphical.target

I could log-in again. Systemd suck like Electrolux if you ask me; of course it ain't my boat, my bridge or my watch :-)

So, your problem description was lacking. You couldn't login because nobody could login because there was no login manager auto-starting. Next time you want startup to end at multi-user.target, instead of reconfiguring the system, just append a 3 to Grub's linu line after striking E at the Grub menu. This way it only happens once, so there's nothing special that needs remembering. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

On 2024-09-02 05:36, bent fender wrote:

Sun, 1 Sep 2024 22:14:18 -0400 Felix Miata <> :

...

bent fender composed on 2024-09-01 06:30 (UTC-0400):

I'll have to be clearer paraphrasing my setup:

- all users are members of group g (1999)

- one data drive is mounted in fstab @ /data all users and group: rwx, others: r

- some users' homes are under /home such as home/u0

- some users' homes are links like /home/ux pointing to /data/ux/Tw (in the case of Tumbleweed). In my Slackware system for example /home/ux points to /data/ux/sLk and so on

- all those users that are actually me have links like /data/ux/0 pointing to /data/ux/zero hosting for example my Sylpheed folders so that it doesn't matter which distro I boot using which desktop my email always works in the same folder. There are other similira rigs for common dolphinrc and like configs. Some apps are conviviality-hogs and resist such efforts so they will soon get dumped, Mozila leading the way because Pan (like many others) is not problematic. Ubuntu's snap or whaaaateeevr was also a conviviality-hog and refused to allow this so Ubuntu-Studio also got dumped.

Instead of symlinks, you could have a different home listed in /etc/passwd: cer-k:x:1040:100:someone:/data/someone:/bin/bash However, it is generally not a good idea to have two distributions use the same home folder, because their configuration files could be different. It is better to use different folder, and symlink the data folders of applications. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)

bent fender composed on 2024-08-31 20:55 (UTC-0400):

...

$ inxi -b

I think I did this with a really-booted TW using kernel arguments 3 and nomodeset (as opposed to a chrooted one):

inxi -b produces minimal information useful in solving graphics issues, mixed with a lot of irrelevant data. In most graphics troubleshooting cases, best invocation from TW is: inxi -GSaz --vz The S brings in system info, the kernel cmdline in particular. --vz censors sensitive data that normally need not be shared in public, very helpful with C. The first z does more limited censoring. In Leap, --vs should also be added, to show the inxi version. Version matters because inxi capabilities have evolved over time, changing the meaning of various output, plus, bugs get corrected. And, inxi in Leap doesn't get upgraded but once in a blue moon, if that often. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

bent fender composed on 2024-09-01 06:55 (UTC-0400):

Sat, 31 Aug 2024 23:19:41 -0400 Felix Miata composed:

...

bent fender composed on 2024-08-31 20:55 (UTC-0400):

...

...

...

$ inxi -b

...

...

I think I did this with a really-booted TW using kernel arguments 3 and nomodeset (as opposed to a chrooted one):

...

inxi -b produces minimal information useful in solving graphics issues, mixed with a lot of irrelevant data. In most graphics troubleshooting cases, best invocation from TW is:

...

inxi -GSaz --vz

Error 22: Unsupported option: --vz Check -h for correct useage.

Dunno how that typo escaped. It was supposed to be: inxi -GSaz --za

inxi -GSaz --za System: Kernel: 5.14.21-150500.55.68-default arch: x86_64 bits: 64 compiler: gcc v: 7.5.0 clocksource: tsc avail: hpet,acpi_pm parameters: root=LABEL=<filter> ipv6.disable=1 net.ifnames=0 noresume consoleblank=0 preempt=full mitigations=auto vga=791 video=1440x900@60 Desktop: KDE v: 3.5.10 tk: Qt v: 3.3.8c wm: kwin with: kicker vt: 7 dm: 1: KDM 2: XDM Distro: openSUSE Leap 15.5 Graphics: Device-1: Intel HD Graphics 630 vendor: Gigabyte driver: i915 v: kernel arch: Gen-9.5 process: Intel 14nm built: 2016-20 ports: active: HDMI-A-2 empty: DP-1, DP-2, HDMI-A-1, HDMI-A-3 bus-ID: 00:02.0 chip-ID: 8086:5912 class-ID: 0300 Display: x11 server: X.Org v: 1.21.1.4 compositor: kwin driver: X: loaded: modesetting alternate: fbdev,intel,vesa dri: iris gpu: i915 display-ID: :0 screens: 1 Screen-1: 0 s-res: 1920x1200 s-dpi: 120 s-size: 406x254mm (15.98x10.00") s-diag: 479mm (18.85") Monitor-1: HDMI-A-2 mapped: HDMI-2 model: Samsung SMS24A850 serial: <filter> built: 2012 res: 1920x1200 hz: 60 dpi: 94 gamma: 1.2 size: 518x324mm (20.39x12.76") diag: 611mm (24.1") ratio: 16:10 modes: max: 1920x1200 min: 720x400 API: EGL v: 1.5 hw: drv: intel iris platforms: device: 0 drv: iris device: 1 drv: swrast gbm: drv: iris surfaceless: drv: iris x11: drv: iris inactive: wayland API: OpenGL v: 4.6 compat-v: 4.5 vendor: intel mesa v: 22.3.5 glx-v: 1.4 direct-render: yes renderer: Mesa Intel HD Graphics 630 (KBL GT2) device-ID: 8086:5912 memory: 30.08 GiB unified: yes inxi -Caz --za CPU: Info: model: Intel Core i3-7100T bits: 64 type: MT MCP arch: Kaby Lake gen: core 7 level: v3 note: check built: 2018 process: Intel 14nm family: 6 model-id: 0x9E (158) stepping: 9 microcode: 0xF8 Topology: cpus: 1x cores: 2 tpc: 2 threads: 4 smt: enabled cache: L1: 128 KiB desc: d-2x32 KiB; i-2x32 KiB L2: 512 KiB desc: 2x256 KiB L3: 3 MiB desc: 1x3 MiB Speed (MHz): avg: 2867 high: 3400 min/max: 800/3400 scaling: driver: intel_pstate governor: powersave cores: 1: 1524 2: 3147 3: 3400 4: 3400 bogomips: 27199 Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx Vulnerabilities: <filter>

Try with and without --za, and you'll see what <filter> can mean. Inxi by default formats to fit in 80 columns without wrapping. Your shared output's formatting is being corrupted by a local constraint to less than 80. You can avoid the wrap corruption by using -y, e.g.:

inxi -Daz --za -y 76 Drives: Local Storage: total: raw: 1.94 TiB usable: 1.03 TiB used: 804.26 GiB (75.9%) SMART Message: Unable to run smartctl. Root privileges required. ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: ZTC model: PCIEG3-128G size: 119.24 GiB block-size: physical: 512 B logical: 512 B speed: 31.6 Gb/s lanes: 4 tech: SSD serial: <filter> fw-rev: R0629A0 temp: 51.9 C scheme: MBR ID-2: /dev/sda maj-min: 8:0 vendor: Seagate model: ST1000NM0011 size: 931.51 GiB block-size: physical: 512 B logical: 512 B speed: 6.0 Gb/s tech: HDD rpm: 7202 serial: <filter> fw-rev: SN02 scheme: GPT ID-3: /dev/sdb maj-min: 8:16 vendor: Seagate model: ST1000DM003-1CH162 size: 931.51 GiB block-size: physical: 4096 B logical: 512 B speed: 6.0 Gb/s tech: HDD rpm: 7200 serial: <filter> fw-rev: CC49

-- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

On 2024-09-01 05:19, Felix Miata wrote:

bent fender composed on 2024-08-31 20:55 (UTC-0400):

...

...

$ inxi -b

...

I think I did this with a really-booted TW using kernel arguments 3 and nomodeset (as opposed to a chrooted one):

inxi -b produces minimal information useful in solving graphics issues, mixed with a lot of irrelevant data. In most graphics troubleshooting cases, best invocation from TW is:

inxi -GSaz --vz

cer@Telcontar:~> inxi -GSaz --vz --vs Error 22: Unsupported option: --vz Check -h for correct parameters. cer@Telcontar:~> (Leap 15.5)

The S brings in system info, the kernel cmdline in particular. --vz censors sensitive data that normally need not be shared in public, very helpful with C. The first z does more limited censoring.

In Leap, --vs should also be added, to show the inxi version. Version matters because inxi capabilities have evolved over time, changing the meaning of various output, plus, bugs get corrected. And, inxi in Leap doesn't get upgraded but once in a blue moon, if that often.

Telcontar:~ # inxi -vs Sensors: System Temperatures: cpu: 45.0 C mobo: 36.0 C gpu: amdgpu temp: 50.0 C Fan Speeds (RPM): fan-1: 1155 fan-2: 2941 fan-3: 0 fan-4: 834 fan-5: 843 fan-6: 848 gpu: amdgpu fan: 203 Telcontar:~ # Doesn't show the version, does it? Telcontar:~ # inxi --version inxi 3.3.23-00 (2022-10-31) Copyright (C) 2008-2022 Harald Hope aka h2 Forked from Infobash 3.02: Copyright (C) 2005-2007 Michiel de Boer aka locsmif. Using Perl version: 5.026001 Program Location: /usr/bin Website: https://github.com/smxi/inxi or https://smxi.org/ IRC: irc.oftc.net channel: #smxi Forums: https://techpatterns.com/forums/forum-33.html This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. (https://www.gnu.org/licenses/gpl.html) Telcontar:~ # Telcontar:~ # inxi --update Starting inxi self updater. Using tiny as downloader. Currently running inxi version number: 3.3.23 Current version patch number: 00 Current version release date: 2022-10-31 Updating inxi in /usr/bin using main branch as download source... Validating downloaded data... Successfully updated to main branch version: 3.3.31 New main branch version patch number: 00 New main branch version release date: 2023-11-02 To run the new version, just start inxi again. ---------------------------------------- Starting download of man page file now. Updating inxi.1 in /usr/share/man/man1 using main branch branch as download source Downloading man page file... Download successful. Validating downloaded man file data... Contents validated. Writing to man location... Writing successful. Compressing file... Download, install, and compression of man page successful. Check to make sure it works: man inxi Telcontar:~ # But still no go: Telcontar:~ # inxi --version inxi 3.3.31-00 (2023-11-02) Copyright (C) 2008-2023 Harald Hope aka h2 Forked from Infobash 3.02: Copyright (C) 2005-2007 Michiel de Boer aka locsmif. Using Perl version: 5.026001 Program Location: /usr/bin Website: https://codeberg.org/smxi/inxi or https://smxi.org/ IRC: irc.oftc.net channel: #smxi Forums: https://techpatterns.com/forums/forum-33.html This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. (https://www.gnu.org/licenses/gpl.html) Telcontar:~ # inxi -GSaz --vz --vs Error 22: Unsupported option: --vz Check -h for correct parameters. Telcontar:~ # -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)

On 8/27/24 9:34 PM, Masaru Nomiya wrote:

The solution is not to use TW snapshot with kernel 6.10.

Tha is, kernel 6.10 has a serious problem with nvidia video cards.

That's not really the case, I'm using the G04 drivers right now with TW and the 6.10 kernel: $ uname -r 6.10.5-1-default $ lsmod | grep nvidia nvidia_drm 65536 1 nvidia_modeset 1339392 5 nvidia_drm nvidia 19791872 204 nvidia_modeset ipmi_msghandler 94208 2 ipmi_devintf,nvidia video 73728 1 nvidia with $ rpm -qa | grep nvidia kernel-firmware-nvidia-20240809-1.1.noarch nvidia-computeG04-32bit-390.157-90.1.x86_64 nvidia-computeG04-390.157-90.1.x86_64 nvidia-gfxG04-kmp-default-390.157_k6.10.5_1-106.1.x86_64 nvidia-glG04-32bit-390.157-90.1.x86_64 nvidia-glG04-390.157-90.1.x86_64 x11-video-nvidiaG04-32bit-390.157-90.1.x86_64 x11-video-nvidiaG04-390.157-90.1.x86_64 from the: https://download.opensuse.org/repositories/home:/wkazubski:/G03/ repo (that has G03 and G04 drivers patched for 6.10) I branched and updated the source for G05 in this repo: https://download.opensuse.org/repositories/home:/drankinatty:/branches:/home... The only change to the driver is in the driver kernel/conftest.sh file where tests for unsafe_follow_pfn() were removed and replaced with test for follow_pfn() which simply required changing a corresponding #if defined() in the driver kernel/nvidia/os-mlock.c source. That's all I'm aware of. Those are more "run-of-the-mill" driver patch changes for the G03-G05 (340, 390 and 470) drivers on every kernel minor version update. Actually these changes are sort of mild compared with earlier kernel 6.x changes needed. It's more remarkable that the official NVidia repo for Tumbleweed hasn't been patched for 6.10 given the kernel was release the 2nd week of July. It will get there, it's just taking a while to do it. The kernel 6.10 patch for G03 - G04 can be grabbed from: https://build.opensuse.org/package/show/home%3Awkazubski%3AG03/nvidia-gfxG04 The G05 6.10 patch can be grabbed from: https://build.opensuse.org/package/show/home:drankinatty:branches:home:ligur... It easier just to install the kernel source (kernel-devel) and install the packages from the repos and let dracut trigger the module build. Or you can grab the 6.10 patch for the current rpm (I believe from the github.com/opensuse/ repo) directly. I haven't ever tried the --apply-patch route yet, but I suppose it does the same thing on the fly. -- David C. Rankin, J.D.,P.E.