Monthly Archives: September 2012

Opensuse 12, VMware WS 9, vmci-Problem

Posted on by

Bei der heutigen Installation der VMware Workstation 9 unter Opensuse 12.1 trat bei mir folgendes Problem auf:

Ich hatte die Installation als root über das Kommando

sh VMware-Workstation-Full-9.0.0-812388.x86_64.bundle

durchgeführt. Die lief dann über den graphischen VMware-Installer auch einwandfrei durch. Ein Start vorhandener virtueller Maschinen (Win XP, Win 7) schlug jedoch mit folgender Fehlermeldung fehl:

Version mismatch with vmci driver: expecting 11.0, got 10.0. Module DevicePowerOn power on failed.

VMCI-Treiber (“Virtual Machine Communication Interface”) sind für den VMware-Workstation-Betrieb essentiell. Sie regeln die Kommunikation zwischen Host und den virtuellen Gästen. VMCI erfordert Kernel-Module; die Fehlermeldung zeigt an, dass nicht das richtige Modul – in der richtigen Version – geladen wird.

Dieses Problem hat mich etwas Zeit gekostet. Ich hoffe, der nachfolgende Artikel zur Problemlösung hilft auch anderen.

Problemursache

Aus meiner Sicht arbeitet der Installer für die WS 9 diesbzgl. unter Opensuse 12.1 und 12.2 nicht hinreichend gründlich und kollidiert in meiner Situation mit dem sog. “Weak Versioning” oder “Weak-Update”-Mechanismus.

Oftmals ist ein Modul mit mehreren Kernel-Versionen kompatibel. Kernel-Updates und KMP-Updates führen dann dazu, dass im Verzeichnis “/lib/modules/KERNEL_VERSION/weak-updates/” und darunter Links zu kompatiblen Modulen anderer (früherer) Kernel-Versionen angelegt werden.

http://http://www.suse.de/~agruen/KMPM/old/KernelModulePackagesManual-CODE10.pdf
http://comments.gmane.org/gmane.linux.kernel.dkms.devel/843

Der gut gemeinte Mechanismus kann schon mal zu Problemen führen:

http://www.gossamer-threads.com/lists/linux/kernel/992144
http://www.linuxquestions.org/questions/suse-novell-60/virtualbox-kernel-modules-wont-load-after-updating-kernel-in-opensuse-11-0-a-696801/

So gilt:
Hat man auf einem Opensuse oder Red Hat System vorher andere VMware WS Versionen am Laufen gehabt und zwischenzeitlich Kernel-Updates (und/oder WS-Updates) durchgeführt, so greift ggf. der beschriebene Mechanismus. Danach befinden sich im oder unterhalb des Verzeichnisses “/lib/modules/KERNEL_VERSION/weak-updates/” also möglicherweise Einträge zu Kernelmodulen für VMware. Diese haben dann Priorität gegenüber anderen gleichlautenden Modulen in anderen Verzeichnissen unterhalb “/lib/modules/KERNEL_VERSION” (mit Ausnahme von Modulen unter “/lib/modules/KERNEL_VERSION/updates”).

Der gleiche Mechanismus greift bei Opensuse übrigens auch, wenn man parallel mehrere Versionen derselben Kernelversion – aber mit unterschiedlicher Modulausstattung wie den Desktop-Kernel “3.1.10-1.16-desktop” oder den Default-Kernel “3.1.10-1.16-default” installiert hat.

Der Installer für die WS 9 er rechnet leider nicht damit, dass es zwei Module “vmci.ko” an unterschiedlichen Stellen unter “/lib/modules/KERNEL_VERSION/” gibt. In meinem Fall war es aber so, dass kontinuierliche Upgrades und zwei parallele Kernelvarianten auf meinem System zu einer solchen Situation geführt hatten. Ein ähnliches Problem gab es schon mal bei Opensuse 11.1 und Opensuse 11.4 mit dem vmmon-Modul.

Ein find-Befehl am root-prompt
zeigte auf meinem aktuellen Opensuse 12.1, auf dem früher unterschiedliche Versionen der WS 7 und 8 installiert und upgegradet worden waren, fast erwartungsgemäß :

mylinux:~ # cd /lib/modules/3.1.10-1.16-default
mylinux:/lib/modules/3.1.10-1.16-default # find . -name “*vmci*”
./weak-updates/updates/vmci.ko
./misc/vmci.ko

