“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 :

Davon gibt es aber noch eine ganze Menge mehr:

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:

• http://serverfault.com/questions/338048/apache-not-starting-after-upgrade-to-opensuse-12-1
• http://forums.opensuse.org/english/get-technical-help-here/applications/471026-apache2-sysvinit-vs-systemd.html
• http://forums.opensuse.org/deutsch-german/hilfe-und-helfen/installation-administration/478587-opensuse-12-2-kde-problem-mit-rc-script-beim-start.html
• http://linux.derkeiler.com/Newsgroups/alt.os.linux.suse/2012-01/msg00040.html
• http://web.archiveorange.com/archive/v/wmeLD0IkFcBxBaZfnWGC
• http://www.howtoforge.com/using-php5-fpm-with-apache2-on-opensuse-12.1
• http://web.archiveorange.com/archive/v/TDuKzP57TCmcXBqqezJd
• http://lists.opensuse.org/opensuse-factory/2012-07/msg00060.html
• http://lists.opensuse.org/archive/opensuse-de/2012-03/msg00233.html

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”

• systemd for Administrators I
• systemd for Administrators II
• systemd for Administrators III
• systemd for Administrators IV
• systemd for Administrators V
• systemd for Administrators VI
• systemd for Administrators VII
• systemd for Administrators VIII
• systemd for Administrators IX
• systemd for Administrators X
• systemd for Administrators XI
• systemd for Administrators XII
• systemd for Administrators XIII
• systemd for Administrators XIV
• systemd for Administrators XV

Dieser Artikel kommt um fast ein Jahr zu spät und ist eigentlich völlig veraltet. Ich habe über Monate hinweg schlichtweg vergessen, ihn zu veröffentlichen.

Ich mache dies nun aber trotzdem, weil er eigentlich einen guten Auftakt für kommende Artikel über die Installation des aktuellen “Opensuse 12.2” darstellt. Man kann dann schön vergleichen, wie sich die Dinge entwickelt haben. Ich verwende den originalen Wortlaut des Artikelentwurfs zu “Opensuse 12.1-Upgrades” aus dem Dezember letzten Jahres.

Erfahrungen beim Upgrade von Opensuse 11.4 auf 12.1 aus dem Dezember 2011

Anfang Dezember 2011 habe ich ein Upgrade eines meiner Arbeitsplatzsysteme von Opensuse 11.4 auf Opensuse 12.1 durchgeführt. Dies erwies sich als nicht unproblematisch; zunächst ging nämlich gar nichts mehr. Eine parallel durchgeführte reine Neu-Installation auf einer anderen Partition verlief nach Startschwierigkeiten dagegen besser.

Es kostete mich erhebliche Mühe, meine ursprünglichen 11.4-System unter 12.1 wieder zum Laufen zu bewegen. Hauptgrund war sicher die Umstellung des System-Startups von “System Init V” auf “systemd”:

Die automatische Umstellung durch das Upgrade-Programm von SuSE hat bei mir nicht sauber funktioniert und zu einem Quasistillstand des Systems während des Boot-Vorgangs geführt. Ursächlich waren vor allem Probleme mit dem Hochfahren des Netzwerks. Nach dem Upgrade ließ sich das System letztlich nur durch Deaktivieren von “systemd” in einen nutzbaren Zustand bewegen. In dem läuft es nach einigen Eingriffen nun aber völlig zufriedenstellend.

Nach meinen Erfahrungen würde ich aber jedem raten, 12.1 zunächst auf einer separaten Partition des Systems zu installieren und kein Upgrade auszuführen. Will man künftig mit “systemd” booten, ist es womöglich einfacher, die alte 11.4-Installation zu behalten, eine separate 12.1-Neuinstallation durchzuführen und sich dann systematisch ein neues System unter 12.1 aufzubauen.

