Opensuse: Upgrade von 11.4 auf 12.1

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.

Opensuse 12.1 – Installationserfahrungen

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.