Nach der WS 9 Installation waren bei mir jedenfalls 2 “vmci.ko”-Module vorhanden! Wie immer und wann auch immer im Zuge früherer Kernel und VMware-Updates das eine “vmci.ko”-Modul im Verzeichnis unter “/lib/modules/3.1.10-1.16-default/weak-updates/updates” gelandet ist. Der Eintrag wird bei mir auch aus anderen Kernel-Zweigen unter “/lib/modules/” (Opensuse’s Desktop-Kernel !) referenziert.

Hinweis:

Hat jemand das gleiche Problem wie ich, findet aber nichts im “weak-updates”-Verzeichni, so lohnt sich jedenfalls eine Suche in anderen Subverzeichnissen von “/lib/modules/KERNEL_VERSION”:
 
Bei anderen Opensuse-Versionen (z.B. 12.2) kann ein zweiter Eintrag statt unterhalb des “weak-updates”-Verzeichnis ggf. auch im “weak-updates”-Verzeichnis selbst oder aber im Verzeichnis “/lib/modules/KERNEL_VERSION/updates” vorliegen.

Das im “weak-updates”-Verzeichnis eingetragene Modul “vmci.ko” ist zwar mit der aktuellen Version 3.1.10-1.16 des Opensuse Default- und des Desktop-Kernels kompatibel, denn dafür wurde das Modul mal von einem VMware-Installer kompiliert. Der Eintrag entspricht aber dem Modul einer VMware WS 8.0.4 Version !

VMware WS 9 benötigt dagegen ein neueres “vmci.ko”-Modul und prüft die Modul-Version offenbar auch beim Hochfahren eines virtuellen Gastes ab. Daher die oben genannte Fehlermeldung! (Die richtige, benötigte und zur WS 9 passende Modul-Version lag und liegt im Verzeichnis “/lib/modules/3.1.10-1.16-default/misc”.)

Offenbar wird im Zuge des Bootvorgangs beim initialen Aufbau der vmware-Umgebung durch das Script “/etc/init.d/vmware” also das falsche Modul – nämlich das im “weak-updates”-Verzeichnis eingetragene – geladen. Woran legt das?

Verantwortlich hierfür sind Prioritätsregeln für die Ladereihenfolge; s. hierzu den obigen PDF-Link zum “Weak-update”-Mechanismus. Zitat:

Modules usually remain compatible with a range of kernel-flavor packages. To make such modules visible to other kernel-flavor packages, symbolic links to compatible modules are put in /lib/modules/version-release-flavor/weak-updates/ directories. Modules in the weak-updates/ directory has lower priority than modules in the updates/ directory, but higher priority than all other modules in /lib/modules/version-release-flavor. If more than one compatible module is available for a kernel, the module with the highest kernel release is chosen.

Auch “/etc/init.d/vmware” verläßt sich darauf, dass es nur ein Modul mit der Bezeichnung “vmci.ko” gibt. Das Script führt einfach “insmod vmci.ko” aus – und dann greifen eben die Prioritätsregeln des “weak-update”-Mechanismus bei der Lade-Reihenfolge. Diese sind im System (depmod!) hinterlegt.

Eigentlich müsste der VMware-Installer für die WS 9 deshalb unter Opensuse nicht nur sein neues “vmci.ko”-Modul kompilieren, sondern auch die alten mit dem Kernel kompatiblen Module (bzw. Links) entfernen – und dabei checken, dass es auch die Einträge unter “weak-updates” erwischt – und dann das neue Modul an der richtigen Stelle (hier: “/lib/modules/3.1.10-1.16-default/misc”) hinterlegen.

Der Installer für VMware WS 9 rechnet aber wohl leider von vornherein fest damit, dass das “vmci.ko”-Modul nur unter dem Verzeichnis “/lib/modules/KERNEL_VERSION/misc”
lag und liegen soll. Das muss nach Updates und Zusatz-kernel-Installation unter Opensuse und Red Hat
aber nicht zwangsläufig der Fall sein.

Das ich nicht der einzige bin, dem das schon mal mit einem VMware-Kernel-Modul passiert ist, kann man nach einer Suche mit

  • “VMware WS Version mismatch vmci vmmon driver” oder
  • “VMware WS Version mismatch vmci” oder
  • “VMware WS Version mismatch”

