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

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

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

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

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

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

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

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

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

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

Wenn man denn so weit kommt ….

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

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

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

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

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

Error 25: Disk Read Error

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

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

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

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

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

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

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

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

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

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

Herunterladen eines aktuellen Nvidia-Treibers als Vorsichtsmaßnahme

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

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

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

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

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

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

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

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

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

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

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

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

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

“Shutting down Name Service Cache
Daemon”.

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

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

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

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

Installation des propritären Nvidia-Treibers

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

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

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

und setzt dort den Parameter

NO_KMS_IN_INITRD auf “Yes”

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

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

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

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

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

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

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

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

Nun zur eigentlichen Installation des Nvidia-Kernel-Moduls :

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

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

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

sh NVIDIA-Linux-x86_64-290.10.run

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

linux 3 nomodeset init=/sbin/sysvinit

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

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

modprobe nvidia

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

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

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

als auch

nomodeset [>>> systemd – Start]

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

SSH- und Postfix-Probleme nach Deaktivierung von IPV6

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

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

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

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

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

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

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

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

Probleme mit Pulseaudio

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

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

Probleme mit LSI / 3ware 3DM2

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

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

VMware Workstation 7 funktioniert nicht

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

Dauerhafte Deaktivierung von systemd

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

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

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