Ich habe auf einem System, das ich von Opensuse 12.1 auf Opensuse 12.2 upgegraded hatte, zweimal kurz hintereinander Probleme mit der Konsistenz des Root-Filesystems unter “ext4” bekommen.

Diese Schwierigkeiten kamen nach einigen größeren Update-Läufen, die ich nach dem Upgrade durchgeführt hatte.

Das Workstation-System beinhaltet einen LSI/3ware-Raid-Controller 9650SE mit einem Raid 10 Array. Das System hat sowohl unter Opensuse 11.4 als auch unter Opensuse 12.1 im Dauereinsatz gut und sehr performant funktioniert. Unter Opensuse 12.2 dagegen bereitet es nun leider Probleme nach Shutdowns mit PowerOff – die führen nämlich mindestens bei einer performance-orientierten Einstellung des Controllers zu Datenverlust und resultierenden Filesystem-Inkonsistenzen.

Interessanterweise konnte ich ähnliche Inkonsistenzen des Root-Filesystems trotz mehrer Anläufe und unterschiedlicher Einstellungen des Controllers nicht unter den auf dem PC immer noch vorhandenen Versionen Opensuse 11.4 und 12.1 provozieren. Das schließt RAM-Defekte praktisch aus. Man könnte nun noch auf einen Platten-Defekt in Sektoren, die die Root-Partition des Opensuse 12.2-Systems betreffen, als eigentliche Ursache tippen. Aber auch smartd zeigte keine Auffälligkeiten.

Die eine Frage ist also, wieso diese Probleme auf ein und demselben System hauptsächlich unter Opensuse 12.2 (vor allem nach umfangreichen SW-Updates) auftreten und nicht unter Opensuse 11.4 oder Opensuse 12.1.

Die andere Frage – und diese ist die für diesen Beitrag interessantere – ist, wie eigentlich systemd beim Booten mit einem inkonsistenten, korrumpierten Root-Filesystem umgeht.

Man muss sich ja selten genug mit dieser Situation auseinandersetzen – und fast hätte ich gerade wegen systemd nicht einmal gemerkt, dass ein gravierendes Problem vorlag ….

Früheres Verhalten von Opensuse bei defekten Root-Filesystemen unter System V

Man erinnere sich:

Unter System V stoppte der Bootprozess, wenn Opensuse 11.4 beispielsweise einen inkonsistenten Zustand des Filesystems entdeckte und wenn das dann automatisch gestartete “fsck” den Schaden nicht automatisch beheben wollte oder konnte. Der Admin wusste dann Bescheid, das System befand sich im Systemverwaltungs-Modus (Runlevel 1) und man konnte sich sofort um das Filesystem kümmern.

Das hatte u.a. den Vorteil, dass sich der Filesystem-Schaden in den vorgefundenen Grenzen hielt und nicht weiter durch Benutzung des fehlerhaften und inkonsistenten Systems verschlimmert wurde.

Aktuelles Verhalten von Opensuse 12.2 mit Systemd bei defekten Root-Filesystemen

Unter Opensuse 12.2 mit systemd ist die oben beschriebene, kluge Politik leider nicht mehr gegeben:

“fsck” (genauer e2fsck) wird zwar gestartet. Aber kommt “fsck” mit der Anzahl oder Qualität nicht klar, wird das fehlerhafte Root-Filesystem durch “systemd” nach kurzem Einblenden einer Warnung in die laufenden Startmeldungen gnadenlos gemounted und der Systemd-Bootvorgang setzt sich fort ! Ja – man mag es kaum glauben – mit einem korrumpierten Filesystem !

Das fand und finde ich nicht nur schockierend, sondern geradezu fahrlässig!

Denn man merkt das Ganze ggf. nur zufällig – nicht zuletzt wegen der hohen Geschwindigkeit von systemd. Bei angeschaltetem Plymouth sieht man u.U. gar nichts, wenn man nicht aufpasst. Zwar wechselt der Schirm beim Start von fsck zu einer Konsole mit Textmodus, aber danach geht es zügig weiter und man landet nach wenigen Sekunden im grafischen Modus – als ob nichts wäre.

Bei textorientiertem Startup ist es fast noch schwerer, das Problem mitzubekommen – die “fsck”-Warnung geht in
der Flut der schnell ablaufenden “systemd”-Meldungen zum Systemstart unter. Was für ein Sch….