im Internet nachvollziehen.

Auf einem anderen System, auf dem ich die WS 8.0.4 jungfräulich aufgesetzt hatte, tauchte das vmci.ko-Modul nur unter “/lib/modules/3.1.10-1.16-default/misc” auf. Na ja, ….. Jedenfalls war die Ursache meines vmci-Problems mit der WS 9, dass es zwei VMware-Kernelmodule gleichen Namens unterhalb von “/lib/modules/3.1.10-1.16-default” gab. Damit war und ist aber auch der Lösungsweg klar.

Lösung

Man verschiebe das Modul als root in ein anderes Verzeichnis (bei mir /extras/root) und starte VMware neu:

mylinux:/lib/modules/3.1.10-1.16-default/weak-updates # cd updates/
mylinux:/lib/modules/3.1.10-1.16-default/weak-updates/updates # ls
balloon blkfront netfront platform-pci scsifront vmblock.ko vmci.ko vmhgfs.ko vmsync.ko vmxnet.ko vsock.ko
mylinux:/lib/modules/3.1.10-1.16-default/weak-updates/updates # mv vmci.ko /extras/root/
mylinux:/lib/modules/3.1.10-1.16-default/weak-updates/updates # /etc/init.d/vmware stop
Stopping VMware services:
     VMware Authentication Daemon     done
     VM communication interface socket family     done
     Virtual machine communication interface     done
     Virtual machine monitor      done
     Blocking file system      done
mylinux:/lib/modules/3.1.10-1.16-default/weak-updates/updates # vmware &

Beim erneuten Start (vmware &) können Abhängigkeiten (vergl. “/lib/modules/3.1.10-1.16-default/modules.dep”) und die bisher definierte Ladereihenfolge nicht mehr richtig aufgelöst werden, weil das (falsche) Modul nun fehlt. VMware versucht in dieser Situation automatisch, seine Module neu zu kompilieren und die Modulabhängigkeiten durch ein abschließendes depmod zu regeln.

Danach gibt es nurmehr ein “vmci.ko”-Modul :

mylinux:/lib/modules/3.1.10-1.16-default # find . -name “*vmci*”
./misc/vmci.ko

und auch “/lib/modules/3.1.10-1.16-default/modules.dep” zeigt die richtigen Einträge/Abhängigkeiten:

misc/vmci.ko:
misc/vmmon.ko:
misc/vmnet.ko:
weak-updates/updates/vmblock.ko:
weak-updates/updates/vmxnet.ko:
weak-updates/updates/vmhgfs.ko: misc/vmci.ko
weak-updates/updates/vmsync.ko:
weak-updates/updates/vsock.ko: misc/vmci.ko

Und natürlich lassen sich die virtuellen Gäste unter der VMware WS 9 nun auch problemlos hochfahren.
Man kann dann auch die die HW-Kompatibilität der alten WS 8 Gästsystem an die WS 9 anpassen.

Viel Vergnügen weiterhin mit der VMware Workstation 9 unter Opensuse 12 !

Umlaute, JQuery, Ajax, Formulare und PHP

Posted on by

Wir setzen im Rahmen unserer Web-Projekte neben dem serverseitigen PHP natürlich auch JQuery auf der Javascript-Seite ein – zunehmend auch, um in unsere CM-Applikationen ajax-basierte Features zu integrieren.

Gerne würden wir alles – Webseiten, JQuery/Ajax, PHP-Programme, MySQL etc. – stromlinienförmig auf UTF-8 ausrichten. Aber das geht leider nicht immer. Teils aus historischen Gründen, teils weil man es kundenseitig mit Apache-Webserver-Installationen zu tun bekommt, die per “AddDefaultCharset”-Directive auf ISO-8859-1 als Standard-Character-Set eingestellt sind, teils aber auch, weil man nicht beliebig an den vorgefundenen Datenbanken herumdrehen kann.

In diesem Umfeld stolpere ich dann ab und zu in das eine oder andere Problem mit Umlauten – zuletzt tatsächlich mal wieder im Zusammenhang mit den Ajax-Tools von JQuery. JQuery/Ajax kann in einem serverseitigen ggf. heterogenen Zeichensatz-Umfeld durchaus für Überraschungen sorgen. So sind im Internet haufenweise Fälle beschrieben, in denen eine bislang laufende PHP-Anwendung nach dem Einsatz von JQuery/Ajax z.B. deutsche Umlaute in den üblichen kryptischen Zeichensalat verwandelt hat, der bei einer ungewollten Zeichensatz-Konversion halt entsteht. Links zu Beispielen findet man weiter unten.

