Opensuse Leap 15.5 – installation of CUDA 12.3 for Machine Learning

Working with Machine Learning and Deep Neural Networks not only requires GPU drivers, but in case of Nvidia GPUs also the installation of CUDA and cuDNN. This process is always a bit tricky as additional environment variables have to be set for IPython-based Jupyterlab or classic Jupyter Notebook. On an Opensuse system one must in addition take care of the right settings in /etc/alternatives.

I have described the necessary steps in a post at “machine-learning.anracom.com“.

I hope this helps people who want to use Leap 15.5 for Machine Learning with Nvidia GPUs, Keras/Tensorflow 2 and Jupyterlab.

Important addendum 01/27/2024:
Although the combination of CUDA 12.3, cuDNN 8.9.7, Tensorflow 2.15 and Nvidia drivers 545.29.06 works regarding AI-models, there is another major problem:
Nvidia’s driver 545.29.06 is buggy – at least for Leap 15.5, KDE/Plasma with multiple screens. The bug affects Suspend-to-RAM. Suspend-to-RAM seems to work in the suspend phase, and the system also comes up afterward in a seemingly proper state of your KDE/Plasma interface (on your screens).

However, the problems begin when you want to change to another virtual screen via Ctrl-Alt-Fx. You wait and wait and wait … The same for changing the run-level or systemd target state or when you want to shut the system down. This makes Suspend-to-RAM with driver 545.29.06 impossible to use.

Recommendation:
If you have a working older Nvidia driver (e.g. a stable 535 version) do not change to 545.29.06. Unfortunately, it is a mess on a multiscreen Leap 15.5 system to return to an older driver version. The Nvidia community repository does not offer you a choice. (Why by the way ????). Downloading an older proprietary driver from Nvidia and trying to install it afterward on a console terminal (after having stopped X11 or Wayland) did not work in my case – the screens displaying the terminal changed their resolution and froze afterward. So, you may have to completely uninstall the present driver 545 completely, go back to standard VGA and then try to install an older driver via Nvidias install mechanism. As I said: It is a mess …

 

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – VII – Grundinstallation für LUKS on LVM

In den letzten Beiträgen meiner Serie zu Voll-Verschlüsselung eines Laptops und angrenzenden Themen

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – I – Vorüberlegungen
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – II – Vorüberlegungen zur Virtualisierung
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – III – Zugriffs-Layer
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – IV – Disk-Layout
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – V – kryptierte Partitionen und Alignment
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – VI – Key-Slots, PBKDF2- und MK-Iterationen

haben wir uns auf einer externen SSD bereits Partitionen und LUKS-LVM-Volumes (LUKS on LVM / VGs: vga, vgs / LVs: lva1, lvs1) für eine Test-Installation von Opensuse Leap 15.0 erstellt. Das Alignment hatten wir dabei – entgegen den Fake-Informationen des externen USB-Controllers – bereits auf die spätere Nutzung der SSD direkt am SATA-III-Bus des Laptops ausgerichtet. Wir schließen diese Disk nun an den Laptop als externe USB-Disk an und nehmen eine Opensuse-Leap15-Installation vor. Ich greife dabei auf ein ISO-Image für eine Installations-DVD zurück. Der Laptop wird von mir an ein geeignetes LAN-Segment angeschlossen; Firewalls erlauben einen Zugriff auf Update Repositories von Opensuse im Internet.

Der Installationsprozess muss anschließende Boot-Vorgänge von verschlüsselten LVM-Volumes sicherstellen. Das betrifft einerseits reguläre Bootvorgänge, andererseits aber auch einen Bootvorgang aus einem vorhergehenden Hibernation-Zustand. Wir ignorieren letzteres in einem ersten Anlauf – und verzichten zunächst völlig auf die Einbindung eines SWAPs. Das führt zu einer Vereinfachung; der Hauptgrund ist aber, dass der Opensuse-Installer mit der Konfiguration auf Basis vorgefertigter LUKS-Devices Probleme hat.

Ich gehe zu Beginn dieses Artikels kurz auf Schritte und Elemente eines regulären Boot-Vorgangs ein und bespreche erst danach einige wichtige Schritte während der Installation. Das erscheint mir zum besseren Verständnis einiger Aktionen sinnvoll.

Ziel ist zudem keine detaillierte, allgemeingültige Installationsanleitung für Opensuse Leap; ich setze vielmehr voraus, dass der interessierte Leser auf seinem Laptop schon mal eine Standard-Opensuse-Installation durchgeführt hat. Hier geht es lediglich um Besonderheiten, die bei der Installation auf LUKS-Volumes zu beachten sind.

