Tag Archives: Opensuse Upgrade

Opensuse Leap 15.4 on a PC – I – Upgrade from Leap 15.3 – repositories, Nvidia, Vmware WS, KVM, Plasma widget deficits

Posted on by

Today I upgraded a desktop PC with an Nvidia graphics card from Opensuse Leap 15.3 to Leap 15.4. I really must say: This was one of the smoothest upgrades I have ever experienced with Opensuse. However, there were again a few standard problems which had to be solved.

In this first post I summarize the upgrade steps and check the basic functionality of KDE/Plasma, VMware Workstation and KVM. I will also comment on some deficits of Plasma widgets for system monitoring.

In a second posts I summarize a brief test of Xwayland. A third post will discuss how to define a screen order for situations where multiple screens are attached to your PC. A brief fourth post will discuss PHP8 and Apache2 settings. We will also check that Eclipse works for PHP and Python/PyDeV. I will also verify the functionality of Python3 (3.9/3.10), Tensorflow2 and Jupyter after the upgrade. A last post provides solutions for multi-soundcard setups with Pulseaudio and pavucontrol.

PC components – and major SW

My PC has two major raid-systems – one with multiple SSDs (at an Intel controller, set up and controlled with the help of Linux mdraid) and one with HDs (3ware controller). The raid systems host LVM volumes and ordinary partitions. The graphics card is a relatively old Nvidia card. Two sound cards (X-Fi, Xonar D2X) are used in parallel. My standard desktop is KDE/Plasma scaled over 3 screens. For virtualization of Windows 10 VMware WS 16 is used. Virtualized Linux systems, however, run on KVM/qemu with virtual spice screens. PHP development is done with the help of Eclipse and a local Apache server. Machine Learning development is done with Python3 (3.9), PyDEV (Eclipse), Tensorflow2/Keras, Juypter.

Upgrade procedure

Regarding the basic upgrade procedure you can adapt steps which I have extensively described for a laptop here. You can just ignore any steps regarding an Optimus based combination of graphics cards.

List of steps

  • Step 1:Make backups! Especially of the LVM volumes or partitions which host your root filesystem and your /home-directory.
  • Step 2: Check your repositories! Save a list of your active ones and their URLs. Reason: Some repository paths below “download.opensuse.org” have changed and you need to include these repos again into zypper. Below I give some information on repositories which directly can be upgraded with the help of ${releasever}.
  • Step 3: Update your current RPMs.
  • Step 4: In a terminal window: 
    mytux:~ # zypper refresh
mytux:~ # zypper update

    Then restart your system and verify that it is working.

  • Step 5: In a terminal window change repo URLs to include ${releasever} 
    mytux:~ # sed -i 's/15.3/${releasever}/g' /etc/zypp/repos.d/*.repo
mytux:~ # sed -i 's/$releasever/${releasever}/g' /etc/zypp/repos.d/*.repo
  • Step 6: In a terminal window test a refesh for the Leap 15.4 repos: 
    mytux:~ # zypper --releasever=15.4 refresh

    If there are problems analyze the reason and eliminate those repositories whose URL have changed. Re-check the success of the refresh.

  • Step 7: In a terminal window download the new RPMs 
    mytux:~ #  zypper --releasever=15.4 dup --download-only --allow-vendor-change
  • Step 8: Close the graphical desktop and switch to a TTY (Ctrl-Alt-F1). Stop the display server and then upgrade 
    mytux:~ # init 3 
mytux:~ # zypper --no-refresh --releasever=15.4 dup --allow-vendor-change
  • Step 9: Pray and reboot to your upgraded Opensuse Leap 15.4

With selected repositories discussed below all these steps could be performed without major problems.

My good news are: There were no problems regarding drivers for the Nvidia card (see below), the raid controllers and my multiple Raid 5 and Raid 10 setups with LVM groups and LVM volumes. No problem was seen regarding Grub2 and systemd.

Which repositories can be directly upgraded via ${releasever}?

Central repositories for the upgrade are 

https://download.opensuse.org/update/leap/15.4/oss/
http://download.opensuse.org/update/leap/15.4/backports/
http://download.opensuse.org/update/leap/15.4/sle/

Their 15.3 precedessors must be active. You need to refresh them and replace the “15.3” in their addresses by “${releasever}”. See my post named above for the required steps. Aside of the central repositories I kept some others active during the upgrade process (with ${releasever}). Worth to name:

