Category Archives: Erfahrungsberichte

Erfahrungen aus dem Alltag eines Linux-Anwenders

Upgrade-Zeit – Vorsorge durch Fallback-Installationen – II

Posted on by

Im letzten Beitrag
Upgrade-Zeit – Vorsorge durch Fallback-Installationen – I
hatte ich versucht darzustellen, wie man mehrere parallele, bootfähige Linux-Installationen auf einem Einzelplatzsystem (PC, Laptop) nutzen kann, um die Arbeitsfähigkeit im Fall von Update/Upgrade-Problemen zu sichern. Man arbeitet normalerweise auf einer “Hauptinstallation“, die zu einer bestimmten Partition (z.B. “/dev/sdf7”) gehört.

Eine Fallback-Installation auf einer separaten Partition (z.B. “/dev/sdf9”) wird dagegen zu geeigneten Zeitpunkten als Abbild (Partitionskopie) eines funktionierenden Zustands der Hauptinstallation erzeugt und danach hinsichtlich von Updates extrem konservativ behandelt.

Updates/Upgrades werden grundsätzlich erst in einer dritten “Experimental-Installation” (z.B. auf “/dev/sdf3”) für Experimente getestet, bevor sie in der Hauptinstallation nachgezogen werden.

Nutz- und Projektdaten des/der Anwender werden dagegen auf speziellen Datenpartitionen untergebracht, die man in den jeweiligen Installationen bei oder nach einem Bootvorgang auf vorgegebene Knoten des Verzeichnisbaumes mountet. Das geschieht auf Basis gleichartiger Einträge für die Datenpartition(en) in den “/etc/fstab”-Dateien der verschiedenen Installationen; z.B.

myexp:~ # cat /etc/fstab
...
UUID=24f67362-236e-49ea-ba38-31c1c2541630       /projekte       ext4    defaults 1 2 
....

Diese Einträge werden beim Kopieren der entstehen im Rahmen der Erstellung der Fallback- und Experimental-Installation als Kopie der Hauptinstallation automatisch übernommen.

Ablauf zur Erstellung und Nutzung der Fallback- und der Experimental-Installation

Der Ablauf zur Erstellung und Nutzung der verschiedenen Installationen (auf jeweils unterschiedlichen Partitionen) ist in folgender Abbildung dargestellt:

Die Kuchendiagramme deuten die (wachsende) Partitionsverteilung an. Wir gehen nachfolgend auf einige wichtige Punkte ein, die bei der Erstellung von Partitionskopien als Grundlage der Fallback- und Experimental-Installation zu beachten sind.

Erstimplementierung Hauptinstallation plus Rettungssystem/Minimalinstallation

Die Erst-Installation eines Linux-Systems (z.B. Opensuse Leap 42.2) erfolgt wie üblich aus dem Netz oder per DVD. Man richtet dann seine Datenpartitionen ein und legt zugehörige Mount-Einträge in der “/etc/fstab” fest. Unter Opensuse unterstützt einen dabei der YaST-Partitioner. Dann “gewöhnt” man sich an das neue System und führt erste sinnvolle Updates durch.

Für die Erstellung der Fallback-Installation wollen wir den Inhalt der Partition, die die Hauptinstallation in einem definierten Zustand enthält, in eine andere (freie) Partition kopieren. Eine Kopie des gemounteten Root-Filesystems kann und sollte aber nicht aus der laufenden Hauptinstallation heraus erstellt werden. Der Grund ist einfach: Während der Kopie würden im Hintergrund stattfindende Schreiboperationen beim Kopieren nicht konsistent abgebildet werden. Das gleiche Thema gibt es ja bereits für Backups.

