Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – I – Vorüberlegungen

Eine Verschlüsselung von Daten auf Laptops ist in Zeiten der DSGVO Pflicht, da Laptops verloren gehen oder gestohlen werden können. Mein in die Jahre gekommener Laptop benötigt eh' einen neue (jungfräuliche) SSD. Zudem muss ich auf Opensuse Leap 15 wechseln. Ein guter Anlass, eine Verschlüsselung von Betriebssystem- und Daten-Partitionen unter Opensuse Leap 15 zu testen.

Vor einem Tausch der SSD wollte ich zunächst ausprobieren, ob eine Betriebssystem-Verschlüsselung unter Opensuse Leap 15.0 mit dem Laptop überhaupt funktioniert. Die meisten Linux-Profis setzen die Kombination "dm-crypt/LUKS" zur Verschlüsselung von Partitionen oder Volumes ein. Dabei spielen verschiedene Parameter eine Rolle, für die unter Opensuse normalerweise der YaST-basierte Partitioner Default-Werte vorgibt.

Ich nahm mir diesmal allerdings die Freiheit, die LUKS-Partitionen selbst mit eigener Parameter-Setzung vorzubereiten. Danach wurde das ganze Unternehmen unerwartet abenteuerlich und es taten sich etliche Falltüren auf. Es gab u.a. Probleme mit dem SuSE-Installer; nicht mehr bootfähige Systeme, nicht funktionales Kryptographie-Setup, Dracut-Probleme sind nur einige Stichworte. Man glaubt, man hat eine Lösung und schon zieht ein Neuinstallieren des Bootloaders über YaST alles wieder in den Abgrund. Probleme mit dem Grafik-System (Optimus; Nouveau, KMS) kamen zwischenzeitlich dazu - mit komischen Querbeziehungen zu systemd beim Shutdown und Aushängen des verschlüsselten Volumes für das /root-Filesystem.

Der ganze Themenkreis erfordert neben praktischen Installations- und Konfigurations-Schritten aber auch einige "theoretische" Vorüberlegungen. Verschlüsselung allein bietet schließlich noch keine hinreichende Sicherheit ... und man muss auch an Konsequenzen für den praktischen Betrieb eines solchen Laptops denken. Zudem kann man sehr verschiedene Wege bzgl. des System-Layouts einschlagen. Beispiele für Varianten sind etwa:

  • Vollverschlüsselung unter Einschluss des root-Filesystems oder Einsatz von Daten-Containern?
  • Vollverschlüsselung des Hosts oder nur darunter virtualisierter Systeme?
  • LVM on LUKS oder LUKS on LVM ?

Das sind nur drei wichtige Variationsmöglichkeiten - über die man schon im Vorfeld der praktischen Installation entscheiden muss. Ich denke, das ist einige Blog-Posts wert ... Auch wenn das primäre Ziel die Voll-Verschlüsselung eines Linux-Laptops unter Opensuse Leap ist, so können viele der angestellten Überlegungen und Vorgehensweisen auch auf Desktops oder z.T. auf einfache Server übertragen werden.

Ich beginne mit einer Reihe von "theoretischen" Vorüberlegungen, die jedoch praktische Auswirkungen auf die Sicherheit der Daten haben. Um eine ständige Unterscheidung zwischen LVM-Volumes und Partitionen zu vermeiden, spreche ich nachfolgend generell von "Volumes". An den Stellen, wo die Unterscheidung wichtig wird, werde ich sie explizit treffen. "Betriebssystem" kürze ich im Weiteren mit OS ab.

Für Grundlagen zu grundsätzlichen Abläufen unter LUKS können Interessierte einen Blick in meine früheren Blog-Posts werfen; dort sind auch viele Links zu weiterführender Literatur im Internet angegeben:
dm-crypt/Luks – Begriffe, Funktionsweise und die Rolle des Hash-Verfahrens – I
dm-crypt/Luks – Begriffe, Funktionsweise und die Rolle des Hash-Verfahrens – II
Ich setze im späteren Verlauf dieser Serie ein grundlegendes Verständnis der Arbeitsweise von LUKS voraus. Die praktische Umsetzung von LUKS auf der Kommando-Ebene zeige ich natürlich (ausschnittsweise) im Zuge dieser Artikel-Serie.

Unterscheidung Vollverschlüsselung - Teilverschlüsselung

Wir unterscheiden im Folgenden zwischen Voll- und Teil-Verschlüsselung. Unter einer Voll-Verschlüsselung verstehe ich dabei einen Ansatz, in dem

  • sowohl das Volume für das OS, mit dem auf die zu schützenden Daten zugegriffen wird,
  • als auch separate Volumes zur Lagerung der zu schützenden Daten,
  • als auch Swap-Volumes

verschlüsselt werden. Bei Abweichungen spreche ich von Teil-Verschlüsselung.

