In der letzten Zeit habe ich mehrere Systeme auf Opensuse 12.1 upgraden müssen. Zudem habe ich zwei komplette Neuinstallationen vorgenommen. Zeit mal etwas über meine Erfahrungen zu schreiben – im speziellen auch zum neuen Startup-Verfahren “systemd”. In diesem Artikel geht es um eine Neuinstallation von Opensuse 12.1 auf einem System mit folgenden Charakteristika:

Quadcore CPU Intel Q9550, 8GB RAM, 3ware Raid-Controller mit 4 2TB-Platten im Raid 10 Modus, Nvidia Grafikkarte EVGA 9800GTX+ an einem 1920×1200 Schirm.

Ich möchte hier das System nur soweit installieren, dass mindest die Grafikkarte läuft, die Anbindung ans Netz erfolgt ist und ich in der Lage bin, einen Vergleich der Startup-Zeiten zwischen “systemd” und dem konventionellen “System V Init”-Verfahren durchzuführen.

Ergänzung 04.10.2012:

Wer sich für kritische Betrachtungen zur “systemd”-Einführung interessiert, kann gerne auch meinen Beitrag

Opensuse 12.1, systemd, shutdown, apache

lesen, in dem ich meinen Eindruck nach etwa einem halben Jahr “systemd”-Nutzung unter Opensuse 12.1 zusammengefasst habe.

Potentiell problematisch sind für eine Opensuse-Installation sind an der Hardwareliste zwei Dinge:

Einerseits das Raid 10-System – das Raid-Array entspricht netto einer Platte mit einem Plattenplatz oberhalb von 3,8 TB . D.h. “fdisk” fällt als Formatierungstool aus; es wird “GPT” benötigt. Hier ist aber Optimismus angesagt, denn der Opensuse-Installer bindet mindestens seit Opensuse 11.3 automatisch GPT ein, wenn er eine entsprechend große Platte erkennt. Das Gleiche gilt natürlich auch für den “Partitionierer” unter Yast. Aber man wiss ja nie …

Schwierigkeiten kann ebenfalls die EVGA-Grafikkarte machen. Bei früheren Installationen hatte ich mit dieser Karte regelmäßig Probleme mit dem 1600×1200-Framebuffer-Modus. Dieser wird von Opensuse aber als Modus mit der maximalen Auflösung angeboten – im besonderen für die Konsolen-Darstellung. Den hochauflösenden Modus möchte man natürlich auch gerne ausnutzen – oft genug mußte ich früher aber schon auf den 1280×1024-Modus ausweichen. Hier war ich gespannt, wie sich der “Opensuse 12.1”-Installer verhält und wie man den Nvidia-Treiber zum Laufen bringt.

Positive Punkte während der Installation

Der 1600×1200 Modus wird während der Installation auch bei der EVGA-Karte weitgehend akzeptiert

Ich konnte im graphischen Installer die Auflösung 1600×1200 wählen. Dies machte bis zum Neustart des installierten Systems über “kexec” auch keine Probleme – weder in zwischenzeitlichen Konsol-Ansichten noch im grafischen Modus selbst.

Die Formatierung des netto 3.8 TB umfassenden zusammenhängenden Raid-Arrays gelang ohne jegliche Probleme

Das Raid 10-System ist bei einer Frmwareversion “FE9X 4.10.00.007” des 3ware-Raid-Controllers recht performant – die Schreibraten liegen um die 220 – 250 MB/sec, die Leseraten sind noch höher. Mehr kann man bei den eingesetzten Samsung “2TB F4 HD204UI”-Platten einfach nicht erwarten. Es wäre schade gewesen, wenn das SuSE-System damit nicht hätte umgehen können. Aber weder der Installer noch der “YAST-Partitioner” hatten damit Probleme – wie erwartet benutzen beide automatisch GPT. Ich habe meiner Standardpolitik folgend, mehrere (genauer 4) 80 GB-umfassende Standard-Partitionen am Anfang des Arrays und danach einen großen LVM-Bereich zur Aufnahme flexibel erweiterbarer
Partitionen für Daten und spätere virtuelle KVM-Maschinen anlegen können. Es gab dabei keinerlei Schwierigkeiten.

