Opensuse 12.2 (64Bit) – Installation – Erfahrungen

Opensuse 12.2 bringt gleich einige Neuerungen, die interessant sind. Darunter fallen der endgültige Umstieg auf “systemd”, die Einführung von “grub2” und “plymouth” (statt bootsplash). Allein deshalb lohnt sich mal eine Probeinstallation.

Andererseits bin ich seit Opensuse 12.1 zunehmend skeptisch geworden:

Neuerungen wie “systemd” führten bei uns zu gravierenden Problemen beim Upgrade vorhandener Opensuse 11.4-Systeme auf Opensuse 12.1. Dies gilt vor allem für Systeme mit Serverkomponenten.
Meine Erfahrungen waren damals überwiegend negativ. Hinzu kommen gemischte Erfahrungen auch bei Neuinstallationen.
Aus meiner jetzigen Rückschau war die Einführung von “systemd” mit Opensuse 12.1 schlichtweg nicht hinreichend vorbereitet und ausgetestet. Siehe auch die Beiträge
https://linux-blog.anracom.com/2012/10/02/opensuse-121-systemd-shutdown-apache/
https://linux-blog.anracom.com/2012/09/09/opensuse-upgrade-von-114-auf-121/
in diesem Blog.

Dass selbst das Linux-Magazin inzwischen über schwierige Zustände beim Opensuse-Projekt berichtet hat, verringert die Skepsis vor einem Umstieg auf Opensuse 12.2 nicht gerade. Umso wichtiger erscheint es, Opensuse 12.2 – in meinem Fall in der 64 Bit-Variante – erstmal gründlich anzutesten, bevor man sich auf Produktivsysteme begibt und Upgrades vornimmt.

In diesem Beitrag stelle ich einige Erfahrungen zusammen, die ich mit einer Neuinstallation auf einem in die Jahre gekommenen System gewonnen habe. Auf diesem System waren bereits andere Opensuse 11.4- und 12.1-Systeme in separaten Partitionen installiert. Bei der Neuinstallation von Opensuse 12.2 in einer weiteren Partition bin ich dann tatsächlich auf einige Probleme und Hürden gestoßen, die es zu überwinden galt. Ich hoffe, dass die zugehörigen Hinweise auch anderen Leuten in einer ähnlichen Situation ein wenig helfen.

Ich will vorwegnehmen, dass ich – fast erwartungsgemäß – die meisten Schwierigkeiten mit dem Wechsel zu Grub2 hatte. Diese können mit der speziellen Harddisk-Konfiguration auf dem System zusammenhängen (s.u.). Von früheren Installationen her war zudem das Legacy Grub auf dem System vorhanden. Die Opensuse 12.1-Partitionen war als aktiv markiert. Da kam es dann in meinem Fall zu Ungereimtheiten mit der Grub2-Installation, die ich umschiffen musste.

Ich habe im Rahmen der Tests auch Anläufe mit dem alten Grub als Bootmanager unter Opensuse 12.2 unternommen. Dabei musste ich dann die Erfahrung machen, dass man sich an einem Wechsel vom Legacy Grub zu Grub2 und ggf. wieder zurück auch die Zähne ausbeißen kann. Werkelt man mit einer Änderung von Grub2-Optionen während gleichzeitig laufender Updates herum, kann man sich Grub auch völlig zerschießen und steht am Schluss ganz ohne Bootmanager da! Sind also früher Installationen auf dem System vorhanden – Vorsicht! – geordnetes Vorgehen ist angesagt.

Aber am Schluss wird alles gut !

opensuse 12.2 Bild 1

Ausgangssituation und Systemkomponenten

Das von mir verwendete System ist ein älteres, dass ich für für Testkonfigurationen von Server-Komponenten und für Virtualisierungstests einsetze. Es weist folgende HW auf:

  • Quadcore 9550
  • 8 GB RAM
  • Mainboard Gigabyte EP 45 Extreme T (konventionelles BIOS, bislang nicht auf EFI/Hybrid EFI umgerüstet)
  • 3ware (LSI) Raid-Controller 9650 S
  • r

  • 4 x 2TB-Platten im Raid 10-Modus mit 3.8 GB Nettoplatz als “/dev/sda”
  • Nvidia 9800GTX+

Am wenigsten Probleme mit diesem System hatte bei bei einer Opensuse 11.4-Installation. Also sollte Opensuse 12.2 mit dem HW-Setup wohl zurechtkommen. Mit der Nvidia 9800GTX+ gab es früher allerdings ab und zu Schwierigkeiten – u.a. bei der Installation von Opensuse 12.1. Deshalb war ich gespannt, wie sich Opensuse 12.2 diesbzgl. verhalten würde.

Hinweise zum Layout des Plattensystems

Um mit dem Plattensystem, das mehr als 2 TB als “/dev/sda” anbietet, umgehen zu können, muss Linux GPT zur Partitionierung einsetzen. Das hatte eine früher Opensuse 11.4-Installation bereits für mich erledigt.

Wegen der Kombination mit einem konventionellen BIOS hatte der Partitonierer von Opensuse 11.4 allerdings ein Plattenlayout mit einem “Hybrid MBR” gewählt. Mehr Informationen hierzu findet man unter

http://www.rodsbooks.com/gdisk/hybrid.html

Ein Nachteil eines Hybrid-MBR ist zumindest unter dem alten Grub der, dass man nur von den ersten 3 Partitionen booten kann. Extended Partitions gibt es unter GPT nicht und wurden/werden vom Opensuse Partitioner auch nicht zur Einrichtung angeboten.

Mich interessierte daher, ob ich nach der Installation von Grub2 in der Lage sein würde, auch von der vierten Partition zu booten. Deswegen habe ich Opensuse 12.2 zweimal auf unterschiedlichen Partitionen installiert – unter “/dev/sda2” und auch unter “/dev/sda4”.

Die Partition “/dev/sda1” ist nur eine kleine, 2GB umfassende Test- und Reserve-Partition. Auf den Partitionen “/dev/sda2” befand sich auf meinem Test-System Opensuse 11.4, auf “/dev/sda3” dagegen Opensuse 12.1. Das zugehörige alte Legacy Grub von Opensuse 12.1 war in der zugehörigen root-Partition (also auf “/dev/sda3”) installiert. Bei der 12.1-Installation wurde ein generischer Boot-Code in den Hybrid-MBR geschrieben. Dieser verweist dann auf den Boot-Loader in “/dev/sda3” – genauer auf die als “aktiv” markierte Partition.

Oberhalb von “/dev/sda4” gibt es auf dem GPT-Hybrid-System übrigens eine weitere Partition “/dev/sda5”. Danach folgt ein umfänglicher LVM-Bereich, in dem sich Partitionen virtueller KVM-Maschinen befinden. Diese virtuellen Systeme greifen von Opensuse 11.4 und Opensuse 12.1 aus per “virtio-Treiber” auf ihre “Partitionen” (im Raw-Format) zu. Alles in allem also ein interessantes Plattenlayout, mit dem Opensuse 12.2 zurecht kommen muss.

Ich beschreibe nachfolgend zuerst eine Installation, die bei mir zu einem laufenden System auf der Partition “/dev/sda2” führte. Dabei wurde also Opensuse 11.4 eliminiert.

Erster Installationsversuch auf “/dev/sda2” – Installation stoppt wegen eines nicht vorhandenen Floppy-Laufwerks

Hohe Auflösung und Plymouth

Der Start der SuSE-Installationsprogramme von der Installations-DVD (Linux-Magazin 10/2012) sieht anfänglich problemfrei aus. Auf dem ersten Dialogschirm wird eine Grafikauflösung von 1920×1200 angeboten. Das ist höher als die maximale 1600×1200-Auflösung früherer Installationen. Das Angebot entspricht aber durchaus den Fähigkeiten des Monitors und der in die Jahre gekommenen Graka Nvidia 9800GTX+. Ich wähle daher diese Auflösung und nehme als Installationssprache Deutsch.

Es folgt ein animierter Schirm mit offenbar hoher Auflösung. Die Animation haben wir dem Einsatz von “Plymouth” zu verdanken, das Bootsplash ersetzt.

Stockende Installation, die zum Stillstand zu kommen scheint

Dann fällt mir allerdings auf, dass die Animation (bewegte weiße Punkte) langsamer wird und völlig ins Stocken gerät. Es dauert ewig, bis der erste grafische Schirm erscheint – in jedem Fall viel länger als ich das von früheren Installationen gewohnt war. Auch die nächsten Schritte dauern und dauern. Schließlich stoppt die Installation beim Punkt “Suche Linux-Partitionen” scheinbar völlig. Als Anfänger kann man nun eventuell schon ins Straucheln geraten.

Ich versuche, Informationen über den aktuellen Systemzustand zu erhalten und wechsle deshalb mit “Strg Alt Fn” versuchsweise zu anderen Terminals. Auf tty4 werde ich schließlich fündig (Strg Alt F4). Dort tummeln sich Nachrichten der Art:

  • end-request: I/O error, dev fd0 sector 0
  • Buffer I/O error on device fd0, logical block 0

Diese Meldungen beziehen sich auf Fehler bzgl. eines Floppy-Devices – abzulesen am Device “fd0”.

Probleme mit einem nicht vorhandenen Floppy-Laufwerk

Ein erneuter Installationsversuch, bei dem ich die nichtgrafischen TTYs frühzeitig beobachte, zeigt, dass diese Meldungen bereits während des ersten HW-Erkennungslaufs noch vor dem Laden des Installationssystems beginnen. Das ist genau der Zeitpunkt, an dem die gesamte Installation träge wird.

Die Meldungen setzen sich dann während der Phase der “Systemanalyse” fort. Während das System dann scheinbar auf der graphischen Oberfläche unter dem Punkt “Linux-Partitionen” einfriert, stapeln sich weiterhin die Meldungen zu “Floppy-Fehlern”.

Das Lustige ist aber: Mein System hat gar kein physikalisches Floppy-Device integriert !

Allerdings ist das Floppy-Laufwerk nominell noch im BIOS aktiviert. Alle früheren Linux-Systeme (ohne moderne Zusätze wie Systemd, Plymouth, grub2, …. ) sind damit anstandslos klar gekommen. Opensuse 12.2 nicht. Offenbar untersucht die HW-Erkennung alles, was im BIOS vorkommt und bricht bei Fehlermeldungen nicht frühzeitig ab. Glaubt man Meldungen im Internet, so soll es allerdings nach langem, langem Warten auch unter Opensuse 12.2 mit der Installation weitergehen:

http://lists.opensuse.org/opensuse-de/2012-09/msg00590.html
http://web.archiveorange.com/archive/v/wmeLD8vfq9UKaTTJLHUR

Soviel Geduld habe ich nicht. Also: Abbruch der Installation und rein ins BIOS. Dort gab es tatsächlich Standardeinstellungen zu Floppys – sowohl bzgl. der Boot-Reihenfolge wie auch bei den generellen Basis-Einstellungen des BIOS (“Standard CMOS Features”). Vor allem unter den “CMOS Features” muss das Floppy-Laufwerk deaktiviert werden. Bei mir :

DRIVE A : None

Nach diesem Kunstgriff läuft die ganze Installation wesentlich schneller ab und bleibt nicht mehr hängen – auch die Fehlermeldungen auf den Konsolen verschwinden.

Alternativ geht auch eine Installation mit “sicheren Einstellungen”. Diese setzt aber bestimmte Einstellungen, die man im Nachhinein wieder rückgängig machen muss. Ich halte es für günstiger, im BIOS alle Referenzen auf Floppy-Laufwerke zu deaktivieren.

Installation kann nach dem automatischen Neustart nicht fortgesetzt werden – man landet in einem alten Boot-Menü

Im zweiten Installationsanlaufs nach der Beseitigung der Floppy-Probleme vermerke ich positiv, dass

  • die graphische Installation graphisch in hoher Auflösung unterstützt wird;
  • der Raidcontroller von 3ware/LSI einwandfrei erkannt wird und der SuSE-Partitionierer wie gewohnt arbeitet.

Ich ändere
den Vorschlag der Installationsroutine hinsichtlich der Anlage einer neuen Partition ab:
Die vorhandenen Swap-Partitionen werden weiterverwendet; das System wird allerdings auf der Partition “/dev/sda2” angelegt, die ich mit ext4 formatieren lasse.