Führt man dennoch ein Upgrade einer 11.4-Installation durch sollte man den Boot-Vorgang auf “sysvinit” umzustellen. Freundlicherweise hat SuSE in den Grub-Start-Screen eine Option zur Umstellung des Bootvorgangs eingebaut: Mit “F5” kann man die alte Bootvariante auswählen. Für eine dauerhafte Umstellung siehe den letzten Punkt dieses Artikels weiter unten.

Insgesamt mögen die aufgetretenen Probleme mit der relativen Komplexität meiner Arbeitsplatz-PCs zu tun gehabt haben. Dort laufen für Entwicklungsarbeiten und lokale Tests diverse Serverkomponenten mit – u.a. Apache2, Tomcat, MySQL, Samba, NFS, Open-LDAP, sowie ein OX6-Testserver. Hinzu kommen Dinge wie mehrere VMware Workstation-Instanzen, 2 Netzwerkkarten, ein Raid-System mit LVM-Partitionen, etc..

Der Vollständigkeit halber sei auch angemerkt, dass meine System Nvidia-Grafikkarten (9800GTX, Nvidia GTX 460, Nvidia GTX 560) hat. Die lassen sich aber mit Nvidias proprietären Treiber letztlich problemfrei zum Einsatz bringen (s.u.).

Wenn man denn so weit kommt ….

Nachfolgend also ein paar Hinweise zu Problemen, die während Upgrades von Opensuse 11.4-Systemen auftraten und evtl. auch für andere nützlich sind:

Probleme mit Grub 0.97 und großen Plattensystemen < 2 TB

Auf manchen meiner Systeme finden sich Raid-Arrays mit 2 TB Nettoplatz an einem 3ware-Raidcontroller 9650-SE-4LPML (Raid 10).

Auf dem System gibt es unterhalb der 1.5 TB-Grenze eine Vielzahl von regulären Sub-Partitionen einer erweiterten Partitionen sowie einen größeren LVM-Bereich. Nun habe ich versucht jenseits von 1,5 TB eine neue logische Partition für eine unabhängige Opensuse 12.1 Installation anzulegen. Das ging ohne Probleme; auch die Opensuse 12.1-Installation lief bis fast zum Schluß
erfolgreich durch.

Was dann jedoch nicht mehr funktionierte, war das abschließende Schreiben des Grub-Bootloaders. Nun weiss man ja, dass die von SuSE verwendete 0.97er-Version vom Grub Probleme mit dem Booten von LVM-Partitionen hat. Meine Partition lag aber außerhalb, genauer jenseits eines definierten LVM-Bereichs und jenseits von 1.5 TB. Dennoch quittierte Grub die Installationsversuche mit einem

Error 25: Disk Read Error

Weitere detaillierte Fehlermeldungen zeigen, dass die Grub-Installation die eben bespielte Partition auf der Platte nicht identifizieren kann.

Wählte ich dagegen eine Partition vor dem LVM-Bereich bei ca. 1.1 TByte als Installationsort, ging das Schreiben des Bootloaders anstandslos durch.

Das ganze Problem hat daher sicher nichts mit dem bekannten (alten) 128 GB Limit zu tun – mein PC ist dafür auch viel zu neu. Entweder hat das Legacy Grub, das bei Opensuse eingesetzt wird, Probleme mit Partitionen jenseits eines LVM-Bereichs auf dem Disk Array, oder aber es gibt oberhalb von 1.2 TB irgendeine weitere Grenze, ab der Adressierungsprobleme auftreten. Oder aber es gibt irgendwelche Probleme mit dem 3ware-Treiber …. Siehe auch:

http://forums.opensuse.org/english/get-technical-help-here/install-boot-login/468058-grub-error-25-during-installation-3.html
http://www.fedoraforum.de/viewtopic.php?f=4&t=21695
http://wiki.ubuntuusers.de/GRUB
http://askubuntu.com/questions/60273/2tb-harddrive-with-lvm-grub-error

Fazit zu diesem Punkt: Bei Partitionierung großer Platten zur Sicherheit immer eine Partition unterhalb von 1.5 TB oder aber eines LVM-Bereich für Neuinstallationen freihalten.