https://download.opensuse.org/repositories/LibreOffice:/7.5/openSUSE_Leap_15.4/
https://download.nvidia.com/opensuse/leap/15.4
https://developer.download.nvidia.com/compute/cuda/repos/opensuse15/x86_64
https://ftp.fau.de/packman/suse/openSUSE_Leap_15.4/
https://download.opensuse.org/repositories/mozilla/openSUSE_Leap_15.4/
https://download.opensuse.org/repositories/devel:/languages:/php/openSUSE_Leap_15.4/

These repositories cause no problems as their URLs for 15.3 and 15.4 only show a difference regarding their release version but not their position in the URL-tree below “download.opensuse.org”. However, some other repositories, like those for X2GO, graphics, network, security have changed their position in the URL-resource-tree and must be reconfigured after the upgrade – e.g with the help of YaST or zypper.

Nvidia driver and the new kernel

On Leap 15.3 I had used the latest Nvidia driver from the usual Nvidia community repository 

download.nvidia.com/opensuse/leap/${releasever}

The active RPM was replaced by the one from the Leap 15.4 repo during upgrade resulting in the RPM “nvidia-compute-G06”, version 525.89.02-lp154.5.1. Both the transition to the respective Nvidia kernel module for the new kernel 5.14.21 and the module’s inclusion in the system’s startup procedures by dracut went without any faults.

The upgraded system directly started into a SDDM login screen. There as a mess regarding my screen order (see a forthcoming post), but this did not hinder a proper login. Afterward KDE/Plasma (in combination with Xorg) started on the three screens attached to my PC. Though I feel that the startup of KDE/Plasma for Xorg takes a more time than on Leap 15.3. But I could see no major problems. GLX applications were running as expected.

VMware Workstation WS 16.2.5 works!

As I already saw with a Leap 15.4 installation on a laptop: VMware WS 16.2.5 works with Leap 15.4 and Kernel 5.14.21. Actually, already version WS 16.2.3 is compatible.

KVM/Qemu works with installed virtual systems!

The transition of KV, qemu und libvitrtd went smoothly. virt-manager works and starts installed virtual systems as expected:

KDE – plasma-systemmonitor and respective widgets do not show information on Nvidia graphics card and not all information on network cards

At least on my system with KDE Plasma 5.24.4 (KDE Framework 5.90) I saw major deficits regarding apps and widgets which should monitor the status of system resources:

  • Problem 1 – no information about the status of the Nvidia GPU: Neither the application “systemmonitor” nor related widgets can deliver information about the status of the NVidia card (temperature, VRAM usage, fan) – with the (useless) exception of the type of the card. See th eimage in the next section. (Note that lm_sensors do not help in this case as the HW sensors did not detect the Nvidia card either.)
  • Problem 2 – no information about virtual network devices: In addition the KDE/Plasma widgets were not able to display all data for network interfaces correctly. E.g. interfaces like lo, bridges and other virtual devices were not even listed. And thus on a more complex configuration with virtualization you will not see your IP addresses with the Plasma-tools.

Regarding the second point: The image below shows that the dialog to set up network monitoring only offers to select an active physical device, in my case eth1. But no virtual devices which are available, too.

And here the devices nmon lists up:

These are clearly Plasma problems as other basic Linux and desktop applications perform much better for the named resources. Someone who works with Machine Learning and with virtualized Linux installations needs to watch the GPU (fans and temperature) and traffic across network devices – virtualized or real. This does not seem to be something we can get from fancy KDE/Plasma widgets today. So, we have to look out for alternatives.

Alternatives to watch the temperature of Nvidia GPUs

One prominent example which covers more than the present KDE widgets for system monitoring is the good old “gkrellm“. I love it, really! Compact, with a lot of already integrated default “sensors” and compatible to lm_sensors! And it delivers me the GPU temperature.

Another desktop tool with a somewhat old fashioned presentation of graphics is psensor. You can get a binary for Leap 15.4 from the “home”-repository of plasmaaregataos.

https://download.opensuse.org/repositories/home:/plasmaregataos/15.4/

Interesting, how much this tool finds out about the Nvidia card (where Plasma tools fail totally).