Aber der Reihe nach!

Wann traten die Probleme auf?

Die Probleme traten bislang ausnahmslos nach umfangreichen mit YaST2 durchgeführten SW-Updates (KDE, Kernel, … ) auf. Und zwar dann, wenn ich nach den Updates nicht sofort einen Systemneustart durchgeführt hatte, sondern mehrere Stunden weiterarbeitete und danach einen Shutdown mit PowerOff machte.

Auf einem ähnlichen System, auf dem OS 12.2 neu installiert wurde, traten solche Probleme bislang nicht auf. Auch ein anderes upgegradetes System zeigt das Verhalten (noch) nicht. Die anderen Systeme befinden sich jedoch noch auf einem anderen SW-Update-Level.

Allerdings weisen diese anderen Systeme bzgl. des Write-Caches des Raid-Controllers auch andere Einstellungen auf:

Der Parameter “StorSave” des 9650-Raid-Controllers steht im Fall der anderen Systemen auf “Balance” – im Fall der problematischen Systeme jedoch auf “Performance”.

Der Controller der problembehafteten Systeme ist ferner nicht batteriegepuffert. Vielleicht passieren im Rahmen des von systemd gesteuerten Shutdowns bei “performanter” Nutzung des Schreibcaches ja unangenehme Dinge. Vielleicht wird der Puffer des LSI/3ware-Controllers beim Shutdown nicht rechtzeitig geleert, vielleicht wird kein “sync” mehr aufgerufen – was weiß ich.

Man muss die Sache, die erst mit Opensuse 12.2 aufgetreten ist, jedenfalls beobachten:

Das Problem trat ausschließlich auf dem Root-Filesystem auf. Alle anderen gemounteten Filesysteme (alle vom Typ “ext4”) des gleichen Raid 10 Arrays – auch solche für virtuelle Maschinen – meldeten auch bei regelmäßig erzwungenen fsck-Vorgängen keinerlei Problem. Das ist deswegen interessant, weil das Root-Filesystem vor dem Power Off als letztes ausgehängt wird.

Ein Verify des Raid-Arrays zeigt nach einem Auftreten von Fehlern im Root-Filesystem jedenfalls auch aufgetretene Parity-Fehler an. Das spricht ein wenig dafür, dass der Shutdown unter “systemd” ggf. zu rasch erfolgt. Komisch nur, dass das auf dem gleichen System unter Opensuse 12.1 nicht geschieht ! Eine Problem zwischen Treiber und Kernel 3.4 ???

Ich habe den LSI/3ware-Controller nun einige Wochen im “Balanced” Modus des Schreibcaches betrieben. Es trat bis heute kein weiteres Problem mit dem Root-Filesystem auf.

Noch fehlt allerdings noch die Gegenprobe, um auszuschließen, dass das Problem nicht einfach durch problematische Update-Pakete oder Update-Vorgänge erzeugt wurde. Ich hatte dafür wegen anderer Themen bislang einfach keine Zeit.

Wegen der Raid-Controller-Einstellungen möchte ich das Ganze bislang also lediglich als Beobachtung ansehen, deren Ursache unklar ist. Ich werde den Raid-Controller nun wieder auf “Performance” stellen und die Sachlage weiter verfolgen.

Nachtrag 19.01.2013:

Nach vielen Tests muss ich leider feststellen: Bei einem Shutdown mit PowerOff kommt es unter OS 12.2 und systemd mit relativ hoher Wahrscheinlichkeit zu Datenverlusten und inkonsistentem Root-Filesystem, wenn der 3Ware-Controller bzgl. der Schreibpufferung (Parameter “Storsave”) auf “Performance” eingestellt ist.

Wie äußerte sich die Inkonsistenz des Root-Filesystems?

Falsche Inode-Verweise, vor allem etliche verwaiste Inodes und falsche Referenz-Counter. Interessant ist, dass die Dateien, die im Rahmen der letzten “fsck”-Bereinigung im Verzeichnis “lost&found” auftauchten, alle mit YaST2 selbst zu tun
hatten.

Die Schäden waren insgesamt jedenfalls von einer solchen Qualität, dass das automatisch gestartete “fsck” damit nicht mehr ohne User-Eingriffe klarkommen wollte. In den von mir beobachteten 2 Fällen tauchte deshalb der Hinweis auf ein manuell durchzuführendes “e2fsck” auf (s.u.) !