Probleme bei einer Neuinstallation mit Grub und großen Plattensystemen > 2 TB

Auf einigen Systemen habe ich Platten im Raid 10-Verbund mit Netto mehr als 3 GB-Plattenplatz. Hier muss GPT zum Einsatz kommen. Dies erledigt der Opensuse-Partitionierer seit Opensuse 11.4 auch relativ problemfrei.

Aber:
Je nach EFI oder BIOS des PCs oder aber bei vorgesehenen NTFS-Partitionen erstellt der Opensuse-Partitionierer einen “Hybrid-MBR”. Siehe hierzu:

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

Grub (z.T. aber auch best. Versionen von Grub2) erlauben dann ggf. keinen Boot-Vorgang von Partitionen mehr, die jenseits der ersten 3 Partitionen liegen. Das sollte man bei der Neuinstallation eines Opensuse 12.1-Systems in einer separaten Partition von vornherein bedenken – wenn auf dem System vorher bereits Opensuse 11.4 und/oder gar MS Windows in weiteren Partitionen installiert worden waren.

Herunterladen eines aktuellen Nvidia-Treibers als Vorsichtsmaßnahme

Beim Upgrade wird eine neuer Kernel installiert. Dies bedeutet, dass man evtl. vorhandene proprietäre Nvidia-Treiber neu kompilieren lassen muss. Es lohnt sich daher, im Vorfeld des Upgrades sich einen aktuellen Treiber-Installer von der Nvidia-Webseite herunterzuladen und an einem geeigneten Ort zu speichern. (Ich habe für solche Dinge immer eine separate Partition, de ich mir in das jeweilige System mounte.)

Für mein aktuelles System kann ich jedenfalls bestätigen, dass man den Treiber mit der Versionsnummer 290.10 mit einer Nvidia GTX 460 letztlich anstandslos zum Laufen bringt und dass unter KDE 4.7.4 keine Probleme auftreten. Zur konkreten Installation siehe den enstprechenden Punkt weiter
unten.

Große Schwierigkeiten werden jedoch alle bekommen, die auf einen 3D-Treiber für eine Geforce FX 5xxx angewiesen sind. Ich habe nämlich parallel versucht, einen Dell 8600C Laptop mit einer Geforce Go 5200 mit Opensuse 12.1 zu bestücken. Leider musste ich hier nach vielen Anläufen auf 3D-Desktop-Effekte, Compositing und 3D-Beschleunigung verzichten.

Der von Nvidia vorgesehene Treiber 173.14.31 funktioniert nämlich nicht mit der aktuellen Kombination aus KDE 4.7, QT-Bibliotheken und dem Polkit, das Opensuse 12.1 installiert. Zumindest nicht mit 3D-Beschleunigung und zugehörigem Compositing für KDE.

Das liegt weniger an Opensuse 12.1 als vielmehr an irgendeiner Inkompatibilität zwischen den aktuellen Qt-Bibliotheken, KDE 4.7 und dem Treiber. Das Ganze funktioniert nämlich schon ab KDE 4.6.5 unter Opensuse 11.4 nicht. Bereits unter Opensuse 11.4 mußte man für solche Installationen das Compositing von vornherein abschalten. Hierzu gibt es gehäuft Artikel in diversen Foren – nicht nur bei Suse.

http://forums.opensuse.org/english/get-technical-help-here/install-boot-login/469160-nvidia-geforce-5200-fx-not-working-no-driver-errors-seen.html
http://forums.opensuse.org/english/get-technical-help-here/install-boot-login/469962-black-screen-after-reboot-opensuse-12-1-a.html
http://forums.opensuse.org/english/get-technical-help-here/install-boot-login/468146-nvidia-drivers-hangs-opensuse-12-1-a.html