And then we have, of course, Nvidia’s own tools: nvidia-settings (graphical) and nvidia-smi (ASCII):

Note that the command to periodically update the nvidia-smi information is:

watch -n0.1 nvidia-smi

Alternatives to watch the data traffic across all network devices – real and virtual

Once again I have to name gkrellm. It provides a lot of information on real and virtual network interface.

Regarding a graphical information on virtual network interfaces we can also use a relatively old KDE tool, namely ksysguard. Besides real network interfaces it detects bridges and KVM or Vmware based virtual devices and tracks their load.

Hint for those who worry about the discrepancy with the screenshot for nmon above: Some devices which nmon showed were not available at the time of the screenshot of ksysguard as certain KVM virtual machines and networks were not yet started. Later ksysguard detects other devices, too:

Based on ncurses you can also use the network part of “nmon” to get information on transfer rates across all defined network interfaces. If you need to go more into details a very good ASCII tool is “iptraf-ng“. “iftop” is also cool, but to watch multiple interfaces in parallel you have to use the command “iftop -i” on multiple terminal windows.

So, dear Plasma developers: When can we expect a fancy Plasma applications or widgets which reproduce and combine the “sensoric” abilities of gkrellm, psensor, ksysguard and iptraf-ng?

Conclusion

The upgrade from Leap 15.3 to Leap 15.4 posed no major problems on my PC. A relatively old VMware WS 16.2.x still worked and there were no problems regarding KVM/qemu. The new Nvidia driver could be compiled without any problems for the new kernel during upgrade and was directly integrated into the system by dracut. The new KDE/Plasma version started without problems on Xorg. Deficits of Plasma widgets for monitoring system devices were obvious; but this is not something we can blame Opensuse for.

In the next post of this series

Opensuse Leap 15.4 on a PC – II – Plasma, Gnome, flatpak, Libreoffice and others on (X)Wayland?

I will have a look at KDE/Plasma started on Xwayland.

Happy working with Opensuse Leap 15.4 and stay tuned …

 

Mail-server-upgrade to Opensuse Leap 15 – and some hours with authentication trouble …

Posted on by

Some of my readers know that the mail server in my private LAN resides in an encrypted KVM/qemu guest. It provides IMAP- and SMTP-services to mail-clients – and receives emails from several hosted servers on the Internet via a fetchmail system in a DMZ. It was/is my policy that any access to a mail service account on my private mail server requires authentication against user entries on a separate LDAP-server. The accounts the IMAP/SMTP-service-daemons deal with are not to be confused with Linux user accounts: On the mail server NO Linux user accounts are required for mail handling. I regard the absence of standard Linux user accounts on the mail-server as a small, but effective contribution to security. No mail user can login into the mail server as a Linux user. Nevertheless authentication for the use of mail services is required.

Upgrade top Leap 15 resulted in unusable mail services

The manual upgrade of the mail server system from OS Leap 42.3 to Leap 15 seemed to work perfectly. I got no serious warnings. As root I could login to the virtual KVM guest via ssh – and systemd had started all required services: Fetchmail operated on external servers in the DMZ and transferred new mails to the upgraded mail server. There my postfix queues and secondary services for virus and spam checks seemed to work perfectly. Regarding IMAP I could also see that new entries for new mails appeared in various email accounts (more precisely: in related spool directories). Everything looked great …

However, the big surprise came pretty soon: No mail user could login to the IMAP-service – neither with Kmail, nor Mutt, nor Thunderbird. Access to the SMTP service for sending email was not possible either. System messages appeared on the GUIs saying that there was an authentication error. A very unpleasant situation which required analysis ….

In the meantime I had to start a backup copy of the old mailserver guest installation. On this front
virtualization proved its strengths and simplicity – I had made a copy of the whole KVM guest before the upgrade and just had to include the copy as a virtualization domain into the KVM setup of the virtualization host. But, as the upgraded server had already processed some new mails, I needed to transfer these mails between the servers and reconstruct and reindex some IMAP accounts … A simple, but a task which can be done by some scripts ….

Error analysis