Nachfolgend deshalb ein paar Hinweise darauf, warum und wann man beim Einsatz von JQuery/Ajax aufpassen muss, und wie man mit den eventuell resultierenden Problemen umgehen kann. Auf Code-Beispiele habe ich verzichtet, da die Kenntnis der Problemursache einem Entwickler i.d.R. schon zeigt, was er zu tun hat. Ich hoffe, die Ausführungen sind trotzdem für den einen oder anderen, der sich mit JQuery, PHP und Umlauten herumschlagen muss, nützlich.

Ich rede nachfolgend übrigens nur über Systeme, in denen ISO-8859-1 bzw. Latin1-Zeichensätze sowie der UTF-8-Zeichensatz eine Rolle spielen.

Problemseparation: Klassische Umlautprobleme aufgrund von Webserver, PHP- und MySQL-Einstellungen

Es ist wichtig, JQuery/Ajax-induzierte Umlautprobleme von anderen Umlaut-Problemen bei Einsatz von PHP-Anwendungen abzutrennen.

Umlaute sind im PHP-, MySQL-Umfeld auch ohne JQuery von Haus aus ein Thema, das eine gewisse Komplexität aufweisen kann:

Dies liegt daran, dass neben Einstellungen des Webservers und neben der php.ini-Konfiguration natürlich auch die Zeichensatz-Einstellungen des Datenbankservers eine Rolle spielen.

Zeichensätze spielen grundsätzlich eine essentielle Rolle im Datenaustausch zwischen Client- und Serverkomponenten einer Applikation – also bei der Client/Server-Kommunikation. Hier gelten zwischen Web-Client und Web-Server Regeln und Konventionen, die man u.U. mit geeigneten Mitteln beeinflussen kann. Server und Client können sich im Rahmen bestimmter Protokolle in vielen Fällen auch darüber informieren, welchem Zeichensatz die eben ausgetauschten (Web-Daten) unterworfen sein sollen und wie die Daten dementsprechend vom Empfänger zu interpretieren und darzustellen sind.

In manchen Fällen gelten aber auch harte Regeln, die man dann schlicht kennen muss. Wie wir sehen werden, liefert JQuery/Ajax u.U. für letzteres ein wichtiges Beispiel.

(Hinweis zur Sicherheit: Ich spreche hier bei der Betrachtung der Web-Server-Client-Kommunikation nicht von URL-Encoding oder ähnlichem, sondern davon, welchem Zeichensatz die empfangenen Daten von der empfangenden Applikation letztlich zuzuordnen sind. Das hat mit URL-Encoding nichts zu tun.)

Klarmachen muss man sich ferner, dass auch viele Datenbanksysteme definierte oder einstellbare Zeichensätze in der Kommunikation und beim Datenaustausch mit ihren jeweiligen Clients einsetzen. Hierfür liefert MySQL ein schönes Beispiel (s.u.).

Andererseits gelten definierte Zeichensätze auch für die interne Repräsentation von Daten in einer Applikation und /oder einer
Datenbank. Der Zeichensatz für die interne Datenrepräsentation oder die Ablage in einer Datenbank kann dabei vom Zeichensatz, den die Datenbank in der Kommunikation mit ihren Clients anwendet, durchaus abweichen! Für die korrekte Zeichenumsetzung sorgt die Bank selbst, man muss als Entwickler aber dennoch wissen, was für ein Zeichensatz für die Kommunikation gilt oder gelten soll und wie man das im Bedarfsfall beeinflussen kann.

Der Unterschied zwischen Zeichensätzen für die Datenbanktabellen und den Zeichensätzen für die Kommunikation mit den Datenbank-Clients führt im Zusammenspiel von MySQL und PHP oftmals zu erheblichen Verwirrungen. Man schaut auf die Kollation der Datenbank-Tabellen und vergisst leider oftmals, dass der Zeichensatz für den Transfer der Daten zwischen Datenbank und PHP-Applikation im Umfeld von Umlautproblemen viel entscheidender ist!