http://www.opensuse-forum.de/nvidia-treiber-problem-bildschirm-zerrupft-opensuse-installation/allgemeines-f17/t6243-f19/
http://www.opensuse-forum.de/blackouts-auf-dem-bildschirm-hardware-treiber/themen-f9/t5867-f11/
https://bugzilla.novell.com/show_bug.cgi?id=707110

http://newsodrome.com/hardware_news/nvidia-geforce-5200-fx-not-working-no-driver-errors-seen-28476333
http://www.adminscode.com/ubuntu-nvidia-geforce-5200-fx-drivers-messed-up-system.html

http://permalink.gmane.org/gmane.linux.suse.general.german/210818

Bislang sah sich aber wohl noch niemand genötigt, den Treiber für die FX 5xxxx Karten zu verbessern.

Probleme nach dem Upgrade auf 12.1 und dem Aufruf des neuen Kernels über “kexec”

Während des Upgrades von Opensuse 11.4 werden etliche zusätzliche Repositories, die ich für Opensuse 11.4 in die Yast-RPM-Verwaltung integriert hatte, abgehängt, wenn man nicht entsprechende Vorkehrungen trifft. Einige Pakete können dann ggf. nicht upgedatet werden. In meinem Fall war das aber nichts Essentielles.

Die erste Stufe des Upgrades lief auf vielen meiner Systeme daher entsprechend anstandslos durch – allerdings nur bis zum Neustart des Systems. Hierbei wird der neue Kernel quasi im laufenden Betrieb mittels “kexec” geladen. Das führte bei mir auf den meisten Systemen noch zur Meldung

“Shutting down Name Service Cache
Daemon”.

Danach kam es jedoch meist zum Stillstand des neu installierten Systems über mindestens 10 Minuten hinweg.

Ein erzungener Warmstart brachte mich dann wieder ins Grub-Menü. Hier erwies sich ein 12.1 Systemstart in der Failsafe-Variante mit einem zusätzlichen Systemstart ohne (!) systemd – also gemäß der alten System V Initialisierungsmethode – als segensreich. Das System lief dann (bis auf Postfix; s.u.) anstandslos hoch.

Danach habe ich zur Sicherheit für den nächsten Restart einen Check der Root-Partition erzwungen und den nächsten Bootvorgang mit der regulären 12.1-Variante – nun aber mit der alten Boot-Variante gemäß “sysvinit” und ohne systemd – herbeigeführt. Das ging denn auch problemfrei. Auch der von Suse standardmäßig installierte Nouveau-Treiber tat das, wozu er im Stande ist – und das ist deutlich weniger als der proprietäre Treiber.

Aber über Letzteres will ich nicht klagen; vielmehr bin ich froh, dass jemand versucht, einen freien Treiber zu entwickeln.

Installation des propritären Nvidia-Treibers

Nichtsdestoweniger will ich auf den proprietären Treiber nicht verzichten. Zur Installation sind folgende Schritte erforderlich:

Als erstes muss man das Laden von KMS beim Bootvorgang verhindern. Dies geht am schnellsten mittels des sysconfig-Editors von Yast. Man öffnet

YaST >> “etc/sysconfig”-Editor >> System >> Kernel

und setzt dort den Parameter

NO_KMS_IN_INITRD auf “Yes”

und – soweit vorhanden – den Parameter KMS_IN_INITRD auf “No”.

Danach ergänzt man zur Sicherheit den Eintrag für den Bootloader in “/boot/grub/menu.lst” um den Parameter “nomodeset”; in meinem Fall sieht der entsprechende Abscnhitt für Opensuse 12.1 dann so aus:

title openSUSE 12.1 – 3.1.0-1.2 (default)
 
root (hd0,5)
 
kernel /boot/vmlinuz-3.1.0-1.2-default root=/dev/disk/by-id/scsi-3600050e07e68a3005c9100008aa70000-part6 resume=/dev/disk/by-id/scsi-3600050e07e68a3005c9100008aa70000-part5 splash=silent quiet acpi_enforce_resources=lax showopts nomodeset vga=0x346
 
initrd /boot/initrd-3.1.0-1.2-default