Was macht Systemd beim Starten mit Inkonsistenzen im Root-Filesystem ?

Tja, in meinen Fällen bemerkte systemd beim Starten zwar die Fehler im Filesystem.
fsck wurde dann gestartet. Aber in den Fällen, in denen fsck nicht mehr ohne Userunterstützung mit den Fehlern klarkommen wollte, wurde das kaputte Filesystem – wie gesagt – gnadenlos gemountet.

Dies geschah in meinem Fall an vier Tagen hintereinander (2.11. bis 5.11.), weil ich von den Fehlern – dank des “fantastisch” schnellen systemd – im Entwicklungsstress nichts mitbekommen habe. Erstaunlich, dass ich überhaupt arbeiten konnte.

Nachfolgend ein Auszug aus “/var/log/messages”:

Nov 2 08:49:25 mux kernel: [ 36.774057] EXT4-fs (sda6): warning: mounting fs with errors, running e2fsck is recommended
Nov 2 08:49:25 mux kernel: [ 36.774270] EXT4-fs (sda6): re-mounted. Opts: acl,user_xattr
 
Nov 2 08:53:58 mux kernel: [ 325.684513] EXT4-fs (sda6): error count: 1896
Nov 2 08:53:58 mux kernel: [ 325.684518] EXT4-fs (sda6): initial error at 1351765087: ext4_lookup:1045: inode 922772
Nov 2 08:53:58 mux kernel: [ 325.684523] EXT4-fs (sda6): last error at 1351786094: ext4_lookup:1045: inode 922772
 
Nov 3 09:41:24 mux kernel: [ 30.059173] bootsplash: status on console 0 changed to on
Nov 3 09:41:24 mux kernel: [ 30.849236] EXT4-fs (sda6): warning: mounting fs with errors, running e2fsck is recommended
Nov 3 09:41:24 mux kernel: [ 30.855514] EXT4-fs (sda6): re-mounted. Opts: acl,user_xattr
 
Nov 3 09:46:00 mux kernel: [ 322.602348] EXT4-fs (sda6): error count: 1896
Nov 3 09:46:00 mux kernel: [ 322.602353] EXT4-fs (sda6): initial error at 1351765087: ext4_lookup:1045: inode 922772
Nov 3 09:46:00 mux kernel: [ 322.602357] EXT4-fs (sda6): last error at 1351786094: ext4_lookup:1045: inode 922772
 
Nov 4 08:34:31 mux kernel: [ 34.497854] bootsplash: status on console 0 changed to on
Nov 4 08:34:31 mux kernel: [ 35.111163] EXT4-fs (sda6): warning: mounting fs with errors, running e2fsck is recommended
Nov 4 08:34:31 mux kernel: [ 35.111397] EXT4-fs (sda6): re-mounted. Opts: acl,user_xattr
 
Nov 4 08:39:07 mux kernel: [ 326.695619] EXT4-fs (sda6): error count: 1898
Nov 4 08:39:07 mux kernel: [ 326.695621] EXT4-fs (sda6): initial error at 1351765087: ext4_lookup:1045: inode 922772
Nov 4 08:39:07 mux kernel: [ 326.695623] EXT4-fs (sda6): last error at 1352014560: ext4_lookup:1045: inode 922286
 
Nov 5 09:37:30 mux kernel: bootsplash: status on console 0 changed to on
Nov 5 09:37:31 mux kernel: EXT4-fs (sda6): warning: mounting fs with errors, running e2fsck is recommended
Nov 5 09:37:31 mux kernel: EXT4-fs (sda6): re-mounted. Opts: acl,user_xattr
 
Nov 5 09:42:22 mux kernel: EXT4-fs (sda6): error count: 2368
Nov 5 09:42:22 mux kernel: EXT4-fs (sda6): initial error at 1351765087: ext4_lookup:1045: inode 922772
Nov 5 09:42:22 mux kernel: EXT4-fs (sda6): last error at 1352067644: ext4_lookup:1045: inode 922721

Hübsch, nicht? Seitdem lasse ich “/var/log/messages” nach jedem Bootvorgang auf entsprechende Schlüsselwörter scannen.