Hinweise: Mein Laptop hat ein Optimus-System (prozessorinterne Grafikkarte + Nvidia-Karte im Verbund). Das macht immer etwas Probleme; in meinem Fall muss man von vornherein bestimmte Video-Einstellungen wählen, um überhaupt den grafischen Install-Bildschirm zu erreichen. Darauf werde ich kurz eingehen. Zudem besitzt mein Test-Laptop noch ein Legacy BIOS. Mit OS kürze ich nachfolgend “Betriebssystem” ab; FS steht für “Filesystem”.

Für die
schlechte Qualität der Bilder entschuldige ich mich; ich habe die am Abend gemacht und die falsche Einstellung am Handy gewählt :-(.

Continue reading

Probleme mit OS 13.2-Upgrade, Backup der OS 13.1 Partition, Grub2, UUIDs

Manchmal geschehen Dinge, die einen zum Verzweifeln bringen können – obwohl man selbst daran schuld ist und den Wald vor lauter Bäumen nicht mehr sieht.

Ich habe gestern versucht, Opensuse 13.2 von einer DVD auf einem System mit konventiionellem BIOS zu installieren. In der Vergangenheit habe ich das eine oder andere Mal schlechte Erfahrungen mit Opensuse-Upgrades gemacht. Deshalb habe ich ein Backup der gesamten Partition angelegt, die das aktuelle laufende Betriebssystem Opensuse 13.1 beinhaltet. Das sollte jeder tun! Und gerade bei einer versuchsweisen Installation von OS13.2 oder einem versuchsweisen Upgrade von OS13.1 auf OS 13.2 von einer DVD lohnt sich das. Siehe unten. (Hinweis: Hat man systemrelevante Verzeichnisse über mehrere Partitionen verteilt, so ist natürlich jede der Partitionen zu sichern.)

Da ich faul bin, habe ich diesmal das Backup in eine freie Partition desselben Systems kopiert. Das mache ich sonst nicht; es gibt bei uns nicht umsonst einen Backup-Server.

Meine Systempartitionen halte ich meist im Bereich von 80 GByte. Meine Entwicklungssysteme haben eine oder 2 SSDs für solche Partitionen, auf denen es schnell zugehen muss, und zusätzliche langsamere Raid-Systeme mit konventionellen Harddisks mit Partitionen für die sonstige Datenhaltung. Eine der dortigen freien Partitionen habe ich nun für die Kopie der SSD-Betriebssystem-Partition genutzt. Die SSD ist als “/dev/sda” und das Raid-System als “/dev/sdb” zugänglich. Beide GPT partitioniert.

Das Backup habe ich habe ich mit “dd” vorgenommen:

dd if=/dev/sda2 of=/dev/sdb15 bs=4K

Dieser Schritt war von der Hoffnung getragen, dass der OS-Prober von Grub 2 während der Opensuse-Installation die kopierte Partition erkennen und auch dafür einen Boot-Menü-Eintrag anlegen würde. Für alle Fälle sozusagen. Viel zu kurz gedacht, weil ich in der Hektik einen wichtigen Punkt vernachlässigt hatte! Siehe unten. Dieser Artikel mag daher für ähnlich unbedarfte User eine Warnung und hoffentlich auch Hilfe darstellen.

Jedenfalls ging das Opensuse 13.2 Upgrade schief und ich wollte/musste das Backup nach einem Rückschreiben auf die ursprüngliche Partition wieder nutzen – das klappte dann zunächst aus verschiedenen Gründen zunächst nicht wie vorgesehen. Aber der Reihe nach.

Opensuse 13.2 Installer versagt

Naiv versuchte ich, das Upgrade wie zuletzt bei OS 13.1 über den DVD-Installer durchzuführen. Also: Auf dem Eingangsschirm über F2 Sprache und über F3 die Auflösung gewählt. Und dabei schon den ersten Fehler gemacht – nämlich nicht auf den neuen Menüpunkt “Keine KMS” in der Vorauswahl für die gewünschte Biddschirmauflösung geachtet. Was immer “Keine KMS” implizieren soll… Ich habe den Punkt zunächst ignoriert – obwohl ich natürlich “Kernel Mode Setting” assoziierte, mir dazu aber keine weiteren Gedanken machte.

Jedenfalls brachte der Installer nach der Auswahl meiner Standardauflösung von 1920×1200 kaum lesbare Zeichen auf den grafischen Installer-Schirm. OK, Grafikkartenproblem – ich habe in besagtem System eine Nvidia GTX 750 TI. Da spinnt halt der Nouveau-Treiber, denke ich. Da ich den Schirminhalt mit ein wenig Phantasie manchmal gerade noch lesen konnte, versuchte ich einfach weiterzumachen. In der Hoffnung, dass sich nach der Grundinstallation und einer Installation des Nvidia-Treibers alles zum Guten wenden würde.

Jedoch : Die Installation scheiterte letztlich bei der automatischen Konfiguration kurz vor dem Reboot mit gleich zwei roten Fehlermeldungen, die ich allerdings wegen des zu geringen Farbkontrastes nicht entziffern konnte – außer, dass man einen Fehler melden solle. Sehr hilfreich …. Nach dem Reboot-Versuch ging dann gar nichts mehr. Mein altes Grub2-Menü war zwar noch da, aber das “upgegradete” System blieb zu Beginn des
Bootvorgangs stehen – ohne jede Chance, auch nur irgendetwas zu tun (ach, du schöne neue Welt von grub2, systemd und KMS!).

OK, dachte ich, wozu hast du eine Sicherung? Also mit “dd” die kopierte Partition an ihren Ursprungsort zurückgeschrieben – und leider wieder nicht darüber nachgedacht, was das eigentlich bedeutet (s.u.). Immerhin: Der Bootvorgang ins alte OS13.1 lief (irgendwie, s.u.). Bis zum grafischen Login. Da war ich erstmal beruhigt.

Weiterer Installationsversuch

Ich habe danach versucht – wieder mit kaum lesbarem Schirm – eine minimale Installation von OS 13.2 ohne KDE oder ein anderes grafisches System vorzunehmen. Ich modifzierte ferner die Partitionierung nach einem bislang gewohntem Muster – wiederum ohne richtig nachzudenken. Und eliminierte dabei eine BIOS Boot Partitiion, die ich unter OS 13.1 auch nicht hatte. Die Quittung kam prompt:
Nach dem Reboot meldete das BIOS, dass es kein bootfähiges System gebe. Ich solle eine Systemdisk einstecken … Na, super ! Nun half die zurückgespielte Sicherung auch nichts mehr …

“Keine KMS” unter dem Installerpunkt F3 Auflösung”

Nach einem Beruhigungstrunk war dann der Ehrgeiz geweckt. Neuer Anlauf mit genauerem Hinsehen und Hin und Her-Schalten zwischen den Spracheinstellungen des grafischen Opensuse DVD-Installers. Das erste, was ich dann ernst nahm, war der neue Punkt (nach “F3”) oberhalb der verfügbaren Auflösungen: “No KMS” – “Keine KMS”.

Unabhängig von “keine” ist “KMS”, interpretiert als “Kernel Mode Setting”, durchaus interessant. Die proprietären NVidia Treiber nutzen ja KMS nicht. Aber die Idee hinter KMS ist ja eigentlich was Gutes. Siehe etwa:
https://wiki.archlinux.org/index.php/kernel_mode_setting
Vielleicht nutzt der OS-Installer jetzt frühzeitig KMS ? Und vielleicht kann ja der Installer im KMS Modus mit aktuellen Nvidia Karten nicht umgehen?

Also mal die Option “Keine KMS” gewählt. Und siehe da: Es wurde zwar für Textmeldungen auf tty1 ein Text-Terminal mit schrecklicher 80×20-Basis-Auflösung eingerichtet, aber der grafische Installer funktionierte plötzlich mit meiner Nvidia-Karte und zeigte ein einwandfreies grafisches Schirm- und Text-Bild. Das ist etwas, worüber die Opensuse-Leute mal nachdenken sollten! Wie soll ein Anfänger mit dieser Situation klar kommen?

Installation von Opensuse 13.2 mit dem Kernelparamter “nomodeset”

Ok; KMS macht dem Installer also Probleme beim Umgang mit meiner speziellen Nvidia-Karte (oder ggf. auch mit anderen Nvidia-Karten). Da ich mich nach der Installation nicht mit niedrig auflösenden Text-Konsolen (tty1 bis tty6) und deren Rekonfiguration rumschlagen will, habe ich mir dann für einen erneuten Installation vorgenommen, zwar eine Auflösung von “1920×1200” statt der Option “Keine KMS” zu wählen, aber gleichzeitig mit dem Kernel-Parameter

“nomodeset”

zu arbeiten. Gott sei Dank hat Opensuse die Eingabezeile für Kernelparameter auf dem Installer-Schirm beibehalten!

Der Vorteil dieser Installationsmethode ist, dass einerseits das Problem mit dem grafischen Installer vermieden wird – aber gleichzeitig die Konsol-Terminals tty1 bis tty6 auf maximale Auflösung konfiguriert werden.

Partitionierung mit BIOS Boot Partition

Mein System war eines mit einem konventionellen BIOS. Kein UEFI. Grub 2 in aktuellen Versionen benötigt aber aus Platzgründen (begrenzter MBR; angrenzender Platz wird belegt) eine kleine Bios Boot Partition, wenn

  • ein System mit
    konventionellem BIOS gebootet werden soll UND
  • die Festplatte, auf der Grub2 installiert wird, eine reine GPT-Partitionstabelle enthält oder ein MBR/GPT Hybrid ist.

Für mehr Informationen zur BIOS Boot Partition siehe

http://en.wikipedia.org/wiki/BIOS_boot_partition
http://wiki.ubuntuusers.de/GRUB_2/Grundlagen
http://www.rodsbooks.com/gdisk/booting.html
http://de.news.siduction.org/2011/10/15/gpt-disks-mit-herkommlichem-bios-booten/

Für mein System mit konventionellem BIOS und GPT-Platten schlug der Opensuse Installer deshalb eine solche Partition im Zuge der versuchten Neuinstallation vor. Ist man bislang ohne eine solche Partition ausgekommen, so war das vielleicht Glück (Grub2 kann manchmal mit Umwegen arbeiten), oder man hatte noch eine älter Grub 2 Version. In jedem Fall sollte man vor der Neu-Installation von OS 13.2 auf eine freien Partition, aber auch vor dem Upgrade eines vorhandenen OS 13.1 unbedingt eine kleine “BIOS BOOT” Partition anlegen, wenn denn die primäre Platte GPT-partitioniert ist und dort eine solche Partition noch nicht existiert.

Diese “BIOS BOOT”-Partition wird vom User zwar nicht formatiert, erhält aber ein spezielles Flag. Der Partitioner von Opensuse, der im Installer aufgerufen wird, stellt dann die Größe automatisch auf etwa 7.3 MByte ein. Man darf alles an den Partitionierungsvorschlägen des Installers ändern, aber die Existenz der Boot Partition sollte man gewährleisten. Im YaST-Partitioner muss man beim Anlegen der Partition folgende Optionen wählen :

  • Partition nicht formatieren
  • Dateisystem ID 0x00 BIOS Grub

Der Typ einer solchen Partition ist übrigens “0xEF02” (falls man Tools wie “gdisk” zur Anlage verwenden will).

Erfolgreiche Installation

Und – oh Wunder – mit dem Kernelparameter “nomodeset” und vorhandener BIOS Boot Partition klappte sowohl die Installation eines neuen Systems auf einer freien Partition (als auch das spätere Upgrade eines vorhandenen OS 13.1). Das vom Installer installierte Grub 2 enthielt nach der testweisen Neuinstallation von OS 13.2 auf einer freien Partition der SSD prompt auch 2 Menüpunkte für

  • sowohl das alte ursprüngliche OS 13.1 auf der SSD (/dev/sda1)
  • wie auch das als Backup kopierte OS 13.1 auf dem Raid-System (/dev/sdb15)

Grub2 bootet trotz korrektem Menüeintrag das vorhandene OS13.1 nicht von “/dev/sda1” sondern von “/dev/sdb15”

Nun probierte ich, das inzwischen ja aus der Sicherung auf “/dev/sda1” zurückkopierte OS 13.1-System zu booten. Das ging zwar – es wurde aber nicht die Partition /dev/sda1 auf das Wurzelverzeichnis “/” gemounted, sondern vielmehr die (langsamere) “/dev/sdb15”.

Warum denn das nun wieder? Der zugehörige Grub2-Menüeintrag sah doch korrekt aus und enthielt sogar den Hinweis auf die “/dev/sda1” im Titel! Auch die Einstellung der “/boot/grub2/grub.cfg” sahen fehlerfrei aus. Ich hatte einfach einen schlechten Tag und bekam das trotz einiger Anläufe und mehrfacher Kontrolle der Grub2 Konfigurationsdatei und der “/etc/fstab” zunächst nicht in den Griff. Dabei war die Lösung bei etwas aufmerksamerem Hinsehen stocksimpel – und dem Profi ist mein oben begangener Fehler sicher nicht entgangen:

“dd” kopiert natürlich 1:1 die komplette Filesystem-Information zwischen den Partitionen mit. Damit auch die
UUID der Partition! Diese war nach dem Kopieren also nicht mehr eindeutig in meinem System!

Siehe zur Bedeutung der UUID z.B.:
http://wiki.ubuntuusers.de/UUID

Grub 2 benutzt in der aktuellen Version aber UUIDs an etlichen Stellen, um die zu einem Menüeintrag zugehörigen Partitionen zu identifizieren. Hierzu ein entsprechender Ausschnitt aus der “/boot/grub2/grub.cfg” :

### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'openSUSE 13.1 (x86_64) (on /dev/sda1)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-d05ea945-8416-45bb-8697-2710a753520e' {
	insmod part_gpt 
	insmod ext2
	set root='hd0,gpt1'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1 --hint='hd0,gpt1'  d05ea945-8416-45bb-8697-2710a753520e
	else
	  search --no-floppy --fs-uuid --set=root d05ea945-8416-45bb-8697-2710a753520e
	fi
	linux /boot/vmlinuz-3.11.10-7-desktop root=UUID=d05ea945-8416-45bb-8697-2710a753520e video=1920x1200 resume=/dev/disk/by-id/scsi-1AMCC_1ZC032077E68A3005C91-part5 splash=silent quiet showopts
	initrd /boot/initrd-3.11.10-7-desktop
}