Nach dem Reboot zeigt ein “lsmod | grep nouveau” aber, dass erneut der “nouveau”-Treiber geladen worden war. Dies war nach der Deaktivierung von KMS etwas überraschend. Ich habe die Einstellungen erneut mit dem sysconfig-Editor geprüft. Auch “/sbin/mkinitrd” wurde am Ende der Einstellungen im sysconfig-Editor korrekt aufgerufen. Dennoch wird also der Nouveau-Treiber geladen. Diese Ungereimtheiten kannte ich schon von Opensuse 11.4; siehe auch:

http://www.linuxforen.de/forums/archive/index.php/t-269600.html
und
http://de.opensuse.org/SDB:Probleml%C3%B6sungen-Grafiktreiber

Aus meiner Sicht reicht das Abstellen von KMS nicht; man muss den “nouveau”-Treiber zusätzlich “blacklisten”. Dafür gibt es mehrere Möglichkeiten – man findet einige in den Beiträgen unter folgendem Link :

http://www.linuxforen.de/forums/showthread.php?t=269600

Man kann das “Blackliste” aber auch der aktuellen Nvidia-Installationsroutine für den proprietären Treiber überlassen. Die setzt nämlich bei entdecktem “Nouveau”-Treiber auf Rückfrage beim User ebenfalls einen Blacklisting-Eintrag.

Nun zur eigentlichen Installation des Nvidia-Kernel-Moduls :

Die erste Frage, die sich stellt, ist: Welche Treiberversion ist für Opensuse 12.1 eigentlich Voraussetzung?

Hier ist darauf hinzuweisen, dass mit dem 3.1.0-Kernel von Opensuse 12.1 für neuere Grafikkarten nur
proprietäre Nvidia-Treiber ab der Version 290 kompatibel sind. Man lädt sich einen entsprechenden aktuellen Treiber aus dem Netz herunter (soweit man sein System nach evtl. Problemen mit systemd überhaupt netzwerkfähig bekommen hat; s.o.).

Ich boote danach zur Installation des Nvidia-Treibers in jedem Fall mal mit dem alten sysvinit – nur da ist ja der Runlevel 3 eindeutig definiert und sicher kein X-Server gestartet. (Ich rechne nicht damit, dass Nvidia seine Treiber bereits auf Eventualitäten von “systemd”-Installationen umgestellt hat). Dann testet man im Runlevel 3 mal mit

sh NVIDIA-Linux-x86_64-290.10.run

ob eine Installation möglich ist. In meinem Fall natürlich nicht, da der Nouveau-Treiber ja noch geladen ist! Den Vorschlag des Nvidia-Installers, einen entsprechend notwendigen Eintrag in Startup-Dateien vorzunehmen (Blacklisting des nouveau-Moduls), bestätige ich. Dann starte ich das System neu – nun auch noch zusätzlich mit dem Parameter “nomodeset”, also

linux 3 nomodeset init=/sbin/sysvinit

Danach probiere ich die Nvidia-Installation nochmals. Das funktioniert nun, der Nouveau-Treiber wird nicht mehr geladen. Ggf. zeigt der Nvidia-Installer während des Installationsvorgangs eine Warnmeldung wegen eines Symbolic-Links. Dies passiert oft, wenn zuvor ein anderer Nvidia-Treiber – aus einer anderen Quelle – geladen war. Der Nvidia-installer korrigiert selbständig den bemängelten Link. Dann ggf. zur Sicherheit die Treiber-Installation nochmals durchführen. Die Warnmeldung sollte dabei nicht mehr auftauchen.

Auf meinem System musste ich nach Abschluß des Nvidias-Installers das Modul “nvidia.ko” übrigens per

modprobe nvidia

selbst laden. Der 290-Installer hatte mit einem Laden während der Installation Probleme – und zwar auf mehreren Systemen – auch mit anderen Grakas. Das “modprobe”-Kommando läuft dann aber (interessanterweise) dennoch ohne Probleme.