Weitere Partitionen hänge ich im Moment noch nicht ein. Das kann man nach erfolgreicher Installation immer noch machen. Softwareseitig installiere ich die Kernelsourcen und den Gnu-Compiler mit. (Wer faul ist, kann einfach das Installations-Schema “Kernel-Entwicklung” unter den SW-Einstellungen wählen.) Der Grund hierfür ist, dass ich später den proprietären Nvidia-Treiber installieren will. Ansonsten belasse ich bei der SW-Installation alles beim Default-Vorschlag. Server-Komponenten will ich mir bei diesem Test nicht ansehen.

Die Einstellungen zum Bootloader sehe ich mir etwas genauer an, lasse sie aber im wesentlichen unverändert. D.h.:

  • Grub2,
  • Installation in der Root-Partition (und nicht im MBR),
  • Aktivieren der Root-Partition,
  • generischer Boot-Code im MBR.

Allein das Zeitintervall bis um automatischen Booten setze ich unter den Bootloader-Optionen auf 300 Sekunden.

Bei den User-Einstellungen wähle ich die Voreinstellungen zur automatischen Anmeldung und zum Empfang der Systemnachrichten für den einzurichtenden Standarduser ab.

Die nachfolgende Installation der benötigten SW-Pakete läuft auf dem Raid10-Array wie gewohnt zügig ab; mehr Zeit als für einen Kaffee bleibt nicht, bis das System automatisch neu startet. Das Grub-Menü nach dem Neustart wirkt auf mich dann allerdings weniger entspannend:

Es ist nämlich das Grub-Menü der alten Opensuse 12.1-Installation. Keine Spur von Grub2.

Schlimmer ist aber, dass es dort (natürlich) keinen Eintrag für Opensuse 12.2 (auf /dev/sda2) gibt. Hätte man die Installation sich selbst überlassen, wäre nach 8 Sekunden gemäß meines Standardeintrags im alten Grub das alte Opensuse 12.1 (mit dem Default-Kernel) gebootet worden. Die Installation kann also unter diesen Umständen nicht wie gewohnt von selbst fortsetzen.

Das halte ich schon mal für ein gravierendes Manko der neuen Version. Wie soll ein Linux-Neuling, der vorher Opensuse 12.1auf seinem System installiert hatte, mit einer solchen Situation umgehen? Er wird sie ggf. nicht einmal verstehen.