It took me quite a while to figure out where the origin of the upgrade problem was located. I first checked my local firewall protocols both on the mail server and on the LDAP server. Nothing special there … Then I checked the LDAP access protocols – there were successful data requests from various systems – but astonishingly not from the mail server. So it seemed that the mail services did not even try to authenticate their users … strange ….
I then created a new IMAP test user based on a new local Linux user account, i.e. with an entry in “/etc/passwd” and “/etc/shadow”. Guess what? This user could work without any problems. So, obviously the communication of the mail services with the LDAP service for authentication was not triggered or failed in a strange way. I, therefore, tried a manual data request to the LDAP server from the mail server – and got a perfect answer. So, there seemed to be no fundamental problem with the required sssd-daemon and client-configurations. What else was wrong? A bit of despair was in the air …

The role of PAM in the game

Then I tried to remember what I had done in the past to separate the email accounts from the Linux user accounts. Over the last years I had actually forgotten how I had treated this problem. After some reading in old diaries my attention eventually turned to PAM …

The PAM-layer offers Linux admins the possibility of fine-tuning access/authentication conditions for the usage
of a service; among other things you can request certain PAM-modules to authenticate a user via given credentials against defined resources. A sequential series of required, sufficient or optional criteria can be set up. ( When a service needs additional Linux user account information during a session NSS can in addition request information from name resolution backends as “/etc/passwd”. However, this is NOT required for mail services. )

Linux mail services often use the SASL-framework and the saslauthd daemon to perform authentication. SASL can communicate with a variety of authentication backends directly – but it can also use PAM as an intermediate layer. And, in fact, I had used PAM to access my independent LDAP-server with mail account credentials via the PAM-module for SSSD.

I have described my simple approach in a previous article
https://linux-blog.anracom.com/2014/03/15/cyrus-imap-mit-sasl-pam-sssd-und-ldap-opensuse-12-313-1-ii/
Unfortunately, only in German. I, therefore, summarize the basic ideas shortly (see also the graphics in the referenced article).

The things one has to do to force IMAP and/or a SMTP services to use LDAP, but other services to use local authentication resources is:

  • We direct local login-services, ssh-services, etc. on the server via PAM to local resources, only.
  • We eliminate any UIDs corresponding to email account names from local resources as “/etc/passwd” and “/etc/shadow” (and NIS if used).
  • We do not create any local home-directories for email account names.
  • We eliminate LDAP as a usable NSS resource from nsswitch.conf; i.e. we eliminate all LDAP references there.
  • We setup special PAM files in “/etc/pam.d” for the IMAP-service and the SMTP-service. These files will necessarily include pam-modules for the “sss“-service (pam_sss.so).
  • We select entries on the LDAP server for users which for any reasons shall NOT or NO LONGER get access to the mail service accounts, set the “host”-attribute for these entries and configure sssd to use the host-attribute. Or deny certain user names access to the IMAP-service by the help of IMAP -configuration files; cyrus e.g offers the maintenance of a list “userdeny_db”.

This strategy worked very conveniently already on an Opensuse 12.3 platform. Examples for the required special files “/etc/pam.d/imap” and “/etc/pam.d/smtp” are given in the article named above. The mix and sequence of the statements there is due to the fact that locally defined system users as “cyrus” must get access to the IMAP-service, too.

What had happened during the Leap 15 upgrade?

My configuration had survived multiple upgrades of the virtualized server in the past. But not the one to Leap 15! What had happened?

After having remembered the importance of the PAM configuration, I eventually had a look into the directory “/etc/pam.d” on the upgraded system and compared it to the respective directory on the original system. Whereas during previous upgrades “personal” PAM configuration files for services had been respected, the upgrade to Leap 15 simply had removed my PAM configuration files for SMTP and IMAP – without a backup! Incredible, but true! Actually and astonishingly, the contents of some other standard PAM files had been transferred to a backup ….

A restoration of my PAM files for the mail services lead to an immediate success – authentication for the access of mail accounts on the upgraded server was possible again. Some hours in the hell for Linux admins came to an end.

Conclusion

Never (!) trust a standard upgrade of a whole Linux system procedure to keep configuration files in “/etc/pam.d” untouched. Keep an admin or system diary for unusual approaches. And – of course: Full
backups of critical systems before backups are a MUST ….

Upgrade auf Opensuse Leap 15.0 – Probleme mit Nvidia-Treiber aus dem Repository und mit VMware WS 12.5.9

Posted on by

Opensuse Leap 15.0 ist nun schon eine Weile auf dem Markt. Zeit, von Leap 42.3 umzusteigen. Also ein Upgrade durchführen. Geht das problemfrei?