Als Konsequenz mussten auch wir immer wieder lernen, dass es sinnvoll und wichtig ist, die Datenbehandlung in den Basisklassen unseres hauseigenen Frameworks auf der PHP-Seite mit zeichensatzbezogenen Kodier- und Dekodier-Funktionen (unter Einsatz von z.B. “utf8_decode”, “utf8_encode”, “iconv” ) sowie MySQL-Anweisungen der Art

auszustatten – und zwar so, dass die Durchführung einer De- oder Enkodierung und/oder der jeweils zu beachtende Zeichensatz sich über Konfigurations- oder Setup-Parameter der Applikation steuern lassen. Damit kann man sich dann flexibel an die vorgefundene Server-Umgebung anpassen!

Dass man sich ohne Vorkehrungen und systematische Analyse der verschiedenen Server-Einstellungen sehr schnell in einem Gestrüpp wiederfinden kann, zeigen z.B. folgende Artikel:

http://www.php-resource.de/forum/php-developer-forum/100181-umlauteproblem-bei-formulardaten-ms-sql.html
http://www.sebastianviereck.de/de/mysql-php-umlaute-sonderzeichen-utf8-iso/
http://www.php.de/datenbanken/45101-problem-mit-utf8-latin1.html
http://www.winfuture-forum.de/index.php?showtopic=193063

Wie gesagt: Bei der MySQL-Datenbank muss man begrifflich sorgsam unterscheiden zwischen den “Collations”-Einstellungen für das Hinterlegen der Daten in den Datenbanktabellen und dem Zeichensatz, den die Bank in der Kommunikation mit ihren Clients (hier: PHP-Modulen des Webservers) einsetzt. Das sind verschiedene Dinge – vor allem eine fehlerhafte oder unerwartete Einstellung des Zeichensatzes für die Kommunikation mit DB-Clients ist nach meiner Erfahrung Ursache für viele Umlaut- und Zeichensatz-Probleme im PHP/MySQL-Umfeld.

Man führe sich im Falle des Falles nochmals den Artikel http://dev.mysql.com/doc/refman/5.1/de/charset-connection.html und die Möglichkeiten des Einsatz des “SET NAMES”-Kommandos bei der Initialisierung der Datenbankverbindung zu Gemüte! Ein kurzer Test mit “SET NAMES” hat mir schon oft geholfen – genau deswegen habe ich ja irgendwann eine generelle Möglichkeit zur Parametrierung in unseren PHP-Applikationssetup vorgesehen.

Bevor man JQuery-induzierte Umlaut-Probleme angeht, sollte man also wissen,

  • ob und mit welchen Zeichensätzen der Webserver und die Datenbank arbeiten und
  • auf Basis welchen Zeichensatzes jede dieser Serverkomponenten Informationen zu ihren jeweiligen Clients überträgt.

Insgesamt sollte man sich beim Analysieren von JQuery/Ajax-induzierten Umlaut-Problemen sicher sein, dass die eigene Applikation mit den unterschiedlichen Webserver- und Datenbankeinstellungen konsistent umgeht und dass nicht schon ohne JQuery ein Umlaut-Problem vorliegt.

Warum muss ich zusätzlich an JQuery denken?

Bei der Parametrierung, der Konfiguration und der Konzeption eigener PHP-Applikationssysteme tut man in jedem Fall gut daran, von vornherein an den Einsatz von JQuery/Ajax zu denken. Warum?

Weil JQuery und seine Ajax-Tools bestimmte Regeln für die Kommunikation mit Webservern befolgen, auf die man sich zumindest serverseitig einstellen muss ! Zu finden sind solche Regeln auf der Seite

http://api.jquery.com/jQuery.ajax/

Es lohnt sich, sich diese Seite in Gänze (!) zu Gemüte zu führen. Liest man dort vorschnell nur den nachfolgend zitierten Abschnitt zum “ContentType” beim Ajax-Setup, so kann man schnell Schiffbruch erleiden.

contentTypeString
Default: ‘application/x-www-form-urlencoded; charset=UTF-8’
 
When sending data to the server, use this content type. Default is “application/x-www-form-urlencoded; charset=UTF-8”, which is fine for most cases. If you explicitly pass in a content-type to $.ajax(), then it’ll always be sent to the server (even if no data is sent). If no charset is specified, data will be transmitted to the server using the server’s default charset; you must decode this appropriately on the server side.