Der wichtigste Punkt ist dabei

root=UUID=d05ea945-8416-45bb-8697-2710a753520e

Leider gab es auch nach dem Zurückkopieren des Inhalts der (Backup-)-Partition von “/dev/sdb15” auf “/dev/sda1” die UUID “d05ea945-8416-45bb-8697-2710a753520e” natürlich zweimal auf dem System – eben für “/dev/sdb15” und “/dev/sda1”.

Überprüfen kann man die UUID als User root mittels des Kommandos

mytux:~ # blkid /dev/sda1
/dev/sda1: UUID="d05ea945-8416-45bb-8697-2710a753520e" TYPE="ext4" PTTYPE="dos" PARTLABEL="primary" PARTUUID="5db53bbc-3db1-4860-8c67-6d9d8391ef29" 
mytux:~ # blkid /dev/sdb15
/dev/sdb15: UUID="d05ea945-8416-45bb-8697-2710a753520e" TYPE="ext4" PTTYPE="dos" PARTUUID="000616c5-0f" 
mytux:~ # 

Siehe zum “blkid”-Befehl http://wiki.ubuntuusers.de/UUID und die man-Seiten.

Das dargestellte Ergebnis führte in meinem Fall natürlich ins Chaos.

Was also tun? Man muss in der von mir herbeigeführten Situation die UUID des Filesystems auf der kopierten Partition “dev/sdb15” ändern! Danach muss man den OS-Prober von Grub2 erneut laufen lassen und Grub2 neu installieren.