Ein abschließendes “init 5” befördert uns schließlich vom Runlevel 3 in den Runlevel 5 – und dort wie erwartet endlich in den grafischen Login-Screen von kdm. Auch der nächste Reboot sowohl mit

nomodeset init=/sbin/sysvinit [>>> konventioneller System V Start]

als auch

nomodeset [>>> systemd – Start]

als Parametern läuft dann fehlerfrei bis auf den Runlevel 5 durch.

SSH- und Postfix-Probleme nach Deaktivierung von IPV6

Man sollte beim Einstellen der Netzwerkparameter im ersten Anlauf IPV6 nicht deaktivieren. Dies wäre unter

“Yast >> Netzwerkeinstellungen” im Bereich “Globale Optionen”

grundsätzlich möglich. Man läuft sonst in Schwierigkeiten beim Einsatz von “ssh -X” von Remotesystemen aus. Ferner entsteht ein kleines Problem bei Postfix, dass sich ggf. nicht mehr ordnungsgemäß starten läßt.

Zur Lösung des ssh/sshd-Problems siehe einen früheren Blog-Beitrag :

https://linux-blog.anracom.com/2012/01/03/opensuse-114121-problem-mit-ssh-x/

Dort wird auch einen Fehlermeldung beim Starten des “sshd”-Daemons bzgl. eines nicht gesetzten bzw. nicht ladbaren “DSA keys” behandelt.

Zum Postfix-Problem bei deaktiviertem IPV6 siehe dagegen die Kommentare unter

http://www.linux-club.de/viewtopic.php?f=5&t=114733

Probleme mit Pulseaudio

Ich hatte und habe immer wieder Schwierigkeiten mit Pulseaudio. Das Zeug taugt irgendwie nichts. Auf einem System mit einer unter Opensuse 11.4 voll funktionsfähigen Audigy
Platinum verweigerte der Sound nach dem Upgrade zu opensuse 12.1 den Dienst – und das völlig inklusive Mixer. Folgende Schritte halfen:

Pulse-Audio deinstallieren   >>   Soundkarte Audigy per Yast neu installieren   >>   alsasound neu starten   >>   aus KDE abmelden   >>   neu einloggen   >>   KMix funktioniert wieder   >>   als Sound-Backend über die KDE “system-settings” entweder “gstreamer” oder “xine”

Probleme mit LSI / 3ware 3DM2

Unter Opensuse 12.1 funktionierte nach dem Upgrade das graphische Tool “3DM2” von LSI / 3ware zur Administration von “3ware”-Raid-Controllern nicht mehr. Genauer muss man sagen: die Version 9.5.3 funktioniert nicht.

Ein Download einer neueren 9.5.4-Version von der Adresse
http://www.lsi.com/downloads/Public/SATA/SATA%20Common%20Files/3DM2_CLI-Linux_10.2.1_9.5.4.zip
sowie eine anschließende Installation über die Shell behoben das das Problem. Danach konnte man wieder auf den Controller zugreifen und den Status der Raid-Units wie Platten verfolgen. Auch unter Firefox 8.

VMware Workstation 7 funktioniert nicht

VMware in den Subversionen 7.X und auch 8.0 funktionierte bei mir unter Opensuse 12.1 überhaupt nicht mehr. Ein Upgrade auf die Version 8.1 löste die Probleme aber.

Dauerhafte Deaktivierung von systemd

Will man wegen permanenter Probleme mit systemd eine dauerhafte Rückkehr zu sysvinit vornehmen, so ist dies unter Opensuse 12.1 mittels einer Installation des Paketes “sysvinit-init” möglich. Man lese hierzu:

http://www.suse.com/releasenotes/i386/openSUSE/12.1/RELEASE-NOTES.en.html

Ob man eine Rückkehr zum alten “sysvinit” auf Dauer wird durchhalten können, steht auf einem anderen Blatt. Zur Zeit häufen sich bei mir Probleme mit shutdowns.