Teilverschlüsselung - Datencontainer und/oder ausschließliche Verschlüsselung von separaten Partitionen/Volumes für Daten?

Viele Leute (auch IT-Profis) wählen zum "Schutz" ihrer Daten den "bequemen" Ansatz, diese in verschlüsselten Containern (Files) oder Partitionen/Volumes zu hinterlegen. Sehr beliebt ist unter Linux und Windows etwa der Einsatz von VeraCrypt. Dabei operiert das OS selbst auf einem unverschlüsselten Volume, weil sich die Anwender (z.T. aus guten Gründen) an eine Voll-Verschlüsselung nicht herantrauen. So kenne ich etwa mehrere Leute, die unter Windows ihre Daten in verschlüsselten Krypto-Containern auf der Systemplatte ablegen und meinen, nun seien die Daten bei einem Verlust oder Diebstahl des Laptops sicher. Das ist ein Irrtum (nicht nur wegen MS Windows 🙂 ). Die Gründe lassen sich u.a. mit folgenden Stichworten charakterisieren:

  • Pufferung von Daten/Dateien durch das Betriebssystem und Anwendungen in "temporären" Verzeichnissen/Dateien/Datenbanken sowie anwendungsspezifische Backup-Dateien.
  • Dateianalysatoren und Indexer für schlagwortbasierte Suchverfahren, die ggf. automatisch ganze Verzeichnisbäume und deren Inhalte durchforsten und Ergebnisse in Datenbanken hinterlegen.

Durch solche Verfahren landen Daten oder Datenfragmente bei der Bearbeitung von Dateien des Kryptocontainers (dekryptiert) auf dem unverschlüsselten (!) Filesystem des Betriebssystems [OS].

Zur Bearbeitung muss man die Dateien ja öffnen und ihren Inhalt entschlüsseln. Mindestens im RAM liegen die Daten dann im Klartext vor. Würden das OS oder die aktuelle Anwendung vom RAM immer nur auf den Krypto-Container zurückschreiben, wäre die Welt in Ordnung; das ist aber in vielen Anwendungen und Betriebssystemen nicht ohne besondere Einstellungen der Fall. Auch unter Linux landen Daten u.a. im /tmp-Verzeichnis, im home-Verzeichnis des Users oder gar im Swap. Hinzu kommen weitere anwendungsspezifische Orte im Filesystem. Kritisch in dieser Hinsicht sind etwa bestimmte Mail-Systeme. Siehe zur Thematik der Lagerung von Daten in ggf. unverschlüsselten Bereichen des Systems auch die unten angegebenen Links.

Das gleiche Thema haben wir, wenn wir nur bestimmte Partitionen/Volumes eines Linux-Laptops für die Aufnahme von Daten verschlüsseln würden - aber das OS auf einem unverschlüsselten Volume desselben Geräts betreiben würden. Hier fungiert dann gleich eine ganze Partition oder ein Volume als "Container". Es gilt aber auch für begrenzte "Container", die man mit LUKS etwa auf Basis von datei-basierten Loop-Devices aufbauen könnte (ja, sowas geht 🙂 ).

Analoges gilt aber auch bei Einsatz externer Krypto-Container - z.B. auf USB-Sticks oder USB-Platten: Die Daten sind dort nur genau so sicher, wie sie es auf dem Laptop oder der PC selbst wären, von denen aus man regelmäßig mit dem externen Container arbeitet. Gerade bei mobilen Leuten ist das also ein Thema. All diese Ansätze entsprechen in Zeiten der DSGVO sicher nicht dem Stand der Technik.

Erstes Fazit: Für eine sichere Datenhaltung kommen wir um eine Verschlüsselung der Volumes/Partitionen für das OS (root-Filesystem) sowie ggf. separate Datenvolumes sowie Swap-Bereiche nicht herum.

Teilverschlüsselung - das Problem mit SSDs

Man könnte bei HDDs noch wie folgt argumentieren: Wenn ich alle Bereiche und Dateien kenne, die das System oder Anwendungen zur Pufferung, Backups, Indizierung etc. nutzen, könnte ich diese Bereiche regelmäßig löschen und mit Nullen oder Zufallsdaten überschreiben. Das funktioniert leider nicht bei SSDs, die heute in die meisten Laptops eingebaut sind. Die oben diskutierte Thematik schlägt dann voll zu:

SSD-Controller verteilen ankommende Daten zur Begrenzung von Ausfällen z.T. in mehrfacher Kopie auf verschiedene Speicherelemente; das Stichwort ist hier "Wear-Leveling". Das geschieht für den Anwender transparent im Hintergrund. Ohne Spezialwerkzeuge hat man als normaler User keinen Zugriff auf diese Storage-Bereiche. Selbst wenn man alle Systembereiche für Pufferung etc. kennt und mit zufälligen Daten überschreibt - es blieben unverschlüsselte Reste auf der SSD erhalten. An die kommen Hacker, die physikalischen Zugriff auf die SSD haben, im Zweifelsfall aber mit Spezialwerkzeugen heran. Einer der Entwickler von Veracrypt lehnt deshalb grundsätzlich vom Einsatz von SSDs auf Hochsicherheitssystemen ab. Siehe hierzu:
https://sourceforge.net/p/veracrypt/discussion/technical/thread/9cd45bb3/
https://www.veracrypt.fr/en/Security%20Requirements%20and%20Precautions.html
https://www.veracrypt.fr/en/Wear-Leveling.html

Das bedeutet:

Keine schützenswerten Daten dürfen den internen SSD-Controller je unverschlüsselt erreichen.

LUKS und auch Veracrypt sorgen dafür, dass genau das bei der Interaktion mit einem Storage-System passiert. Setzt man SSDs ein, so müssen also alle genutzten Partitionen, auf denen man schützenswerte Daten hält und auf denen ggf. unverschlüsselte Kopien oder Fragmente landen könnten, verschlüsselt werden. Allein hieraus ergibt sich eine Voll-Verschlüsselung für den Linux-Betrieb auf SSDs.

Das bedeutet aus meiner Sicht nicht zwingend, dass die komplette jungfräuliche SSD verschlüsselt werden muss. Aber mit OS-Installationen auf unverschlüsselten Partitionen darf man später NICHTS (!) Geheimhaltungswürdiges anfassen. Das ist in der Praxis gar nicht so einfach - und verlangt erhebliche Selbstdisziplin. Wer sicher gehen will, wird daher entweder die gesamte SSD oder zumindest alle OS-, Daten- und Swap-Partitionen, auf und mit denen regulär gearbeitet wird, verschlüsseln.

SSDs werfen übrigens noch ein zweites Problem im Zusammenhang mit Verschlüsselung auf: das des sog. Trimmens (fstrim-Kommando). Darauf komme ich in einem späteren Blog-Artikel zurück.

Teilverschlüsselung - das Hibernation-Problem

Vor allem im Fall von Laptops muss man sich auch mit dem Thema "Hibernation" auseinandersetzen. Beim Übergang in den maximal stromsparenden Zustand werden aktuelle RAM-Inhalte auf die Platte geschrieben (unter Linux evtl. in den SWAP-Bereich). Nach dem Öffnen eines Krypto-Devices wird im RAM aber auch der sog. "Master-Key" für das symmetrische Verfahren zur Datenverschlüsselung vorrätig gehalten. Das ist nicht nur bei LUKS so! Der Master-Key würde im Hibernation-Vorgang also auf der Platte landen ...

Auch das ist ein Grund dafür, auf Laptops alle Volumes/Partitionen die vom OS genutzt werden, zu verschlüsseln. Ein Angreifer könnte etwa einen Laptop in die Hände bekommen, der sich schon in einem Hibernation-Zustand befindet oder ihn nach gewisser Zeit erreichen wird. Der typische Fall für Freelancer ist der Verlust beim Umstieg zwischen zwei Zügen. Oder der gezielte Diebstahl in der Mittagspause.

Man sollte sich für seine Distribution in jedem Fall darum kümmern, was als Platz für Hibernation genutzt wird. Natürlicherweise bietet sich der SWAP an. Auch unter Opensuse Leap ist das der Fall. Der Swap-Space muss auf einem Laptop mit Hibernation deshalb auch eine hinreichende Größe (> RAM) haben. Siehe:
https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.power-mgmt.html
Unter Suse müssten wir auf einem System mit aktiviertem Hibernation also unbedingt den SWAP-Space verschlüsseln.

Es gibt übrigens ein ganz ähnliches Problem im Zusammenhang mit Virtualisierung. Dort kann man Gastsysteme in einen "Saved"-Zustand überführen, in dem auch der RAM der virtuellen Maschine in einem vorgegebenen Verzeichnis-Bereich des OS - also ggf. auf einem unverschlüsselten Bereich des Systems gespeichert wird. Aber genug für heute ...

Zwischenfazit

Erste einfache Überlegungen sprechen gegen eine Teil-Verschlüsselung von (mobilen) Systemen, die Sicherheit geheim zu haltender Daten auf dem Stand der Technik garantieren sollen. Im nächsten Beitrag

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – II – Vorüberlegungen zur Virtualisierung

stellen wir Überlegungen zur Verschlüsselung virtualisierter Systeme an.

Links zum Thema "Warum Voll-Verschlüsselung?"

https://en.opensuse.org/SDB:Encrypted_root_file_system
https://wiki.archlinux.org/index.php/Disk_encryption

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

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

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