Installation of NVIDIAG02 drivers on Leap 15.5

Acknowledgements

I appreciate the guidance provided by Bernhard M. Wiedemann on the structure and
contents of Leap, Tumbleweed and Slowroll kernels.

I also appreciate the package updates which wkazubki has developed for the original
kernel 5.4.14-1, without which this implementation would have been impossible.


Why do this ?

I am new to openSUSE, and unlike with other distros, I’ve experienced no problems with
the Leap nouveau drivers which are normally installed on this type of machine. As a
precaution against possible (if unlikely) future difficulties, I’ve proceeded with this
alternative.


PROCEDURE

On my HP Pavilion Media Center m8247cPC test machine, which has a x86_64-v1 processor,
I downloaded and installed the openSUSE-Leap-15.5-NET-x86_64.iso

NB - This procedure does not work for xorg-x11-server versions > 1.19.n

The ABI number for the NVIDIAG02 driver is 23.0. The ABI number for the
standard Leap15.5 xorg server is 24.0. The Leap15.0 xorg server ABI number
is the required match of 23.0.

Accordingly, the relevant Leap15.0 graphics modules were downloaded and collected
in a Leap15.0Graphics directory:

xf86-input-evdev-2.10.5-lp150.1.10.x86_64.rpm
xf86-input-joystick-1.6.3-lp150.1.8.x86_64.rpm
xf86-input-keyboard-1.9.0-lp150.1.8.x86_64.rpm
xf86-input-libinput-0.27.1-lp150.1.1.x86_64.rpm
xf86-input-vmmouse-13.1.0-lp150.1.7.x86_64.rpm
xf86-input-void-1.4.1-lp150.1.7.x86_64.rpm
xf86-input-wacom-0.34.2-lp150.1.10.x86_64.rpm
xf86-video-fbdev-0.4.4-lp150.1.7.x86_64.rpm
xf86-video-nouveau-1.0.15-lp150.1.9.x86_64.rpm
xf86-video-vesa-2.4.0-lp150.1.1.x86_64.rpm
xorg-x11-driver-video-7.6_1-lp150.2.5.x86_64.rpm
xorg-x11-server-1.19.6-lp150.6.1.x86_64.rpm