Upgrade von PCs/Workstations

Ich habe Upgrades inzwischen an einem Laptop und auf zwei Linux-Workstations durchgeführt. Ich spreche nachfolgend also nicht über echte Opensuse-basierte Server-Systeme. Die gute Nachricht für Leute, die ihre PCs / Workstations bislang unter Opensuse Leap 42.3 mit ext4 und LVM betrieben haben, ist:

Man kann ohne allzu große Schwierigkeiten auf Leap 15.0 upgraden. Das gilt auch, wenn man eine Reihe von Zusatz-Repositories für bestimmte SW eingesetzt hat (in meinem Fall für Produkte aus den Packman-, Security-, Network-, Forensic-, PHP, Java-, …. -Repositories, die Opensuse eben so anbietet).

Einschränkungen:
Da Leap 15.0 bzgl. BTRFS ein paar neue Features mitbringt, traue ich mich nicht, dieses Statement so auch für Systeme zu machen, bei denen das Root-Filesystem auf BtrFS aufsetzt. Auch Laptops mit Optimus-Systemen habe ich noch nicht umgestellt.

Vorgehensweise für das Upgrade
Man folgt für das Upgrade am besten der unter
https://kamarada.github.io/en/2017/08/03/how-to-upgrade-from-opensuse-leap-422-to-423/
beschriebenen grundsätzlichen Schrittfolge. Der genannte Artikel beschreibt zwar den Wechsel von Leap 42.2. auf Leap 42.3. Die angegebenen Schritte lassen sich aber ganz analog auch auf ein Upgrade auf von Leap 42.3 auf Leap 15.0 anwenden. Natürlich muss man “Leap 42.2” bzw. “Leap 42.3” in den Vorgaben sinngemäß durch “Leap 42.3” bzw. “Leap 15.0” ersetzen.

Das Upgrade von KDE/Gnome und SSDM/GDM3 funktioniert. Auch Apache2- und MySQL-Dienste werden auf den neuesten Stand gebracht und laufen dann mit den alten Konfigurationen weiter. KVM/Gäste ließen sich in der erneuerten KVM/QEMU/libvirt/spice-Umgebung problemfrei starten. Nach dem Upgrade des System-Kerns bindet man die benötigten zusätzlichen Repositories ein und zieht seine Spezialanwendungen und Multimedia-Anwendungen nach. Bzgl. Multimedia primär über Packman; nur im Einzelfall greife ich auf Pakete anderer Multimedia-Repos zu. Unter Leap 15 unterstützt auch eine Implementierung von JAVA 10 etwa Eclipse Photon bei entsprechender Konfiguration sehr stabil. Das Weiterentwickeln von SW mit Hilfe von Eclipse ist also gesichert. Einzig manche Default GTK3-Styles muss man ändern, um sowohl LibreOffice 6 als auch Eclipse Photon mit Dark Scheme ohne Augenprobleme nutzen zu können (s. hierzu frühere Artiekl im Blog).

Natürlich gibt es im Einzelfall aber doch ein paar knifflige Hürden. Nachfolgend zwei, die mir den Umstieg erschwert haben:

Nvidia-Probleme

Für ein KDE-basiertes System “mytux1”, auf dem ich schon bislang die Nvidia-Treiber aus dem Opensuse-Nvidia-Repository genutzt hatte, funktionierte der Wechsel auf Leap 15.0 anstandslos. Man landet bei der Vorgehensweise des oben erwähnten Artikels zwar zunächst (erwartungsgemäß) im Konsolen-Modus. Dort muss man über die ASCII-Variante von YaST Oberfläche das Nvidia-Repository
https://download.nvidia.com/opensuse/leap/15.0
zum YaST-Software-Management hinzufügen und anschließend die passenden Treiber für sein Nvidia-Kartenmodell installieren. SDDM und KDE5 Plasma kamen nach einem Reboot dieses Systems auf Anhieb hoch.

Schwierigkeiten bereitete aber ein anderes KDE-basiertes System “mytux2”, für das ich seit Jahren aktuelle proprietäre Treiberversionen von der Nvidia Web-Site heruntergeladen und manuell über den Nvidia-Installer installiert hatte. Auf diesem System führte der Versuch einer ersten Treiberinstallation aus den Opensuse-Nvidia-Repositories ins Nirwana:

Beim Hochfahren
flackerte zunächst das Konsolen-Terminal mit dem angezeigten Prompt; in diesem Modus sind kontrollierte Eingaben kaum möglich. Das ist mir übrigens nicht zum ersten Mal bei Upgrades passiert. Zur Vorsorge ist es sehr nützlich, vor dem Upgrade den SSHD-Service zu aktivieren (systemctl enable ….). Man kann sich dann beim Hochfahren nach dem Upgrade wenigstens von anderen Systemen aus einloggen und ein “init 3” absetzen, damit sich die Anzeige “beruhigt”.

Nun hat man zwei Möglichkeiten: Download einer aktuellen Treiber-Version von der Nvidia-Website und manuelle Installation. Oder aber: Zuschalten des Nvidia-Repositories und Installation der Treiber über RPM-Pakete und YaST. Ich habe zuerst Letzteres versucht. Systemd initiierte dann nach einem Restart auch den Wechsel zum graphischen “Target” und versuchte erkennbar X und SDDM zu starten; das Ganze endete aber in einem schwarzen Schirm mit Mauszeiger. Und nicht mit der Anzeige des SDDM-Login-Schirm …

In einigen Internet-Beiträgen zu ähnlichen Problemen wird empfohlen, den User “sddm”, unter dem der Login- und Display-Manager SDDM für KDE Plasma-Nutzer ausgeführt wird, zu einem Mitglied der Gruppe “video” zu machen. Das half in meinem Fall aber gar nichts.

Was war da faul?

Zunächst besorgte ich mir zum Vergleich den aktuellen Treiber manuell von der Nvidia-Website; in der gleichen Version wie im Nvidia-Repository hinterlegt. Und siehe da: die manuelle Installation (inkl. Kompilation etc.) über den Nvidia-Installer (also das “run”-Skript ) funktionierte! Allerdings kam eine Warnung, dass die vorhandene “libglvnd“-Installation nicht vollständig sei. Man wird dann vom Nvidia-Installer gefragt, ob er die Installation aus eigenen Ressourcen korrigieren solle. Ich habe dem zugestimmt. Danach kamen SDDM und KDE Plasma anstandslos hoch. Durchatmen: wenigstens die manuelle Installation führt zum Erfolg. Es gibt also kein fundamentales Problem zwischen Leap 15 und den Nvidia-Treibern. Was aber, wenn man aus bestimmten Gründen zu den Opensuse-Nvidia-Repos wechseln will?

Eine komplette Deinstallation des Nvidia-Treibers über das zugehörige Run-File per

bash /extras/Updates/nvidia/NVIDIA-Linux-x86_64-390.87.run –uninstall

und eine anschließende Installation des gleichen Treibers per Opensuse-Nvidia-Repo führte leider wieder ins Nirwana.

Auffällig war bei der manuellen Deinstallation allerdings eine Meldung zu nicht ordnungsgemäß herstellbaren Links im Verzeichnis “/usr/lib64”. Dort liegen bekanntermaßen *.so-Libraries. Ein genaues Studium der im Zuge der verschiedenen Installationen angelegten Links in diesem Verzeichnis brachte dann die Lösung:

Nach einer funktionierenden manuellen Installation des Treibers von der Nvidia-Website gab es dort folgende relevante Einträge : 

mytux2:/usr/lib64 # la | grep libGL
-rw-r--r--   1 root root       656 Sep 21 18:46 libGL.la
lrwxrwxrwx   1 root root        10 Sep 21 18:46 libGL.so -> libGL.so.1
lrwxrwxrwx   1 root root        14 Sep 21 18:46 libGL.so.1 -> libGL.so.1.7.0
-rwxr-xr-x   1 root root    665720 Sep 21 18:45 libGL.so.1.7.0
....

Das Vergleichssystem “mytux1” zeigte hingegen folgende Konstellation: 

mytux1:/usr/lib64 # la | grep libGL
lrwxrwxrwx   1 root root        14 Sep  4 21:40 libGL.so -> libGL.so.1.0.0
lrwxrwxrwx   1 root root        14 Sep  4 21:40 libGL.so.1 -> libGL.so.1.0.0
-rwxr-xr-x   1 root root    588160 Apr 25 03:09 libGL.so.1.0.0