Zum Umsetzen der UUID von “/dev/sdb15” darf diese Partition nicht gemounted sein. Ist sie wie in meinem Fall mit “ext4” formatiert, ändert man die UUID (nach dem Unmounten) mit “tune2fs”:

mytux:~ # tune2fs -U `uuidgen` /dev/sdb15      
mytux:~ # blkid /dev/sdb15
/dev/sdb15: UUID="1dffa36e-b8ba-484b-81aa-577fe4c600c6" TYPE="ext4" PTTYPE="dos" PARTUUID="000616c5-0f"  

Ok. Im Anschluss die üblichen Schritte für die Konfiguration und Installation von “grub2” durchführen:

mytux:~ # grub2-mkconfig -o /boot/grub2/grub.cfg
mytux:~ # grub2-install --boot-directory=/boot /dev/sda

Siehe für Hintergrundsinformationen
https://activedoc.opensuse.org/book/opensuse-reference/chapter-10-the-boot-loader-grub2

https://fedoraproject.org/wiki/GRUB_2?rd=Grub2
http://www.dedoimedo.com/computers/grub-2.html
http://wiki.gentoo.org/wiki/GRUB2_Quick_Start

Die, die es sich einfacher
machen wollen, verwenden im aktuell gebooteten Opensuse-System (in meinem Fall also in dem eben neu installierten OS13.2) “Yast2 >> Bootloader”. Ich gehe hier nicht näher auf die von Opensuse gewählten Einstellungen zum Grub2-Bootloader ein. Wichtig ist, dass unter dem Reiter “Bootloader-Optionen” die Checkbox “Fremdes OS testen” einen Haken hat.