Der letzte Satz deutet schon mal Schwierigkeiten an – man muss sich ggf. um die Servereinstellungen kümmern! Andererseits könnte man aber auch glauben, dass man den Zeichensatz für die Kommunikation mit dem Server clientseitig durch ein geeignetes Setup für die JQuery/Ajax-Transaktion vorgeben kann. Dies ist aber nicht durchgehend der Fall, denn es gilt auch folgendes weitere Zitat von der genannten api.jquery.com-Webseite:

Sending Data to the Server
 
By default, Ajax requests are sent using the GET HTTP method. If the POST method is required, the method can be specified by setting a value for the type option. This option affects how the contents of the data option are sent to the server. POST data will always be transmitted to the server using UTF-8 charset, per the W3C XMLHTTPRequest standard.

Das spielt natürlich eine essentielle Rolle, wenn man – wie wir – bei der Erstellung und dem Einsatz von CM-Systemen größere Nutzdaten aus umfangreichen Formularen per JQuery/Ajax zum Server übertragen muss. Eine solche Übertragung wird man typischerweise statt mit GET mit POST durchführen (Datenmenge, Sicherheit).

Anders als beim Datenaustausch über GET ist JQuery/Ajax im Falle eines Datenversands mit POST offenbar aus guten Gründen eigen und legt sich auf UTF-8 fest!

Blöd nur, wenn die serverseitige Zielumgebung konsistent auf ISO-8859-1 und nicht auf UTF-8 ausgelegt ist.

Sprich:
Du hast es mühsam geschafft, in einer konsistenten “ISO-8859-1/latin1”- Apache/MySQL-Kundenumgebung eine interaktive PHP-Applikation einwandfrei zum Laufen zu bringen. Dann schaltest du irgendwann nette JQuery/Ajax-Features auf POST-Basis dazu und bekommst möglicherweise und “überraschend” Zeichensalat in allen Texten.

Von solchen Erlebnissen zeugen viele Anfragen in Foren mit z.T. halbgaren Lösungsansätzen – ein paar Beispiele:

http://stackoverflow.com/
questions/2539090/jquery-ajax-umlauts-special-characters-are-a-mess
http://forum.de.selfhtml.org/archiv/2009/7/t188450/
http://www.ajax-community.de/javascript/6113-jquery-formular-umlaute.html
http://www.ajax-community.de/javascript/8872-problem-umlauten.html
http://www.buildblog.de/2009/05/01/ajax-und-umlaute-das-ewig-wahrende-utf-8-problem-und-seine-losung/
http://www.php.de/javascript-ajax-und-mehr/71100-formular-umlaute.html
http://www.perl-community.de/bat/poard/thread/17021
http://www.fundstücke-im-netz.de/2012/03/28/umlaute-mit-ajax-verwenden/
http://ecotronics.ch.honorius.sui-inter.net/wordpress/2010/jquery-ajax-und-encoding/
http://de.softuses.com/68699
http://www.mail-archive.com/discuss@jquery.com/msg19364.html

Das ungewollte Erzeugen von Zeichensalat kann dabei selbst in Testumgebungen ein Problem werden, denn die nach dem Ajax-Einsatz durch kryptische Zeichen ersetzten Umlaute der deutschen, französischen oder skandinavischen Texte muss man auch da ggf. erstmal wieder aus Backups restaurieren. Wenn es sich um größere Texte handelt, wird ja keiner anfangen, das wieder von Hand zu bereinigen!

Was hilft beim JQuery/Ajax-Einsatz in eventuellen ISO-8859-1/Latin1-Umgebungen ?

Nachdem man einmal verinnerlicht hat, dass JQuery/Ajax bei POST als Datentransfermechanismus UTF-8 in der Kommunikation mit dem Webserver erzwingt, ist klar: Man muss serverseitig etwas tun, wenn in der dortigen Verarbeitungskette nicht UTF-8 vorgesehen ist.

Das Zauberwort – besser die einzusetzende Funktion – heißt dann:

utf8_decode().

Siehe hierzu

http://de.php.net/manual/de/function.utf8-decode.php