Andere Versionsnummern, aber eine ähnliche Verlinkung.

Nach dem manuellen Uninstall per “bash /extras/Updates/nvidia/NVIDIA-Linux-x86_64-390.87.run –uninstall ” auf “mytux2”
und einem Installieren der Treiberdateien aus den Opensuse-Nvidia-Repositories für Leap 15.0 ergab sich hingegen folgendes Bild: 

mytux2:/usr/lib64 # la | grep libGL       
lrwxrwxrwx   1 root root        14 Sep 21 19:52 libGL.so -> libGL.so.1.0.0
lrwxrwxrwx   1 root root        14 Sep 21 19:52 libGL.so.1 -> libGL.so.1.2.0
-rwxr-xr-x   1 root root    588160 Apr 25 03:09 libGL.so.1.0.0
lrwxrwxrwx   1 root root        14 Sep 21 19:52 libGL.so.1.2 -> libGL.so.1.2.0
-rwxr-xr-x   1 root root    430760 Nov 21  2016 libGL.so.1.2.0
...

Hier war zwischenzeitlich offenbar etwas Altes aus dem Jahre 2016 restauriert worden! Woher der Nvidia-Uninstaller das auch immer genommen haben mag… Dass der Nvidia Installer/Uninstaller damit zu tun hatte, ergab sich aus der Tatsache, dass die Datei “libGL.so.1.2.0” sich keinem RPM-Repository zuordnen ließ, die libGL.so.1.0.0 aber schon : 

mytux2:/usr/lib64 # rpm -qf libGL.so.1.0.0
libglvnd-1.0.0-lp150.1.1.x86_64

Wer immer da wann was im “libGL/libglvnd”-Umfeld verbrochen hatte; dieser Schaden ließ sich beheben. Offenbar ist für die Repository basierten Treiber nur die “libGL.so.1.0.0” maßgeblich. Ich habe daher eine Umsetzung der Links vorgenommen und die “libGL.so.1.2.0” gelöscht. (Auch die manuelle Treiberinstallation nutzt diese Bibliothek ja nicht …; s.o.). 

mytux:/usr/lib64 # la | grep libGL
lrwxrwxrwx   1 root root        14 Sep 21 19:52 libGL.so -> libGL.so.1.0.0
lrwxrwxrwx   1 root root        14 Sep 21 23:27 libGL.so.1 -> libGL.so.1.0.0
-rwxr-xr-x   1 root root    588160 Apr 25 03:09 libGL.so.1.0.0
lrwxrwxrwx   1 root root        14 Sep 21 23:27 libGL.so.1.2 -> libGL.so.1.0.0

Die Dateien aus dem Opensuse-Nvidia-Repository habe ich dann zur Sicherheit nochmal überinstalliert. Und siehe da, danach lief alles. Den Link “libGL.so.1.2” konnte ich schließlich auch ohne Schaden wegschmeißen.

Merke: Eine Historie mit Wechseln von Nvidia-Treiber-Installationen aus dem Opensuse-Repository und manuellen Installationen per Nvidia-Installer-Daten bleibt nicht immer verwerfungsfrei. Ein Blick in die Links unter “/usr/lib64” ist hilfreich.

Problem mit VMware WS 12.5.9 unter Leap 15.0

Auf einem meiner Systeme läuft eine relativ aktuelle VMware WS 14.1.1-Umgebung. Die überlebte das Upgrade auf Leap 15.0 anstandslos. Die Module wurden im Hintergrund neu kompiliert und erfolgreich gestartet.

Auf einem anderen System lief aber die WS 12.5.9. Die ließ sich zunächst nicht dazu bewegen zu starten. Die Module für den “Virtual Machine Monitor” wie das “Virtual Network” konnten nicht erfolgreich kompiliert werden. Hier hatten findige Menschen aber dankenswerterweise schon vorgearbeitet; das Problem ist bekannt und gelöst. Die notwendigen Schritte, die auch auf meinem System zum Erfolg führten findet ihr hier

https://communities.vmware.com/message/2777306#2777306

Addendum, 25.03.2020: The steps described in the referenced community article work on Leap 15.1, too.

Viel Spaß dann mit Opensuse Leap 15 ! ZU Leap 15 und Optimus bald mehr, wenn ich Zeit finde …