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:
- Auf Plymouth während des Bootvorgangs verzichten. Das erfordert einen Eingriff in die Grub2-Konfiguration.
- Direkte Installation des proprietären Nvidia-Treibers.
- 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_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.