Spätestens an den Stellen, an denen die PHP-Module sich des übertragenen und im $_POST-Array gelandeten Inhalts annehmen (Prüfungen, Vorverarbeitung, etc.), muss man die per JQuery/Ajax übertragenen Strings in einer ISO-8859-Umgebung prophylaktisch mit “utf8_decode()” dekodieren!

Ob man eine pauschale initiale Decodierung für alle Strings im $_POST-Array vor allen weiteren Schritten vornehmen will, hängt ein wenig von den eingesetzten Analyse- und Prüfroutinen für die Daten ab ab. Das gilt im besonderen für sicherheitsbezogene Prüfungen – hier muss jeder selber wissen, was sinnvoll und richtig ist. Irgendwann im Zuge der Verarbeitung ist die Dekodierung unter den angenommenen Voraussetzungen aber unvermeidbar.

Aber:
Das gilt nur im Fall eines vorhergehenden Ajax/JQuery-Transfers auf ein auf ISO-8859-1 eingestelltes Zielsystem und genau genommen nur im Falle von Strings.

Wie weiss oder erfährt mein PHP-Programm darüber etwas?

Bzgl. der String-Eigenschaft:

Man kann z.B. is_string(), is_numeric(), etc. zum Testen einsetzen. Aus meiner Sicht sollte man aber sowieso durch andere Mechanismen bei der Übertragung von Formulardaten dafür gesorgt haben, dass das empfangende PHP-Programm sehr genau weiß, was es an welcher Stelle des
POST-Arrays als Datentyp erwartet. Schon aus Sicherheits- und Validierungsgründen! Dieses Thema hat man also in der Regel von Haus aus schon im Griff.

Bzgl. der Kennzeichnung eines Ajax-Transfers für die PHP-Seite:

Ich benutze hierfür typischerweise ein wohldefiniertes zusätzliches “Hidden Input-Feld” im selben Web-Formular, dessen Nutz-Daten übertragenen werden sollen. Da ich ja eh’ JQuery im Falle eines Ajax-Transfers bemühe, kann ich vor der Durchführung der POST-basierten Ajax-Transaktion dieses Input-Feld von JQuery auch noch schnell mit einem numerischen Wert füllen lassen, der dem PHP-Programm dann anzeigt, dass ein Ajax-Transfer vorliegt. Einfache numerische Werte sind von UTF-8 / ISO-8859-Transformationen ja nicht gefährdet (ASCII-Kompatibilität von UTF-8)!

Das serverseitige PHP-Programm kann aufgrund der übertragenen Zusatz-Information in einem speziellen, mit numerischem Inhalt belegten $_POST-Array-Feld herausbekommen, ob die POST-Daten per JQuery/Ajax-Transaktion geschickt wurden. Hat das PHP-Programm auf Basis seines parametrierten Grund-Setups nun noch Informationen darüber, ob es in einer UTF8-Server-Umgebung oder in einer ISO-8859/Latin1-Umgebung läuft, so ist klar, wann utf8_decode() einzusetzen ist und wann nicht.

Client- bzw. serverseitig läßt sich so ein informatives “Zusatz-Feature” natürlich sehr schön generalisiert und über entsprechende Methoden eigener Bibliotheksobjekte für Datentransaktionen abhandeln – sowohl unter Javascript als auch auf der PHP-Seite. Die benötigte Code-Menge ist wirklich minimal!

Hat man das erstmal codeseitig erledigt, kann man anschließend normale POST-Transfers mit Web-Seitenwechsel locker und entspannt mit Ajax-Transaktionen ohne Web-Seitenwechsel jederzeit kombinieren und zwischen beiden hin- und herwechseln.

Den geringen Aufwand, den man für die notwendigen Vorsorgemaßnamen client- und serverseitig investieren muss, spielt man danach locker wieder durch den bequemen, einfachen Einsatz der Ajax-Tools von JQuery ein.

Ohne jeden Zeichensalat! Zumindest in “ISO-8859-1”-Umgebungen. Mit anderen Zeichensätzen als ISO-8859-Varianten und UTF-8 bin ich nicht so vertraut, so dass ich das, was ich oben beschrieben habe, nicht auf andere Zeichensätze generalisieren möchte.

Viel Spaß nun mit Umlauten, JQuery/Ajax und PHP in UTF-8 und ISO-8859-Umgebungen!

Opensuse: Upgrade von 11.4 auf 12.1

Posted on by

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.