Ergänzung 13.12.2012 zur “GPT-Partitionierung”:
Das System hat ein Gigabyte Board, das noch mit einem konventionellen BIOS betrieben wird. (Es gibt inzwischen zwar EFI-Updates von Gigabyte. Ich habe die aber nicht benutzt.) Die Reaktion des SuSE-Partitioners auf die Aufgabe, einen 3.8 TB-Platte mit einem BIOS zu kombinieren, war die Anlage eines sog. “Hybrid MBR”. Ich möchte an dieser Stelle darauf aufmerksam machen, dass ein “Hybrid MBR” nicht ohne Tücken ist: So kann man ein Booten aus Partitionen jenseits der ersten 3 in der Regel komplett vergessen – sowohl mit dem herkömmlichen Grub als auch mit bestimmten Grub2-Varianten.

Falls sich jemand fragt, woher die “Politik” mit den 4 Standardpartionen stammt:

Ich bringe hier bootfähige Fallbacksysteme unter, die in Notfällen in der Lage sein müssen, auch Daten in einem bestimmten Umfang aufzunehmen. Die Fallback-Systeme bestehen meist aus Abbildern bewährter Versionen auf einem bestimmten Update-Stand in Kombination mit bewährten KDE-Versionsständen. So komme ich bei größeren Problemen – wie sie im besonderen relativ häufig bei KDE-Upgrades auftreten – oder auch bei Schwierigkeiten mit LVM-Partitionen relativ schnell wieder zu laufenden Systemen, ohne komplette Neuinstallationen oder eine vollständige Restauration von Backups durchführen zu müssen. Hat man Sicherungen seiner Datenpartitionen auf Platten separater externer Systeme untergebracht, oder sind die Datenpartitionen selbst unbeschadet, so erledigt sich die Arbeit meist schon durch Einbinden der Datenpartitionen (ggf. über NFS). Abbilder der Systeme (z.B. per dd) haben sich in der Praxis schon mehrfach bewährt, wenn ein KDE-Upgrade das aktuelle System fast in die Unbenutzbarkeit getrieben hat.

Die Installation geht relativ zügig vonstatten

Aufgrund der hohen Performance des Raid 10-Arrays wird die Installation auch beim Laden vieler Serverkomponenten etc. zügig abgewickelt. Bei der vorgenommenen Installation habe ich praktisch alle relevanten Serverkomponenten sowei eine große Zahl von Entwicklungskomponenten mit installieren lassen. Insgesamt 3,6 GByte an Paketen. Das ging wirklich schnell. Ist aber kein spezielles Verdienst von SuSE.

Probleme während der Installation

Die Weiterführung der grafischen Installation nach Ausführung von “kexec” bringt das System zum Sillstand

Nach der Installation aller Pakete versucht der Installer den neuen Kernel mit “kexec” zu laden und danach das neue System hochzufahren. Hierzu wird temporär auf die Konsolenansicht gewechselt. Danach sollte eigentlich die grafische Installationsoberfläche im aktualisierten System erneut gestartet werden; im Anschluß daran sollte die Konfiguration des neuen Systems (Geräteerkennung und Treiberimplementierung) erfolgen.

Der Wechsel des Installers auf die Konsole für die Durchführung von “kexec” funktionierte. Der Kernel wurde ordnungsgemäß mit “kexec” geladen. Danach werkelte das System noch fleissig im Verborgenen (aha – die erste Anzeichen von systemd – keine Meldungen mehr auf der Konsole!) – und dann wurde der erneute Start der grafischen Installer-Oberfläche eingeleitet. Bei mir endete das aber leider mit eine hübsch bunten Schirm aus Fragmenten und einem Einfrieren des Systems. Das System (besser X-Window) reagierte auch nicht mehr auf Tastatureingaben – ein “Ctrl-Alt-D” für ein geordnetes Herunterfahren blieb wirkungslos. Ich war also gezwungen, die Installation abzubrechen und einen Warmstart durchzuführen.