Danach wurde OS 13.1 sowohl von seiner ursprüglichen Partition “/dev/sda1/” als auch vom backup “dev/sdb15” scheinbar korrekt und mit konsistenten Einstellungen gebootet.

Stimmt das ? Nein, nicht wirklich. Denn wenn man sich die “/etc/fstab” der Kopie auf “/dev/sdb15” ansieht, steht da ja immer noch die ursprüngliche Partition der SSD als Boot-Partition drin :

/dev/disk/by-id/ata-Samsung_SSD_840_PRO_Series_S1AXNSAF109572J-part1 /	ext4  acl,user_xattr  1 1

Erstaunlicherweise funktioniert der Boot-Vorgang von der backup-Partition trotzdem und es ist danach gemäß der Grub2-Konfiguration auch wirklich “/dev/sdb15” auf “/” gemounted (man prüfe das mit “mount”). Den Eintrag in “/etc/fstab” müsste man natürlich noch ändern, falls man das “Backup” wirklich zum Arbeiten nutzen wollte und dafür eine konsistente Konfiguration haben möchte. Aber eigentlich ist das Arbeiten mit der Sicherungskopie nicht Sinn der Sache – das Backup soll ja eigentlich unangetastet bleiben. Ok, im vorliegenden Fall diente der Versuch der Vermehrung von Wissen …