Systemd im aktuellen Zustand ist dem Admin jedenfalls nicht dabei behilflich, solche katastrophalen Entwicklungen mit korrumpierten Filesystemen zu vermeiden.

Aber: ich will mich ja nicht aufregen …..

Schadensbehebung – trotz Chaos mit dem Rescue Target

Nun versuche man mal, auf einem von “systemd” gesteuerten Opensuse-System, das Rescue-Target zu erreichen, um “fsck” – wie empfohlen – manuell ablaufen zu lassen. Ich habe das interessehalber auf verschiedenen Systemen in verschiedenem Upgrade-Zuständen getestet.

Ergebnis: Es war unter Opensuse 12.1 und zeitweise (!) auch unter Opensuse 12.2 (vor allem im Originalzustand) fast abenteuerlich, das “isolated rescue target” zu erreichen:

• Das lt. SuSE angeblich noch funktionierende “init 1” führte auf mehreren Systemen zu einem Herunterfahren des Systems mit unmittelbar danach – und ohne oder gar trotz Userinteraktion – ablaufendem Restart in das “default target” – also den grafischen Modus.
• “systemctl isolate rescue.target” zeigte – je nach Update-Zustand des Opensuse 12.1 oder 12.2-Systems das gleiche fehlerhafte Verhalten wie “init 1” oder aber ein unterschiedliches Verhalten – je nachdem, ob es von Konsole “tty2” oder “tty1” gestartet wurde.
• Zwischenzeitlich funktionierte dann lediglich “systemctl rescue” halbwegs wie erwartet. Einen Wechsel der Konsole musste man dabei aber vermeiden. Das Verhalten von systemd war in jedem Fall schwierig – oft verlor man auch den Prompt auf der Konsole, von der der Shutdown gestartet wurde. Überhaupt mutet es merkwürdig an, dass im “Rescue Modus” mehrere Konsolen ansprechbar sind.
• Ein mehrfaches Hintereinanderausführen des Herunterfahrens in den Rescue Modus mit anschließendem Hochfahren in den Default-Modus mit Konsol-Wechsel verhielt sich z.T. unberechenbar.

Wohlgemerkt: Ich spreche hier von Tests auf Systemen, die (außer systemd) keine Defekte beherbergen.

Inzwischen – also auf dem aktuellen Update-Niveau des Opensuse 12.2-Systems – haben sich die Dinge aber deutlich verbessert. Nun funktionieren

“systemctl isolate rescue.target”

und

“systemctl rescue”

im wesentlichen wie erwartet. Man habe Geduld – die Meldung zum Eingeben des Passwortes und der Prompt erscheinen manchmal zeitversetzt.

Bevor nun aber möglicherweise Ekstase bei den systemd-Anhängern aufkommt – es gibt immer noch gravierende Probleme mit der systemd-Logik:

• Ein anschließendes “systemctl default” führt zwar zum Hochfahren in den graphischen Modus – auf der ursprünglichen Konsole mag sich unter Opensuse 12.2 aber der Prompt nicht mehr einstellen.
• Ferner läuft der “agetty”-Prozess nach “systemctl rescue” und einem anschließenden “systemctl default” unter Opensuse 12.2 regelmäßig Amok und verbraucht 90% der CPU-Zeit eines Prozessor-Cores. Man muss “agetty” tatsächlich abschießen, um dem Herr zu werden.

So ist das halt, wenn ein einziges Super-Programm wie “systemd” alles und jedes im System unter Kontrolle behalten muss. Die Tatsache, dass es mit mehreren Konsolen umgehen muss, ist von der neuen Superlösung wohl noch nicht richtig verdaut worden.

Aber ich rege mich nicht auf ….. auch vor den letzten Systemupdates kam man (nach mehreren Konsole-Wechseln und unermüdlichem Probieren) meist doch irgendwie in einen Zustand, der dem früheren “init 1 ” irgendwie ähnelte.

Leider, leider hieß das aber noch lange nicht, dass dann unter “systemd” immer ein

“mount -o remount,ro /dev/rootdevice”

für einen manuellen fsck-Lauf möglich gewesen wäre.

Das ging nur in 50 % der von mir untersuchten Fälle. Bei den Systemen mit bereits vorhandenem Filesystem-Fehler gar nicht. Vielleicht auch bedingt durch die sich inzwischen vergrößerten Probleme mit dem inkonsistenten Filesystem.