Ich möchte an dieser Stelle klarstellen, dass dieses Problem meiner Meinung nach vor allem durch
die EVGA Grafikkarte meines Testsystems bedingt ist. Denn auf anderen Systemen mit moderneren Nvidia-Karten trat das hier beschriebene Problem bei einer Neuinstallation vom Opensuse 12.1 nicht auf. Je nach Treibermodul (nouveau) hat die Karte halt doch immer mal wieder Probleme beim Wechseln zwischen dem 1600×1200-Framebuffermodus für die Konsole und dem grafischen Installationsmodus.

Warmstart und erneutes Booten nach System V-Manier ermöglichen nach ein paar Maßnahmen die Fortführung der grafischen Installation

Was macht man in einer solchen Situation, in der man zu Beginn der automatischen Konfiguration zum Warmstart gezwungen wird? Das danach möglicherweise inkonsistente Filesystem macht einem wenig Sorge; das schafft ext4 schon. Ein fsck-Vorgang geht auf dem Raid-System zudem sehr, sehr schnell. Aber wie geht man mit dem dem offenbar problematischen Standard-Grafiktreiber (Nouveau) für die Grafikkarte um?

Meine Schritte waren folgende:

Schritt 1:
Nach dem Warmstart boote ich nur in den Runlevel 3 und zur Elimination von Unwägbarkeiten zusätzlich auf “systemd” verzichten. Ersteres erreicht man durch Eingabe des Parameters “linux 3” in die Parameterzeile des Grub-Startup-Schirms. Und für das zweite hat SuSE dankenswerterweise eine Option angeboten. Man kann auf dem Startbildschirm “F5” betätigen und danach “System V” auswählen. Alternativ gibt man als Parameteroption

init=/sbin/sysvinit

ein. Dann wird der Startvorgang nach alter “System V”-Manier durchgeführt.

Der “System V”-Bootvorgang in den Runlevel 3 erfolgte dann problemlos. Das war auch fast zu erwarten, da die Darstellung der Konsole schon während des ersten Installationsanlaufes keine echten Probleme bereitet hatte. Der grafische Installationsvorgang wurde aber nicht sofort fortgesetzt.

Schritt 2:
Im nun erreichten Runlevel 3 habe ich als ersten geprüft, welches Grafikkartenmodul geladen war. Es war – wie vermutet – das “nouveau”-Treiber-Modul, das SuSE ja seit 11.4 als Default einsetzt. Dieses Treibermodul ließ sich auch nicht entladen – es wurde bei einem “rmmod”-Versuch als “in use” deklariert. Mit einer solchen Situation kann auch der Nvidia-Treiber-Installer nicht umgehen. Deshalb war ein erneuter Bootvorgang von vornherein unausweichlich. Als beste Methode, das System von einer Fortführung der Installation zu überzeugen, erschien es mir nach früheren Erfahrungen, KMS abzuschalten und auch die Pakete für den “Nouveau”-Treiber zu entfernen. Also habe ich mit

“Yast >> /ect/sysconfig-Editor >> System >> Kernel”

den SuSE-Konfigurationsparameter

“NO_KMS_IN_INITRD” auf “Yes”

gesetzt. Ferner habe ich über das Yast-Softwaremanagement das Paket

xorg-x11-driver-video-nouveau”

deinstalliert. Alles in der Hoffnung, dass das System nun erkennen würde, dass die automatische Konfiguration noch nicht durchgeführt oder abgeschlossen wurde. Typischerweise erkennt das SuSE-System das nämlich (wo immer SuSE diese Info hinterlegt wird).

Schritt 3:
Ich habe dann neu gebootet – wiederum mit den Parametern “linx 3 init=/sbin/sysvinit”. Und tatsächlich: Diesmal wurde direkt nach dem Hochfahren eine Meldung angezeigt, dass der Installationsvorgang wegen eines Fehlers nicht abgeschlossen wurde. Danach erfolgte direkt der Wechsel in den grafischen Modus zur Fortsetzung der automatischen Konfiguration. Die wurde auch ohne Fehlermeldungen abgeschlossen. Ein weiterer Bootvorgang in den Runlevel 3 verlief dann ohne Fehler.