Nachdem die Welt nun wieder in Ordnung und das Wissen um die Tücken des OS13.2-Installers hinreichend vermehrt war, konnte ich nun endlich auch ein erfolgreiches Upgrade des vorhandenen OS 13.1 auf “/dev/sda1” fahren!

Was haben wir durch die Upgrade- und Installationsversuche zu Opensuse OS 13.2 gelernt ?

Bzgl. Grub 2:

  • Behalte immer im Kopf, dass Grub2 UUIDs heranzieht, um Partitionen zu identifizieren. Überlege dir auf dieser Basis deine Backup- und Restaurierungs-Strategie bzgl. aller Konsequenzen (unter Vermeidung der Erzeugung doppelter UUIDs im gleichen System).
  • Lege Backups einer Partition, die du mit “dd” erzeugst, deshalb am besten nicht auf ein und demselben System an! Wenn doch ändere ggf. die UUID des Backup-Filesystems und merke dir die alte UUID für evtl. Restaurierungsarbeiten.
  • Bist du nach Neuinstallationen oder anderen Systemexperimenten gezwungen, das (mit “dd” erzeugte) Backup (evtl. ohne geänderte UUID) zurückzukopieren, dann ändere spätestens vor diesem Schritt die UUID der Backup-Partition. Und kümmere dich darum, dass die zurückgeholte Partition eine UUID erhält, die mit den aktuellen Grub2-Einstellungen kompatibel ist – oder lege mit Hilfe eines anderen, noch bootfähigen Systems Grub2 nach dem Rückkopieren komplett neu an (inkl. Durchlaufen des OS-Probers!).
  • Bei Booten eines Systems mit konventionellem BIOS : Unbedingt vorab oder während der Installation eine (kleine) unformatierte Partition vom Typ “BIOS GRUB” anlegen, wenn man eine reine GPT-partitionierte Festplatte oder eine MBR/GPT-Hybrid-Platte besitzt. Im Falle von (U)EFI ist sowieso eine EFI-Partition anzulegen.

Bzgl. der Opensuse 13.2 Installation von der DVD:

  • Unbedingt das alte System sichern.
  • Der grafische “Opensuse 13.2”-Installer kann Probleme mit Nvidia-Karten bekommen (grafisches Schirmbild mit fast unleserlichem Text, verwaschenem Kontrast und fehlerhafter Glättung). Er hat mit Sicherheit Probleme mit einer GTX 750 TI. Dann bei der Installation mal als Kernelparameter “nomodeset” eingeben oder unter F3 die Option “Keine KMS” wählen.
  • Ein Upgrade mit aktivem KMS führte bei mir (Nvidia-Karte, Opensuse 13.1) zum Scheitern der Installation im Verlauf der automatischen Konfiguration (der Systemgeräte) kurz vor dem Reboot.

Viel Spass nun bei euren eigenen Experimenten mit einem Opensuse 13.2 Upgrade oder einer OS 13.2 Installation!