Ich bin dagegen nach wie vor optimistisch und glaube, dass

  • die Installationsroutinen von Opensuse 12.2 entweder ein Problem mit GPT und dem Hybrid-MBR haben
  • und/oder dass schlicht vergessen wurde, dass es bereits aktivierte Partitionen geben mag
  • und/oder dass es ein Problem mit der Zählweise der Partitionen gegeben haben mag – was bei Grub(1) (hd0,1) bzw. (hd0,2) ist, ist bei Grub2 (hd0,2) bzw. (hd(0,3).

Chainloading zwischen Grub und Grub2 erlaubt Fortsetzung der Installation

Ich boote deshalb einfach mein altes Opensuse 12.1-System und erstelle dort einen neuen Eintrag für das Booten von “/dev/sda2”. Das ist im guten alten Grub ja noch auf einfache und überschaubare Weise möglich. Man editiert die Datei

“/boot/grub/menu.lst”

oder nutzt zur Not

YaST2 >> System >> Bootloader.

###Don’t change this comment – YaST2 identifier: Original name: Linux other 1 (/dev/sda2)###
title opensuse 12.2 (/dev/sda2)
rootnoverify (hd0,1)
chainloader +1

Ganz einfach! Man beachte das Chainloader-Statement; ich gehe also davon aus, dass bei der
Openuse 12.2-Installation der Bootloader tatsächlich in die Partition “/dev/sda2” geschrieben wurde. Nach einem Reboot wird diese Option dann auch im Legacy-Grub-Menu angeboten.

Und siehe da – nach der Auswahl wird tatsächlich zum neu installierten System gewechselt und die Installation wird fortgesetzt. Das ist zwar wünschenswert – erklärt aber noch nicht, warum der alte Bootloader von Opensuse 12.1 angesprochen wird. Hierzu weiter unten mehr.

Fortsetzung der Installation

Während der Fortsetzung der Installation wird zunächst ein Text-Konsolen-Schirm angezeigt – auch hier ist am Schriftfont die hohe Auflösung zu erkennen. Allerdings fehlt auf TTY1 ein Hintergrundsbild wie man es eigentlich aus früheren Opensuse-Installationen kennt. Der Verlust dieses Schnickschnacks belastet mich angesichts des Gewinns eines Videomodes mit sehr hoher Zeilenanzahl allerdings wenig.

Problemloser Wechsel von der Textkonsole zur grafischen Installationsoberfläche und zu KDM/KDE

Nach der Anzeige einiger Meldung der von systemd gestarteten Dienste wechselt die Installation zurück zum grafischen Schirm. Dieser Satz schreibt sich so leicht – aber er beinhaltet gegenüber den früheren Erfahrungen mit Opensuse 12.1 bereits einen beachtlichen Fortschritt:

  • Erstens verhebt sich der Installer im Gegensatz zu Opensuse 12.1 nicht an den “kexec”-Experimenten des damaligen Installationsprozesses.
  • Zweitens kommt es in dieser Phase nicht zu einem größeren Problem mit der Graka – auch der Nouveau-Treiber hat also sich also verbessert. (Wenn auch nur begrenzt – s.u.).
  • Drittens fährt systemd alles, was im Moment benötigt wird, sauber hoch. Das war unter Opensuse 12.1 keineswegs auf allen Systemen so.

Nach der “automatischen Konfiguration” wird KDM gestartet und ich kann mich in KDE 4.8 ohne Probleme einloggen. Dort kann ich sowohl “OpenGL” als auch “XRender” für das Compositing verwendet. 3D-Effekte des Desktops funktionieren anstandslos – auch hier sind wieder Fortschritte im Nouveau-Treiber erkennbar.

Problemlose Netzwerkeinrichtung – trotz systemd

Ich richte mal prophylaktisch die Netzwerkanbindung (DNS, Gateway, Hostnamen, etc.) über YaST2 ein, wobei ich für den Arbeitsplatzrechner nicht (!) den NetzworkManager sondern “ifup” verwende. Wegen früherer schlechter Erfahrungen unter Opensuse 11.4 und 12.1 mit einer IPV6-Deaktivierung lasse ich IPV6 aktiviert.

Es sind keinerlei Probleme mit den beiden Ethernet-Schnittstellen meines Systems feststellbar. Routing etc. funktioniert anstandslos unter IPV4 und IPV6. Auch das etwa susespezifische Zusammenspiel netzwerkrelevanter Setup-Dienste mit systemd klappt. Man findet den insgesamt schon für Opensuse 12.1 typischen Mix aus LSB- und nativen systemd-Diensten vor. Ein

systemctl | grep LSB

zeigt:

bluez-coldplug.service       loaded active exited       LSB: handles udev coldplug of bluetooth dongles
cpufreq.service       loaded active exited       LSB: CPUFreq modules loader
cycle.service       loaded active exited       LSB: Set default boot entry if called
fbset.service       loaded active exited       LSB: Framebuffer setup
localnet.service       loaded active exited       LSB: setup hostname and yp
r
lvm.service       loaded active exited       LSB: start logical volumes
network-remotefs.service       loaded active exited LSB: Configure the remote-fs depending network interfaces
network.service       loaded active exited       LSB: Configure the localfs depending network interfaces
SuSEfirewall2_init.service       loaded active exited       LSB: SuSEfirewall2 phase 1
SuSEfirewall2_setup.service       loaded active exited       LSB: SuSEfirewall2 phase 2
xdm.service       loaded active running       LSB: X Display Manager

Der LSB “network.service” lässt sich jedenfalls problemfrei über

“systemctl stop network.service”
bzw.
“systemctl start network.service”

stoppen und starten. Das anstandslose Hochfahren des Netzwerks war zumindest bei Opensuse 12.1-Installationen keineswegs immer gegeben. Hier hat SuSE offenkundig nachgebessert. Das hatte ich aber schon aufgrund der fortschreitenden und spürbaren Verbesserungen des Opensuse 12.1-Systems im Zuge von Updates erwartet. SSH lässt sich auch problemlos einrichten.

Meine vorläufige Freude wird jedoch deutlich getrübt, als ich das System nun manuell und testweise reboote.

Erster Standard-Reboot – Grub 2 ohne Eingabezeile – Probleme mit dem Nouveau-Treiber

Fehlende Zeile für Parametereingaben unter Grub2

Hierbei lande ich erwartungsgemäß zunächst wieder im alten Grub-Menü von Opensuse 12.1. Dort wähle ich meinen oben angelegten Opensuse 12.2-Eintrag und lande nun natürlich nicht mehr auf einem Installationsschirm, sondern auf einem grafischen Grub2-Display. So weit, so gut!

Auf meinem neu installierten Opensuse 12.2 vermisse ich als Grub2-Neuling eine Eingabezeile zu Boot-Optionen, wie ich dies vom alten SuSE-spezifischen, alten Grub-Splash-Schirm gewohnt war. Nach einem Studium der umfassenden Übersicht über Grub2 und seiner Möglichkeiten unter folgenden Adressen

https://wiki.archlinux.org/index.php/GRUB2
http://wiki.gentoo.org/wiki/GRUB2

erkenne ich, dass ich mich daran wohl gewöhnen muss. Siehe auch:

http://forums.opensuse.org/blogs/jdmcdaniel3/how-start-opensuse-12-2-grub-2-into-run-level-3-112/
http://forums.opensuse.org/english/get-technical-help-here/install-boot-login/478535-where-give-one-time-boot-options.html

Na ja, denke ich mir, zur Not gibt es ja den Grub-Editor-Modus, den man vom Menü aus über Betätigen der der “e”-Taste erreicht.

Aufgrund von Warnhinweisen im Internet zur angeblichen Nichtlesbarkeit des zugehörigen Editor-Schirms probiere ich das gleich mal aus. Die nichtgrafische Editor-Variante ist zu diesem Zeitpunkt jedenfalls noch sehr gut lesbar (schwarze Schrift auf grünlichem Hintergrund). Aber auch hier ist die Freude aber nur von begrenzter Dauer (s.u.).

Jedenfalls kann man dort die Boot-Kommandos zur Not um Kernel-Parameter ergänzen. Umständlich – aber immerhin möglich. So richtig beschweren kann man sich hierüber auch nicht – die fehlende Möglichkeit zur Parametereingabe ist ja keinesfalls SuSE-spezifisch.

Off Topic:

Ich verstehe allerdings mal wieder nicht,
warum mit der Einführung neuer Systemkomponenten unter Opensuse oder Linux generell ständig bewährte, einfache und bequeme Eingriffsmöglichkeiten für die User und/oder Admins eliminiert werden. Windows und Apple lassen grüßen. Ich mag diese Entwicklung jedenfalls überhaupt nicht !
 
Grub2 setzt hier eine Kette von zunehmenden User-Einschränkungen fort, die mit dem Wegfall einfacher Möglichkeiten zur Einstellung der CPU-Core-Frequenzen sowie Prozessor- und Energiespar-Modi unter KDE und Gnome begann. Akonadi zentralisierte dann unter KDE zwar die Datenverwaltung und vor allem Datenpufferung am Desktop, ist für den normalen User in der Interaktion mit essentiellen Desktop-Komponenten wie der Desktop-Suche und Groupware-Clients aber kaum durchschau- und beeinflussbar. Eingeführte Subsysteme wie das schreckliche Pulseaudio erschwerten im Vergleich zu anderen Soundsystemsystemen dem User die Handhabung seiner Soundkomponenten, ….Systemd hat den Admins zuletzt einfache skriptbasierte Möglichkeiten zur Steuerung und zum Testen des Systemstarts weggenommen. Grub2 erschwert nun die Übergabe von Kernel- und Startup-Parametern. Hat sich durch all diesen “Fortschritt” eigentlich wirklich etwas für den normalen Anwender verbessert ??? Aber ich schweife ab …..

Bzgl. dauerhafter Einträge von Boot-Parametern unter Grub 2 sind vielleicht folgende Hinweise nützlich:

http://www.gtkdb.de/index_7_1428.html
http://manual.siduction.org/de/sys-admin-grub2-de.htm
http://ubuntuforums.org/showthread.php?t=1613132

Der experimentierfreudige Leser wird feststellen, dass der Umgang mit Grub2 mindestens gewöhnungsbedürftig und z.T. durchaus schwieriger ist als mit dem Legacy Grub. Dennoch kann Grub2 mehr als Grub – ein Beispiel folgt am Ende des Artikels.

Ungewohnte Bezeichnung der bootbaren Systeme

Blöd finde ich auch folgendes:

Der oberste Eintrag im Grub2 Menü heißt schlicht “Opensuse” und leider nicht Opensuse 12.2, was ich persönlich verunsichernd finde, wenn bereits andere Opensuse-Systeme installiert sind. Umso mehr, als die Grub2-Menü-Einträge zu den vorhandenen Opensuse 11.4- und 12.1-Systemen korrekte Versionsnummern beinhalten. Es ist einfach inkonsequent, das aktuelle System nicht mit der Versionsnummer zu bezeichnen ! Was passiert denn, wenn Opensuse 12.3 kommt? hat man danach dann 2 Einträge mit der Bezeichnung “Opensuse” unter Grub 2? (Oder ist das Ganze gar der erste Hinweis darauf, dass es kein Opensuse 12.3 mehr geben wird?)

Na ja, das ist nur ein kleiner Lapsus und eine Anregung dazu, selber mal zu versuchen, den Eintrag in der Grub2-Konfiguration auf Opensuse 12.2 abzuändern. Das ist ganz nützlich, um sich mit der neuen Struktur der Konfigurationsdateien von Grub 2 vertraut zu machen. Die oben angegebenen Links helfen!

Probleme mit dem Nouveau-Treiber und dem Wechsel von der Plymouth-Oberfläche zum KDM-Schirm – unbenutzbare grafische Oberfläche

Ich boote vom Grub2-Menü aus den “Opensuse”-Eintrag in der obersten Zeile. Die Plymouth-Animation verkürzt die kurze Wartezeit.

Dann vollzieht sich mit meiner NVidia-Karte leider ein sehr kläglicher Versuch des Wechsels vom Plymouth-Framebuffer-Modus zum regulären grafischen X11/KDM-Modus. Der grafische Schirm auf TTY 7 erscheint völlig in farbige Pixelbereiche zerlegt und ist nicht benutzbar.

Auch andere haben oder hatten ähnliche Probleme:
http://forums.opensuse.org/deutsch-german/hilfe-und-helfen/
installation-administration/479285-update-auf-12-2-kein-video-treiber-far-nvidia-graka-funktioniert-mehr.html

http://www.linux-club.de/viewtopic.php?f=48&t=116117
http://www.opensuse-forum.de/gel%C3%B6st-graphische-probleme-beim-hochfahren-anf%C3%A4nger-startprobleme/allgemeines-f17/t7925-f20/

Dass solche Probleme auch mit ATI-Karten auftauchen könne, zeigt folgender Artikel:
http://www.linux-club.de/viewtopic.php?f=4&t=116565

Gott sei Dank funktioniert nach diesem Desaster aber noch ein “STRG ALT F1”. Während ich umschalte, wundere ich mich noch, wieso der Wechsel zur X11-Oberfläche während der vorhergehenden Phase der Installationsfortsetzung funktioniert hat. Ich erinnere mich dann daran, dass zwischenzeitlich ein Text-Bildschirm mit den systemd-Meldungen zu sehen war und vermute, dass aus dem Text-Modus heraus der Wechsel zur X11-Oberfläche klappt.

Workaround zum Starten der grafischen Oberfläche

Also logge ich mich auf TTY 1 ein, reboote mit init 6 (ja das geht noch – trotz systemd). Als nach Grub2 Plymouth startet drücke ich erfolgreich “STRG Alt F1” und betrachte danach statt Plymouth die systemd-Startmeldungen. Auch interessant ! Wirklich !

Und siehe da: Danach erfolgt ein einwandfreier Wechsel zur grafischen Oberfläche und KDM.
Das ist doch schon mal ein guter Workaround !

Nun hat man als betroffener User theoretisch 3 Möglichkeiten:

  1. Auf Plymouth während des Bootvorgangs verzichten. Das erfordert einen Eingriff in die Grub2-Konfiguration.
  2. Direkte Installation des proprietären Nvidia-Treibers.
  3. Systemupdates und Test, ob (zufällig) etwas besser wird.

Wie man die proprietären Nvidia-Treiber aus Repositories installiert, erfährt man hier: http://de.opensuse.org/SDB:NVIDIA-Treiber

Ich führe die Nvidia-Installation allerdings lieber in der Form durch, dass ich mir den aktuellen Treiber von der Nvidia-Webseite runterlade und danach die Nvidia-Installationsroutine samt Kompilation ablaufen lasse. Das verschiebe ich aber noch ein Weilchen. Da ich die Kompilation am liebsten für die neueste bereitgestellte Kernel-Variante durchführe, um unnötigen Doppelaufwand zu vermeiden, entscheide ich mich also für Option 3.

Updates ermöglichen den reibungslosen Wechsel zwischen Plymouth und KDM – auch bei Einsatz des Nouveau-Treibers

Mit Hilfe von YaST2 date ich nun den Kernel und seine Sourcen ab. Gleichzeitig aber auch andere Pakete – u.a. Mesa, den NetworkManager, den PackageManager, udev, libnfnetlink0 und auch module-init-tools, mdm, dbus, LVM, X11, sowie alles im systemd- und nouveau-Umfeld, was an Updates angeboten wird. Weitere Pakete werden von der SuSE RPM-Verwaltung automatisch nachgezogen.

Zu diesem Zeitpunkt führe ich noch keine Updates von Grub, Bootsplash oder Plymouth durch. Das hebe ich mir für einen späteren Schritt auf.

Danach reboote ich. Und siehe da – ich habe erneut Glück:

Nach dem Update klappt der Wechsel von “Plymouth” zum X11/KDM-Schirm anstandslos!

Schade, dass die entsprechenden Verbesserungen nicht schon in die Original-Distribution Einzug gehalten haben.

Nun habe ich also eine erste durchlaufende Opensuse 12.2-Installation. Zwar noch über den Chainloader-Mechanismus von Grub (Opensuse 12.1) zu Grub 2 und auch ohne den propritären Nvidia-Treiber – aber immerhin.

Bootzeiten mit der aktuellen “systemd”-Variante

Bevor ich mich an die Installation des Nvidia-Treibers mache, messe ich vorab mal die Bootzeiten. Der Vollständigkeit und systemd halber.

Warum allein stehende System unter 20 Sekunden booten müssen, ist mir immer verborgen geblieben. In Virtulisierungsumgebungen und clusterartigen HA-Umgebungen, in denen Ersatz-Systeme auf freien Knoten hochgefahren werden müssen, verstehe ich das. Aber auf Desktop-Systemen?

Trotzdem – für die wachsende Anzahl an systemd-geilen Rekordjägern im Internet hier mal meine Referenzzahl für ein festplatten-basiertes System:

Gemessene Bootzeit, bis ich den Login-Namen in KDM eingeben kann: 11.5 Sekunden

Zeiten von “systemd-analyze”: 11.362 Sekunden [ 4.15 Sek Kernel , 7.2 Sek Userspace ]

Nicht schlecht für ein System mit konventionellen und relativ langsamen Festplatten – also ohne SSD !

Aber:

Die Zeiten sind aus meiner Sicht für praktische Belange kaum relevant und letztlich auch völlig auch irreführend, da das installierte System ja nur ein Minimalsystem ohne den Start umfangreicherer Dienste darstellt. Schon au einem Entwicklungssystem sieht die sache ganz anders aus. Siehe hierzu auch meinen letzten Beitrag :
“Opensuse 12.1, systemd, shutdown, apache” (https://linux-blog.anracom.com/2012/10/02/opensuse-121-systemd-shutdown-apache/)

Problemfreie SW-Updates

Als nächstes führe ich Updates aller anderen SW-Pakete durch und teste dann das Resultat.

KDE läßt sich ohne Probleme mit Hilfe des KDE 4.9-Repositories “http://download.opensuse.org/repositories/KDE:/Release:/49/openSUSE_12.2” auf den aktuellen versionsstand 4.9.2 bringen. Zusätzlich lade ich unter der SW-Verwaltung von YaST2 auch die Repositories

  • http://download.opensuse.org/repositories/mozilla/openSUSE_12.2/
  • http://download.videolan.org/pub/vlc/SuSE/12.2
  • http://download.opensuse.org/repositories/security/openSUSE_12.2/
  • http://ftp.uni-erlangen.de/pub/mirrors/packman/suse/openSUSE_12.2/
  • http://download.opensuse.org/repositories/multimedia:/apps/openSUSE_12.2/
  • http://download.opensuse.org/repositories/multimedia:/libs/openSUSE_12.2/
  • http://opensuse-guide.org/repo/12.2/
  • http://download.opensuse.org/repositories/network/openSUSE_12.2/
  • http://download.opensuse.org/repositories/server:/database/openSUSE_12.2/

Die Anzahl an Repos wirkt groß. Zugegeben – man muss wissen, was man tut, wenn man mit so vielen Repositories arbeitet. Aber manche Dinge erhält man auf dem neuesten Stand nur aus den angegebenen Repositories.

KDE 4.9.2 läuft mit all seinen Stärken und Schwächen und den bekannten Bugs im Bereich Kontact/Kmail. Statt amarok setze ich Clementine vom Multimedia-Repository ein. VLC bringe ich über das Repository von Videolan und Libreoffice über das zugehörige Repository auf den neuesten Stand. Firefox ziehe ich in der aktuellen Version vom Mozilla-Repository, K3b und diverse Codecs über das Packman-Repository. FWBuilder ziehe ich vom Security Repository, MySQL vom Database Repository. Zur Beobachtung des Systems installiere ich gkrellm. Schließlich führe ich mit “sensors-detect” auch noch eine Erkennung von HW-Sensoren durch, die ich in “ksysguard” einbinde.

Auf Details des konfigurierten Desktop-Systems kann ich hier nicht weiter eingehen. Alles läuft, wie ich das erwarte. Unterschiede zu einer entsprechenden Installation unter Opensuse 12.2
sind auf Userseite nicht feststellbar.

Installation Nvidia-Treiber

Die Installation des Nvidia-Treibers in der Version 304.51 (oder neuer) verläuft einfach. Man lade sich die Treiber-Dateien von der NVIDIA-Webseite runter. Dann ausloggen aus KDE/Gnome. Mit

systemctl stop xdm.service

die KDM-Oberfläche und X11 beenden. (Es geht auch noch “init 3”).

Dann als root in dem Verzeichnis, in dem die Treiberdateien abgelegt wurden :

sh NVIDIA-Linux-x86_64-304.51.run

Der Installer warnt im ersten Anlauf und verlangt Schritte, um den Nouveau-Treiber zu deaktivieren (“blacklisting”). Die Rückfrage des Installers zu entsprechenden Maßnahmen bejahe ich. Das “Blacklisting” des Nouveau-Treibers kann man den neu angelegten Dateien unter dem Verzeichnis “/etc/modprobe.d” entnehmen:

  • nvidia-installer-disable-nouveau.conf
  • und/oder nvidia.conf

Dann gehe ich vor einem Reboot mit Hilfe von “yast” noch in den “/etc/sysconfig”-Editor und prüfe, dass unter

System >> Kernel

der Eintrag für

“NO_KMS_IN_INITRD” auf “Yes”

steht. Ein Einfügen von “nomodeset” als Kernel-Boot-Parameter in Grub2 war danach nicht mehr notwendig.

Danach bootet man neu. Es wird nun zunächst der alte nv-Treiber statt des Nouveau-Treibers geladen. Man sollte trotzdem bis zum KDM-Schirm gelangen. Man loggt sich erneut auf einer Text-Konsole ein und deaktiviert wie oben beschrieben den xdm-Service. Dann führt man erneut – und diesmal ohne Umwege – die Installation des proprietären NVidia-Treibers mit Hilfe von “sh NVIDIA-Linux-x86_64-304.51.run” durch. Man bestätigt alle Rückfragen zur Kompilation und zu den Kompatibilitätsdateien. anschließend prüft man mit

lsmod | grep nvidia

dass das nvidia-Moul geladen ist. Wenn nicht: “modprobe nvidia” und Analyse der nachfolgenden Meldungen.

Anschließend startet man – hoffentlich erfolgreich – mit

systemctl start xdm.service

und jetzt vom Nividia-Treiber unterstützt, wieder die grafische Oberfläche. Unter KDE hat man anschließend unter “Anwendungen” im SUSE-Start-Menü Zugriff auf die Anwendung “NVIDIA X Server settings”.

nvidia settings

Insgesamt wirkt die 3D-Beschleunigung schneller, glatter und flüssiger als zuvor mit dem Nouveau-Treiber. Ich teste das immer oberflächlich mit dem schnellen Hin- und Herziehen von “Wabernden Fenstern” und der Beobachtung der Kantendarstellung bei den bewegten und gleichzeitig schwingenden Fenstern (bei synchronisierter Frequenz mit dem Schirm – hier 60 Hz. Hierfür “VSync” unter den KDE Systemeinstellungen im Reiter “Erweitert” der “Arbeitsflächeneffekte” aktivieren ).

Allerdings kostet das Laden des Nvidia-Treibers etwas Boot-Performance:

Die Zeit bis zum Einloggen unter KDM steigt durch den Nvidia-Treiber auf auf 12.7 Sek. Warum das Laden des Nvidia-Treibers als Kernelmodul mehr als 1 Sekunde kostet, ist mir ehrlich gesagt völlig schleierhaft.

Danach konfiguriert man sich seine Oberfläche endgültig gemäß der eigenen Bedürfnisse. U.a. ändere ich dann regelmäßig die von KDE zu verwendenden Schriften und Font-Glättungsverfahren. Im Laufe der Zeit habe ich gelernt, welche TTF-Schriften für meinen Schirm optimal sind, für welchen Fontgrößen-Bereich man die Glättung besser abschaltet und welcher Glättungsmodus optimal ist. Das Ergebnis ist dann typischerweise 10 mal besser als der ganze Cleartype-Mist unter Windows XP und speziell unter Windows 7. Warum
sich die Leute den aktuellen ClearType-basierten Schriftenverunstaltungsquatsch unter Windows 7 bieten lassen, ist für mich ein absolutes Rätsel ! Früher war die Schriftendarstellung unter Linux im Vergleich zu Windows ein Problem – heute ist es genau umgekehrt, auch wenn Win-Fans das nicht gerne hören werden.

Ein Update des grub2-RPMs führt zu einem unleserlichen Grub2- Editor-Modus

Bei der ganzen initialen Updaterei hatte ich bislang einen Schritt ausgelassen – nämlich ein Update der Grub2-RPMs. Dieses führe ich jetzt abschließend durch. Leider treten danach zwei Effekte ein, die auch im Internet mehrfach beschrieben wurden:

Verlust der grafischen Darstellung des Grub2-Menüs

Der erste Effekt ist, dass man zunächst in einem ASCII-basierten Grub-Modus und nicht mehr in einem grafischen Modus landet. Das lässt sich aber leicht beheben:

Man öffnet unter KDE YaST2 und dort die Bootloader-Einstellungen. Über die Taste “Bootloader-Optionen” gelangt man zu einem Fenster, in dem man die Option für den graphischen Modus anhakt und die vorhandene SuSE-Datei für das “theme” lädt.

Grub2_KOnfig

Beim nächsten Reboot hat man wieder die grafische Oberfläche.

Unleserlicher Grub2-Editor-Modus wegen unpassender Schrift- und Hintegrundsfarben

Leider schlägt nun ein zweiter Effekt zu: Der Editor-Modus (Taste “e” !) basiert danach auf hellen Schriften auf einem grünen Suse-Hintergrund und wird völlig unleserlich. Das finden weder ich noch andere lustig:

https://bugzilla.novell.com/show_bug.cgi?id=778350
http://us.generation-nt.com/answer/os-12-2-update-kde-4-8-4-auf-4-8-5-grub2-screen-augenkrebs-help-209149222.html
http://www.linux-club.de/viewtopic.php?f=4&t=116596

Etwa in der Mitte des folgenden Artikels und auch im übernächsten Artikel findet man eine Beschreibung zur Farbkorrektur, die man adaptieren kann.

http://forums.opensuse.org/english/get-technical-help-here/install-boot-login/479058-grub-2-boot-menu-boot-options-entry-field-missing.html
http://forums.opensuse.org/english/get-technical-help-here/install-boot-login/478535-where-give-one-time-boot-options-2.html

Ich habe mir dem Geiste der Anleitungen folgend jedenfalls eine Datei

/etc/grub.d/43_openSUSE

angelegt. Der Inhalt ist folgender:

#!/bin/sh -e
set -e
 
prefix=/usr
exec_prefix=/usr
 
. /usr/share/grub2/grub-mkconfig_lib
COLOR_NORMAL=”black/black”
COLOR_HIGHLIGHT=”white/black”
 
if [ “${GRUB_TERMINAL_OUTPUT}” = “gfxterm” ] ; then
     cat < set color_normal=${COLOR_NORMAL}
set color_highlight=${COLOR_HIGHLIGHT}
EOF
else
     cat << EOF set menu_color_normal=white/black
set menu_color_highlight=black/light-gray
EOF
fi

Mit

# chmod 755 43_openSUSE
grub2-mkconfig -o /boot/grub2/grub.cfg

binde ich di neue Datei in die Grub2-Konfiguration ein.

Danach hatte ich beim Wechsel zum Grub2-Editor-Modus wieder einen lesbaren Schirm – mit schwarzen Schrift-Fonts. Die Alternative ist natürlich, auf die grafische Darstellung des Grub2-Menüs einfach ganz zu verzichten.

Ich möchte nicht verschweigen, dass das Farbproblem mit Grub2 auch vom Update nach KDE 4.9.2 mit verursacht worden sein kann. Denn mit der KDE 4.9.2-Installation wird auch ein neues opensuse-spezifisches Branding für Grub2 geladen, das eine höhere Versionsnummer als das aus dem Opensuse Update-Repository. Ob ein Wechsel zum Branding RPM des Update-Repositories evtl. wieder eine Verbesserung der Lesbarkeit mit sich bringt, habe ich nach der Anstrengung mit dem zusätzlich grub2-Skript nicht mehr getestet.

Grub2 – Beseitigung der Chainloader-Konfiguration mit Opensuse’s 12.1 Legacy Grub

Hat man noch keine Erfahrung mit Grub2 sollte man Grub2 ruhig nach dem beschriebenen Muster in Verkettung mit einem bereits vorhandenen Legacy Grub von Opensuse 12.1 ausführen. Dann kann man experimentieren – ohne gleich auch den Zugang zu seinen vorhandenen Installationen zu verlieren.

Direktes Booten zum Grub2-Menü

Allerdings hat mich schon interessiert, ob man den Chainloader-Umweg über das Legacy Grub-Menü von Opensuse 12.1 in meiner Konstellation nicht auch loswerden kann. Ja, das geht!

Ursache der ganzen Verwirrung ist nämlich die Tatsache, dass in dem Hybrid-MBR meiner Raid-10-“Platte” nach der Opensuse 12.2-Installation zwei (!) Partitionen als aktive, bootfähige Partitionen markiert sind.

SuSE hat in seinen Installationsroutinen vergessen, Konstellationen mit bereits vorinstalliertem Opensuse 12.1 in einer höheren Partition als der neuen Opensuse 12.2-Partition korrekt zu behandeln ! Zumindest im Umfeld von GPT-Platten mit Hybrid MBR.

Hier muss man nämlich trotz des GPT-Layouts auch noch mit “fdisk” ran. Ich setze am Prompt ein

fdisk /dev/sda

und anschließend folgendes Sub-Kommando “p” zum Aufliste der erkannten Partitionen ab:

Command (m for help): p
 
Disk /dev/sda: 4000.0 GB, 3999977701376 bytes
255 heads, 63 sectors/track, 486302 cylinders, total 7812456448 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
Disk identifier: 0x00000000
 

das Ergebnis ist:

Device Boot Start End Blocks Id System
/dev/sda1 2048 4208639 2103296 83 Linux
/dev/sda2 * 4208640 213921791 104856576 83 Linux
/dev/sda3 * 213921792 465596415 125837312 83 Linux
/dev/sda4 1 1 0+ ee GPT

ab.

Die Kommandos zeigen tatsächlich, dass zwei Partitionen als aktive bootfähige Partitionen markiert sind. Entfernt man bei “/dev/sda3” mit der fdisk-Option “a” das Bootflag und führt dann einen Reboot durch, so kommt man auch auf meinem System direkt in das Grub2-Menü von Opensuse 12.2.

Grub2 – Booten von /dev/sda4

Nun wollte ich abschließend noch wissen, ob ich denn mit Grub2 auch ein Opensuse 12.2 von der Partition “/dev/
sda4” booten kann. Ich habe mir dazu Opensuse 12.2 nochmal auf /dev/sda4/ installiert. Mit dem oben geschilderten Problem, dass die Installation zunächst nicht fertiggestellt werden kann (zumindest nicht ohne Tricks).

Folgender Eintrag im Grub2 Menü des Opensuse 12.2-Systems auf /dev/sda2/ ermöglichte mir dann die Möglichkeit, um Opensuse 12.2 von /dev/sda4/ direkt zu booten (bzw. zunächst mal die Installation fertgzustellen):

menuentry ‘openSUSE 12.2 (x86_64)’ –class gnu-linux –class gnu –class os $menuentry_id_option ‘osprober-gnulinux-simple-42efa3d9-5a63-4a01-82a2-9a550e9858f4’ {
     insmod part_gpt
     insmod ext2
     set root=’hd0,gpt4′
     if [ x$feature_platform_search_hint = xy ]; then
         search –no-floppy –fs-uuid –set=root –hint-bios=hd0,gpt4 –hint-efi=hd0,gpt4 –hint-baremetal=ahci0,gpt4 –hint=’hd0,gpt4′ 42efa3d9-5a63-4a01-82a2-9a550e9858f4
     else
         search –no-floppy –fs-uuid –set=root 42efa3d9-5a63-4a01-82a2-9a550e9858f4
     fi
     linux /boot/vmlinuz-3.4.6-2.10-desktop root=/dev/sda4
     initrd /boot/initrd-3.4.6-2.10-desktop
}

Vorher kann man mit dem “osprober” erst mal sehen, ob das neu installierte Opensuse 12.2 auch gefunden wird. Das ist der Fall:

xen2:~ # os-prober
/dev/sda3:openSUSE 12.1 (x86_64):SUSE:linux
/dev/sda4:openSUSE 12.2 (x86_64):SUSE1:linux

Der OS-Prober wird aber auch bei der Erstellung der Bootloader-Konfiguration automatisch über das Script “/etc/grub.d/30_os-prober” aufgerufen und bindet die erkannten Systeme ein. Der oben zitierte Eintrag rührt also von der Ausführung des Kommandos

grub2-mkconfig -o /boot/grub2/grub.cfg

her.

Interessant ist, dass das Legacy Grub von Opensuse 12.1 beim Versuch, mit einem Chainloader-Eintrag auf /dev/sda4 weiterzukommen, die Grätsche macht.

Somit ist Grub 2 trotz der oben aufgetretenen Darstellungsprobleme in meinem Fall wirklich zu etwas nützlich und gut !

Fazit – viel Licht, ein wenig grüner Schatten

Das mit viel Vorschusslorbeeren bedachte Oprensuse 12.2 kann sich im Rahmen einer Neuinstallation auf einem System mit vorhandener Opensuse 12.1-Installation auf einer anderen Partition eines (GPT-) Datenträgers auch als sperrig erweisen.

So ist das oben beschriebene Thema mit dem (im System nicht vorhandenen) Floppy-Laufwerk zumindest ärgerlich.

Sehr problematisch finde ich die beschriebene Panne mit den zwei als aktiv markierten Partitionen und dem resultierenden Starten des Grub-Legacy- Bootloaders von Opensuse 12.1, der sich in einer höheren Partition befand. Ich bin mir nicht sicher, ob das Thema ein GPT-spezifisches ist oder mit dem Hybrid-MBR des vorhandenen Plattensystems zu tun hat. Ich vermute, dass beides eher nicht der Fall ist. Dann wäre das aufgetretene Probelem einer nicht ohne Tricks fortsetzbaren Installation allerdings eine Hürde, von der ich glaube, dass sie die eine oder andere Installation zum Scheitern verurteilen würde.

Im Nachhinein finde ich den anfänglich fast gezwungenermaßen beschrittenen Umweg einer Chainloader-Konfiguration mit Grub und Grub2 für ein System mit unterschiedlichen Opensuse-Installationen gar nicht so schlecht. Bei Experimenten mit Grub2 hat man dann immer noch eine Fallback-Lösung. Wie gezeigt, kann man aber nach einer Bereinigung der Boot-Flags auch direkt mit
Grub2 booten.

Positiv finde ich, dass man auch bei einem GPT-System mit Hybrid-MBR mit Hilfe von Grub2 nun offenbar eine Booten von Partitionen, die sich jenseits der dritten Standard-Partition und sich (wg. GPT!) nicht in einer erweiterten Partition befinden, möglich ist.

Eventuelle Schwierigkeiten mit dem Nouveau-Treiber beim Wechsel von der Plymouth-Animation zur X11-Oberfläche kann man SuSE nicht wirklich anlasten. Ein Workaround und ein Update helfen, die Probleme zu beseitigen.

Ärgerlicher ist da schon das Thema mit dem Grub2-Farbhintergrund des Suse-Themes im Grafik-Modus, wenn man vor dem Booten mit “e” zum Editieren/Ergänzen der Grub2-Menüeinträge ansetzen will.

Positiv fällt hingegen auf, dass es – ganz im Gegensatz zu Opensuse 12.1 – praktisch keine Probleme mehr mit “systemd” oder dem neuen Kernel gab. Allerdings ist diese Aussage mit Vorsicht zu genießen, da ich auf dem Testsystem noch keine Serverkomponenten installiert habe und da es sich um eine Neuinstallatiion und kein Upgrade eines vorhandenen Opensuse 12.1-Systems handelte. Die Bootperformance eines reinen Desktop-Systems ist jedenfalls hervorragend – wer immer darauf Wert legen mag.

Der aktuelle proprietäre Nvidia-Treiber lässt sich ohne Schwierigkeiten auch für etwas ältere Grafikkarten installieren und erlaubt einen performanten 3D-animierten Desktop auch unter KDE 4.9.2.

Die initiale Plymouth-Animation bei hoher Auflösung ist eine nette Spielerei, die die kurze Bootzeit noch weiter verkürzt, wenn denn der abschließende Übergang zu KDM vom Nouveau-Treiber und der Grafikkarte anstandslos bewältigt wird – was bei mir im Zuge der Installation zunächst leider nicht der Fall war. Positiv ist zu vermelden, dass auch die Auflösung der Textkonsolen besser geworden ist, wenngleich man auch auf tty 1 nun auf einen grafischen Hintergrund verzichten muss. Aber wer braucht das schon ?

Also: Insgesamt verlief meine Installation etwas hakelig. Mit Workarounds ließ sich schließlich jedoch ein performantes Desktop-System mit KDE 4.9.2 implementieren. Weitere Berichte folgen.

opensuse 12.2 Bild 2

Opensuse 12.1, systemd, shutdown, apache

“systemd” unter Opensuse 12.1 – ein Start nicht ohne Probleme

Ich versuche immer mal wieder, mich mit “systemd” anzufreunden – mehr gezwungenermaßen als mit Freude. In diesem Beitrag sammle ich lose einige Gedanken und Erfahrungen, die mir der erste Kontakt mit “systemd” unter Opensuse 12.1 beschert hat. Dieser Erstkontakt war vor allem von Zeitaufwand zur Behebung von schwerwiegenden Upgrade-Probemen auf mehreren unterschiedlichen Systemen gekennzeichnet. Das es nicht nur mir so ging, beweisen zahllose Kommentare, Hilferufe etc. im Internet (s.u.).

Ich bin wirklich kein Spezialist für Initialisierungsverfahren von Betriebssystemen. In der Tiefe kann ich “systemd” deshalb sicher nicht hinreichend würdigen und beurteilen. Vielleicht wird “systemd” in 2 Jahren auch mal ein ganz tolles Ding sein.

Leider wird man das “systemd”-Initialisierungs-Verfahren bis dahin ab Opensuse 12.2 aber nicht mehr einfach abstellen können – wie etwa den fehleranfälligen Soundserver “Pulseaudio”, der ja von einem der Mitautoren von systemd stammt. Das ist eines der Pakete, das ich nach regelmäßig schlechten Erfahrungen unter Opensuse mit gleicher Regelmäßigkeit einfach deinstalliere. Danach funktioniert der Sound auf meinen Systemen regelmäßig besser und zuverlässig!

Da etwas Ähnliches mit systemd ab Opensuse 12.2 nicht mehr auf einfache Weise geht, muss es erlaubt sein, sich nach dem aus meiner Sicht mehr als holprigen Start von “systemd” unter Opensuse 12.1 auch als Unbedarfter ein paar Gedanken zu machen.

Zentralisierte Komplexität

Systemd soll ja in der Theorie eine geradezu riesige Menge von Vorteilen aufweisen. Man sehe hierzu:

http://0pointer.de/blog/projects/why.html

Genau diese überwältigende Fülle an Features macht einen alten IT-Mann aber auch misstrauisch. Denn wenn im Zuge des Hochfahrens eines Linux-Systems so viel (anders und besser) geleistet werden soll, wie in den Tabellen des obigen Links dargestellt, dann besteht schon der begründete Verdacht einer gewissen, wenn nicht gar hochgradigen Komplexität des zugehörigen steuernden Programms.

Der Eindruck verstärkt sich, wenn man anfängt, sich als Linux-Nutzer ganz unbedarft in die Dokumentation und umfassenden Überlegungen eines der Hauptinitiatoren von “systemd” (Lennart Poettering) einzuarbeiten. Siehe die mittlerweile 15 Beiträge der Serie “systemd for Administrators” in “Lennarts Blog” :

http://0pointer.de/blog.

Da ich persönlich es schwierig fand, in dem Blog zu navigieren, finden Interessierte eine Auflistung der 15 Poettering-Artikel mit ihren Link-Adressen am Ende meines hiesigen Blog-Beitrags.

“Systemd” wirkt – wenn vielleicht auch nicht aufgebläht, wie manche Kritiker meinen – so doch immerhin äußerst umfangreich und mit extrem hohen, ambitiösen Ansprüchen befrachtet. Eine knappe, halbwegs neutrale Darstellung der wesentlichen Vor- und Nachteile bietet aus meiner Sicht der folgende Artikel:

http://ikhaya.ubuntuusers.de/2012/09/22/systemd-das-init-system/

Dort lesen wir:

“systemd verlagert die Komplexität von vielen kleinen Skripten in eine zentrale Software.”

Man muss sich das einfach mal auf der Zunge zergehen lassen. Als Projektmanager, aber auch als SW-Entwickler lege ich normalerweise Wert darauf, Aufgaben in kontrollierbare, überschau- und kapselbare sowie delegier- und testbare Einheiten zu zerlegen. Alle diese Punkte treffen auf die Organisation des Bootvorgangs unter
System V – trotz der relativ komplexen Organisation der Startskripte – voll zu. Und vor allem:

Unter System V hat der shell-kundige Admin eine sehr weitgehende Kontrolle über den kompletten Startvorgang des Linux-Systems. Man ist deshalb wirklich versucht, die eben zitierte Aussage mal etwas ironisch umzuformulieren:

Man ersetzt die Komplexität vieler kleiner, aber separat kontrollierbarer Monster durch ein großes, komplexes Supermonster – und das Ganze ist ja bekanntlich mehr als die Summe seiner Teile – im Guten wie im Schlechten!

Es beschleicht einen jedenfalls ein ungutes Gefühl. Da wird eine geschlossene zentrale Steuereinheit gebaut, der man als Admin zwar noch Vorgaben machen kann, die – bzw. deren Module – man selbst aber nicht mehr kontrolliert oder kontrollieren kann. Diese zentrale Einheit muss dann auch tatsächlich alles im Griff haben und mit vielen komplexen Abhängigkeiten während des System-Initialisierungsvorgangs umgehen können! So etwas kann man sicherlich bauen – aber man muss kein Prophet sein, um zu prognostizieren, dass die notwendige Qualität und Reife einiges an Zeit erfordern wird.

Genau deswegen wäre es aus meiner Sicht auch sehr verwunderlich gewesen, wenn der praktische Umstieg von “System V” auf “systemd” unter Fedora 15/16 und Opensuse 12.1 ohne Probleme verlaufen wäre.

Ich bin als jemand, der als Anwender Linux-Desktop und -Serversysteme Linux für professionelle Schreibtisch- und SW-Entwicklungsarbeiten immer wieder in den Griff bekommen muss, zwar nicht wirklich kompetent, Grundsatzprobleme wie die Vor- und Nachteile von “System V” und “systemd” objektiv zu beurteilen. Ich bin kein Kernel-Entwickler oder Betriebssystem-Designer und habe keine Zeit, mich mit allen Untiefen von Linux zu befassen. Aber man macht halt beim praktischen Umgang mit “Innovationen” unter Linux im Laufe der Jahre so seine Erfahrungen. Ich erinnere nur an die bebenartigen Auswirkungen der Einführung von Akonadi als zentralem Datenpuffer bzw. Datendrehscheibe unter KDE …..

Zusammenfassen möchte ich meine bisherige Erfahrung mit der Einführung von “systemd” unter Opensuse 12.1 wie folgt:

Für mein Gefühl tauchten nach dem Upgrade von Opensuse 11.4 zu Opensuse 12.1 auf zu vielen meiner Systeme zu viele gravierende Probleme auf, als dass ich mich schnell mit “systemd” hätte anfreunden können.

Einen Teil der Probleme habe ich unter
https://linux-blog.anracom.com/2012/01/08/opensuse-121-erfahrungen-mit-einer-neuinstallation/
beschrieben. Weitere Erfahrungen folgen im Verlauf dieses Artikels.

Bei aller Innovationsfreude:

Die Einführung von systemd unter Opensuse 12.1 ist für mich erneut ein schlagendes Beispiel dafür, dass zu oft zu schnell an Fundamenten gerüttelt wird, ohne distributions- oder entwicklerseitig einen wirklichen Plan B zu haben. Was die langfristig sicher sinnvolle Einführung neuer zentraler Komponenten kurzfristig an massivem Ärger für die davon abhängig gemachten Dienste nach sich ziehen kann, hat man doch exemplarisch bei der Einführung von Akonadi unter KDE studieren können. Bis heute hat ein ehemals phantastisches KDE die Folgen nicht bewältigt!

Natürlich ist es immer schwer, einen geeigneten Zeitpunkt für so fundamentale Umstiege zu finden. Aber die regelmäßigen Schwierigkeiten, komplexere Opensuse 11.4-Systeme auf 12.1-Systeme mit “systemd” upzugraden, empfand ich in der Praxis doch als so schwerwiegend, dass ich “systemd” manchmal innerlich verflucht habe:

Mal ging/geht der gesamte Upgrade schief oder bricht mittendrin ab, manchmal funktioniert auch eine Neuinstallation nicht, mal kommt das Netzwerk nicht hoch, mal treten ewig lange Boot- oder Shutdown-Zeiten auf, dann gehen Shutdowns nicht mehr problemfrei über die Bühne, mal geht Apache
nicht und zieht Open-Xchange mit in den Abgrund, dann wieder funktionieren Postfix und MySQL nicht.

Man macht im Laufe von 6 Monaten so ziemlich alles durch, was in vielen Foren an Problemen im “systemd”-Umfeld beschrieben ist. Und man muss immer in die Trickkiste greifen, um die Probleme zu lösen. Wer es nicht glaubt:

Man google mal mit “systemd Opensuse 12.1 System bootet nicht”. Ein beispielhafter schöner Artikel eines verzweifelnden Users findet sich hier:

http://forums.opensuse.org/deutsch-german/hilfe-und-helfen/installation-administration/475133-opensuse-bootet-nicht.html

Wohlgemerkt:
All die von mir oben genannten Probleme traten zumindest auf meinen Systemen nach einem Umschalten auf System V (sysvinit) von Haus aus nicht auf oder verschwanden wieder. Manche Probleme gaben sich zugegebenermaßen auch im Zuge weiterer Updates.

Gewiss: Man kann sich immer irgendwie durchwurschteln, zwischenzeitlich auf System V zurückschalten, auf Updates mangelhafter Probleme hoffen, etc. – aber nervig und vor allem zeitaufwändig ist der Umstieg auf ein “systemd”-basiertes Opensuse 12.1 bisher doch gewesen.

Das will ich gar nicht den grundlegenden, innovativen Ideen zu “systemd” anlasten, eher unzureichenden praktischen Erprobungen vor dem Opensuse 12.1-Release. Es nutzt halt nichts, dass im Fall simpler Systeme eine Neu-Installation u.U. problemfrei durchläuft. Der Prüfstein ist für mich eher der fehlerfrei durchlaufende Upgrade eines komplexen Systems. Und genau da haperte es gewaltig. Aber ich weiß schon: Irgendwie ist man bei kostenfreien Linux-Systemen halt immer Beta-Tester und bezahlt mit eigenem Aufwand.

Zum Umstieg verdammt …

Immerhin hatte SuSE unter Opensuse 12.1 dem Anwender noch die Wahl gelassen, unter welcher Variante – systemd oder sysvinit – er booten wollte. (Ganz so schön getrennt, wie sich das liest, war die Alternativen übrigens nicht – aber lassen wir mal die technischen Details). Die unterschiedlichen Initialisierungsvarianten konnte man auf SuSE’s Grub-Startschirm über die “F5”-Taste erreichen oder aber durch Installation alternativer Pakete. (Siehe http://news.opensuse.org/2011/12/22/systemd-%E2%80%93-boot-faster-and-cleaner-with-opensuse-12-1/).

Ich fand das eigentlich einen guten Schachzug und hätte mir sehr gewünscht, dass diese Politik der Wahlfreiheit mehr als nur einige wenige Monate Bestand gehabt hätte. Leider wurde und wird man aber durch die “Politik” von SuSE systematisch gezwungen, den Umstieg auf “systemd” zu vollziehen. Es gab bereits im Lauf der letzten Monate eine Reihe von Anzeichen dafür, dass bei SuSE beschlossen wurde, keine Zeit mehr in die alten “System V”-Strukturen zu stecken, sondern alle Kräfte auf “systemd” zu konzentrieren.

Ein spürbares Beispiel ist die Tatsache, dass es auf dem aktuellen Update-Stand bei etlichen Opensuse 12.1-Systemen nicht mehr möglich ist, unter “System V”-Bedingungen einen fehlerfreien Shutdown hinzubringen.

Die auf einen kurzfristigen “systemd”-Umstieg ausgerichtete Politik wurde durch das aktuelle Release von Opensuse 12.2 bestätigt ( (s. die Release Notes zu Opensuse 12.2; http://www.suse.de/relnotes/i386/openSUSE/12.2/RELEASE-NOTES.en.html :

“Some desktop components depend on services provided by systemd only. So while openSUSE 12.2 still has basic support for booting a system with sysvinit as fallback, sysvinit nevertheless is considered deprecated and probably even faulty or broken in some regard.”

Genau, möchte man ergänzen – weil man halt ein
bewährtes Startup-Verfahren kurzfristig von der Wartung der Distribution ausnimmt und verkümmern läßt!

Dieser Blog-Artikel bezieht sich aber noch auf Opensuse 12.1. Nach ein paar grundsätzlichen Anmerkungen zu “systemd” aus der Anwender-Perspektive möchte ich bei aller Kritik auch konstatieren, dass “systemd” tatsächlich erhebliche Geschwindigkeitssteigerungen mit sich bringen kann. Hierzu nenne ich ein paar Zahlen für ein voll ausgestattetes Entwicklungsystem.

Ob der Zeitgewinn beim Booten auf solch speziellen Systemen allerdings all den anderen Ärger wert ist, mag der Leser selbst beurteilen.

Danach gehe ich noch kurz auf meine Shutdown-Probleme und Aspekte einer u.U. erforderlichen Reinstallation von Apache2 auf einem systemd-System ein. Diese stehen stellvertretend als Beispiele dafür, welchen Ärger man sich beim “kurzfristigen” Umstieg auf systemd einhandeln konnte.

Kritik an systemd

Wenn man beginnt, sich mit “systemd” zu beschäftigen, stößt man neben vielfachen Beschwerden frustrierter User nach dem Umstieg auf Opensuse 12.1 (u.a. natürlich in Opensuse-nahen Foren) im Internet auch auf grundsätzliche Kritik.

Kritische Anmerkungen und Gesichtspunkte bzgl. “systemd” findet man u.a. in folgendem Beitrag und der nachfolgenden Diskussion – das Ganze ist trotz persönlicher Aversionen der Autoren wirklich recht interessant zu lesen:

http://lists.debian.org/debian-devel/2011/07/msg00269.html

Etwas übersichtlicher geordnet findet man die Diskussion übrigens unter:

http://thread.gmane.org/gmane.linux.debian.devel.general/163640

Dass es tiefgehende Meinungsverschiedenheiten gab, zeigt auch eine Betrachtung der anfänglichen systemd-Diskussion für das Debian-System unter folgendem Link :

http://lwn.net/Articles/452865/

Wie schwierig und im Detail auch noch unausgegoren die Anpassung diverser Linux-System- und Server-Dienste an “systemd” voranschritt, kann man auch sehr schön an den emotionsgeladenen Dialogen zu folgendem “Bug” unter Red Hat nachvollziehen, der sich auf das Zusammenspiel von MySQL und Systemd sowie auf die Folgen eines (zu) stark parallelisierten Starts von Daemonen und Diensten bezieht:

https://bugzilla.redhat.com/show_bug.cgi?id=714426

Die dortige Diskussion vom Anfang dieses Jahres zeigt, dass der Umstieg auf “systemd”, den nach Red Hat damals auch Opensuse zu vollziehen begonnen hatte, noch nicht fertig, nicht perfekt und an der einen oder anderen Stelle eventuell auch noch nicht völlig durchdacht war. In wieweit das heute auch noch gilt, wird sich u.a. an Opensuse 12.2 erweisen.

Im Kern spricht mir aber einer der Diskussionspartner in Red Hats “bugzilla” aus dem Herzen:

Wieso opfert man eigentlich bewährte Strukturen, mit denen man Abhängigkeiten in der Startreihenfolge klar und eindeutig steuern kann, einem komplexeren System aus parallelisierten Starts an Diensten, wenn das auf einfachen Desktop-Systemen insgesamt nur wenige Sekunden Vorteil bringt?

Ich persönlich bin da konservativ: Klare Strukturen gehen mir vor Geschwindigkeit !

Faktisch war es ja auch so, dass man z.B. im Vergleich zu den Default-Einstellungen von SuSE unter den alten “System V”-Bedingungen den Startvorgang durchaus durch eine optimierte Startreihenfolge von Diensten beschleunigen konnte.

Bzgl. von Serversystemen fällt die Startzeit sowieso nicht besonders ins Gewicht. Wichtiger ist dort vielmehr die störungsfreie Uptime. Und wenn es um Ausfallsicherheit geht, muss man sich eh nach anderen Lösungen im HA-Bereich umsehen.

Instruktiv sind auch folgende
Beiträge zu den konzeptionellen Schwächen von “systemd” in einem serverähnlichen Umfeld:
http://monolight.cc/2011/05/the-systemd-fallacy/
http://www.softpanorama.info/Commercial_linuxes/Startup_and_shutdown/systemd.shtml

Nun ein paar eigene Fragen und Gedanken zu “systemd”:

1. Performance-Vorteile – für wen eigentlich?

Eine erste Fragestellung an “systemd” bzgl. der angeblich so bedeutsamen Geschwindigkeitsvorteile ergibt sich aus der täglichen Praxis für mich wie folgt:

Einfache Linux-Desktop-Systeme ohne serverähnlichen Ballast booten heute auch unter sysvinit schon sehr schnell (z.T. < 20 Sekunden) - auch auf modernen Laptops. Hier ein paar Sekunden gewinnen zu wollen, erscheint als Spielerei und Rekordjagd in einem Wettbewerb, der eigentlich von niemandem ausgerufen wurde. Auf Servern ist ein Zeitgewinn beim Booten hingegen wenig relevant. Für welche Zielgruppe soll "systemd" also eigentlich wirklich etwas bringen? Für Workstations? (Hierzu weiter unten ein paar Zahlen).

2. Verringerte Komplexität der Startup-Konfiguration ? Fehlende Posix-Konformität

Zum Zweiten finde ich auch nach mehreren Monaten Gewöhnungszeit überhaupt nicht, dass “systemd” für den normalen Linux-User/Admin einfacher zu handhaben sein soll, als das alte System V mit seinen Runlevels und der Scriptstruktur unter “/etc/init.d”. Ich finde auch nicht, dass es wirklich überschaubarer ist.

Man schaue sich die relevanten Verzeichnisse unter “/etc/systemd” und /”lib/systemd” sowie diverse Unterverzeichnisse unter “/var” einmal an. Mal ehrlich: Die Script-, Verzeichnis- und Link-Struktur unter “/etc/init.d/” wirkt fast aufgeräumter, wenn man das Prinzip mal verstanden hat.

Ja, andererseits stimmt es schon:
Man konzentriert sich unter “systemd” als Admin (gezwungenermaßen?) mehr auf Abhängigkeiten und Zielzustände des Systems und seiner Dienste und weniger auf Skript-Logik. Aber es gilt auch:

Die Anweisungen für die Konfigurationsdateien erschließen sich auch nicht unmittelbar – das mag allerdings ein Gewohnheitsproblem sein, welches sich mit der Zeit gibt.

Viel problematischer finde ich jedoch, dass dem Admin ein substanzieller Teil an Kontrolle verloren geht:

Ein Script konnte man (bei aller internen Komplexität) auf einfache Weise checken, debuggen, modfizieren, im Detail an eigene Bedürfnisse anpassen und auch erweitern. Diese Freiheit für den Shell-kundigen Anwender ist mit “systemd” plötzlich so gut wie verschwunden. Die Durchführung der begrenzten Konfigurationseinträge wird weitgehend von kompilierten Programmen übernommen.

Ich weiß – gerade nach den unter Opensuse 12.1 aufgetretenen Schwierigkeiten – wirklich nicht, ob ich das gut finden soll:

Wenn nach einem Systemupgrade oder Systemumstellungen das ganze System im Bootvorgang hängen blieb, dann konnte man früher durch Eingriffe in die Startup-Skripts und die Startreihenfolge zur Not immer etwas zur Analyse und Behebung der Schwierigkeiten tun. Unter “systemd”-Bedingungen ist das nach meinen bisherigen Erfahrungen ungleich schwieriger ! Wie gesagt:

Man hat viele kleine Monster, die ein Sysadmin aber zur Not noch einzeln zähmen konnte, durch ein zentrales Supermonster ersetzt, mit dem der Admin nur noch durch Konfigurationszeilen in Textdateien, aber nicht auf Ebene der Programmlogik kommunizieren kann.

Die insgesamt fehlende Posix-Konformität wird von den systemd-Befürwortern als “Befreiung von zu engen Grenzen” dargestellt. Man kann das aber auch als Abspaltung und Sonderweg von Linux gegenüber Unix- und BSD-Derivaten deuten – mit entsprechenden Risiken. Ganz zu schweigen von der
Tatsache, dass Ubuntu (noch) einen eigenen Weg beschreitet. In der Konsequenz werden die Hersteller von Server-SW und graphischen Oberflächen ihre Pakete wieder auf mehr Varianten an Boot/Startup-Verfahren ausrichten müssen. Ob das Linux nützt?

3. Tools für die Verwaltung von Units und Targets?

Zum Dritten fehlen mir im Alltag ordentliche graphische Verwaltungstools für die Einrichtung und das Management von systemd-“Units” und -“Targets”. Vielleicht kenne ich sie auch nur nicht – man stolpert jedenfalls nicht gerade darüber.

Auf der passiven Betrachtungsseite gibt es wenigstens das Kommando “systemadm“, das einem in strukturierter Weise eine Überblick über die laufenden Services verschafft. Viel mehr als eine einfache graphische Umsetzung dessen, was “systemctl” auf der Kommandozeile ausspuckt, plus ein paar Tasten zum Stoppen, Starten, Restarten und Reloaden eines Services, bietet es aber auch nicht.

Beim Einsatz des Befehls “systemctl” (http://en.opensuse.org/openSUSE:Systemd_tips) kommen dagegen Hacker-Gefühle aus früheren Zeiten auf … Wahrscheinlich bin ich auf meine alten Tage einfach zu faul und bequem geworden …

Was bringt systemd an Performance auf einem System mit vielen Server-Diensten ?

Ich habe in einem früheren Blog-Eintrag mal die Zeiten angegeben, die ich mit und ohne systemd beim Booten eines Systems ohne spezielle Server-Dienste gemessen hatte :
https://linux-blog.anracom.com/2012/01/08/opensuse-121-erfahrungen-mit-einer-neuinstallation/.

Für simpel gestrickte Systeme kann ich sagen:

“systemd” bringt auf meinen Opensuse 12.1-PCs ohne komplexere Serverkomponenten ca. 4 Sekunden Zeitersparnis gegenüber insgesamt ca. 14 Sekunden Bootzeit ohne systemd. Das Ergebnis (10 Sek Bootzeit) ist möglicherweise auf moderne Laptops übertragbar.

Betrachtet man einmal genauer, was auf anderen rekordverdächtigen Systemen mit superschnellen Bootzeiten eigentlich abläuft, so muss man konstatieren : Praktisch nichts, weil diese Systeme nur in einer minimalen Grundausstattung gefahren werden !

Siehe hierzu : https://bbs.archlinux.org/viewtopic.php?id=147841&p=1.

Realistisch sind die dort genannten Zahlen z.B. für SW-technisch voll ausgereizte Entwicklungs-Systeme oder Server mit komplexem Innenleben und komplexer Peripherie überhaupt nicht.

Auf einem Workstation-System von mir, dass ich als Entwicklungsystem nutze, laufen i.d.R. viele Server- und auch Desktop-Dienste mit: u.a. Apache2 mit PHP und Tomcat, MySQL mit einer Vielzahl von Datenbanken, Postgres, LDAP, Postfix, IMAP, NFS, SMB, NMB, Open-Xchange 6, KVM, VMware Workstation mit unterschiedlichen virtuellen Netzwerken und DHCP-Komponenten, NTP, Firewalldienste, SSHD, SVN, etc.. Hinzu kommen natürlich KDM/KDE.

Das System ist komplex, hat 2 Raid10-Controller mit Überwachungstools, aktivierte smartmon-Tools und eine Vielzahl von LVM-basierten Partitionen, 2 Netzwerkkarten, 2 Soundkarten, eine Nvidia-Grafikkarte, zig USB3 und USB2-Anschlüsse, ….

Da sieht die Welt dann beim Booten schon ganz anders aus – und ist von der SW-Seite her viel serverähnlicher. Es ist daher interessant, sich für so ein System mal Bootzeiten mit und ohne systemd anzusehen.

Hier die Zahlen für den Bootvorgang unter Opensuse 12.1 bis zum Abschluss der Bereitstellung aller Services und der Möglichkeit zum graphischen Login unter kdm:

  • Mit systemd: 48 Sekunden (Kernel 7 Sek + userspace 41 Sek)
  • Ohne systemd: > 82 Sekunden

Das sind dann doch schon erhebliche Unterschiede zwischen “System V” und “systemd” – die etwa einen Faktor 1.7 zu Gunsten von “systemd” ausmachen!

Die Zahlen muss man zudem unter dem Vorbehalt interpretieren, dass der Faktor sogar noch größer sein könnte, wenn nicht ein Teil der Dienste unter Opensuse 12.1 (wie etwa MySQL) noch nach dem alten Muster gestartet werden würde (s.u.).

Also man kann nicht sagen, dass systemd nichts bringt ! Aber für wen denn nun eigentlich?

Ob ich ein simples System innerhalb von 10 oder 14 Sekunden booten kann, ist mir ehrlich gesagt wurscht. Bei einem komplexen System, das ich jeden Tag hochfahre, einen Faktor 1.7 zu gewinnen ist mir persönlich nicht ganz egal. Aus dieser Perspektive lohnt sich das Befassen mit “systemd” schon eher. Ist also “systemd” hinsichtlich der Performance-Gewinne eigentlich für Entwicklungs- und Serversysteme gedacht?

Es liegt ja auf der Hand: Wo viele Services gestartet werden, kann man auch viel parallelisieren. Aber schnelle Bootzeiten bei einem Server? Wen interessiert das wirklich?

[Nebenbei gilt auch:
Ein ähnlich schwergewichtiges System wie das oben betrachtete bootet unter Opensuse 11.4 (allerdings ohne OX6) statt in 80 Sekunden in ca. 55 Sekunden. Dann frage ich mich schon, was hier eigentlich abläuft …. Für eine Detailanalyse hatte ich bisher leider keine Zeit.]

Systemd funktioniert unter Opensuse 12.1 eigentlich als gemischter Start von nativen “systemd”-Diensten und konventionellen “LSB”-Diensten

Bei genauerem Hinsehen muss man feststellen:

In Wirklichkeit lebten und leben wir zumindest unter Opensuse 12.1 noch mit einem Mix aus nativen “systemd”-Diensten und anderen Diensten, die praktisch über die alten und bewährten “System V”-Strukturen initialisiert werden.

Dies galt nach einem Upgrade auf Opensuse 12.1 u.a. für MySQL. Native “systemd”-Dienste erfordern ein “.service”-File. Ich habe unmittelbar nach einem Upgrade deshalb mal nach einer Datei “mysql.service” gesucht, eine solche Datei aber leider bis heute nicht gefunden.

Ich weiß nicht mehr genau, ob ein “clean install” von Opensuse 12.1 hieran etwas ändert – glaube es aber nicht. (https://bugzilla.novell.com/show_bug.cgi?id=730904).

MySQL wird zumindest nach einem Opensuse 12.1-Upgrade also nicht als nativer “systemd”-Dienst eingesetzt. Hier vermittelt statt dessen ein “Compatibility-Layer” von systemd und startet den MySQL-Service noch mittels der alten System V-Scripte.

Im “Kofler” (http://kofler.info/uploads/pdf/linux2011-update7.pdf) lesen wir hierzu entsprechend :

“Nach Fedora in Version 15 hat nun auch openSUSE sein Init-System auf Systemd umgestellt. open-SUSE 12.1 geht in diesem Punkt allerdings nicht so weit wie die aktuelle Fedora-Version 16: Sehr viele Dienste, vor allem Netzwerk-Dämonen, werden weiterhin von herkömmlichen Init-V-Scripts
gestartet. (Die Init-V-Kompatibilität von Systemd macht dies möglich.)
 
Eine grundsätzliche Einführung zu Systemd können Sie im bereits erwähnten Update-Kapitel zu Fedora 15 nachlesen:
http://kofler.info/uploads/pdf/linux2011-update4.pdf
Um die doch recht unübersichtlichen Konfigurationsdateien von Systemd besser zu erforschen, können Sie die grafische Benutzeroberfläche systemadm zu Hilfe nehmen. Das Programm ist im Paket systemd-gtk versteckt.
 
Wenn ein Dienst im Feld DESCRIPTION mit LSB bezeichnet wird, ist dies übrigens ein Hinweis darauf, dass der Prozess nicht durch ein Init-V-Script und somit nur indirekt via Systemd
gestartet wurde.

Die kursiven Hervorhebungen habe ich vorgenommen. Siehe zum Vergleich auch :
http://forums.opensuse.org/english/get-technical-help-here/applications/475423-starting-mysql-boot-how.html

MySQL ist auf einem upgegradeten Opensuse 12.1 genau ein solcher “LSB”-Service :

mysql_service

Davon gibt es aber noch eine ganze Menge mehr:

LSB_Services

Wen das Thema der sysvinit-Kompatibilität tiefer interessiert, der lese hierzu folgende, einführende Artikel :

https://wiki.archlinux.org/index.php/Systemd
http://en.opensuse.org/openSUSE:Systemd_status
https://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd

Ich denke heute, dass viele Probleme, die ich beim Upgrade von 11.4 auf 12.1 erleben musste, evtl. damit zusammenhängen, dass das Umstellen auf “service”-files an der einen oder anderen Stelle beim Upgrade im Gegensatz zu einer Neuinstallation schief gegangen sein mag. Ferner mag es sein, dass der Mix aus “alten” und “neuen” Startstrukturen nicht alle Abhängigkeiten richtig auflöst.

Evtl. wurden Abhängigkeiten, die ich selbst definiert hatte oder die im Zuge der Installation von Drittprodukten festgelegt worden waren, im Upgrade nicht richtig in die neue Mischstruktur aus nativen systemd- und alten sysvinit-konfigurierten Diensten transformiert. Diese Gefahr bestand und besteht halt auf komplexen Entwickler-Systemen, auf denen lokal zu Testzwecken eine Vielzahl von Diensten mitläuft.

Deswegen war ich beim Umstieg auf Opensuse 12.1 heilfroh, dass man immer auf die alten System-V-Konstellation zurückgehen konnte. [Ich hatte deshalb auf einigen Systemen dauerhaft das Paket “sysvinit-init” installiert].

Shutdown-Probleme unter sysvinit (und systemd)

Vor einiger Zeit drängt mich aber nicht nur die Politik von SuSE sondern auch meine bessere Hälfte zum Wechsel in Richtung systemd. Ein Grund hierfür ist der, dass SuSE seit dem Erscheinen von Opensuse 12.1 immer wieder auftretende Probleme mit dem Shutdown nicht vollständig in den Griff bekommt.

Im Internet gibt es einen hübsche Liste von Fehlermeldungen, bei denen Leute nach “kernel”-, “systemd”- oder “sysvinit”-Upgrades keinen ordentlichen Shutdown mehr unter Opensuse 12.1 zustande bekommen. Man google mal mit
“Systemd Opensuse 12.1 shutdown hängt” oder “Systemd Opensuse 12.1 shutdown geht nicht mehr” oder entsprechenden englischen Suchbegriffen.

Bei manchen Opensuse-12.1-Systemen mit “systemd” tauchte das Problem zunächst unter KDE und den zugehörigen Shutdown-Tools auf, die leider nicht mit den erforderlichen, aktuellen Kommandos für eine systemd-Umgebung belegt waren. (Soviel zur einfacheren Handhabung von systemd).

Das ließ sich zumindest in meinem Fall aber leicht korrigieren. (Siehe auch :
http://forums.opensuse.org/english/get-technical-help-here/install-boot-login/469017-12-1-computer-does-not-power-down-upon-shutdown.html )

Einige Leute bekamen dann jedoch im Zuge von Opensuse-Updates ein unabhängiges, zusätzliches Problem unter “systemd” . Dieses lag dann nicht an den bekannten Änderungen – nämlich dass das Kommando “halt” als “halt -p” oder “shutdown -h now” ausgeführt
werden muss. Ich habe das auf den bei mir betroffenen Systemen abgeklappert und kontrolliert.

Da half oftmals nur ein Wechsel zurück zur klassischen “sysvinit”-Konfiguration. Unter Opensuse 12 erreicht man das – wie gesagt – schnell durch dei F5-Taste beim Booten oder die Installation des Pakets “sysvinit-init” (“it will uninstall systemd-sysvinit package”).

Die SuSE-Leute haben natürlich versucht, das Thema in seinen auftretenden Variationen zu fixen – das belegt die Kommunikation in vielen Bug-Trackern und Foren. Ich vermute aber, dass hier mehr Energie in das “systemd”-relatierte Probleme gesteckt wurde, als in das gleiche Problem unter “sysvinit”.

Denn leider und/oder interessanterweise tauchte das Thema mit der Zeit erneut auch bei Systemkonstellationen mit der klassischen “System V”-Konfiguration unter Opensuse 12 auf – also mit “sysvinit-init”. Hiervon war und bin u.a. auch ich selbst betroffen.

Ein “shutdown” (oder auch ein “Reboot”) scheitert in diesen Fällen (meist) unmittelbar nach dem “unmount” der Laufwerke. Das “halt”-Kommando wird dann nicht mehr oder nicht richtig ausgeführt. Die Maschine hängt in einem fast ganz heruntergefahrenen Zustand – nur der “Poweroff”-Vorgang findet nicht statt (trotz “halt -p”).

So habe ich bei mir drei unterschiedliche Opensuse 12.1-Systeme, bei denen sich die gesamte Installation gem. der Opensuse-Update-Repositories auf einem aktuellen Stand befindet. Alle Systeme haben KDE als graphische Oberfläche. Hardwareseitig läuft auf allen Systemen ein SATA-Raid-Controller mit je 4 SATA-Platten im Raid10 Modus. Die CPUs sind unterschiedliche Quad-Cores. Auf keinem dieser Systeme ist z.Z. ein problemfreier Shutdown unter “sysvinit-init” möglich!

Neuerdings aber sehr wohl unter “systemd”!

Auf keinem der Systeme liegt es am unvollständigen “halt”-Kommando ! Man kann in den Runlevels 1 bis 3 alle denkbaren Varianten durchführen und wird das Problem unter “sysvinit-init” dennoch nicht los.

Im Gegensatz zu den Workstation-Systemen habe ich dagegen einen Laptop (ohne Raidcontroller), bei dem es interessanterweise genau umgekehrt ist: Hier funktioniert der Shutdown problemfrei unter dem klassischen “sysvinit-init” – nicht aber unter “systemd”.

Gleicher Paketstand bei allen Systemen! Dies deutet darauf hin, dass das Thema nicht unabhängig von der Hardware-Konstellation ist. Vertrackt ist einfach, dass der Zeit-Punkt, zu dem der shutdown stirbt, vom genauen Updatezustand des Systems und auch von der Kernelversion abhängt:

Mit dem original zu Opensuse 12.1 ausgelieferten Kernel 3.1.0-1.2.1 gab und gibt es auf keinem meiner Systeme ein Problem – weder unter systemd noch unter sysvinit-init. Alle nachfolgenden von Opensuse für 12.1 angebotenen Kernelversionen führten dagegen zu Schwierigkeiten.

Diese äußern sich in Abhängigkeit vom Updatestand anderer Pakete und vom System etwas unterschiedlich. Manchmal erscheint von SuSE’s “halt”-scipt eine “missing”-Meldung zum Zustand eines der durchgeführten init.d-scripts – manchmal nicht. Auf einem der Systeme klappt ein shutdown dann, wenn zunächst ein “init 1” durchgeführt wurde, auf den anderen Systemen nicht. Zwischenzeitlich funktonierte ein Shutdown auf einem bestimmten System manchmal vom Runlevel 3 aus, aber leider nicht immer.

Ich habe weder die Zeit und die Lust, das pro System im Detail zu debuggen !

Ich halte fest:
Shutdown/Reboot-Probleme sind bei mir erst mit der Einführung von “systemd” und ab Kernel-Version 3.1.0-1.9.x aufgetreten. Alle Systeme wurden (mühsamst) von Opensuse 11.4 auf 12.1 upgegradet. Unter Opensuse 10.x bis 11.4 und unter Opensuse 12.1 mit der Kernelversion 3.1.0 gab es nie solche Probleme.

Umstieg zu systemd auf meinen vom Shutdown-Problem betroffenen Systemen – Probleme mit Apache2

Nachdem meine bessere Hälfte
es verständlicherweise leid ist, bei einem shutdown zunächst in den Runlevel 1 zu fahren, und unter “systemd” der Shutdown bei diesbezüglichen Tests kein Problem machte, unternahm ich auf zwei der Workstations einen erneuten Anlauf mit “systemd”.

Nach einigem Einsatz und im Gegensatz zu den erheblichen Problemen, die ich unmittelbar nach dem Upgrade auf Opensuse 12.1 mit systemd erlebt habe, fahren die Systeme inzwischen (allso auf dem aktuellen Update-Stand) relativ soft in den Betriebszustand mit graphischer Oberfläche hoch und runter. Diesen Zustand zu erreichen, war allerdings mit einer reihe von Schwierigkeiten verbunden. Zwei Beispiele:

  • Auf einem der Systeme liefen weder der Apache2-Service noch dortige lokale OX6-Services unter “systemd” hoch. Wohl aber unter sysvinit.
  • Auf einem anderen System hingegen, an dem ein USB-ISDN-Controller angeschlossen ist, der primär von einer virtuellen VMware-Instanz genutzt wird, kam das Netzwerk nicht mehr hoch.

Ich musste mich also u.a. mit Apache und “systemd” befassen. Auch hier kann man reichlich Berichte über ähnliche Erfahrungen im Internet finden. Siehe etwa:

Die netten Lösungsansätze in folgenden Artikeln funktionierten bei mir leider nicht:

http://forums.opensuse.org/english/get-technical-help-here/applications/470208-how-start-apache-service-12-1-a.html
http://www.linux-club.de/viewtopic.php?f=21&t=114874

Nach mehreren vergeblichen Versuchen, durch Änderungen der Startup-Scripts wie auch der Apache-Konfiguration etwas Funktionsfähiges zustande zu bringen, habe ich aufgegeben. Ich habe schließlich Apache2 deinstalliert, anschließend neu reinstalliert und danach wieder mit den vorherigen Konfigurationsdateien ausgestattet. Danach lief und läuft Apache2 nun auch unter “systemd”-Startbedingungen anstandslos hoch.

Im Zuge dieser De- und Re-Installations-Arbeiten gibt es mehrere Dinge zu beachten, die zwar selbstverständlich
erscheinen, die ich anderen Betroffenen dennoch ans Herz legen möchte. Dies gilt vor allem für Leute, die auf einem betroffenen System Open-Xchange 6 [OX6-CE] installiert haben:

  1. Zur Sicherheit die gesamten Web-Server-Verzeichnisse sichern – unter Opensuse also “/srv/www/” bzw. “/srv/www/htdocs” und zugehörige Unterverzeichnisse. Unbedingt aber das ox6-Verzeichnis unterhalb /srv/www/htdocs sichern!
  2. Es lohnt sich, die alten Konfigurationsdateien unter “/etc/apache2” zu sichern. Die Restaurierung des alten Apache-Zustands geht dann einfach viel schneller. Insbesondere dann, wenn man zu Testzwecken eine Reihe unterschiedlicher Domainen eingerichtet hat und Zertifikate für SSL/TLS benutzt.
  3. Zur Sicherheit auch alle Dateien unter “/etc/php5” oder “/etc/php” sichern. Man will seine php.ini-Konfiguration für den Apache-Server ja bei Bedarf auch restaurieren können. Echte Abhängigkeiten bestehen nur bzgl. des PHP-Moduls; aber sicher ist sicher.

Der erste Punkt ist wirklich wichtig, wenn man OX6[CE] im Schadensfall nicht neu installieren will:

Mir gingen im Zuge der Reinstallation und eines ersten fehlgeschlagenen Apache2-Starts alle OX6-Dateien verloren! Nur die – nicht die Daten anderer Verzeichnisse und Domainen! Warum habe ich bis heute nicht verstanden. Ich hätte das allerdings auch nicht für möglich gehalten. Evtl. ist das auch so ein Problem, das mit dem Mix aus nativen systemd-Diensten (hier dem neu installierten Apache2) und konverntionell gestarteten Diensten (hier dem Dienst “openxchange-groupware”) zusammenhängt? Ich weiß es nicht.

Aus der Sicherung ohne Modifikation eingespielt, nahmen die OX6-Dateien bei mir danach auf dem schließlich von “systemd” hochgefahrenen Apache2 anstandslos ihren Dienst wieder auf. Gegenüber einer potentiell erforderlichen OX6-Reinstallation und Dateneinspielung aus Sicherungen der OX6-Datenbank war das jedenfalls ein erheblicher Zeitvorteil.

Kurz noch eine Anmerkung zu dem erwähnten System mit dem Netzwerk-Problem:

Das Netzwerk fuhr auf diesem System nach der Umstellung auf “systemd” nicht mehr hoch. Damit stoppte der Bootvorgang insgesamt, weil weitere Dienste zwingend das Netzwerk benötigten. Als Ursache ließ sich nach einigem Testen ein Fehler beim Hochfahren eines problematischen ISDN-Treibers lokalisieren. Von “sysvinit” locker geschluckt, verursachte dies erhebliche Probleme unter “systemd”. Ein Neuaufsetzen der Runlevel (! Lol …) mit Hilfe von YaST – Deaktivieren des ISDN-Moduls und Eliminieren von VMware aus dem Runlevel 2 – “löste” schließlich das Problem.

Dieses “Phänomen” zeigt einerseits, wie anfällig systemd ist, und in welchem Mischzustand sich Opensuse 12.1 noch befindet.

Konsequent umsteigen

Abschließend möchte ich auch anfügen, dass man den Umstieg auf “systemd” zur Behebung von Shutdown-Problemen konsequent durchziehen sollte, wenn und nachdem man alle anderen Schwierigkeiten mit Apache und anderen Diensten unter systemd in den Griff bekommen hat.

Ich habe z.T. schlechte Erfahrungen mit abwechselnden systemd/sysvinit Boot- und Shutdownvorgängen – zumindest bei installiertem “sysvinit-init”-Paket. Da verschluckt sich beim Shutdown immer wieder mal eine Komponente. Man sollte also das Paket “systemd-sysvinit” installieren und das Paket “sysvinit-init” deinstallieren. Und danach halt versuchen, dauerhaft mit “systemd” zu leben.

Fazit

Mein Unbehagen im Zusammenhang mit “systemd” ist auf dem aktuellen Stand von Opensuse 12.1 nur gemildert, aber nicht beseitigt. Die Einführung von “systemd” im Zuge von Upgrades auf Opensue 12.1 verursachte auf etlichen Systemen erhebliche Probleme, die sich nur mit Mühe und/oder zeitweiligen Wechsel
zurück zu “sysvinit” umschiffen ließen.

Es ist allerdings spürbar, dass sich die Lage unter “systemd” und Opensuse im Zuge von Updates zu 12.1 in den letzten Monaten systematisch verbessert hat. Bei Opensuse allerdings dezidiert zu Ungunsten der Pflege und Wartung des bisherigen bewährten System-V-Initialisierungs-Verfahrens.

Wem die Performance-Vorteile eines hochparallelisierten Starts von Systemdiensten eigentlich zu Gute kommen sollen, ist mir heute viel unklarer als zum Zeitpunkt der Einführung von “systemd”. Den größten Effekt bringt “systemd” offenbar auf Systemen, bei denen viele Dienste gestartet werden, denn gerade dort ist ja auch viel parallelisierbar. Das sind aber Server oder server-ähnliche Systeme – und dort ist ein superschneller Start irrelevant.

An “systemd” führt aufgrund der Politik des Distributors trotz aller Zweifel kein Weg mehr vorbei, wenn man Linux weiter unter Opensuse nutzen will. Wirklich offenkundige Vorteile sehe ich als Anwender noch nicht. Aber vielleicht kommt das ja noch, wenn ich mich künftig noch intensiver mit “systemd” befassen muss.

Aus den bisherigen, sehr gemischten Erfahrungen ziehe ich auch folgende Konsequenz :
Ich werde Opensuse 12.2 im ersten Anlauf jedenfalls nicht durch Upgrade von 12.1, sondern von Grund auf neu installieren und danach Stück für Stück Dienste und Daten aus der alten Umgebung übernehmen. Die Politik, mehrere Versionen eines Betriebssystems parallel am Laufen zu haben, ist sowieso klug, wenn man mit kostenfreien Linux-Distributionen arbeitet. Aber das ist keine neu Erkenntnis.

Bis bald! Hoffentlich in einer besseren Opensuse 12.2-Welt!

Liste der grundlegenden Artikel von Lennart Poettering zu “systemd”