Ich musste
jedenfalls in zwei Fällen auf eine CD mit “Rescue-System” ausweichen und von dort meine Root-Partition auf der Platte reparieren.

Seitdem habe ich wieder Ruhe. Was immer die Ursache des defekten Filesystems war – der eigentliche Skandal ist der Umgang von systemd mit einem defekten Filesystem beim Booten !

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

Andererseits bin ich seit Opensuse 12.1 zunehmend skeptisch geworden:

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

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

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

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

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

Aber am Schluss wird alles gut !

Ausgangssituation und Systemkomponenten

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

• Quadcore 9550
• 8 GB RAM
• Mainboard Gigabyte EP 45 Extreme T (konventionelles BIOS, bislang nicht auf EFI/Hybrid EFI umgerüstet)
• 3ware (LSI) Raid-Controller 9650 S
• 4 x 2TB-Platten im Raid 10-Modus mit 3.8 GB Nettoplatz als “/dev/sda”
• Nvidia 9800GTX+

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

Hinweise zum Layout des Plattensystems

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

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

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

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

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

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

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

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

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

Hohe Auflösung und Plymouth

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

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

Stockende Installation, die zum Stillstand zu kommen scheint

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

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

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

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

Probleme mit einem nicht vorhandenen Floppy-Laufwerk

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

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

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

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

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

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

DRIVE A : None

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

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

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

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

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

Ich ändere den Vorschlag der Installationsroutine hinsichtlich der Anlage einer neuen Partition ab:

Die vorhandenen Swap-Partitionen werden weiterverwendet; das System wird allerdings auf der Partition “/dev/sda2” angelegt, die ich mit ext4 formatieren lasse.

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

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

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

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

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

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

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

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

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

Ich bin dagegen nach wie vor optimistisch und glaube, dass

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

Chainloading zwischen Grub und Grub2 erlaubt Fortsetzung der Installation

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

“/boot/grub/menu.lst”

oder nutzt zur Not

YaST2 >> System >> Bootloader.

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

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

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

Fortsetzung der Installation

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

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

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

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

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

Problemlose Netzwerkeinrichtung – trotz systemd

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

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

systemctl | grep LSB

zeigt:

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

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

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

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

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

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

Fehlende Zeile für Parametereingaben unter Grub2

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

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

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

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

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

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

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

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

Off Topic:

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

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

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

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

Ungewohnte Bezeichnung der bootbaren Systeme

Blöd finde ich auch folgendes:

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

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

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

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

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

Auch andere User haben oder hatten ähnliche Probleme, übrigens auch mit ATI-Karten. Eine Recherche im Internet zeigt entsprechende Meldungen.

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

Workaround zum Starten der grafischen Oberfläche

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

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

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

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

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

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

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

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

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

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

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

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

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

Bootzeiten mit der aktuellen “systemd”-Variante

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

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

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

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

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

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

Aber:

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

Problemfreie SW-Updates

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

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

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

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

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

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

Installation Nvidia-Treiber

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

systemctl stop xdm.service

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

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

sh NVIDIA-Linux-x86_64-304.51.run

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

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

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

System >> Kernel

der Eintrag für

“NO_KMS_IN_INITRD” auf “Yes”

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

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

lsmod | grep nvidia

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

Anschließend startet man – hoffentlich erfolgreich – mit

systemctl start xdm.service

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

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

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

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

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

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

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

Verlust der grafischen Darstellung des Grub2-Menüs

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

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

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

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

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

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

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

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

Ich habe mir dem Geiste der Anleitungen folgend jedenfalls eine Datei

/etc/grub.d/43_openSUSE

angelegt. Der Inhalt ist folgender:

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

Mit

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

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

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

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

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

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

Direktes Booten zum Grub2-Menü

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

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

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

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

fdisk /dev/sda

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

Command (m for help): p
 
Disk /dev/sda: 4000.0 GB, 3999977701376 bytes
255 heads, 63 sectors/track, 486302 cylinders, total 7812456448 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
 

das Ergebnis ist:

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

ab.

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

Grub2 – Booten von /dev/sda4

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

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

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

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

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

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

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

her.

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

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

Fazit – viel Licht, ein wenig grüner Schatten

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

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

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

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

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

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

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

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

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

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

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