The graphics downgrade was implemented from the Leap15.0Graphics
directory with the command,
sudo zypper install --solver-focus update --oldpackage ./*.rpm

NB: This graphics downgrade does not affect the functioning of Leap15.5
under the standard 5.14.21-150500 kernel, so there is no time pressure to
proceed beyond this point.


Install 5.4.14-1 kernel

The required components were collected in a
directory simply name Kernel-5.4.14-1:

kernel-default-5.4.14-1.1.gfc4ea7a.x86_64.rpm
kernel-default-devel-5.4.14-1.1.gfc4ea7a.x86_64.rpm
kernel-devel-5.4.14-1.1.gfc4ea7a.noarch.rpm
kernel-syms-5.4.14-2.26.x86_64.rpm
util-linux-2.36.2-2.29.x86_64.rpm
util-linux-lang-2.36.2-2.29.noarch.rpm
util-linux-systemd-2.36.2-2.1.x86_64.rpm

The kernel installation was implemented from this directory
with the command
sudo zypper install --solver-focus update --oldpackage ./*.rpm

The installation process was characterized by several warning messages:

-several instances of unverifiable security keys: entered i to ignore each one.
-missing dependencies for the kernel-syms package; entered option 2 to ignore
them and proceed with the installation. This problem was caused because
the kernel-syms version number was not an exact match to the other kernel
packages. It was used because it was the only one available.

A reboot was recommended at this point.

After the reboot, both resident kernels were functional with nouveau drivers, so
there was no time pressure to proceed further.


All future work is under the 5.4.14-1 kernel.

Preparation for NVIDIAG02 installation:

In /etc/X11, there is no standard xorg.conf file, so driver
installation depends on the 3 packages in /etc/X11/xorg.conf.d:
50-device.conf, 50-screen.conf, and 50-monitor.conf. Those
files after a standard Leap-15.5 installation are merely samples
with no active statements. NVIDIAG02 installation requires
the following edited copies:

50-device.conf

# Having multiple "Device" sections is known to be problematic. Make
# sure you don't have in use another one laying around e.g. in another
# xorg.conf.d file or even a generic xorg.conf file. More details can
# be found in https://bugs.freedesktop.org/show_bug.cgi?id=32430.
#
Section "Device"
  Identifier "Device0"
#
#  #Driver "radeon"
    Driver "nvidia"
#
#  ## Required magic for radeon/radeonhd drivers; output name
#  ## (here: "DVI-0") can be figured out via 'xrandr -q'
#  #Option "monitor-DVI-0" "Default Monitor"
#
EndSection

50-screen.conf

# Having multiple "Screen" sections is known to be problematic. Make
# sure you don't have in use another one laying around e.g. in another
# xorg.conf.d file or even a generic xorg.conf file. More details can
# be found in https://bugs.freedesktop.org/show_bug.cgi?id=32430.
#
Section "Screen"
  Identifier "Screen0"
#
  Device "Device0"
#
#  ## Doesn't help for radeon/radeonhd drivers; use magic in
#  ## 50-device.conf instead
  Monitor "Monitor0"
#
EndSection

50-monitor.conf

# Having multiple "Monitor" sections is known to be problematic. Make
# sure you don't have in use another one laying around e.g. in another
# xorg.conf.d file or even a generic xorg.conf file. More details can
# be found in https://bugs.freedesktop.org/show_bug.cgi?id=32430.
#
Section "Monitor"
  Identifier "Monitor0"
#
#  ## If your monitor doesn't support DDC you may override the
#  ## defaults here
      HorizSync   28.0 -33.0
      VertRefresh 43.0 - 72.0
#     Option "DPMS"
#
#  ## Add your mode lines here, use e.g the cvt tool
#
EndSection

NVIDIAG02 Installation

The required components were collected in
a directory name NVIDIAG02:

nvidia-computeG02-304.137-lp155.1.1.x86_64.rpm
nvidia-gfxG02-kmp-default-304.137_k5.4.14_lp155.2-lp155.37.1.x86_64.rpm
x11-video-nvidiaG02-304.137-lp155.1.1.x86_64.rpm

The driver was implemented from this directory with the command
sudo zypper install --solver-focus update --oldpackage ./*.rpm

Again, the installation process was characterized by several warning messages:

-several instances of unverifiable security keys: entered i to ignore each one.
-a missing dependency, “nothing provides ‘ksym(default: PDE_DATA) = fe34717c’
As there was no suitable package available, selected the option to carry on.

Immediately after this install, the /etc/modprobe.d directory should be examined to
verify the presence of the nvidia-default.conf file containing the single statement,
blacklist nouveau. If it’s not there, it should be manually entered.


After reboot, selection of Kernel 5.4.14-1 should result in normal graphics in effect.
The inxi -Gxx command should give the following results:

Graphics:
  Device-1: NVIDIA C61 [GeForce 6150SE nForce 430] vendor: Hewlett-Packard
    driver: nvidia v: 304.137 arch: Curie bus-ID: 00:0d.0 chip-ID: 10de:03d0
  Device-2: Logitech type: USB driver: uvcvideo bus-ID: 1-1.2:4
    chip-ID: 046d:080c
  Display: x11 server: X.Org v: 1.19.6 driver: N/A display-ID: :0 screens: 1
  Screen-1: 0 s-res: 1680x1050 s-dpi: 90
  Monitor-1: VGA-0 res: 1680x1050 dpi: 90 diag: 558mm (21.97")
  API: OpenGL v: 2.1.2 NVIDIA 304.137 renderer: GeForce 6150SE nForce
    430/integrated/SSE2 direct render: Yes

Booting under the original Kernel 5.14-21-150500 will no longer work because
the nvidia library is not present.

Len E.

I’ve discovered that in the installation procedure described, I missed using some of
wkazubki’s latest kernel 5.4.14-1 updates.

I have a HP Compaq Presario pc with the same graphics card as the HP Pavilion
Media Center m8247c. It also has a x86_64-v1 processor. I installed a fresh copy
of the openSUSE-Leap-15.5-Net-x86_64.iso on it for a retest.


The only change in the retest was a directory containing the up-to-date kernel modules.
The contents were a follows:

kernel-default-5.4.14-lp155.2.1.x86_64.rpm
kernel-default-devel-5.4.14-lp155.2.1.x86_64.rpm
kernel-devel-5.4.14-lp155.2.1.noarch.rpm
kernel-syms-5.4.14-lp155.2.1.x86_64.rpm
util-linux-2.36.2-2.29.x86_64.rpm
util-linux-lang-2.36.2-2.29.noarch.rpm
util-linux-systemd-2.36.2-2.1.x86_64.rpm

The exact same steps in the retest were taken, as previously described.

The only warning messages encountered were about the unverifiable security keys.
The other warnings had disappeared.


On the final reboot, the initial screen was at a very low resolution.
The HorizSync and VertRefresh specifications in the 50-monitor.conf file
had been optimized for the large screen on the HP Media Center.

It was sufficient to simply comment them out to achieve a normal-looking screen
on the 17“ monitor on the HP Compaq Presario.

Len E.

Some of the packages shown in the directory listings are found in non-standard locations on the openSUSE website.

The following description specifies where they are located.


-In Wojciech Kazubski’s home directory,
https://download.opensuse.org/repositories/home:/wkazubksi:/

G02/15.5/x86_64

nvidia-gfxG02-kmp-default-304.137_k5.4.14_lp155.2-lp155.39.1.x86_64.rpm

kernel-lts/15.5/x86_64

kernel-syms-5.4.14-lp155.2.1.x86_64.rpm
kernel-default-devel-5.4.14-lp155.2.1.x86_64.rpm
kernel-default-5.4.14-lp155.2.1.x86_64.rpm

kernel-lts/15.5/noarch

kernel-devel-5.4.14-lp155.2.1.noarch.rpm


https://software.opensuse.org/package/

x11-video-nvidiaG02 → openSUSE Leap 15.5 → show community packages → home:wkazubski → expert download → grab binary packages directly (15.5) →
x11-video-nvidiaG02-304.137-lp155.30.1.x86_64.rpm

nvidia-computeG02 → openSUSE Leap 15.5 → show community packages →
home:wkazubski → expert downloads → grab binary packages directly (15.5) →
nvidia-computeG02-304.137-lp155.30.1.x86_64.rpm


Len E.

It is honorful that you try and experiment with such stuff. Many newcomers are overwhelmed by simple issues like a package conflict. You took some time to develop a working procedure.

But there needs to be a strong warning with this procedure you present here. You heavily decreased the security of your system and are vulnerable now. You downgraded xorg-x11-server to an over 5 years old, unmaintained version with countless unfixed security issues. The same applys for the Nvidia v304 driver and is even worse as it is EOL since 7 years, and does no longer recieve any security fixes.

So you ripped some really big holes into the security of your box without need. You would be much better by using the nouveau drivers on an up to date Leap box.

Hi Hui:

I appreciate your commentary on security issues, and I hope you can update my
understanding on such matters.

My computer programming experience with mainframe Cobol and Fortran languages and assembler language on IBM 1401 machines is ancient history, so I’m anything but an authority on Linux coding. So there’s some issues surrounding security that I don’t understand.

I’ve always had the perception that the higher the level that software functions in an operating system, the more prone it is to security compromises.
Device drivers, for graphics cards and other hardware are very low-level and very specific to the hardware they operate. To my knowledge, drivers are only changed when the hardware they operate changes. They aren’t changed for security purposes. The Nvidia v304 drivers are unchanged, and don’t need to change over time because they are only relevant/useful on the original hardware they were created for.

The Linux kernel is another matter, functioning at a higher level in the operating system and supremely complex in comparison to device drivers. Takashi had similar precautionary statements to yours when I was considering use of the original 5.4.14 kernel, so it was a huge relief when Wojcieh came out with an
up-to-date version.


On the other Linux distros I’ve worked with, the nouveau drivers have been sporadically unreliable, so I’ve continually downgrade to Nvidia v304 drivers with no problems.
What undoubtedly helps is that my home network of 5 computers and 4 printers is entirely cable-driven, no WIFI.


For your consideration …
Len E.

Completely wrong. Have a look at the security bulletins. Drivers contain CVEs with high severity.
https://nvidia.custhelp.com/app/answers/detail/a_id/5586
https://nvidia.custhelp.com/app/answers/detail/a_id/5557
https://nvidia.custhelp.com/app/answers/detail/a_id/5551
https://nvidia.custhelp.com/app/answers/detail/a_id/5520
https://nvidia.custhelp.com/app/answers/detail/a_id/5491

Each new minor version update of the driver is also a security update. Over the support lifetime of a graphic card, the driver recives many, many updates. Function updates, security updates and more.

The same applies for AMD or any other driver.

Hi Hui:

The CVE information you provided was certainly an eye-opener !!

It means I’ve been incredibly lucky in avoiding problems in using
xorg-x11-server -1.19.n for the last 6 years, ever since I came across
the procedure description in a post by a ubuntu expert, enigma9o7
in July, 2018 entitled “nvidia-304 won’t install”.


Fortunately, because of experience with previous test failures, I’ve learned how to back out of the current installation to a safe situation:

With kernel-5.4.14-1 in effect:
-remove x11-video-nvidiaG02-304.137 package
-rename the 50-device.conf, 50-monitor.conf, 50-screen.conf files to
50-device.nopconf, 50-monitor.nopconf, 50-screen.nopconf respectively
-ensure that the only blacklist file in /etc/modprobe.d is disable-nvidia.conf
containing the single statement blacklist nvidia
-upgrade xorg-x11-server-1.19.6 to the current Leap 15.5 level, which will
upgrade all the dependent input and video packages as well

Reboot into either of the 2 resident kernels should be normal, with the nouveau driver in effect.


Thank you for your safety-oriented advice !

Len E.

Hi Hui:

I’ve just stumbled onto the fact that NVIDIA’s 340.108 GPU Display Driver
only supports kernels up to 5.4. This means that users with graphics cards requiring NVIDIAG03 drivers have been out of luck also for Leap 15.5.


Wojciech’s fresh 5.4.14-1 kernel could be the answer to their problems also. He has thoughtfully included i740fb.ko (as shown in the modules.order file) in the kernel for users with very old Intel graphics cards. If he could add nvidiafb.ko to the kernel also, this could work in lieu of NVIDIAG02 and NVIDIAG03 drivers.


I understand that for the integrity of Leap now and going forward, fully-supported drivers are mandatory. But rather than slamming the door on users of old equipment as Red Hat has done, Wojciech’s kernel modified as just described could be an option for old-equipment users like myself who are prepared to take their lumps if necessary with old, deprecated drivers.


I comment with some confidence about nvidiafb, because I’ve just gone through an exercise with antiX-23 where the the latest version wouldn’t install on my old equipment but the initial antiX-23 version did so without issue. The answer was that the initial version, with kernel-5.10.188 which had nvidia.ko included, installed with nvidiafb as the preferred driver, whereas the latest version with nouveau as the preferred driver would not install.

I downgraded the latest version kernel to 5.10.188, and it worked fine.


I really hope that this suggestion merits some serious consideration.

Len E.

A heads-up:

Wojciech has completed some magnificent work in the last 48 hours !

In his home directory:

-under drivers → v02 → 15.5 → x86_64 there is:

nvidia-computeG02-304.137-lp155.50.1.x86_64.rpm
2024-12-17, 2:44:44 p.m.
11.9 MB
nvidia-gfxG02-kmp-default-304.137_k5.14.21_150500.53-lp155.52.1.x86_64.rpm
2024-12-18, 3:54:23 p.m.
3.4 MB
x11-video-nvidiaG02-304.137-lp155.50.1.x86_64.rpm

-under drivers -->v02 → 15.6 → x86_64 there is:

nvidia-computeG02-304.137-lp156.50.1.x86_64.rpm
2024-12-17, 2:44:51 p.m.
11.9 MB
nvidia-gfxG02-kmp-default-304.137_k6.4.0_150600.21-lp156.52.1.x86_64.rpm
2024-12-18, 3:54:55 p.m.
3.4 MB
x11-video-nvidiaG02-304.137-lp156.50.1.x86_64.rpm


These packages eliminate the need for the 5.4.14-1 kernel in the installation procedure.

Similar packages for nvidia-340.108 graphics users are in the drivers → v03 directory.

To be continued …

Len E.

I’ve completed some tests with Wojciech’s latest NGIDIGAG02 drivers.
The cause of the failures of both initial tests of the Leap 15.5 and Leap 15.6 versions was that I installed NET versions of both Leap 15.5 and Leap 15.6 iso’s respectively.


IT IS IMPERATIVE for success that the kernel used for building the
nvidia-gfxG02-kmp-default package is the same as the active kernel on
the installed .iso.
Although Wojciech’s builds of those packages are only 3 days old, the kernels in effect on the NET-installed iso’s are already newer than the kernels he used and therefore NOT the same:

On Leap 15.5, the kernel he used was 5.14.21_150500.53,
the latest is 5.14.21_150500.55.88

On Leap 15.6, the kernel he used was 6.4.0_150600.21,
the latest is 6.4.0_150600.23.30


For the retest of Leap 15.5, after downgrading to Leap15.0Graphics, the required kernel modules were downloaded and assembled in a directory:

kernel-default-5.14.21-150500.53.2.x86_64.rpm
kernel-default-devel-5.14.21-150500.53.2.x86_64.rpm
kernel-devel-5.14.21-150500.53.2.noarch.rpm

The kernel was downgraded with the command,
sudo zypper install --solver-focus update --oldpackage ./k*.rpm

After rebooting and selecting this kernel, the result was the same as in both initial tests: no graphics, a command-line login prompt instead.

I proceeded anyway with the editing of the 50-device.conf, 50-screen.conf and 50-monitor.conf files, and installed the 3 driver packages.

On reboot, still no graphics and a command-line login prompt.
I entered the sudo startx command, and the graphics came up o.k. albeit with the root user in effect.

The inxi -Gxx command output is as follows:

Graphics:
  Device-1: NVIDIA C61 [GeForce 6150SE nForce 430] vendor: Hewlett-Packard
    driver: nvidia v: 304.137 arch: Curie bus-ID: 00:0d.0 chip-ID: 10de:03d0
  Display: server: X.org v: 1.19.6 driver: N/A display-ID: :0 screens: 1
  Screen-1: 0 s-res: 1280x1024
  Monitor-1: VGA-0 res: 1280x1024 dpi: 106 diag: 383mm (15.07")
  API: OpenGL v: 2.1.2 NVIDIA 304.137 renderer: GeForce 6150SE nForce
    430/integrated/SSE2 direct render: Yes
ljarvis@cDeb12:~$ 

I’ll retest the Leap 15.6 version in the same manner and see what happens.

Len E.

I proceeded with the retest on Leap 15.6 without success.

I followed the same procedure as with Leap 15.5, but could not
get past the resultant blank screen at the end of the procedure.

Hopefully, some improvements will materialize in the New Year.


Merry Christmas to all, and especially to Wojciech !!

Len E.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.