Auf diese Weise hatte ich wenigstes die Installation ordnungsgemäß abgeschlossen. Ein “lsmod | grep nouveau” zeigte aber, dass nun immer noch (oder erneut?) der “nouveau”-Treiber geladen war. Dies war insofern überraschend als wir ja
zumindest einen entsprechenden Kernelparameter gesetzt hatten, der zu einer Deaktivierung von KMS führen sollte. 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 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 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.

Das nächste größere Ziel war nun die Ersetzung des “nouveau”-Treibers durch den proprietären Treiber. Hierzu musste das neu installierte System erst einmal netzwerkfähg werden. In meinem Fall wollte ich den benötigten Treiber nämlich einfach per “scp” von einem anderen System kopieren. Hierzu muss man neben den Netzwerkeinstellungen auch den sshd-Daemon zum Laufen bringen. (Ein Treiberdownload per Browser kam erstmal nicht in Frage, da ja nicht klar war, ob der Nouveau nicht erneut Probleme machen würde.)

Netzwerk, sshd, IPV6 und Probleme mit dem dsa-key

In meiner Testinstallation schlägt die standardmäßige DHCP-Konfiguration fehl, weil sowohl auf unserem Router als auch dem Standard-DHCP-Server des Netzes unsere “iptables”-basierten Firewalls nur uns bekannte MAC-Adressen zulassen. Für den Nvidia-Test trage ich deshalb die IP(V4)-Adresse auf dem neuen System zunächst von Hand, und zwar mittels “Yast >> Netzwerkeinstellungen” ein – und gleich auch noch das Standardgateway sowie einen DNS-Server. Alles wie von früheren Opensuse-Installationen her gewohnt – das Setzen der Parameter funktionierte einwandfrei. (Nach der Freigabe der MAC-Adresse der Netzwerkkarte auf dem Router (Standard-Gateway) kann der PC dann auch auf das Internet zugreifen.)

Noch ein wichtiger Hinweis zu IPV6:

Man sollte beim Einstellen der Netzwerkparameter im ersten Anlauf IPV6 nicht deaktivieren (dies wäre bei “Yast >> Netzwerkeinstellungen” unter “Globale Optionen” 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

Nun starte ich schließlich nach den im anderen Blogbeitrag beschriebenen Maßnahmen zu ssh den sshd-Daemon “rcsshd start”. Von einem Remotesystem aus kopiere ich mir nun die Nvidia-Treiberdatei mittels

scp QUELL_PFAD_NVIDIA_TREIBER_DATEI UID@12.1_HOST:/ZIEL_PFAD_NVIDIA_TREIBER_DATEI

auf mein Opensuse 12.1-System. (Die groß geschriebenen Parameter sind natürlich an die jweiligen lokalen Verhältnisse anzupassen.)

Installation des Nvidia-Treibers

Welcher Treiber ist der
richtige? Hier ist nach einem Fehlversuch meinerseits darauf hinzuweisen, dass mit dem 3.1.0-Kernel von Opensuse 12.1 für neuere Grafikkarten nur der proprietäre Treiber ab der Version 290 kompatibel ist.

Dann teste ich im Runlevel 3 mal mit

sh NVIDIA-Linux-x86_64-290.10.run

ob eine Installation möglich ist. Natürlich nicht, da der Nouveau-Treiber ja noch geladen ist. Den Vorschlag des Nvidia-Installers, einen entspechend 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 dabei Probleme – und zwar auf mehreren Systemen – auch mit anderen Grakas. Das “modprobe”-Kommando läuft dann aber ohne Probleme.

Ein abschließendes “init 5” befördert uns danach 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.

Bis auf die oben schon genannten Themen mit der Deaktivierung von IPV6 verhält sich das Opensuse-System dann im wesentlichen wie von Opensuse 11.4 her gewohnt.

Zeitvergleich zwischen Bootvorgängen mit “Systemd” und “System V init”

Nun trage ich noch die Parameter “nomodeset init=/sbin/sysvinit” mit Hilfe von “Yast >> bootloader >> Weitere >> Konfigurationsdateien bearbeiten” permanent für den Opensuse 12.1-Eintrag des Boot-Menüs in die Datei “/boot/grub(menu.lst” ein. Will ich künftihg ein wenig mit “systemd” herumexperimentieren, kann ich den Parameter auf dem initialen Bootscreen immer noch manuell löschen.

Diese Wahlmöglichkeit nutze ich als erstes für einen Zeitvergleich. Ich möchte gerne wissen, was mir “systemd” außer der Tatsache, dass ich keine Meldungen während des Bootvorgangs mehr sehe, an Performance beim Booten bringt. Als erstes sehe ich mir die Zeit an, die vergeht bis nach dem Start aus dem Grub-Menü heraus der KDM-Login-Schirm erscheint. Das ernüchternde, etwas subjektive und handgestoppte Ergebnis ist:

• Booten in den Runlevel 5 mit konventioneller Methode: 20 Sek
• Booten in den Runlevel 5 mit “systemd”: zw. 15 und 16 Sekunden

Im besten Fall !

Fairerweise muss man sagen, das beim Starten des X-Window-Systems Zeit vergeht, die nicht allein von systemd sondern von der Grafikkarte, dem Treiber und dem angeschlossenen Schirm abhängt : wir sprechen hier von ca. 4 Sekunden. Das passt zum Eintrag in “/var/log/messages”:

Jan 8 13:15:59 xen systemd[1]: Startup finished in 4s 211ms 950us (kernel) + 6s 583ms 110us (userspace) = 10s 795ms 60us.

Deshalb dachte ich, dass man einen faireren Vergleich dann bekommt, wenn man mit den
unterschiedlichen Startvarianten nur in den Runlevel 3 hochfährt. Also habe ich die Vergleichsläufe erneut mit “linux 3” als Startparameter durchgeführt. Und da erhielt ich dann ein wahrhaft schockierendes und für mich überhaupt nicht mehr nachvollziehbares (aber reproduzierbares) Ergebnis:

• Booten in den Runlevel 3 mit konventioneller Methode: 13 Sek
• Booten in den Runlevel 3 mit “systemd”: > 38 Sek

Tatsächlich finde ich in “/var/log/messages” folgenden Eintrag:

Jan 8 13:40:27 xen systemd[1]: Startup finished in 4s 163ms 726us (kernel) + 34s 824ms 357us (userspace) = 38s 988ms 83us.

Damit hatte ich erstmal genug von “systemd”! Was immer die Opensuse-Entwickler da fabriziert haben. Das wirkt nicht ganz ausgreift- trotz schöner Artikel wie etwa unter folgender Adresse:

http://news.opensuse.org/2011/12/22/systemd-%e2%80%93-boot-faster-and-cleaner-with-opensuse-12-1/

Man lese aber auch mal die anschließenden Kommentare!

Hinzu kommen richtig ernsthafte Probleme mit systemd beim Upgrade von komplexeren Opensuse 11.4-Systemen auf Opensuse 12.1. Dazu aber mehr in künftigen Beiträgen.

Erstes Fazit

Bei Schwierigkeiten während der Installation hilft es ggf. mit “F5” und auf konventionelle Weise zu booten.

Der Nouveau-Treiber kann während der Installation im Zusammenspeil mit bestimmten Grafikkarten erhebliche Probleme bereiten. Für Nvidia-Karten muss man nach der Installation von Opensuse 12.1 den neuesten proprietären Treiber der Version 290 installieren. Frühere Treiber laufen nicht mit dem neue Kernel.

Die größte Neuerung von Opensuse 12.1, nämlich “systemd” verbessert den Startvorgang -auf einem elementaren System, auf dem keine Serverkomponenten geladen werden. Der sowieso schon schnelle Startup wird beschleunigt – allerdings nicht um weltbewegende Faktoren. Die Verbesserung wird zudem auf einem frisch installierten System nur dann wirksam, wenn in den Runlevel 5 gebootet wird.

Bei einem Start in den Runlevel 3 verhält sich “systemd” unter Opensue 12.1 unerklärlich schlecht; der Startvorgang dauert dann um einen Faktor 3 länger als ein konventionelles Hochfahren des Systems nach bewährter “System V”-Manier.