Wir benötigen daher eine weitere unabhängige Minimalinstallation (ohne grafischen Schnickschnack) in einer separaten Partition. Das dortige System booten wir dann zum Erstellen von Kopien anderer nicht gemounteter Partitionen. Alternativ können wir zum Kopieren natürlich auch ein ein Linux-Live-System einsetzen. Für Opensuse
Tumbleweed existieren entsprechende ISO-Images (siehe https://de.opensuse.org/openSUSE:Tumbleweed_installation).

Eine andere Alternative bietet ein Rettungssystem, wie es auf Installations-DVDs etlicher Distributionen vorhanden ist. Ein Rettungs- oder Live-System ist aber auch leicht zu erstellen (s. etwa http://www.system-rescue-cd.org/Download/, https://en.opensuse.org/SDB:Live_USB_stick, https://linux-club.de/wiki/opensuse/Installationsmedien_zu_openSUSE).

Hat man später bereits eine Experimental-Installation angelegt, so kann man natürlich auch die einsetzen, um die Partition der Hauptinstallation für eine Fallback-Installation auf eine andere Partition zu kopieren.

Partition für Kopie der Hauptinstallation erstellen

Eine Fallback-Installation entsteht am einfachsten durch Kopie der Partition mit der Hauptinstallation auf eine andere (Ziel-) Partition – und einige nachfolgende Schritte. Die Ziel-Partition muss man natürlich vor dem Kopiervorgang angelegt haben. Hierbei ist folgender Punkt wichtig:

Die Zielpartition muss mindestens die gleiche Größe haben wie die Original-Partition; die Zielpartition kann aber auch größer sein. Das gewährleistet man bei der Erstellung durch geeignete Wahl des Start- und Zielsektors (bzw. des Start- und End-Zylinders). Die Differenz – also die Anzahl der Sektoren (bzw. Zylinder) in der Zielpartition – sollte den gleichen Wert haben wie beim Original.

(Das Zusammenfallen von Partitionsgrenzen mit Zylindergrenzen ist ein Spezialthema für HDs mit MBR und sog. CHS-Adressierung; ich kann hier nicht darauf eingehen. Partitionierungstools achten in der Regel bei der Partitionsanlage auf eine entsprechende Optimierung. Auf Platten mit GPT-Partitionstabelle und LBA-Adressierung operiert man sehr viel einfacher mit Sektoren.)

Es gibt eine Reihe von Tools, um Partitionen aufzulisten, anzulegen und zu verändern. Für Opensuse hatten wir ja schon den “YaST-Partitioner” erwähnt. Interessanterweise bietet dieses Tool eine Dimensionierung neuer GPT-Partitionen über die Eingabe von Start/End-Zylinder an. Ein distributionsübergreifendes grafisches Tool ist “gparted” (welches auf dem CLI-Tool “parted” aufsetzt). gparted unterstützt natürlich GPT-HDs/SSDs und zeigt Start- und End-Sektoren für Partitionen an.

Daneben findet sich das CLI-Tool “fdisk“, das inzwischen auch mit GPT-Disks umgehen kann. Speziell für GPT-HDs/SSDS ist das CLI-Tool “gdisk” gedacht. Auch mit gdisk können wir die Größe neuer Partitionen präzise über Angaben zu Sektoren festlegen.

Die Sektor-Information sieht z.B. für zwei gleich große Partitionen “dev/sdf3”, “/dev/sdf7” einer Platte “/dev/sdf” unter fdisk wie folgt aus: 

myexp:~ # fdisk -l /dev/sdf
Disk /dev/sdf: 477 GiB, 512110190592 bytes, 1000215216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 04AD1B2B-6934-444D-BD93-83FE4A3AE15C

Device         Start       End   Sectors  Size Type
...
/dev/sdf3  171960320 339742719 167782400   80G Linux filesystem
...
/dev/sdf7  507590656 675373055 167782400   80G Linux filesystem

Ich ziehe auf GPT-Platten für eine präzise Dimensionierung jedoch meist “gdisk”
heran: 

myexp:~ # gdisk -l /dev/sdf 
GPT fdisk (gdisk) version 0.8.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdf: 1000215216 sectors, 476.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 04AD1B2B-6934-444D-BD93-83FE4A3AE15C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1000215182
Partitions will be aligned on 2048-sector boundaries
Total free space is 286739053 sectors (136.7 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048       167766015   80.0 GiB    8300  primary
   ....
   3       171960320       339742719   80.0 GiB    8300  primary
   ....
   7       507590656       675373055   80.0 GiB    8300  primary
   8       675373056       675710975   165.0 MiB   EF00  primary
myexp:~ #
myexp:~ # gdisk /dev/sdf
GPT fdisk (gdisk) version 0.8.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): i
Partition number (1-8): 7
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 85C6892A-D709-4A3F-9758-D521A7A11F68
First sector: 507590656 (at 242.0 GiB)
Last sector: 675373055 (at 322.0 GiB)
Partition size: 167782400 sectors (80.0 GiB)
Attribute flags: 0000000000000000
Partition name: 'primary'

Command (? for help): i
Partition number (1-8): 3
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 4C6C4872-1C36-465A-A09F-7CC0EF542E4D
First sector: 171960320 (at 82.0 GiB)
Last sector: 339742719 (at 162.0 GiB)
Partition size: 167782400 sectors (80.0 GiB)
Attribute flags: 0000000000000000
Partition name: 'primary'

Wie erstellt man nun eine weitere neue Partition mit identischer Größe? Wir machen das mal versuchsweise mit “gdisk”; dort gibt es dafür das Subkommando “n” (für “new”). Ein Blick in die man-Seiten zu “gdisk” zeigt übrigens auch, dass Änderungen erst dann wirksam werden, wenn wir unter gdisk abschließend den “w”-Befehl absetzen. 

myexp:~ # gdisk /dev/sdf
GPT fdisk (gdisk) version 0.8.8

Partition table scan:
... 
Found valid GPT with protective MBR; using GPT.
Command (? for help): n
Partition number (9-128, default 9): 
First sector (34-1000215182, default = 717672448) or {+-}size{KMGTP}: 
Last sector (717672448-1000215182, default = 1000215182) or {+-}size{KMGTP}: +167782400
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): 
Changed type of partition to 'Linux filesystem'

Command (? for help): p
Disk /dev/sdf: 1000215216 sectors, 476.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 04AD1B2B-6934-444D-BD93-83FE4A3AE15C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1000215182
Partitions will be aligned on 2048-sector boundaries
Total free space is 118956653 sectors (56.7 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048       167766015   80.0 GiB    8300  primary
   ...
   3       171960320       339742719   80.0 GiB    8300  primary
   ...
   7       507590656       675373055   80.0 GiB    8300  primary
   8       675373056       675710975   165.0 MiB   EF00  primary
   9       717672448       885454847   80.0 GiB    8300  Linux filesystem

Command (? for help): i
Partition number (1-9): 9
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 696C551B-591D-4411-A951-18D337F548D9
First sector: 717672448 (
at 342.2 GiB)
Last sector: 885454847 (at 422.2 GiB)
Partition size: 167782400 sectors (80.0 GiB)
Attribute flags: 0000000000000000
Partition name: 'Linux filesystem'

Command (? for help): q

Man beachte hier die GUID, die eine Partition in eindeutiger Weise auf einem Device identifiziert. Die GUID ist von einer sog. “UUID” des Filesystems (s.u.) in einer Partition zu unterscheiden !

Schreibt man die geänderte Partitionstabelle im letzten Schritt tatsächlich mit “w” auf die Platte, informiert “gdisk” den laufenden Kernel nicht über die Änderungen! Das geschähe ohne weitere Maßnahmen erst bei einem Reboot. Will man das vermeiden, hilft das CLI-Kommando “partprobe“, das zusammen mit dem Tool “parted” installiert wird. 

myexp:~ # partprobe /dev/sdf

es geht alternativ auch 

myexp:~ # /sbin/blockdev --rereadpt /dev/sdf

Kopieren der Partition mit der Hauptinstallation mit Hilfe des CLI-Kommandos “dd”

Ein “geeigneter Zeitpunkt” zum Erstellen einer Kopie der Hauptinstallation ergibt sich im laufenden Betrieb im Zuge von Updates nach einer Phase zufriedenstellender täglicher Arbeit. Steht man vor einer Upgrade-Aktion für sein Linux-System, wird man die laufende Hauptinstallation in jedem Fall kopieren und daraus eine bootfähige Fallback-Installation herstellen.

Für eine bitweise Kopie ist der Einsatz des CLI-Kommandos “dd” am einfachsten. Siehe zu einer Einführung bzgl. “dd” etwa https://wiki.ubuntuusers.de/dd/ und https://wiki.archlinux.de/title/Dd). “dd” ist unter Linux ein wirkliches wichtiges Werkzeug, das man in Kombination mit “gzip” und “tar” nicht zuletzt auch für die Erzeugung von Updates nutzen kann! Man sehe sich also zu “dd” unbedingt mal die man-Seiten und auch unten angegebene Links an.

Nehmen wir an, unsere aktuell benutzte Hauptinstallation liegt auf einer Partition “/dev/sdf7”. Auf der gleichen Platte befinde sich bereits eine Partition “dev/sdf9” gleicher Größe (man prüfe hierzu die Sektor- oder Zylinderanzahl in einem Partitionierungstool; s.o.). Aktuell gebootet worden sei eine Installation auf einer Partition “/dev/sdax” (x im Beispiel ungleich 7 oder 9) oder eben ein Live- oder Rettungs-System. Im gebooteten System erreicht man dann eine bitweise Kopie von “/dev/sdf7” auf “/dev/sdf9” per 

myexp:~ # dd if=/dev/sdf7 of=/dev/sdf9 bs=1M

Zum Parameter “bs” siehe die man-Seiten! Auf einer optimal angebundenen SSD dauert ein solcher Kopier-Prozess für eine “80 GByte”-Partition deutlich weniger als 10 Minuten. 

myexp:~ # dd if=/dev/sdf7 of=/dev/sdf9 bs=1M
81925+0 records in
81925+0 records out
85904588800 bytes (86 GB, 80 GiB) copied, 418.97 s, 205 MB/s

Die SSD operiert hier mit ca. 400 MB/s, da sie ja lesen und schreiben muss.

Haben wir damit schon unsere gewünschte “Fallback-Installation” erstellt? Da wir ja mit der Partition auch das dortige Filesystem samt Inhalten bitweise kopiert haben, könnte man meinen, dass mit der Kopie schon alles erledigt sei – und man nur noch den Bootmanager “Grub2” unter Einbeziehung aller verfügbaren OS-Installationen (z.B. mittels YaST2 >> Bootloader” neu schreiben lassen muss.

Das ist ein gewaltiger Irrtum!:

Warnung: Bitte schreibt nach Kopie einer Partition mit einer Betriebssysteminstallation nicht den Boot-Manager neu – und schon gar nicht unter Einbeziehung aller bootbaren Filesysteme.

Warum? Die Antwort gibt der nächste Abschnitt …

Vermeidung gleicher UUIDs
verschiedener Filesysteme nach dem Kopieren von Partitionen

Wenn wir eine Partition bitweise kopieren, wird der gesamte Inhalt (Filesystem + dessen Inhalte) 1:1 in die Zielpartition übertragen. Jedes Filesystem hat nun aber eine ID, die sog. “UUID“, die in einem System eindeutig sein sollte.

Die UUID eine Filesystems ist eine (hoffentlich eindeutige) Kombination aus alphanumerischen Zeichen. S. die nachfolgende Abbildung:

Die UUID vorhandener Partitionen kann man sich mit vielen Partitionstools und auch dem Kommando “tune2fs” anzeigen lassen. Ein geeignetes Kommando für die Kommandozeile ist aber auch “blkid“. Testet man unmittelbar nach unserem Kopiervorgang von “/dev/sdf7” auf “/dev/sdf9”, so erhält man 

myexp:~ # blkid | grep "sdf7\|sdf9"
/dev/sdf7: UUID="96c9a3bf-60fe-496e-801c-3a3047ac71a9" TYPE="ext4" PARTLABEL="primary" PARTUUID="85c6892a-d709-4a3f-9758-d521a7a11f68"
/dev/sdf9: UUID="96c9a3bf-60fe-496e-801c-3a3047ac71a9" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="6b579030-567a-4c7a-b705-34b55113d6d5"

Diese leider von uns selbst erzeugte Uneindeutigkeit hat nach dem Kopiervorgang noch keine unmittelbaren Folgen. Der Befund ist aber dennoch außerordentlich problematisch, denn es gilt:

Aktuelle Linux-Distributionen identifizieren zu mountende oder im Bootprozess anzusprechende Filesysteme (bzw. Partitionen) nämlich genau über die “UUID”.

Siehe zu der Thematik auch: https://wiki.ubuntuusers.de/UUID/. Unter Opensuses “YaST Partitioner” gibt es hierzu übrigens eine Grundeinstellung, die man auch modifizieren kann:

Unter Linux steuert u.a. die Datei “/etc/fstab” bekanntermaßen das Mounten von Filesystemen – u.a. auch des root-Filesystems – in bestimmten Phasen des Systemstart mit. Werden nun die zu mountenden Filesysteme (Partitionen) in der Datei “/etc/fstab” tatsächlich durch UUIDs gekennzeichnet, können schon beim nächsten Bootvorgang ernsthafte Probleme auftreten; es gibt nach unserer Partitionskopie mittels “dd” ja zwei Filesysteme mit derselben UUID!

Noch schlimmer werden die Verhältnisse, wenn wir auch noch die Grub2-Konfiguration unter Einschluss aller bootbaren Installation updaten; das ist dann ein sicherer Weg in den Abgrund; mit Doppelmounts auf “/” und nachfolgenden Katastrophen ist zu rechnen!

Deshalb gilt:

Warnung: Bevor man irgendetwas nach dem bitweisen Kopieren einer Partition in einen andere auf dem Datenträger ein und desselben aktiven Systems unternimmt, sollte man unbedingt die UUID des kopierten Filesystems ändern, sowie die Einträge in den dortigen Dateien “/etc/fstab” und “/boot/grub(2)/grub.cfg” an die neue Situation anpassen.
Nur dann werden wir die kopierten Installationen auch ohne Probleme bootfähig zu bekommen! Auf keinen Fall sollte man vor Erledigung dieser Schritte im aktuell gebooteten System die Bootloader-Konfiguration neu schreiben lassen.

Ändern der UUID im Filesystem der kopierten Partition

Wie ändert man die UUID eines (kopierten) Filesystems? Hierzu braucht man zwei Schritte:

  • Schritt 1: Generieren einer neuen UUID mittels des Befehls “uuidgen“
  • Schritt 2: Ändern der UUID auf der kopierten Partition mittels des Kommandos “tune2fs device -U newUUID“

Wir führen das mal am Beispiel unseres kopierten Filesystem auf der Partition “/dev/sdf9” durch: 

myexp:~ # uuidgen 
a65d6a9b-cc87-4af7-95bf-f407f463f344
myexp:~ # tune2fs /dev/sdf9  -U a65d6a9b-cc87-4af7-95bf-f407f463f344
tune2fs 1.42.11 (09-Jul-2014)
myexp:~ # blkid | grep "sdf7\|sdf9"
/dev/sdf7: UUID="96c9a3bf-60fe-496e-801c-3a3047ac71a9" TYPE="ext4" PARTLABEL="primary" PARTUUID="85c6892a-d709-4a3f-9758-d521a7a11f68"
/dev/sdf9: UUID="a65d6a9b-cc87-4af7-95bf-f407f463f344" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="6b579030-567a-4c7a-b705-34b55113d6d5"

Damit sind wir aber keineswegs fertig …

Anpassen der Datei “/etc/fstab” und der “/boot/grub2/grub.cfg” im kopierten Filesystem

Bevor wir den Bootloader neu schreiben lassen, ändern wir zunächst die Dateieen “/etc/fstab” und zur Sicherheit auch der “/boot/grub2/grub.cfg” ab. Hierzu mounten wir das frisch kopierte Filesystem im aktuell gebooteten System – z.B. auf “/mnt” -und ersetzen in der dortigen “fstab” (also in der /mnt/etc/fstab”) die Einträge mit der alten UUID:

myexp:~ # mount /dev/sdf9 /mnt
myexp:~ # cat /mnt/etc/fstab
UUID=d9a73a89-b89b-4fda-8c4c-9034e42d1274       swap    swap    defaults 0 0 
UUID=96c9a3bf-60fe-496e-801c-3a3047ac71a9       /       ext4    acl,user_xattr 1 1 
UUID=73B4-E5BA  /boot/efi       vfat    umask=0002,utf8=true 0 0 
UUID=24f67362-236e-49ea-ba38-31c1c2541630       /projekte       ext4    defaults 1 2 
....
....

Problematisch ist vor allem der zweite Eintrag, der noch die kopierte UUID beinhaltet! Diese UUID ändern wir nun mit Hile eines Editors unserer Wahl auf die neue – per uuigen generierte und per tune2fs zugeordnete – UUID ab: 

# cat /mnt/etc/fstab
UUID=d9a73a89-b89b-4fda-8c4c-9034e42d1274       swap    swap    defaults 0 0 
UUID=a65d6a9b-cc87-4af7-95bf-f407f463f344       /       ext4    acl,user_xattr 1 1 
UUID=73B4-E5BA  /boot/efi       vfat    umask=0002,utf8=true 0 0 
UUID=24f67362-236e-49ea-ba38-31c1c2541630       /projekte       ext4    defaults 1 2 
....

Damit haben wir schon mal größeres Unglück verhindert. Eine Anpassung der “/etc/fstab” ist der wichtigste Schritt.

Ganz auf die sichere Seite gegenüber späteren manuell verursachten Fehlern kommen wir aber erst mit entsprechenden Änderungen in der Datei “/mnt/boot/grub2/grub.cfg” – oder aber einer Elimination der Datei für das (versehentliche) Schreiben des Bootloaders unter der neuen Installationm. .

In der “/mnt/boot/grub2/grub.cfg” finden sich Boot-Einträge der Form 

menuentry 'openSUSE 42.2 (x86_64) (on /dev/sdf7)' --class suse --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-96c9a3bf-60fe-496e-801c-3a3047ac71a9' {
	insmod part_gpt
	insmod ext2
	set root='hd5,gpt7'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd5,gpt7 --hint-efi=hd5,gpt7 --hint-baremetal=ahci5,gpt7  96c9a3bf-60fe-496e-801c-3a3047ac71a9
	else
	  search --no-floppy --fs-uuid --set=root 96c9a3bf-60fe-496e-801c-3a3047ac71a9
	fi
	linuxefi /boot/vmlinuz-4.4.104-18.44-default root=UUID=96c9a3bf-60fe-496e-801c-3a3047ac71a9 ro resume=/dev/disk/by-uuid/d9a73a89-b89b-4fda-8c4c-9034e42d1274 splash=silent quiet showopts elevator=deadline intel_pstate=disable swapaccount=1 pti=on
	initrdefi /boot/initrd-4.4.104-18.44-default
}
submenu 'Advanced options ......
....
......

Würden wir diese “grub.cfg” (nach einem Booten der kopierten Installation) dummerweise direkt zur Implementierung des
Bootloaders per “grub-install” nutzen, gäbe es ein vermeidbares Chaos.

In der Datei müssen wir deshalb natürlich alle Strings “96c9a3bf-60fe-496e-801c-3a3047ac71a9” ersetzen durch “a65d6a9b-cc87-4af7-95bf-f407f463f344”. Das geht mit Editoren wie “kate” relativ gefahrlos.

Ein noch einfacherer Schritt zur Absicherung gegenüber späteren potentiellen Unglücken durch manuelle Befehle zum Schreiben des Bootloaders ohne vorherige Neugenerierung der “boot.cfg” ist, die Datei schlicht umzubenennen – und damit für versehentliche Installationen auszuschalten: 

    
myexp:~ # mv /mnt/boot/grub2/grub.cfg /mnt/boot/grub2/grub_before_copy_180219.cfg_orig

Bootfähigkeit der neuen Installation herstellen

Natürlich schreiben wir den Bootloader aber eher von der funktionierenden “ursprünglichen” Hauptinstallation aus. Haben wir die “etc/fstab” in er kopierten Partition auf die neue UUID angepasst, können wir – ohne vorheriges Verändern des Grub2-Bootloaders – unser System getrost neu booten und dabei die ursprüngliche Hauptinstallation starten. Von dort aus nehmen wir nun eine Erweiterung des Bootloaders vor, so dass dei neue “Fallback”-Installation später im Grub2-Bootmenü mit angeboten wird.

Unter Opensuse nutzen wir dazu YaST’s Bootloader-Modul:

Dieses Programm bietet 3 per Reiter (Tabs) erreichbare Konfigurationsseiten an. Die letzte ist für unsere Zwecke am wichtigsten und sieht wie folgt aus:

Hier müssen wir die Option “Fremdes OS testen” abhaken.

[Zu alternativen CLI-Kommandos “grub_mkconfig”, “update-grub” (Ubuntu) bzw. “grub2-mkconfig” (Opensuse) und “grub-install” siehe den letzten Beitrag und die Doku eurer Distribution. Unter Opensuse Leap prüft “grub2-mkconfig” durch Aufruf des “os-prober”-Skripts fremde OS gleich mit und schreibt den gesamten Output defaultmäßig in die “/boot/grub2/grub.cfg”.]

Danach finden wir in der Datei “/boot/grub2/boot.cfg” Einträge folgender Art zum Filesystem auf “/dev/sdf9” vor: 

 
....
### BEGIN /etc/grub.d/30_os-prober ###
...
...
menuentry 'openSUSE 42.2 (x86_64) (auf /dev/sdf9)' --class suse --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-a65d6a9b-cc87-4af7-95bf-f407f463f344' {
	insmod part_gpt
	insmod ext2
	set root='hd5,gpt9'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd5,gpt9 --hint-efi=hd5,gpt9 --hint-baremetal=ahci5,gpt9  a65d6a9b-cc87-4af7-95bf-f407f463f344
	else
	  search --no-floppy --fs-uuid --set=root a65d6a9b-cc87-4af7-95bf-f407f463f344
	fi
	linuxefi /boot/vmlinuz-4.4.104-18.44-default root=/dev/sdf9
	initrdefi /boot/initrd-4.4.104-18.44-default
}
submenu 'Erweiterte Optionen für openSUSE 42.2 (x86_64) (auf /dev/sdf9)' $menuentry_id_option 'osprober-gnulinux-advanced-a65d6a9b-cc87-4af7-95bf-f407f463f344' {
	menuentry 'openSUSE 42.2 (x86_64) (auf /dev/sdf9)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.4.104-18.44-default--a65d6a9b-cc87-4af7-95bf-f407f463f344' {
		insmod part_gpt
		insmod ext2
		set root='hd5,gpt9'
		if [ x$feature_platform_search_hint = xy ]; then
		  search --no-floppy --fs-uuid --set=root --hint-bios=hd5,gpt9 --hint-efi=hd5,gpt9 --hint-baremetal=ahci5,gpt9  
a65d6a9b-cc87-4af7-95bf-f407f463f344
		else
		  search --no-floppy --fs-uuid --set=root a65d6a9b-cc87-4af7-95bf-f407f463f344
		fi
		linuxefi /boot/vmlinuz-4.4.104-18.44-default root=/dev/sdf9
		initrdefi /boot/initrd-4.4.104-18.44-default
	}

Diese Einträge im Boot-Menü hat YaSTs Bootloader-Modul dann auch schon gleich auf der Platte verewigt. Sie werden beim nächsten Bootvorgang mit angeboten.

Damit haben wir unsere durch “dd” erzeugte “Fallback-Installation” auf “/dev/sdf9” bootfähig verankert.

Experimental-Installation und Upgrade

Eine Experimental-Installation” erzeugt man in einer weiteren Partition auf ganz ähnliche Weise wie oben beschreiben und macht auch diese nach UUID-Änderung und Anpassung der dortigen “/etc/fstab” bootfähig. Für die Experimentalinstallation kann man dann eine probeweises Upgrade vornehmen. (Im Beispiel von Opensuse Leap 42.2 auf Leap 42.3 …).

Andere Einstellungen in der “/etc/fstab”

Das “Gefährliche” bestand bei unserem Vorgehen vor allem in der Duplizierung der UUID – und eventuellen diesbezüglichen Einstellungen in der “/etc/fstab”. Natürlich kann man die Einträge in der “/etc/fstab” auch auf Basis konventioneller Laufwerksbezeichnungen (“dev/sdxn”) vornehmen.
Der Yast-Partitioner bietet hierfür sogar eine Einstellungsoption an:

Einträge mit normalwer Bezeichnung sähen so aus: 

 
/dev/sdf9       /       ext4    acl,user_xattr 1 1

Dies befreit aber aus einer Vielzahl von Gründen nicht davon, die UUID des Filesystems trotzdem abzuändern.

SSDs – und Intervalle für Partitionskopien

Eine Kopie größerer Partitionen durchzuführen ist schreibintensiv. Nicht alle SSDs haben eine hinreichende Qualität, um solche Schritte oft durchführen zu können. Die SSD leidet darunter (wear leveling count). Man sollte die Erstellung einer neuen “Fallback-Installation” als Kopie der Hauptinstallation daher nur in größeren Zeitabständen vornehmen.

Hat man gute Erfahrungen mit Updates sowohl in der Experimental-Installation als auch auf der Hauptinstallation gemacht, spricht ja nichts dagegen, Updates auch auf der Fallback-Installation systematisch und kontrolliert nachzuziehen. Nur vor Upgrades erscheint mir die Anlage einer Fallback-Installation als Kopie der aktuellen Hauptinstallation unvermeidlich.

Ich hoffe, der eine oder andere hat beim Lesen ein paar Dinge aufgeschnappt, die er noch nicht kannte …

Links

Übersicht GPT
https://en.wikipedia.org/wiki/GUID_Partition_Table
https://de.wikipedia.org/wiki/GUID_Partition_Table
https://www.thomas-krenn.com/de/wiki/GUID_Partition_Table

Übersicht Linux Partitioning Tools
http://dwaves.de/2017/05/23/linux-overview-partitions-difference-fdisk-gdisk-cfdisk-parted-gparted/

Partition Alignment
https://www.thomas-krenn.com/de/wiki/Partition_Alignment

UUID ändern
http://www.sudo-juice.com/how-to-change-the-uuid-of-a-linux-partition/

Backups mit dd
https://www.linux.com/learn/full-metal-backup-using-dd-command
https://wiki.archlinux.de/title/Image-Erstellung_mit_dd
https://www.thegeekstuff.com/2010/10/dd-command-examples/
http://www.linux-community.de/Archiv/Tipp-der-Woche/Mit-dd-schnell-Festplattenimages-erstellen
https://www.thomas-krenn.com/de/wiki/Dd_unter_Linux

Upgrade-Zeit – Vorsorge durch Fallback-Installationen – I

Posted on by

Vor wenigen Wochen lief bei Opensuse und bei Ubuntu der Supportzeitraum für die jeweils vorletzten Versionen ab. Ein Leser des Blogs hat mich angeschrieben und gebeten, mal für einen Linux-Einsteiger zu beschreiben, wie ich denn bei System-Upgrades “immer wieder auftauchenden Problemen aus dem Weg” ginge.

Erste spontane Antwort: Gar nicht 🙂 ; Probleme tauchen halt auf und sind zu lösen oder zu umgehen. Ich habe die Frage dann aber mal wie folgt interpretiert:

Wie erhält man sich trotz möglicher Upgrade-Probleme die Fähigkeit zum beruflich dringend erforderlichen Weiterarbeiten, wenn es nach dem Upgrade Probleme gibt?

Das ist durchaus ein paar Betrachtungen wert. Gerade Freiberufler können sich Arbeitsausfälle aufgrund “zerschossener” Systeme nicht leisten. Das betrifft bei mobilen Beratern u.a. Laptop-Installationen.

Beim Schreiben fiel mir allerdings auf, dass ich vor Upgrades/Updates alleinstehender Linux-Systeme zu Methoden greife, in die sich ein “Einsteiger” erst mal einarbeiten muss und die selbst auch ein gewisses Gefahrenpotential in sich bergen. Leute, das kann ich euch leider nicht ersparen. Deshalb vorweg:

Bitte seid bei einer Nachahmung der nachfolgenden Vorschläge extrem vorsichtig, macht Backups und testet erstmal in einer risikofreien Umgebung – im Besonderen das Kopieren von Festplatten-Partitionen. Ich hafte nicht bei Schäden.

Ferner benötigt man für meinen Ansatz HDs/SSDs mit 500GB aufwärts; man braucht Plattenplatz. Dennoch hat sich die nachfolgend beschriebene Methodik bewährt; sie hat mir schon des öfteren wertvolle Zeit für Problemlösungen verschafft. Die Vorgehensweise hat aber nur einen Sinn auf Einzelplatz-Systemen; sie ist nicht (!) für Server oder Firmen-Installationen geeignet. Und: Sie ersetzt keineswegs (regelmäßige) Backups auf externe Medien!

Frust nach und mit Upgrades/Updates unter Linux? Ja, das gibt es …

Viele Linux-Einsteiger beschreiben ein gar nicht so seltenes Erlebnis mit ihrem Desktop- oder Laptop-System so: “Dann hab’ ich mein Linux upgedated bzw. upgegradet und dabei wohl was falsch gemacht – und mir das System zerschossen. Musste neu installieren.“. (Siehe u.a. Linux-Foren unter Facebook). Das sollte eigentlich unter Linux nicht so ablaufen … passiert aber dennoch.

Ein Grund ist vermutlich: Für Einsteiger ist schwer zu erkennen, was mögliche Ursachen für das “Zerschießen” sind und wo bzw. wie man die richtigen Maßnahmen zur Korrektur einleitet. Der Wunsch, möglichst schnell wieder arbeiten zu können, führt dann gerade bei Windows-Umsteigern fast reflexartig zu Neuinstallationen.

Was manchmal schon im Zuge komplexer Packet-Updates passiert, gilt erst recht für Linux-System-Upgrades, bei denen womöglich auch noch an Grundfesten des Systems gerüttelt wird (wie etwa bei der Einführung von systemd, neuen KDE-Haupt-Versionrn, etc…). Spätestens nach der ersten schlechten Erfahrung mit einem System-Upgrade stellt man sich beim nächsten Mal Fragen:

Soll ich (nach einer Datensicherung) die neue Linux-Version auf einer neuen oder der bisherigen System-Partition ganz von Null neu installieren? Oder die alte Installation durch komplizierte Schritte auf die neue Version bringen? Mit dem Risiko, dass dabei etwas schiefgeht, das System nicht mehr bootet, man sich nicht mehr einloggen kann oder die graphische Oberfläche nicht mehr läuft? Und man nicht mehr produktiv arbeiten kann?

Das sind alles berechtigte Fragen! Frustrierende Erlebnisse mit System-Komponenten, die nach Updates/Upgrades nicht mehr erwartungsgemäß funktionieren, haben nämlich auch erfahrene Linux-User immer wieder. Glaubt keinem, der etwas anderes behauptet!

Auch unter Linux gilt: Shit happens! Und oft genug liegt die Schuld nicht mal bei einem selbst … Linux
ist halt ein komplexes Konglomerat aus unterschiedlichen Komponenten, die von unterschiedlichen Teams entwickelt werden. Die Zusammenstellung übernehmen Distributoren, die auch nicht jede mögliche Installationsvariante testen können. Hinzu kommen ggf. problematische Treiber, u.a. für Grakas. Ergebnis: Fehler treten häufiger auf, als einem als Linux-Fan lieb wäre ….

Vorsorge und Arbeits-“Continuity”

Erfahrene Linux-Nutzer sorgen vor, indem sie eine funktionierende Arbeitsumgebung vorhalten. Komplette Neuinstallationen sind bei Update-Problemen nur selten der richtige Weg: erstens lernt man durch Neuinstallationen nichts und zweitens besteht die Gefahr, wieder in die gleiche Falle zu tappen. Im Falle von System-Upgrades führt eine Neuinstallation dagegen zum mühsamen Nachziehen von bereits getroffenen Konfigurationsentscheidungen – und ohne Rückgriff auf eine noch funktionierende Installation ist das Arbeiten in dieser Phase ggf. eingeschränkt.

Natürlich denkt man vor Updates/Upgrades an Backups der vorhandenen funktionstüchtigen Installation auf externe Medien. Das setzt voraus, dass man sich mit der Restaurierung ganzer Betriebssysteme und den zugehörigen Linux-Tools befasst. Zu dieser wichtigen Grundübung findet man viele hilfreiche Artikel im Internet. Ich möchte in diesem Artikel aber eine andere, zusätzliche Maßnahme besprechen – und zwar den den Ansatz einer

vorsorgenden Partitionierung – unter Einschluss jederzeit bootbarer “Fallback- und Experimental-Partitionen”.

Das ersetzt (regelmäßige) Backups (u.a. für den Fall vom Plattendefekten) keineswegs, erleichtert aber den Umgang mit komplexen Updates oder System-Upgrades.

Motivation ist die Aufrechterhaltung der Möglichkeit zum schnellen Fortsetzen der produktiven Arbeitfür den Fall, dass beim Updaten/Upgraden etwas schief geht. Man spricht auch von ArbeitsKontinuität oder neudeutsch “Continuity“, die eben die Verfügbarkeit funktionierender Installationen voraussetzt.

Nun höre ich schon die Profis fragen: Schon mal was von Snapshots gehört? Ja, aber der von mir beschriebene Ansatz ist auch dann wirkungsvoll, wenn man sich mit Snapshot-Systemen (wie etwa auf Basis von BtrFS oder LVM2) noch nicht auskennt. Zudem sind Filesystem-Snapshots bei vollständigen System-Upgrades eher in Frage zu stellen.

Voraussetzungen und Zielgruppe

Der Artikel richtet sich an Linux-Ein/Um-Steiger, die schon ein paar Schritte mit dem System gegangen sind und sich bereits ein wenig in Plattenpartitionierung wie den Systemstart über Boot-Manager eingearbeitet haben – oder willens sind, das zu tun. So setze ich voraus,

  • dass man weiß, was Partitionen (oder ggf. LVM-Volumes) und Filesysteme sind, wie man die mit entsprechenden Tools seiner Linux-Distribution oder auf der Kommandozeile erstellt, dimensioniert und in den Hauptverzeichnisbaum einhängt (mounted),
  • dass man bereit ist, sich mit den Befehlen “dd”, “uuidgen” und “tune2fs” auseinanderzusetzen
  • dass man keine Scheu hat, System-Dateien zu editieren.
  • dass man bereit ist, sich ein wenig um Grub2 als Boot-Manager auseinanderzusetzen.
  • dass genügend Festplattenplatz vorhanden ist, um 3 Betriebssystem-Partitionen mit einer Größe von etwa 40 bis 80 GByte aufzunehmen.

Der letzte Punkt mag dem einen oder anderen als Platzverschwendung erscheinen. Ja, das erscheint mir aber in der Abwägung gegenüber dem Punkt “kontinuierliche Arbeitsfähigkeit” und auch gegenüber der Schonung von Nerven zweitrangig.

Übrigens: Bis auf spezielle EFI- und Swap-Partitionen, verwende ich den Begriff “Partition” nachfolgend auch synonym für logische LVM2-Volumes. Das ist technisch natürlich nicht korrekt; der Unterschied tut
hier aber nichts zur Sache. LVM2 ist im besonderen mit dem Grub2-Boot-Manager kompatibel. Wem die Begriffe LVM2 und LVM-Volume nichts sagen, kann deren weitere Erwähnung in Klammern erstmal getrost ignorieren.

Ich erläutere die hier verfolgte Philosophie einer Fallback-Partition für Desktop-Systeme und Laptops anhand von Opensuse. Die Grundprinzipien lassen sich meist aber einfach auf andere Distributionen wie etwa Ubuntu abbilden – auch wenn sich ein paar Bezeichnungen von Dateien oder Programmen leicht unterscheiden. Es geht mir auch nur um alleinstehende Desktop-/Laptop-Systeme, auf denen man weitgehend der Herr des Geschehens ist – nicht aber um Server-Systeme oder server-basierte Installationen; letztere erfordern andere Fallback- und Continuity-Strategien.

Vier Maxime für den Umgang mit Updates/Upgrades

Beim Umgang mit kritischen Updates von Systemkomponenten oder gar Upgrades des Betriebssystems orientiere ich mich an folgenden Leitlinien:

  • Never touch a running system – ohne die Konsequenzen zu kennen oder solide einschätzen zu können.
  • Haupt-Installation und separate Partitionen für Nutz- und Anwendungsdaten: Die Betriebssystem-Installation für den täglichen Gebrauch erfolgt auf einer Festplattenpartition begrenzter Größe. Es wird von vornherein eine getrennte Ablage von OS-System-Dateien einerseits und späteren Projekt-Daten (Applikationsdaten, Nutzerdateien, ggf. Virtualisierungsumgebungen) andererseits auf unterschiedlichen Partitionen (LVM-Volumes) der Systemplatte(n) angestrebt.
  • Fallback-Installation: Im beruflichen Einsatz muss man bei Problemen schnell auf eine noch funktionierende Installation zurückgreifen können – hierzu braucht es eine jederzeit bootbare Fallback-Installation auf einer weiteren, separaten Partition der HD/SSD des Systems.
  • Experimental-Installation: Man braucht eine Spielwiese, um neue Programme, aber auch umfassendere oder kritische Updates/Upgrades gefahrlos ausprobieren zu können. Eine entsprechende dritte Betriebssystem-Installation sollte auf einer weiteren eigenen Partition (Volume) untergebracht werden.

Während die erste Maxime übergreifend gilt, haben die anderen drei offenbar eine Auswirkung auf die Partitionierung (und/oder das LVM-Layout) des Systems. Die “Methodik” zur Erhaltung der Arbeitsproduktivität besteht also darin,

  • dass man eine garantiert funktionsfähige Fallback-Installation in bootfähigem Zustand bereit hält,
  • dass man komplexe Updates/Upgrades erstmal auf einer Experimental-Installation austestet, bevor man die Updates/Upgrades auf der Haupt-Installation nachzieht.
  • dass man zu geeigneten Zeitpunkten sowohl die Fallback-Installation als auch die Experimental-Installation als Kopie eines funktionierenden Zustands der Hauptinstallation erneuert. (Falls in zeitlicher Nähe: zuerst die Experimental-Installation und dann die Fallback-Installation.)

Das ist zunächst mal einfach und hoffentlich auch einleuchtend. Wie man die Partitions-“Kopien” erzeugt und dabei Boot-Probleme vermeidet, besprechen wir später. Zunächst gilt:

“Continuity” erfordert, mehrere funktionierende Betriebssystem-Installationen auf ein und demselben System vorzuhalten. Eine dient als Fallback für das produktive Arbeiten, wenn es mal zu Problemen mit der “Haupt-Installation” kommt. Die Fallback-Installation ist daher bzgl. Updates extrem vorsichtig zu behandeln. Ggf. wird man Updates sogar völlig unterlassen. Die Funktionstüchtigkeit dieser Installation ist wichtiger als ein aktueller Paket-Status!

Alle drei in der Liste angesprochenen Installationen müssen separat bootbar sein – und die Daten, mit denen man kontinuierlich (weiter-) arbeiten will, müssen deshalb unabhängig von den einzelnen OS-Installationen gelagert werden.

Ein Zugriff auf produktive Projekt-Daten muss von jeder der drei Installationen aus durch ein “Mounten” des Filesystems der Datenpartitionen in definierte Knotenpunkte des jeweiligen Verzeichnisbaums in gleichartiger Weise ermöglicht werden (s.u.).

Wir benötigen jedenfalls mehrere Partitionen (oder LVM-Volumes) auf der/den Systemplatte/n. Das kann dann in etwa so aussehen:

Die erste Aufgabe für den Linux-Einsteiger, der der obigen Philosophie folgen will, ist also:

Mache dich mit der Partitionierung einer Festplatte und Tools wie etwa “gdisk“, “gparted” oder unter Opensuse auch mit dem “Yast Partitioner” vertraut. Zur Einrichtung eines reinen Linux-Systems sollte man dabei auch schon mal was von ein GPT-Layout von Festplatten gehört haben – und sich (soweit möglich) von veralteten Dingen wie “erweiterten Partitionen” aus MSDOS- bzw. MBR-Zeiten lösen. Siehe etwa: https://wiki.ubuntuusers.de/Partitionierung/Grundlagen/, http://www.linux-community.de/Internal/Artikel/Print-Artikel/EasyLinux/2016/01/OpenSuse-Leap-42.1, https://kofler.info/opensuse-leap-42-1/.

(Merke nebenbei: MS Windows gehört unter Linux eigentlich ins “Fenster”; genauer in eine virtuelle Maschine; zumindest dann, wenn man Windows nicht für 3D-Games benötigt. Auf sowas wie eine primäre NTFS-Partition in einem MBR-Plattenlayout kann man dann völlig verzichten. Will man eine vorhandene NTFS-Windows-Partition aber aus berechtigten (!) Lizenz-Ängsten und auf UEFI-Systemen aus Ängsten vor Boot-Fehlern nicht zerstören, sollte man sie in jedem Fall verkleinern. Die meisten Linux-Installationsprogramme bieten das an.)

Partitionsgrößen für die Betriebssystem-Installationen relativ klein halten!

Als Einsteiger tendiert man dazu, während der Linux-Erstinstallation ein vom Installer der jeweiligen Distribution vorgeschlagenes Partitionsmuster für die Festplatten zu übernehmen. Die meist vorgeschlagenen 2 oder 3 Linux-Partitionen (neben einer Swap- und ggf. auch einer EFI-Partition) umfassen dann insgesamt oft den gesamten Plattenplatz. Kennt man sich dann aber nicht mit so schönen Dingen wie LVM aus, nimmt einem das erhebliche Flexibilität!

Leuten mit ein wenig Erfahrung rate ich deshalb eher dazu, sich im Vorfeld einer Installation genau zu überlegen, welche Partitionen man tatsächlich für welche Zwecke auf seinem Desktop-System benötigt. Den Platz für die zu hauptsächlich zu nutzende Betriebssystem-Installation sollte man dabei auf das Notwendige (s.u.) begrenzen und den Rest der Platte erstmal frei halten.

Zweite Aufgabe für Umsteiger:

Bei der ersten Installation von Linux sollte man die Partition für das Root-Filesystem in der Größe begrenzen; sinnvolle Werte liegen nach meiner Erfahrung zwischen 40GB und 80GB. Das lässt einem genügend Luft für Programm-Installationen und Experimente. Persönlich nehme ich meist 80 GB. Den Vorschlag für eine Swap-Partition kann man übernehmen. Auf weitere Partitionen (etwa wie oft vorgeschlagene für “/home”) kann und sollte man dagegen erst mal verzichten; sie kann man später bei Bedarf immer noch anlegen.

(Bei Nutzung von LVM sollte man unabhängig von der zugrunde liegenden Partitionierung und Volume-Gruppen das logische Volume für das Root-Filesystem begrenzen). Auf einem reinen Linux-PC-System gibt es in meinem Ansatz daher zunächst nur : ggf. eine EFI-Partition, eine rel. kleine Swap-Partition (< 4GB) und eine Partition für das Root-/-Filesystem (mit 40 bis 80GB; in ext4-Formatierung, s.u). Sonst nix!

Wir nutzen den freigelassenen Plattenplatz für unsere Daten-Partition(en) und für weitere Partitionen (Volumes), die unsere Fallback- bzw. Experimental-Installation aufnehmen. Wir werden die Inhalte der Fallback-Partition und der Experimental-Partition später als Kopien eines bestimmten Zustands der Hauptinstallation erstellen. Wir benötigen also mindestens 2 x die Größe der Partition für die Hauptinstallation (also z.B. 3 x 80GB) als freien Plattenplatz; den Rest können wir für eine oder mehrere Datenpartitionen nutzen. (Hinweis: Will man mit schnellen Virtualisierungssystemen arbeiten, braucht man ggf. auch dafür weitere Partitionen (Volumes).)

Unter Opensuse wird während der Installation der sog. YaST-Partitionmanager angeboten. Er erlaubt eine Reduktion der Partitionsgröße im sog. “Expertenmodus”. Ein weiterer Punkt: Nehmt als Anfänger lieber “ext4” als Filesystem und nicht BtrFS. Ich habe hierfür gute Gründe, die ich aus Platzmangel an dieser Stelle aber nicht erläutern kann.

Hat man aber die Erstinstallation bereits hinter sich und wurden dabei zu große Partitionen angelegt, muss man im Nachhinein Platz schaffen. Hierbei muss man sich mit Hilfe der genannten Partitionierungstools dazu kundig machen, welche Partitionen im aktuellen Zustand noch wie weit verkleinert werden können. Danach kann man die vorhandenen Partitionen mit Hilfe der Partitionstools in der Größe reduzieren. Ggf. muss man dazu vorher ein Live-System oder eine Rettungsinstallation von CD/DVD oder USB-Disk booten.

Einsatz eines Bootmanagers – Grub2

Unsere Strategie läuft auf mehrere bootbare Linux-Installationen hinaus. Linux erlaubt über die Installation von sog. “Boot-Managern” das Booten verschiedener Betriebssystem-Installationen aus unterschiedlichen Partitionen der HDs/SSDs des Systems. Hierzu wird einem beim Systemstart eine Liste verfüg- und bootbarer Installationen angezeigt.

Bootmanager werden von den meisten Linux-Distributionen bereits im Rahmen der Erstinstallation des Systems eingerichtet. Der aktuelle distributionsübergreifende Standard ist hierbei wohl “Grub2“. Eine gute Übersicht über diesen relativ komplexen Bootmanager liefern folgende Artikel:

https://en.wikipedia.org/wiki/Grub2#GRUB_version_2
https://opensource.com/article/17/3/introduction-grub2-configuration-linux
https://wiki.ubuntuusers.de/GRUB_2/ und https://wiki.ubuntuusers.de/GRUB_2/Konfiguration/
Für Details siehe: https://www.gnu.org/software/grub/manual/grub/grub.pdf

Ich kann in diesem Artikel aus Platzgründen nicht auf Details von Grub2 eingehen. Für unsere Zwecke ist es ausreichend zu wissen, dass der Grub2-BootLoader in drei Schritten installiert oder modifiziert wird: Zunächst wird aus Vorgaben in der Definitionsdatei “/etc/default/grub” und weiteren Skript- und Konfigurations-Dateien unter dem Verzeichnis “/etc/grub.d/” eine temporäre Konfigurationsdatei erzeugt. Der notwendige Befehl ist je nach Distribution “grub-mkconfig” (z.B. Ubuntu) oder “grub2-mkconfig” (z.B. Opensuse). Das Ergebnis kann man dann über die Kommandozeile mit dem Kommando “update-grub” in die Datei “/boot/grub/grub.cfg” (Ubuntu) bzw. “/boot/grub2/grub.cfg” (Suse) schreiben lassen. Schließlich
schreibt man dann die notwendigen Informationen und Boot-Programme mittels des CLI-Befehls “grub-install” (Ubuntu) oder “grub2-install” (Suse) in bestimmte Plattenbereiche (die wiederum u.a. vom Platten-Layout, GPT oder MBR abhängen).

Spezialtools der verschiedenen Distributionen führen zumindest Teile oder gar alle dieser Schritte in einem Arbeitsvorgang durch:
Opensuse: Yast2 >> System >> Bootloader”
Ubuntu: z.B. Grub Customizer (https://www.pcwelt.de/ratgeber/Grub-Bootloader_anpassen-10017211.html, https://www.bitblokes.de/den-bootloader-via-gui-im-griff-grub-customizer/, https://wiki.ubuntuusers.de/GRUB_Customizer/)
Diese Tools erlauben es auch, die Systempartitionen nach anderen bootbaren Installationen durchsuchen zu lassen – und binden letztere in die Auswahlliste des Boot-Menüs ein.

In unserem Kontext ist/wird vor allem die Konfigrationsdatei “/boot/grub[2]/grub.cfg” relevant. Man kann diese Datei zur Not auch mit einem Editor modifizieren, wenn man sicher ist, was dabei zu tun ist. Wir werden weiter unten lediglich bestimmte begrenzte Strings der “grub.cfg” (in kopierten Partitionen) durch andere ersetzen.

Dritte Aufgabe für Umsteiger:

Befasst euch mit dem Boot-Vorgang und dem Grub2-Boot-Manager.

Nutzdaten auf separaten Partitionen – und die besondere Rolle des eigenen Home-Verzeichnisses “~”

In meiner “Methodik” ist die Unterscheidung zwischen Partitionen für die Systeminstallation einerseits und für Nutzdaten andererseits essentiell. Die meisten Nutzdaten, die man als Benutzer anlegt, lassen sich in Projekte und eigene Ordnerhierarchien gliedern und schlagen sich in dortigen Dateien nieder (z.B. Text-Dateien, Präsentationen, selbst entwickelte Programme, Bilder, Movies …). Hinzu kommen Daten wie Favoriten aus bestimmten Applikationen, die man meist aber zur Sicherungszwecken in separate Files exportieren und importieren kann. Selbst den Ablageort von Datenbank-Dateien kann man meist selbst festlegen. Für all diese Daten lege ich grundsätzlich eine oder mehrere eigene Partitionen (LVM-Volumes) mit zugehörigen Filesystemen (ext4) an, die auf selbst definierte Knotenpunkte im Dateibaum gemountet werden – etwa in Subverzeichnisse unter “/mnt” (/mnt/MyProjects, /mnt/MySamba, /mnt/MyPics …). Eine von der System-Installation unabhängige Datenhaltung vereinfacht im übrigen Backups erheblich.

Hat man die Nutzdaten erstmal vom OS-“Rest” absepariert, so können die Nutzdaten über Filesystem-Mounts in jede funktionierende und gebootete Betriebssysteminstallation eingebunden werden. Die Vorgaben dazu hinterlegt man in der jeweiligen Datei “/etc/fstab”; s. hierzu die man-Seiten oder https://wiki.ubuntuusers.de/fstab/. Unter Opensuse kann man die Einträge auch mit dem YaST-Partitionmanager vornehmen lassen. Natürlich muss man die Dateien und Mount-Punkte jeweils mit den nutzerbezogenen Rechten versehen.

Es ergibt sich also eine dritte Aufgabe für Ein- und Umsteiger:

Arbeitet euch in das “Mounten” von Filesystemen ein – studiert die Bedeutung der Einträge in der /etc/fstab.

[Ergänzung für Fortgeschrittene: Persönlich halte ich meine Projektdateien zudem weitgehend in SVN- oder Git-Verzeichnissen, die mit einem zentralen SVN-/Git-Server abgeglichen wird. Das gilt auch für Dokument-Dateien. Serverbasierte Versionsmanagement-Systeme erlauben neben der Versionierung seiner Arbeiten zudem schnelle “Backups” durch Replikation der Dateien auf weitere Systeme (Server, PCs, mobile Laptops, …). ]

Ausnahmen von der Lagerung eigener “Daten” in
separaten Partitionen
Neben selbst erzeugten Projekt-Daten in Dateien gibt es auch automatisch generierte Konfigurationsdateien, die Einstellung zur persönlichen grafischen Desktop-Umgebung und persönliche Einstellungen zu bestimmten Applikationen betreffen. Auch diese Dateien werden meist in Unterordnern des eigenen Home-Verzeichnisses “/home/uid” [~] untergebracht – u.a. unter “~/.config”.

Diese “Konfigurations”-Dateien sind im Sinne einer schnellen Restauration der Produktionsfähigkeit wichtig! Sie sind ferner relativ eng mit anderen Bibliotheken einer Distributionsversion verzahnt. Wir wollen später mehrere Partitionen mit funktionstüchtigen Installationen, aber auf unterschiedlichen Versionsständen, durch das Kopieren von Partitionen einrichten. Das spricht dann dafür,

die Inhalte des eigenen Home-Verzeichnisses im Gegensatz zu sonstigen Nutzdaten nicht auf eine separate Partition zu legen.

Warum?
Der eigene grafische Desktop und OS müssen im Verbund funktionieren! Das führt dann beim Starten einer neuen Desktopversion u.U. zu automatischen Updates der Konfigurationsdateien. Diese Modifikationen kann man danach ohne Spezialkenntnisse nicht mehr so einfach zurückdrehen. Hat man also das eigene “~”-Verzeichnis auf eine separate Partition verlagert, die man dann nach einem Systemupgrade unter der neuen Installation mounted, so ist nach einem Start der neuen Desktop-Umgebung die spätere Nutzbarkeit der Konfigurationsdateien unterhalb von “~” in der noch vorhandenen alten Installation in Frage gestellt! Das muss man vermeiden – und deswegen ist es besser, das “/home”-Verzeichnis in unserem Verfahren nicht aus dem Root-Filesystem abzuseparieren.

In den turbulenten KDE4-Anfangszeiten (gerade mit Kontact/Kmail) ist mir schmerzlich bewusst geworden, dass es auf einem Stand-Alone-System kaum Sinn macht, das eigene Home-Verzeichnis mit seinen Konfigurationsdateien in eine separate Partition zu verlagern – auch wenn dass bei vielen Distributionen im Installationsprozess so vorgeschlagen wird. Man muss das alte Home-Verzeichnis dann in jedem Fall sichern, wenn man wieder auf die alte Installation zurück will. Dann kann man es in den unterschiedlichen Installationen gleich mit vorhalten – auch wenn das Platz kostet. (Das sieht auf einer serverbasierten Installation, bei der das Home-Verzeichnis ggf. auf einem zentralen NFS-Server liegt und über Netz auf dem lokalen PC gemountet wird, natürlich anders aus.)

Eine weitere Ausnahme bilden womöglich Mail- und Groupware-Daten, die zumeist ebenfalls in Unter-Ordnerhierarchien des persönlichen Desktops – also unterhalb irgendwelchen Konfigurationsordnern des eigenen Home-Verzeichnisses untergebracht werden. Entsprechende Dateien lassen wir mal außen vor – die Ursprungsdaten zu Mails gehören aus meiner Sicht eh’ immer auf einen (ggf. lokalen und virtualisierten) IMAP-Server. In lokalen Mailsystemen der Desktops sollten davon höchstens Kopien vorgehalten werden.

Zwischenfazit

Genug für heute! Es sollte klar geworden sein, dass ich die Kontinuität meiner Arbeitsfähigkeit gegenüber Update/Upgrade-Probleme neben Backups durch verfügbare Fallback-Installationen und eine Speicherung von Nutzdaten auf separaten Partitionen sicherstelle.

Im nächsten Beitrag

Upgrade-Zeit – Vorsorge durch Fallback-Installationen – II

bespreche ich dann den Einsatz des “dd”-Kommandos zum Anlegen von Partitionskopien – und bespreche, wie ihr ein mögliches Chaos beim Booten, das sich aus duplizierten sog. UUIDs der Filesysteme ergeben würde, vermeidet.

Service-Wüste IT-Hosting … im Zweifel ist erst mal der Kunde schuld … Szenen aus dem realen Leben

Posted on by

Es gibt ein paar Dinge im IT-Leben, die können einen aufregen. Im Besonderen Provider-Support. Nicht zuletzt, weil das Zeit kostet. Gerade musste ich das wieder erleben. Mit der Folge ungesund erhöhten Blutdrucks. Daher der nachfolgende Text:

Sei ca. 13:00 Uhr ist eine unserer bei Strato gehosteten Domänen nicht mehr oder nur erratisch erreichbar. Mal 0,8 Sek Antwortzeit, mal 120 Sekunden, mal interner Verbindungsfehler. Typische Antwortzeiten der letzten Monate lagen dagegen bei 0,8 bis 2,5 Sekunden – je nach Tageszeit. Was tut man in einer solchen Situation? Man ruft seinen Provider an. Man schildert das Problem. Erste Antwort:

“So etwas können wir leider nicht supporten.”

Man langt sich an den Kopf, man stöhnt innerlich und äußerlich und bemüht sich dann, dem Ansprechpartner klar zu machen, dass die Webseiten inkl. PHP seit Monaten bis heute 13:00 anstandslos liefen. Und: Kein Support gibts nicht … ob er denn Support-Mitarbeiter sei oder nicht?

Beim Stichwort PHP wurde besagter “Support”-Mitarbeiter dann plötzlich hellhörig und empfahl mir einen Umstieg auf PHP 7.2. Dann würde das wieder und schneller funktionieren. Auf die Rückfrage, ob ältere PHP-Versionen denn von Strato noch unterstützt würden, kam ein klares: Ja. Ob er denn auch Daten zu Performanceunterschieden vorliegen hätte und wie er mir erklären könne, warum der Einbruch abrupt geschehen sei. Ich wurde nach einigen Wortwechseln dann zu einem “Techniker” verbunden. Selbiger hatte dann den schlauen Gedanken, mal in die Error-Logs zu sehen. Und den weniger schlauen Gedanken, dass da wohl meine Skripte nicht laufen würden …. Da könne man nichts tun – ich müsse das selber debuggen.

Gleichzeitig flimmerten verschiedene Meldungen über den Schirm – Tenor: “Interner Proxy-Server …. – keine Antwort vom Upstream-Server.” Was ich dem Techniker pflichtbewusst mitgeteilt habe. 3 Minuten später lief meine Domäne dann wieder plötzlich sehr schnell, dann erneut Fehler und/oder bis zu 120 Sek. Responsezeit.

Ich habe mir zwischenzeitlich selbst die Error-Logs angesehen (aktuell bei Strato im Web-Kundenbereich übrigens in einer katastrophalen 1-zeiligen Darstellungsweise). Die Meldungen implizierten, dass die FastCGI-Server (wieso eigentlich trotz bekannter Schwachstellen FastCGI??) bei Strato keine Antwort von anderen Servern (File-Server) erhielten und die Skripts deshalb auf einen Timeout liefen. Keine der Meldungen deutete auf einen Skriptfehler hin. Es gab immer nur Timeout-Fehler. Ein ergänzender Blick in die Zugriffslogs zeigte zudem, dass es bis heute 13:00 keinerlei Probleme – außer typischen Angriffsversuchen auf vermutete (!) WordPress-Installationen – gab.

So gewappnet rief ich wieder an. Nun bekam ich nach einigem Hin und Her die Empfehlung, Security-Einstellungen (permanente SSL-Umlenkung und Filter) abzuschalten (!); solche Domän-Einstellungen würden manchmal “eine korrekte Ausführung von PHP-Skripten verhindern”.

Stirnrunzeln, innerliches Stöhnen, Nerven beruhigen, Hinweise auf den unglaublichen Kern der Botschaft und die Widersprüchlichkeit zu anderen Befunden absondern, Ausprobieren um des lieben Friedens willen und trotz Sinnlosigkeit: Brachte erwartungsgemäß gar nichts. Ich wurde dann auf erneuten Wunsch zu einem Techniker verbunden; die Verbindung brach dabei ab.

Zwischenzeitlich Check der Skripte. Originalzustand. Check Lauffähigkeit bei eingeschaltetem Fehlertracking in der php.ini einer Testdomäne. Kein Fehler. Erneuter Check der Strato-Error-Logs, wenn denn mal verzögert ein Seitenaufbau erfolgte – Zero Fehler.

Erneuter 4-ter Anruf. Der Kollege lies mich den Sachverhalt in Ruhe darstellen. Schließlich:

Er habe gerade das gleiche Problem mit einem anderen Kunden gehabt. Seit 20 Minuten wisse man nun auch, dass es ein größeres Problem intern bei Strato gebe. Man habe bisher vermutet, dass manche Kunden ihre Skripts modifiziert hätten. Nun wisse
man aber, dass das Problem bei Strato läge. “Tut uns leid – aber Sie können beruhigt sein, es liegt nicht an Ihren Skripten”.

Ach ….

Interessanterweise hatte auch die Telekom seit 13.00 Uhr ein flächendeckendes Problem. Da ich nicht weiß, ob man Ausschnitte von der Seite allestörungen.de kopieren darf: Dort ist Deutschland weitgehend und bis auf Thüringen zur Zeit (14:30 Uhr) rot eingefärbt. Sieht schlimm aus. Der Meldungspegel zu Störungen bewegt sich aktuell in Richtung 350 pro Viertelstunde.

Nun war Strato ja mal eine Telekom-Tochter und hatte (hat?) wohl auch einen Teil der internen Netzwerk-und Backbone-Infrastruktur bei der ehemaligen Mutter am Laufen. Ein Schelm, wer da nun einen Zusammenhang im Störungsaufkommen vermuten möchte … Am Strato-Support ging das jedenfalls spurlos vorbei.

Was haben wir gelernt? Fehler macht jeder – das ist OK. Probleme gibt es in der IT auch immer wieder. Auch das ist OK. Was aber nicht geht, sind folgende Dinge:

Erstmal den Support verweigern, die Schuld beim Kunden zu suchen, Abwimmeln und Techniker, die (vielleicht aus Zeitdruck) nicht genauer hinschauen und nicht genau hinhören.

Die Servicewüste Deutschland wächst – bei Strato offenbar in größerem Ausmaß, seit das Unternehmen eine Tochter der 1&1-Muttergesellschaft wurde. Die “ISO 27001”-Zertifizierung von Strato in Ehren – aber an der Support-Front ist Ebbe. Und das nach einer erst kürzlich erfolgten Preiserhöhung für die Hosting-Pakete.

Die Störungsmeldungen bei der Telekom haben gegen 15:00 Uhr den Höchstwert von 418 pro 15 Minuten passiert.

16:30 Uhr: Die Antwortzeiten meiner Domäne schwankten gerade zwischen 0,162 Sekunden und 120 Sekunden. Eben wieder ein Ausfall.

Nun, um 16:40 Uhr: 0,16 bis 0,26 Sekunden nach erstmaligem Laden der PHP-Skripte (< 1 Sek).

Jetzt 16:45 Uhr: Stabilität seit mehr als 5 Minuten … bei der Telekom fällt das Störungsaufkommen.

Sinkender Blutdruck …

Upgrade Laptop to Opensuse 42.3, Probleme mit Bumblebee und VMware WS 12.5, Workarounds

Posted on by

Gestern war ein Upgrade meines nun schon in die Jahre gekommenen Laptops von Opensuse Leap 42.2 auf Leap 42.3 fälllig.
Ich bin dabei gem. der schönen Anleitung in
https://kamarada.github.io/en/2017/08/03/how-to-upgrade-from-opensuse-leap-422-to-423/
vorgegangen. Zu der Anleitung gibt es nichts weiter zu sagen; die ist perfekt. Im Upgrade hatte ich nur die Standardrepositories (inkl. Update-Repository) für Leap 42.3 benutzt.

Mein Laptop hat eine Nvidia-Karte (Optimus-System). Das ursprüngliche Leap 42.2 lief auf dem Laptop deshalb mit einer Bumblebee-Installation; das funktionierte einwandfrei. Zudem nutzte ich auf dem Laptop VMware WS 12.5. Nach dem Leap-Upgrade hatte ich jedoch sowohl mit Bumblebee als auch VMware-Workstation Probleme – obwohl auch Leap 42.3 nur einen Kernel der nun doch schon recht alten Version 4.4 aufweist! nach dem Ugrade war bei mir 4.4.92-31 aktiv; bei der Leap_42.3 war dagegen der Kernel 4.4.76 der Default-Kernel.

Nebenbei: Bzgl. der Kernelversionen hat der SLES-Unterbau von Opensuse Leap plötzlich den unangenehmen Nebeneffekt, dass man an älteren Kernelversionen kleben bleibt … Von SUSEs Seite müssen ggf. Back-Portierungen aus neuen Kernelversionen zu älteren Versionen vorgenommen werden. Das kann Nebeneffekte zeitigen (s.u.). Bin mal gespannt wie Opensuse mit diesem Thema in Zukunft umgehen will …

Wiederholte Modul-Einträge in der Datei “/etc/sysconfig/kernel”

Das erste Problem war, dass die Datei “/etc/sysconfig/kernel” nach dem Neustart mehrfache Einträge zum Laden von nvidia-Modulen enthielt. Woher immer das stammte; vielleicht hatte ich das ja schon früher von Experimenten mit Bumblebee drin. Vielleicht wurden die Einträge aber auch im Upgrade hinzugefügt. Jedenfalls mal checken, dass in dieser Datei nach dem Upgrade kein überflüssiger Unsinn drinsteht.

Bumblebee-Installation wieder zum Laufen bringen

Bumblebee lief nach dem Upgrade nicht mehr. Ok, dachte ich, also die für Leap 42.3 passenden Repositories aktivieren und diverse Bumblebee-Pakete aktualisieren. Es gibt jedoch mehrere Repositories mit Bumblebee-Paketen für Opensuse Leap, u.a.
http://download.opensuse.org/repositories/home:/Bumblebee-Project:/nvidia:/3xx.xx/OpenSUSE_Leap_42.3.
Unter Leap 42.1/42.2 hatte ich etliche Pakete aus diesen Repositories benutzt.

Für Leap 42.3 gilt (nach meiner Erfahrung): Zu nutzen ist
http://download.opensuse.org/repositories/X11:/Bumblebee/openSUSE_Leap_42.3
und sonst gar nichts! Auch nicht das Nvidia-Community-Repository!

Die im “X11:Bumblebee”-Repository vorhandenen Pakete – inklusive der Pakete mit dem proprietären Nvidia-Treiber – kann und sollte man dagegen (bis auf eines) installieren; das Paket “primus” habe ich mir allerdings aus dem 42.3-Update-Repository geholt.

Ergänzung 02.12.2017: Wichtige Ausnahme:
bbswitch sollte man nicht installieren. Es reicht bbswitch-kmp-default! Und nur letzteres hat bei mir funktioniert – und zwar ohne dkms-Service.

Die Installation von bbswitch aktiviert den “dkms”-Service; waren sowohl “bbswitch-kmp-default” und “bbswitch” installiert, so führte dies bei mir anhand von Statusanzeigen erkennbar zu einem wechselseitigen An- und Abschalten der Graka im Bootprozess; sie wird danach von den Treibern nicht mehr erkannt.

(Auf die anderen Repositories zu unterschiedlichen Nvidia-Treibern sollte man wirklich nur im Notfall zurückgreifen, und zwar dann, wenn ihr für eure Graka zwingend einen älteren Nvidia-Treiber benötigt; aber auch dann nur x11-video-nvidia installieren. Nicht dagegen das Paket “dkms-nvidia”!)

Zu beachten ist also auch folgender Hinweis: Falls ihr früher einen laufenden dkms-Service hattet: Unbedingt deaktivieren! Und zwar nach der Installation der Pakete, aber schon vor einem anschließenden Neustart des Systems.

systemctl disable dkms

Das steht im Gegensatz zu den Anweisungen in der Anleitung
https://de.opensuse.org/SDB:NVIDIA_Bumblebee
absolut notwendig! Zumindest auf meinem Laptop … Fragt mich bitte nicht, warum der dkms-Service zu Problemen führt.

Der Bumblebee-Dämon “bumblebeed” dagegen muss über den zuständigen Service aktiviert werden

systemctl enable bumblebeed

Zudem checken, dass der User, unter dem ihr mit einer grafischen Oberfläche arbeitet, Mitglied der Gruppen “video” und “bumblebee” ist. Ggf. mittels “usermod -G video,bumblebee USERNAME” korrigieren.

Dann Neustart des Systems. Die Kommandos

optirun glxspheres
vblank_mode=0 primusrun glxspheres
optirun -b none nvidia-settings -c :8

sollten danach alle einwandfrei funktionieren.

Sollte das nicht der Fall sein und immer noch eine Meldung kommen, dass die Graka nicht vorhanden sei und der “nvidia”-Treiber nicht geladen werden könne:

Alle Pakete aus dem Nvidia-(Community)-Repository (Treiber nvidia-gfx-GL04 und ähnliche), aus dem Nvidia-Bumblebee-Repository und dem oben angegebenen Standard-Bumblebee-Repository löschen. Danach nur die Pakete aus dem oben angegebenen Standard-Repository http://download.opensuse.org/repositories/X11:/Bumblebee/openSUSE_Leap_42.3
mit Ausnahme von bbswitch (!) installieren. Den dkms-Service dann prophylaktisch deaktivieren! Neustart.

Ein probeweiser Start des dkms-Service führt nach einem vorhergehenden Erfolg mit “primusrun” in jedem Fall wieder in die Katastrophe:

Danach kommen in Logfiles Fehlermeldungen, dass es kein passendes Grafik Device gäbe. Am Terminal erscheint: “Cannot access secondary GPU …”. Das ließ sich durch ein anschließendes normales Stoppen des dkms-Service nicht mehr beheben. Bumblebee funktionierte auch nach dem Stoppen des dkms-Service nicht mehr ordnungsgemäß; nvidia Module ließen sich selbst manuell nicht mehr laden. Da half nur ein Reboot – natürlich bei deaktiviertem dkms-Service.

Ich habe leider keine Zeit, der genauen Ursache auf den Grund zu gehen. Bei künftigen Änderungen des Kernels muss man ohne korrekt funktionierendes dkms ggf. halt ein Update für die nvidia- und bbswitch-Module aus dem Bumblebee-Repository erzwingen und damit (zumindest bzgl. nvidia) eine Neukompilation durchführen lassen. Interessant ist, dass für den bei mir nach dem Leap-Upgrade aktiven Kernel 4.4.92-31 ein Link von
/lib/modules/4.4.92-31-default/weak-updates/updatesbbswitch.ko -> /lib/modules/4.4.676-1-default/updates/bbswitch.ko
angelegt wurde. Der funktioniert offenbar. Irgendwas am Kernel 4.4.92 missfällt womöglich dkms beim Versuch, für den neueren Kernel das passende Modul zu definieren. Der 4.4.92-Kernel führt aufgrund von Rückportierungen, die die SuSE-Leute wohl vorgenommen haben, auch noch in anderem Kontext – nämlich bzgl. der VMware WS – zu Schwierigkeiten.

Probleme mit der VMware Workstation 12.5. unter Leap 42.3 beheben

Meine unter Leap 42.2 installierte VM WS 12.5.1 lief nach dem Leap-Upgrade nicht mehr. Auch ein Upgrade der Workstation-SW auf die aktuelle Version 12.5.8 endete beim ersten Startversuch mit Kompilierungsfehlern. Die konnte ich mir im Detail zwar ansehen; wie man aber die problematischen Stellen im Quellcode der VMware-Module beheben hätte müssen, lag jenseits meiner Kenntnisse und Fähigkeiten.

Hier half aber der Beitrag eines offenbar Kernel-Kundigen im VMware Community Forum:
https://communities.vmware.com/message/2693257#2693257
Dort suche man nach dem Beitrag von “hendrikw84“! Herzlichen Dank an diesen Herrn! Seine Vorgaben zur Korrektur diverser Codezeilen funktionieren nämlich einwandfrei. (Ursache der Probleme sind offenbar Rückwärtsportierungen von Features des Kernels 4.10 in den Code des Kernels 4.4. Was immer die SuSE-Leute dabei gedacht haben …)

[ Warum allerdings die eine vorgeschlagene Korrektur-Zeile

retval = retval = get_user_pages((unsigned long)uvAddr, numPages, 0, ppages, NULL);

nicht gleich zu

retval = get_user_pages((unsigned long)uvAddr, numPages, 0, ppages, NULL);

verkürzt werden kann, ist mir etwas schleierhaft. Typo? Die letzte Zeile für retval klappt für den Code von hostif.c unter vmmon-only/linux nämlich auch.]

Nach Durchführung der Korrekturen ließen sich die VMware-Codes jedenfalls anstandslos für Kernel “4.4.9-31-default” kompilieren – und die nötigen Kernelmodule wurden fehlerfrei erzeugt. Meine zwei lokalen (non shared) virtuellen Maschinen für Windows-Installationen liefen damit bislang einwandfrei.

Ob es – wie in der Diskussion im VMware Community Forum angedeutet, Probleme mit “shared VMs” auf Servern gibt, habe ich nicht getestet. Auf Servern verwende ich KVM-Installaionen mit spice oder X2GO.

Viel Spaß denn mit Opensuse 42.3 auf dem Laptop!

SSD Raid Arrays unter Linux – IX – Chunk Size und Performance eines md-Raid-10-Arrays

Posted on by

In früheren Blogbeiträgen hatte ich mich Ende 2016 ein wenig mit SSD-Raid-Arrays unter Linux auseinandergesetzt:

SSD Raid Arrays unter Linux – I – ein facettenreiches Thema
SSD Raid Arrays unter Linux – II – Hardwarecontroller ?
SSD Raid Arrays unter Linux – III – SW- Raid vs. Intel-iRST-Raid – Performance?
SSD Raid Arrays unter Linux – IV – OS und Daten auf einem Raid-Array?
SSD Raid Arrays unter Linux – V – SW-Raid vs. iRST-Raid – Boot-Unterstützung?
SSD Raid Arrays unter Linux – VI – SW-Raid vs. iRST-Raid – Flexibilität?
SSD Raid Arrays unter Linux – VII – problematische Aspekte von Raid-5-Arrays
SSD Raid Arrays unter Linux – VIII – Setup von Raid-10-Arrays mit mdadm

Ich möchte in diesem Blog-Beitrag einige Performance-Daten für ein Raid-10-Setup mit SSDs nachreichen. Wir betrachten dabei ein SW-Raid-Array (md-Raid), dass mit Hilfe von “mdadm” erstellt wurde. Die Daten, die auf einem Opensuse-System gewonnen wurden, unterstreichen den großen Einfluss der “Chunk-Size” auf einige Einsatzszenarien. Wichtigstes Ergebnis:

Man kann nicht grundsätzlich davon ausgehen, dass eine große Chunk-Size (≥ 512 KB) die beste Performance liefern wird.

Test-Voraussetzungen

Die Voraussetzungen für die nachfolgend ermittelten Daten waren:

Raid-Array:
Linux SW-Raid-10-Array aus 4 SSDs (Samsung EVO 850); Near N2-Layout. Verwendete Partitionsgrößen auf den SSDs: 40 GiB. Das Array wurde z.B. für eine Chunk Size von 32kiB z.B. erzeugt mit

 
mdadm --create --verbose /dev/md/d02 --level=raid10 --bitmap=none --chunk=32 
--layout=n2 --raid-devices=4 /dev/sda5 /dev/sdb5 /dev/sdc5 /dev/sdd5

Eine “Bitmap” (s. hierzu den letzten Artikel) wurde also nicht angelegt. Für die “Chunk Size” wurden test-abhängig Werte von 8k, 16k, 32k, 512k verwendet. Vor jedem Einzeltest wurde ein fstrim-Befehl auf die zu testende Partition des Raid-Systems abgesetzt. Hinsichtlich der Schreibtests lagen also optimale Voraussetzungen vor. Es wurden LVM2 Logical Volumes verwendet, die mit einem “ext4”-Fielssystem versehen wurden. Der LVM- und Filesystem-Overhead gegenüber einem Schreiben mit dem Tool “fio” (s.u.) auf unformatierte Partitionen erwies sich als unerheblich.

OS und HW:
Opensuse Leap 42.1 mit Kernel 4.1; i7 6700K; Onboard Z170 Intel Raid-Controller (Kernel-Modul: pinctrl_sunrisepoint). Scheduler: Deadline.
Die Kernelversion ist leider wichtiger als man meinen möchte. Die nachfolgend ermittelten Daten lassen sich z.B. auf einem System mit Opensuse Leap 42.2 mit Kernelversion 4.4 nicht erzielen! Bei gleichem Setup, gleicher FIO-Version und identischem HW-Unterbau ist die Performance zum Teil deutlich schlechter. Für Einzelprozesse und Daten-Paket-Gößen unterhalb 1 MB waren auf derselben HW-Plattform Perfromance-Einbrüch von 25 bis zu 30 % zu verzeichnen.
Unverständlicherweise! Im asymptotischen Bereich (große Daten-Pakete, die die Chunk Size weit übersteigen und/oder viele parallel arbeitende Jobs) werden aber die gleichen Werte wie unter einem 4.1 Kernel erreicht. Vorläufige Untersuchungen zeigen, dass die schlechtere Performance ein Effekt ist, der schon bei Einzel-SSDs auftritt und durch das Raid10-System nur noch verstärkt wird.

Test-SW und Datenstruktur:
Ich habe primär “fio” in der Version 2.2.10 und für sequentielles Lesen/Schreiben großer Datenpakete ergänzend auch “gnome-disks” eingesetzt. Es wurden Daten von insgesamt 500 MB Größe geschrieben. Unter “fio” galten dabei besondere Bedingungen: Die Nutzung des Linux-Caches wurde durch Optionen umgangen; wir wollen ja die tatsächliche Raid-Performance testen. Typische Einstellungen für die FIO-Jobs waren in etwa solche wie nachfolgend für einen “Random Write”-Job angegeben: 

[global]
size=500m
direct=1
bs=64k
ioengine=sync

[write]
bs=64k
numjobs=1
rw=randwrite

Die fio-Blocksize “bs” wurde im Test zwischen 8k und 20000k variiert – damit wurde im Test abgefragt, wie das System auf unterschiedliche strukturiertes Datenaufkommen reagiert: Kleine einzelne Datenpakete (spike-artig) vs. größere Datenpakete (etwa größere Files).

Nur 1 Job liest oder schreibt auf das Array:
Von großer Bedeutung für die Testergebnisse ist die fio-Einstellung, dass nur genau ein (1) Job zu einem Zeitpunkt ein Datenpaket lesen oder schreiben soll. Die Ergebnisse würden sich drastisch ändern, wenn mehrere Jobs gleichzeitig auf das Raid-System zugreifen würden. Im Besonderen würde die Schreibperformance bei “Random Write”-Tests deutlich nach oben gehen. Damit wird sich ein kommender Artikel befassen.

Man kann in etwa sagen, dass eine zunehmende Zahl von Jobs einen ähnlichen Effekt hat wie eine deutliche Vergrößerung der Größe “bs”: Es stehen zu einem Zeitpunkt immer viele Datenblöcke, die über Chunks möglichst parallel auf die Platten geschrieben werden. Die Chunksize wird dann einfach früher und trotz evtl. kleiner “bs”-Werte überschritten.

Schwankungsbandbreite
Die Ergebnisse zu den Transferraten haben eine Schwankungsbandbreite zwischen 8 und 25 MB/sec. Tendenziell ist die Schwankungsbreite bei kleinen Datenpaketgrößen höher. Das liegt u.a. auch an der sonstigen Auslastung des Testsystems. Ich habe versucht, so viele Prozesse wie möglich abzuschalten; ferner wurde jede der durchgeführten Messungen 3 mal wiederholt. Es wurde ein sinnvoller Mittelwert bei leichter Bevorzugung hoher Werte angegeben.

Daten

Die nachfolgende Tabelle ist wie folgt zu lesen:

Am Kopf der verschiedenen Testblöcke ist die Art des Lesen/Schreibens (Random vs. Sequential) angegeben.

  • Die Variation der “Chunk Size” entnimmt man der zweiten Spalte.
  • Es folgen pro Zeile mehrere Blöcke aus jeweils 2 (oder 3) zusammengehörigen Spalten mit der verwendeten fio-“bs” und dem zugehörigen Messwert für die Datentransferrate in MiB/s. Zu den mit “gdisk” bezeichneten Spalten s.u..
  • Die Zeilen mit SSD am Anfang zeigen Werte, die für eine einzelne SSD-Partition außerhalb des Raid-Verbunds gemessen wurden (Einzelzugriff auf eine SSD).
  • Die Spalten mit der Überschrift “gdisk” stehen für zusätzliche Werte, die mit dem Tool “gnome-disks” gewonnen wurden. Sie betreffen nur sequentielle Lese- und Schreibtests.

Grün markierte Werte markieren aus meiner Sicht akzeptable Werte; bei ihnen kommt auch die Performance-Verbesserung durch Einsatz eines
Raid-vebrunds gegenüber einer Einzel-SSD voll zum Tragen. Werte für sequentiell Zugriffe und eine Chunk Size von 16K habe ich leider noch nicht erhoben; sorry.

n

500M

                                      

Random Read

                            

gdisk

    

gdisk
 

chunk

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

MB/s

bs

MB/s

MB/s

SSD

–

8

64

16

126

32

200

64

278

128

327

512

433

1024

460

  

20000

497

  

R10_0

16

8

66

16

149

32

235

64

448

128

604

512

753

1024

832

  

20000

851

  

R10_1

32

8

66

16

128

32

215

64

390

128

720

512

791

1024

868

  

20000

932

  

R10_2

512

8

64

16

128

32

209

64

277

128

318

512

436

1024

851

  

20000

976

  
                                       

Random Write

                                      
 

chunk

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

MB/s

bs

MB/s

MB/s

SSD

 –

8

166

16

243

32

409

64

457

128

458

512

478

1024

492

  

20000

502

  

R10_0

16

8

158

16

285

32

484

64

615

128

680

512

730

1024

775

  

20000

790

  

R10_1

32

8

166

16

295

32

384

64

609

128

731

512

754

1024

816

  

20000

850

  

R10_2

512

8

130

16

299

32

347

64

430

128

464

512

463

1024

837

  

20000

873

  
                                       

500M

                                      

Seq Read

                                    
 

chunk

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

MB/s

bs

MB/s

MB/s

SSD

 –

8

  

16

371

32

425

64

480

128

483

512

493

1024

506

  

20000

517

  

R10_0

16

8

  

16

  

32

  

64

  

128

  

512

  

1024

  

986

20000

    

R10_1

32

8

  

16

355

32

432

64

796

128

724

512

773

1024

883

950

20000

980

1030

R10_2

512

8

  

16

354

32

425

64

472

128

495

512

485

1024

950

998

20000

1010

1100
                                       

Seq Write

                                      
 

chunk

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

MB/s

bs

MB/s

MB/s

SSD

 –

8

  

16

333

32

410

64

456

128

485

512

484

1024

490

  

20000

502

  

R10_0

16

8

  

16

  

32

  

64

  

128

  

512

  

1024

  

380

20000

    

R10_1

32

8

  

16

298

32

377

64

647

128

734

512

756

1024

812

399

20000

850

840

R10_2

512

8

  

16

301

32

370

64

423

128

450

512

464

1024

836

374

20000

886

841
                                       

 

Interpretation

Wir kommen zu folgenden Ergebnissen und möglichen Erklärungen des festgestellten Verhaltens:

Feststellung 1: Besonders das Lesen kleiner Datenpakete liegt den Samsung SSDs nicht.

Erklärungsansatz: Typischer SSD-Leistungseinbruch bei kleinen Datenpaketen
Wir sollten nicht allzu sehr überrascht sein, wenn wir bei kleinen Datenpaketen einen generellen Performance-Verlust der SSDs feststellen. Dieses Verhalten ist schon bei Einzel-SSDs gegeben – und übrigens auch bei klassischen Harddisks nicht anders. Viele Leute sind sich dessen aber nicht bewusst; in der Werbung geben die Hersteller ja meist nur die sequentiell erreichbaren Maximalraten an. Diese Werte spiegeln aber das tatsächliche, im Mittel deutlich kleinere Leistungsvermögen bei kleinen Einzeldatenpaketen überhaupt nicht wieder. Der Fairness sei auch gesagt, dass HDDs im Bereich kleiner Datenpakete sehr viel schlechtere Werte zeigen.

Erklärungsansatz: Erwartbar stärkerer Einbruch der Lese- als der Schreibperformance bei kleinen Datenpaket-Größen
Offenbar ist es ein verbreitetes Phänomen, dass bei vielen SSDs für geringe Datenpaketgrößen die Leseperformance hinter der Schreibperformance zurückfällt. Siehe hierzu:
http://www.anandtech.com/show/6935/seagate-600-ssd-review/5
Ich habe leider keine Ahnung, wie das technisch zu begründen ist. Besseres Caching zu schreibender Daten auf dem internen SSD-Controller? Jedenfalls zeigen meine Daten genau diesen Effekt – z.T. mit einer überraschend großen Diskrepanz zwischen Lese- und Schreibperformance.

Feststellung 2: Erst wenn die Datenpaketgröße die “Chunk Size” (deutlich) übersteigt, hebt sich auch die Performance des Raid-10-Arrays deutlich gegenüber der einer einzelnen SSD ab.

Feststellung 3: Unterhalb einer Datenpaketgröße von 1MB wird auch bei Überschreiten der Chunk Size keine Verdoppelung der Performance gegenüber einer Einzel SSD erreicht.

Erklärungsansatz: Fundamentale Bedeutung der Chunk Size
In den vorhergehenden Blogbeiträgen hatte ich bereits diskutiert, dass die Chunk Size eine Mindestgröße angibt, ab der parallele Zugriffe auf die 2 Stripeset-Komponenten des Raid-10-Arrays überhaupt erst ermöglicht werden. Deshalb würde man für Situationen, in denen der “bs”-Wert – also die Größe des zu verarbeitenden Datenpakets – die Chunk Size unterschreitet, einen deutlichen Einbruch der Performance erwarten. Da das Raid-System auch Overhead verursacht, würde man bei kleinen Datenpaketen ggf. sogar damit rechnen, dass die Performance des Raid-Arrays die einer Einzel-SSD (also außerhalb des Raid-Verbunds) unterschreitet. Statistisch geschieht das tatsächlich; in der Tabelle kommt das durch eine leichte Bevorzugung besserer Werte aber nicht zum Tragen.

nFeststellung 3: Eine annähernde Verdoppelung der Leistung wird erst asymptotisch bei großen Datenpaketen erreicht. Das gilt für Random Read/Write wie für Sequential Read/Write. Im asymptotischen Bereich mit Datenpaketgrößen > 1MB sind auf einem Raid-10-Array mit Consumer-SSDs aber Schreibraten jenseits von 850 MB/sec und Leseraten jenseits von 1000 MB/sec möglich (SSD: EVO 850).

Erklärungsansatz: ???
Ehrlich gesagt, hier kann ich keine fundierte Erklärung liefern. Timing-Probleme des SSD-Controllers? Timing-Probleme zwischen Kernel, SW-Raid und dem Controller? Zusammenspiel interner SSD-Caches mit dem Test? Besonders erklärungsbedürftig scheint mir zu sein, dass beim sequentiellen Lesen sowie einer Chunk Sitze von 32 KB im Bereich von Datenpaket-Größen zwischen 64KB und 512 KB keine Systematik vorzuliegen scheint. Es wäre an dieser Stelle auch interessant zu sehen, wie sich eigentlich ein Raid-0-Array verhält.

Feststellung 4: Bei großen Datenpaketen nähern sich die Random-Raten den sequentiellen Raten an.

Erklärungsansatz: Asymptotik
Mit wachsender Größe der Datenpakete gibt man dem System die Möglichkeit, ein immer sequentielleres Verhalten zu erreichen.

Feststellung 5: gnome-disks liefert vor allem beim sequentiellen Schreiben von Datenpaketen mit 1MB Größe seltsame und gegenüber fio viel zu kleine Werte.

Erklärungsansatz: ???
Keine Ahnung. Hier stimmt jedenfalls irgendetwas nicht. Ich persönlich traue hier “gnome-disks” nicht.

Erstes Fazit

Auch wenn wir nicht alle Daten schlüssig erklären können, sind vier Befunde offenkundig:

  • Mit Hilfe eines Raid-10-Arrays kann man eine deutlich höhere Performance als mit Einzel-SSDs erreichen.
  • Eine theoretisch mögliche Verdoppelung von Datentransferraten wird nur asymptotisch für große Datenpakete und sequentielle Zugriffe erreicht.
  • Für Szenarien, in denen nur 1 Job zu einer Zeit Daten liest oder schreibt, hängt der mögliche Performance-Gewinn stark davon, ob die Größe der Datenpakete im Mittel die “Chunk Size” übersteigt oder nicht. Die richtige Wahl der “Chunk Size” ist vor allem dann wichtig, wenn regelmäßig einzelne kleine Datenpakete vom und zum Raid-10-Array transferiert werden müssen. Das kann z.B. für bestimmte Datenbank-Anwendungen relevant sein.
  • Eine Chunk Size von 32K stellt einen guten Kompromiss bzgl. der Unterstützung relativ kleiner Datenpaketgrößen und einer gleichzeitigen Performanceverbesserung gegenüber Einzel-SSDs dar.

Ausblick

Themen weiterer Artikel sollten Test für mehrere parallel lesende/schreibende Jobs, für andere Kernelversionen und auch für Raid-5-Arrays sein. Ich bitte diesbzgl. um etwas Geduld.