Author Archives: Ralph Mönchmeyer

Opensuse 11.4 – Kontact/Kmail 4.7.0 – Probleme

Posted on by

Mutig (oder dumm?) wie ich bin, habe ich am Wochenende gewagt, eine unser Linux-Arbeitsstationen unter Opensuse 11.4 von KDE 4.6 auf KDE 4.7 umzustellen. Dabei nutzte ich – wie bei früheren KDE Updates auch – das Opensuse KDE Factory Repository.

Leider hatte ich es versäumt, mir den neuen Inhalt des KDE Factory Repositories genauer anzusehen. Dabei wäre mir nämlich folgendes aufgefallen:

Suse hatte die KDE PIM-Pakete und Akonadi bislang auf dem Stand der KDE 4.4 ausgeliefert (also z.B. Kmail 1.13. statt Kmail 2.x). Gründe hierfür waren sicher die vielen Probleme mit den neuen Versionen und deren Zusammenspiel mit Akonadi – siehe hierzu meine eigenen Beiträge in diesem Blog. (U.a. gab es Probleme mit dem enormen CPU-Verbrauch von Nepomuk und virtuso-t.) Nun hat aber auch SUSE die neuen Versionen Kontact 4.7, Kmail 4.7 und weitere Programme sowie die zugehörigen Akonadi-Versionen ins KDE Factory Repository aufgenommen.

Das hatte ich nach meinem Urlaub nicht mitbekommen – und das blieb leider nicht ohne Folgen:

Problem 1: Kmail und Kontact 4.7.0 ließen sich nicht starteten

Das erste Problem war, dass sich Kontact wegen Kmail nicht mehr starten ließ bzw. wegen eines “schweren Fehlers”

“In KMail ist ein schwerwiegender Fehler aufgetreten. Das Programm wird beendet.
Die Fehlermeldung lautet: Fehler beim Einholen der Ressourcen-Sammlung. … ”

immer wieder geschlossen wurde. Siehe hierzu auch:


https://bugzilla.novell.com/show_bug.cgi?id=708977
http://forums.opensuse.org/english/get-technical-help-here/pre-release-beta/463408-kde-4-7-out-2.html
http://www.kde-forum.de/post/13239/kontact-4-7-0-und-akonadi-funktionieren-nicht.html#post13239
http://www.linuxforen.de/forums/showthread.php?p=1779066

Ziemlich sarkastische – aber aus meiner Sicht auch angemessene Kommentare findet man hier:
https://bbs.archlinux.de/viewtopic.php?id=19453


Problembehebung:
Mich hat die Behebung dieses Problems alles in allem etwa 2 Stunden gekostet. Zunächst habe ich mit einem jungfräulichen Benutzeraccount versucht, Kontact/Kmail 4.7 zum Laufen zu bewegen. Dieser Test ist bei KDE-Updates immer nützlich, denn nach dem Aufsetzen eines jungfräulichen Users gibt es keine alten Konfigurationsdateien unter ~/.kde4/share und den dortigen Subverzeichnissen. Da es dann mit dem jungfräulichen User ging, war klar, wo ich weitermachen musste.

Ich musste letztlich “alle” alten Dateien zu Kmail und Akonadi in meinen eigenen Subverzeichnissen von “~/.kde” eliminieren sowie den Akonadi-Server und die Akonadi-Ressourcen komplett neu einrichten.

Es reichte übrigens nicht, die “kmail*rc”-Dateien in “~/.kde/share/config” zu eliminieren/umzubenennen. Ich musste auch Dateien unter dem Subverzeichnis “~/.kde/share/apps” entfernen. Dabei muss KDE immer mal wieder neu gestartet werden (z.B. mit init 3 – init 5).

Schließlich habe ich es so nach mehreren Anläufen geschafft, Kmail 4.7 zum Laufen zu bringen und auch an einen IMAP-Server in unserem Netz anzubinden.

Problem 2: In Kmail macht die initiale Einrichtung von Spam-Filtern das Weiterarbeiten unmöglich

Naiv wie ich bin, habe ich dann versucht, Spam-Filter einzurichten. Dies hat sich als sehr schlechte Idee erwiesen, da diese Filter beim initialen Lauf über große Mailordner (und davon habe ich viele) ein Bedienen der Kontact-
Oberfläche völlig unmöglich machten. Man sieht den “Fortschritt” der Mail-Analyse – das lief doch unglaublich langsam ab. Ich habe Kontact schließlich gewaltsam beendet und die Filter-Einstellungen (Bogo-Filter und/oder Spam-Assassin) wieder aus den Kmail-Konfigurationsdateien entfernt.

Spam-Filter werde ich deshalb erst wieder bei der Version KDE 4.7.1 wieder ausprobieren. Frühestens ….

Problem 3: Das manuelle Einstellen der Reihenfolge der Mailordner funktioniert unter Kmail 4.7 nicht mehr

In der Ansicht der Mailfolder konnte man bislang die Reihenfolge der angezeigten Mailordner nicht nur alphabetisch oder nach anderen Anzeigespalten sortieren lassen, sondern die Darstellung der Reihenfolge auch manuell festlegen. Das funktioniert unter Kmail 4.7 im Moment schlicht nicht mehr. Bei unserer doch umfänglichen Ordnerlandschaft ist das einfach ärgerlich.

Problem 4: Keine Kontact-Verbindungen zu einem OX 5 Server – nur zu OX6

Leider nutzt einem Kmail alleine auch nicht viel, wenn man nicht mehr an einen Teil seiner Kontakte und Adressdaten herankommt und auch seine Kalender-Einträge nicht mehr öffnen kann. Bei uns liegen Kontakte und Kalender zu einem größeren Teil nämlich immer noch auf einem Open-Xchange Server der Version 5. Wir betreiben zwar auch einen Open-Xchange Server der Version 6 (aus Kostengründen in der Community Edition) auf einem Opensuse 11.0-System. Aber die Migration aller alten OX5 Daten – insbesondere auch der umfänglichen Wissenseinträge oder des Dokumentenarchivs vom OX 5 zum neueren OX 6 System hatten wir bislang nie vollständig vollzogen. Warum auch, wenn man zwei fehlerfrei laufende Serversysteme hat.

Die schlechte Nachricht ist nun die:

Die Akonadi-Konnektoren zu OpenXchange Ressourcen funktionieren bei KDE/Kontact 4.7.0 im Gegensatz zu älteren Versionen (z.B. unter KDE 4.4) nur noch für den OpenXchange Server 6 aber nicht mehr für den OX 5. Ob sich das bei künftigen Versionen noch ändern wir, weiß ich nicht.

Schade eigentlich, dass die KDE-Entwickler die bis KDE 4.4 anstandslos funktionierenden Schnittstellen zu OX5 nicht auch in die neuen Kontact/Korganizer/Kontakt-Versionen übernommen haben. Das ist für mich nicht nachvollziehbar.

Jedenfalls kann ich im Moment den Zugriff von meinem KDE 4.7 System auf den alten OX 5 Server vergessen – und damit auch den direkten Zugriff unter Kontakt auf die dort liegenden Informationen. Das ist schon ziemlich blöd, wenn einem plötzlich in der täglichen Arbeit einige Adressbücher und E-Mail-Adressen fehlen.

Wer also produktiv mit einem OX 5 Server arbeiten will oder muss, sollte von einem KDE Update auf KDE 4.7 unter Opensuse besser die Finger lassen.

Gott sei Dank habe ich Zugriff auf mehrere Opensuse 11.4-Systeme, auf denen noch eine 14 Tage alte KDE 4.6-Version mit den KDEPIM-Komponenten von KDE 4.4 läuft..

Was Positives

Nun aber auch ein paar gute Nachrichten:

a) Ich habe dann am Sonntag mal testhalber einen OX 6 Server unter Opensuse 11.4 aufgesetzt. Hierzu mehr in einem anderen Beitrag. Dies ist praktisch genauso einfach oder schwierig wie unter Opensuse 11.0.

b) Die Anbindung des Gespanns Kontact/Akonadi von KDE 4.7 an die Ressourcen (Adressbücher, Kalender, Tasks) der OX 6 Server unter Opensuse 11.0 und Opensuse 11.4 funktioniert doch sehr ordentlich. Ich konnte beim ersten Rumspielen zumindest keine echten Probleme erkennen.

c) In Kmail wurde ein alter, ärgerlicher Regressions-Fehler von Anfang 2009 nun endlich behoben: Beim Ziehen von Mails aus der Mailliste über die Ordner im Ordnerbereich öffnet sich die Ordnerhierarchie nun wieder. Das erleichtert die Mailverschieberei in der komplexen Ordnerstruktur eines Unternehmens doch erheblich.

r
d) Die in einem früheren Beitrag zu Kmail 2 und unter https://bugs.kde.org/show_bug.cgi?id=246678 kritisierten Problemen mit dem hohen CPU-Verbrauch von Nepomuk und Virtuoso beim Indizieren neuer Mails scheinen behoben zu sein. Nepomuk läuft jedenfalls bei mir und ich kann die früheren extremen Ausschläge in der CPU-Belastung nicht mehr sehen.

Fazit

Der Schritt auf KDE/Kontact 4.7 ist mit Kinderkrankheiten verbunden. OX 5 Nutzer sollten den Schritt auf KDE 4.7 unter Opensuse lieber bleiben lassen oder vorab ernsthaft eine Migration auf OX 6 in Angriff nehmen.

PHP-Unterstützung unter Eclipse Indigo

Posted on by

Da es z.Z. kein Paket gibt, dass einem eine direkte Installation einer PHP-Entwicklungsumgebung unter dem neuen Eclipse “Indigo” ermöglichen würde, ist ein wenig Handarbeit erforderlich.

Ich beziehe mich nachfolgend auf die Hinweise von “aaronbonner” auf der Webseite http://aaronbonner.tumblr.com/post/6035060125/installing-pdt-3-on-eclipse-3-7-indigo.

Die aktuelle Eclipse-Indigo-Version holt man sich von http://www.eclipse.org/downloads/.

Dort lädt man sich das Paket “Eclipse Classic 3.7” (in meinem Fall für 64Bit Linux) herunter und “installiert” das Paket in seinem Wunschverzeichnis durch entsprechendes Expandieren des Tar-Balls (z.B. mit ark).

Nun gilt es zunächst, Eclipse die erforderlichen Update-Sites bekannt zu machen. Wir wechseln daher über den Menüpunkt

“Help >> Install New Software … ”

auf die Seite “Available Software”. Hier klicken wir auf den Link “Available Software Sites” und fügen folgende Repository-Sites hinzu:

  • Indigo >> “http://download.eclipse.org/releases/indigo”
  • The Eclipse Project Updates >> “The Eclipse Project Updates”
  • PDT 3.0 Update Site >> “http://download.eclipse.org/tools/pdt/updates/3.0/milestones”
  • Subversive Site >> “http://community.polarion.com/projects/subversive/download/eclipse/2.0/indigo-site/”
  • Subversive Update Site >> “http://community.polarion.com/projects/subversive/download/integrations/update-site”
  • Subversive Integrations >> “http://community.polarion.com/projects/subversive/download/integrations/update-site”
  • Subversive SVN Connectors >> “http://community.polarion.com/projects/subversive/download/integrations/update-site”
  • WTP-Patches >> “http://download.eclipse.org/webtools/patches/drops/R3.1.2/P-3.1.2-20100413200422/repository/wtp-patches312-tests”

Wie man die Sites benennt, ist dabei jedem selber überlassen. Hauptsache die http-Adressen stimmen.

Danach installiert man sich die benötigten Pakete – in meinem Fall :

  • Eclipse Web Developer Tools
  • Eclipse XML Editors and Tools
  • Eclipse XSL Developer Tools
  • JavaScript Development Tools
  • JAX-WS DOM Tools
  • JAX-WS Tools
  • Native JavaHL 1.5 Implementation
  • Native JavaHL 1.6 Implementation
  • PHP Development Tools (PDT) Runtime Feature
  • PHP Development Tools (PDT) All-In-One SDK
  • PHP Development Tools (PDT) SDK Feature
  • PHP Development Tools (PDT) Source Feature
  • Remote System Explorer End-User Runtime
  • Subversion Revision graph
  • Subversive SVN Connectors
  • Subversive SVN JDT Ignoe Extensions
  • Subversive SVN Team Provider
  • Subversive SVN Team Provider Connectors Sources
  • SVNKit 1.2.2
  • SVNKit 1.3.3
  • SVNKit 1.3.5
  • Web Page Editor
  • WST Server Adapters
  • Axis2-Tools
  • Dynamic Languages Toolkit – Mylyn Integration
  • JST Server Adapters
  • JST Server UI
  • Mylyn Commons
  • Mylyn Context Connector: Eclipse IDE
  • Mylyn SDK
  • Mylyn Task List
  • Mylyn Task-Focused Interface
  • PDT Mylyn Feature
  • Subversive SVN Integration for the Mylyn Project
  • Target Management Terminal

Am wichtigsten sind hier natürlich die PDT-Pakete. Für die SVN-Anbindung
sind die Subversion-Pakete und Konnektoren wichtig. Wer Task-orientiert arbeiten will, sollte auf die Mylyn-Pakete zurückgreifen.

Viel Spass dann mit Eclipse Indigo und der zugehörigen PHP-Unterstützung !

Blender: Seeking Yellow – reloaded

Posted on by

In meiner Freizeit befasse ich mich immer mal wieder gerne mit Simulationsprogrammen. So hatte ich ein paar Jahre lang viel Freude an dem “Windows”- und “Apple”-Programm “Bryce”. Blender erschien mir – gemessen an meinen unprofessionellen Interessen – zu komplex und bzgl. einer Einarbeitung zu aufwendig. Jetzt habe ich mal wieder einen Anlauf unternommen und mich mit der Blender-Version 2.5 auseinandergesetzt. Als Einstieg habe ich ein Thema aufgegriffen, dass ich früher schon einmal mit Bryce behandelt habe.

Ein 3D Raytracing-“Experiment” mit Bryce

Vor ein paar Jahren hat mich Michael Grossmann anläßlich eines seiner Kunstprojekte auf eine interessante “Problemstellung” für Simulationsprogramme aufmerksam gemacht:

Was geschieht wenn man grüne und rote Glasscheiben übereinander legt? Und was geschieht im Gegensatz dazu, wenn man Schichten aus selbstleuchtenden Gasen übereinander legt?

In entsprechenden Experimenten kann man den Unterschied zwischen “aktiver” und “passiver” Farbmischung studieren. In der Malerei, beim Druck, aber auch in Photobearbeitungs- oder Publishing-Programmen beschäftigt man sich vor allem mit der passiven Farbmischung, während z.B. die Bilderzeugung auf LCD-Schirmen auf dem Prinzip der aktiven Farbmischung beruht. In vielen Fällen führt deshalb das Arbeiten am PC schnell auf eine Einbahnstraße vom RGB-Farbraum zum druckrelevanten CYMK-Farbraum. Gerade aus künstlerischer Sicht interessiert am PC die “aktive” Farbmischung als eigenständiges Thema leider kaum.

Ein paar “Versuche” mit Photoshop und danach Bryce haben Michael und mich 2003 dazu veranlasst, das Thema “aktive” Mischung in 3D mal anhand folgender konkreter Fragestellung anzugehen:

Was geschieht, wenn man einen Quader aus selbstleuchtendem roten Gas in eine passende, asymmetrisch positionierte Ausbohrung in einen Quader aus selbstleuchtendem grünen Gas setzt? (Beide Gase seien transparent.)

Die Physik und Grundlagen der menschlichen Farbwahrnehmung sagen einem, dass man auf diesem Wege – je nach Dicke der betrachteten grünen oder roten Schichten – ein Farbspektrum von Rot über Orange, Gelb, Grün erzeugen können muss – je nachdem wie sich die Lichtstrahlen aus den farbigen Gasbereichen überlagern. Faktisch sollte bei einer asymmetrischen Konfiguration der Blickwinkel dafür ausschlaggebend sein, was man sieht.

Michael und ich haben damals die Raytracing-Methoden von Bryce zur wirklichkeitsnahen Simulation dieser Aufgabenstellung angewendet. Die gewünschten selbstleuchtenden Gase habe ich mit Hilfe des äußerst vielseitigen Materialeditors von Bryce erzeugt. Siehe zu den Ergebnissen unserer Simulationen :
seeking yellow

von_der_Kante_635

So akademisch die ganze Idee anmuten auch mag – sie ist in mehrerlei Hinsicht interessant: physikalisch, künstlerisch, philosophisch – denn aus entsprechenden Simulationen kann man einmal mehr etwas darüber lernen, das nicht alles so ist, wie es zu sein scheint und dass die Bilder, die unsere Sinneswahrnehmung in unserem Bewußtsein erzeugt, “künstliche”, durch unser Gehirn und Sinnesverarbeitung vorinterpretierte Bilder sind. Obwohl wir etwas “Gelbes” im Zentrum unserer simulierten “Versuchsanordnung” sehen, sendet keines der simulierten Objekte einen gelben Lichtstrahl aus! Zur Erklärung siehe den obigen Link.

Simulationstechnisch hat die Aufgabenstellung einiges zu bieten: Mit Hilfe
geeigneter Simulationsprogramme wie Bryce kann man hier etwas darstellen, was technisch nur schwer zu realisieren wäre. Und ferner erlaubt uns Bryce, eine Kamera in die Gas-Objekte hinein zu bewegen und Blickwinkel aufzunehmen, die in einer realen Welt kaum zugänglich wären. Ferner steht entsprechenden Kamerafahrten durch die Gaskörper nichts im Wege. Und nicht zuletzt macht die Sache Spass – denn die Ergebnisse können farblich wirklich spektakulär sein. Siehe hierzu die Bilder unter seeking yellow

Blender statt Bryce

Trotz meines Fables für Bryce fanden Michael und ich es als Linux-Anhänger damals etwas ärgerlich, dass wir es nicht geschafft haben, unser “seeking yellow”-Projekt mit Opensource-Programmen durchzuziehen. Im besonderen kamen wir mit dem Material-Editor der damaligen Blenderversion nicht klar.

Außerdem gab es damals einige Leute, die das Ergebnis der Simulation schlichtweg für Unsinn erklärt haben, da sie mit aktiver Farbmischung nicht vertraut waren. Daher erschien es uns wichtig, die Ergebnisse unseres “Ray-Tracing-Experiments” durch ein unabhängiges Simulationsprogramm bestätigen.

Vor ein paar Tagen habe ich deshalb erneut versucht, unsere damaligen “Experimente” ansatzweise mit “Blender” in der Version 2.5 nachzuvollziehen.

Dieses Unterfangen erwies sich als viel leichter als anfänglich vermutet. Blender bestätigt die früheren Ergebnisse der Bryce-Simulationen von Michael und mir in vollem Umfang. Zudem können wir nun viel einfacher und ganz ohne Windows auch komplexe Konfigurationen studieren.

Diese “Experimente” mit Blender mögen auch für andere interessant sein. In einigen weiteren Artikeln in der Kategorie “Blender” dieses Blogs werde ich beschreiben, wie man etwa zu folgenden Bildern kommt:

cube_in_cut_cube_rundinger_110719

cubes_cut_and_uncut_110718_640

cubes_cut_and_uncut_uten_env_map_110718_opt

metaball_sphere_in_cube_110717_3

cube_in_cut_cube_rundinger_110719_opt

Obwohl in diesen Ansichten einer Kombination von roten, grünen, blauen Quadern oder Kugeln eingesetzt wird und alle möglichen gelben, orangen und violetten Farben erscheinen, gibt es im ganzen “Versuchsaufbau” der Simulationen kein einziges Objekt, das gelbe oder violette Strahlen aussenden würde. Aber in einer 3D-Welt mit aktiven Farbmischungen ist eben so einiges
möglich. An anderen Beispielen kann man zudem zeigen, dass es mit einfachen eckigen Körpern gelingen kann, runde kaustik-ähnliche Kurven zu erzeugen.

Optik in 3D macht Spaß mit Blender !

Eclipse – zu langsam bei großen Dateien?

Posted on by

Muss nach einer längeren Pause mal wieder intensiv mit PHP entwickeln. Bei dieser Gelegenheit habe ich mich wirklich über einen größeren Bug in Eclipse Helios geärgert.

Das Problem unter Eclipse Helios

Dieser Bug betrifft das Editieren großer Dateien und gliedert sich eigentlich in 2 Teile:

  • Die Reaktionsgeschwindigkeit des Editors beim Tippen nimmt mit zunehmender Größe der Dateien immer schneller ab. Die getippten Buchstaben erscheinen nur erheblich verzögert am Schirm. Oberhalb 5000 Zeilen pro Datei ist der Eclipse eigene PHP Editor nicht mehr zu gebrauchen.
  • Parallel zum Tippen beginnt Eclipse offenbar den gesamten Code des Files auf potentielle Fehler zu untersuchen. Die CPU-Belastung ist hierbei enorm.

Leider kann man sich nicht immer aussuchen, wie groß die Dateien sind, mit denen man arbeiten muss. Und dann wird der Eclipse Editor unter Helios wirklich zu einer Arbeitsbehinderung.

Siehe hierzu auch https://bugs.eclipse.org/bugs/show_bug.cgi?id=326261. In den Beiträgen zum Bug wird als Zwischenlösung empfohlen, das Syntaxcoloring abzuschalten. Ferner gibt es einen etwas schwierig einzuspielenden Patch.

Lösung 1: Wechsel zu Eclipse Indigo

Ich habe gestern auf meinem Laptop die neue Eclipse Version Indigo installiert. Nach einem Tag intensiver Arbeit kann ich diesen Schritt jedem empfehlen, der von dem beschriebenen Problem betroffen ist. Unter Indigo ist der erste der beiden Punkte tatsächlich behoben. Man kann auch bei relativ großen Dateien wieder fließend tippen.

Allerdings folgt auf das Editieren weiterhin eine längere Orgie der Dateianalyse mit sehr hoher CPU-Belastung. Wohl dem, der hier mehrere CPU-Cores zur Verfügung hat.

Wie ich von Helios zu Indigo übergegangen bin, beschreibe ich in einem nachfolgenden Artikel.

Lösung 2: Kompaktere Codes – kompaktere Klassen

Ein Gutes hat der “Bug” ja vielleicht: Um die Code-Dateien zu verkleinern, beginnt man immer öfter, über den Aufbau und die Struktur der eigenen Klassen nachzudenken.

Ich habe jedenfalls bei meinen eigenen Klassen, in denen sich über die Jahre hinweg immer mehr Methoden angesammelt haben, begonnen, bestimmte Variablen bzw. Methoden besser zu gruppieren, in separate Repräsentations- und Funktionalklassen zu bündeln und dann auszulagern. Bei Bedarf instanziiert die ursprüngliche Klasse dann entsprechende Objekte. Hierzu gibt es je nach Situation mehrere brauchbare Entwurfsmuster.

Eine einfache Variante, die die Struktur der wachsenden Klassen weitgehend aufrechterhält, ist die Delegation der Aufgabe in der Form, dass man die bisherige Methode in der Hauptklasse belässt, aber die Aufgabe selbst auf den Aufruf eines Funktionalklassen-Objekts und dessen entsprechende Methode verschiebt. Die zu manipulierenden Variablen werden dabei ggf. von der ursprünglichen Hauptklasse selbst wiederum als Objekt übergeben. Da diese Übergabe immer “by reference” geschieht, wird der Bedarf an Speicher nicht wesentlich erhöht. Die Klassen-Codes werden bei einem solchen Vorgehen i.d.R. sehr viel kompakter.

Denen, die sich mit Entwurfsmustern intensiv beschäftigen möchten, sei bei dieser Gelegenheit übrigens das Buch “PHP Design Patterns” von Stephan Schmidt (http://www.phpdesignpatterns.de/auflage-2/#buch) allerwärmstens empfohlen. Ich jedenfalls entdecke immer wieder neue “Offenbarungen” in diesem Buch.

Ein anderer Weg zu überschaubaren Dateien führt ggf. über eine klarere Unterteilung der Vererbungshierarchie.

Content Assistance bei verteiltem Code

In beiden Fällen ist es bzgl. der Unterstützung (Content Assistance) beim Coding sinnvoll, sich im Editor auch Variable aus anderen Dateien vorschlagen zu lassen. Hierzu muss amn den entsprechenden Haken unter dem Menüpunkt

"Window >> Preferences >> PHP >> Editor >> Content Assist >> Show Variables from other files"

setzen.

.

Opensuse 11.4, XEN, Nvidia, uvesafb

Posted on by

Wie bekommt man auf einem System mit einer Nvidia-Karte

  • Opensuse 11.4,
  • den zugehörigen XEN-Kernel
  • und einen graphischen Desktop mit 3D-Beschleunigung in der Dom0 des XEN-Systems

zum Laufen ?

Dieses Thema mag auf den ersten Blick fast esoterisch erscheien. Aber es gibt tatsächlich Entwickler für graphische Applikationen, die auf einem System virtualisierte Gäste laufen lassen und gleichzeitig in der Dom0 3D-Grafik betreiben wollen.

Siehe auch:
http://www.nvnews.net/vbulletin/showthread.php?t=60125

Ferner ist es so, dass man bei einem laufenden 3D-beschleunigten X-Server (z.B. in der Dom0) auch 3D-Output der virtuellen Maschinen beschleunigt darstellen kann: Das X-System beherrscht ja schon seit langem beschleunigten 3D-Ouput auch über ein Netzwerk.
Also kann man den graphischen Output der virtuellen Maschine über das (virtuelle gebridgte) Netzwerk des Hosts auch auf dem X-Server des Hosts beschleunigt darstellen. Bei einem leistungsstarken System geht das besser als man meinen möchte. Dazu mehr in einem künftigen Beitrag.

Ich habe selbst schon vor 3 Jhren bei meinen ersten Versuchen mit XEN Anläufe unternommen, um eine 3D-Beschleunigung mit Nvidia-Karten in der Dom0 irgendwie und halbwegs stabil hinzubekommen. Aber ich bin regelmäßig gescheitert. Nun hat sich inzwischen aber einiges getan (s. das oben angegebene Forum) und jetzt hat es endlich auch auf meinen XEN-Systemen unter Opensuse 11.4 so funktioniert wie ich mir das vorstelle. Meinen Lösungsansatz findet ihr im Original unter

http://www.nvnews.net/vbulletin/showthread.php?t=60125&page=10

als Beitrag des Users “moenchmeyer”.

Hier stelle ich als Ergänzung eine deutsche Variante der von mir angegebenen Schritte ins Netz.

Das Testsystem von mir hat einen Q9550 Quad Core Prozessor einen Raid10 Plattenverbund und eine Nvidia 9800 GTX+ Grafikkarte sowie 8 GByte RAM. Es wird als 64-Bit-System mit den entsprechenden x86_64-Kernelvarianten und Kernelmodulen betrieben.

Es sind zwei Hürden zu überwinden :

  1. Die Installation (inkl. Kompilation) des Nvidia-Treibers für den XEN-Kernel von Opensuse 11.4
  2. Der Einsatz von “uvesafb” statt des normalen Vesa Framebuffer-Verfahrens für die TTYs tty1 bis tty6 des XEN hosts.

Ohne Punkt 2 erhält man beim Umschalten von der graphischen Desktop-Umgebung, die typischerweise auf tty7 läuft, zu einem der textorientierten Terminals (tty1 bis tty6, tty10) nämlich nur schwarze Schirme. Und das mag zumindest ich nicht. Wie also kann man das vermeiden?

Schritt 1: Installation von Opensuse 11.4 mit den Xen und Virtualisierungspaketen (libvirt etc.)

Man installiere auf dem künftigen XEN-System Opensuse 11.4 zunächst ganz regulär. Vor dem eigentlichen Installationsvorgang wählt man bei der SW-PaketKonfiguration am besten gleich die Option “hostserver für Xen Virtual Machine” aus. Dann spart man sich die spätere Nach-Installation. Zusätzlich installiert man die notwendigen Compiler und Zutaten einer elementaren Entwicklungsumgebung sowie die Kernelquellen, um später Kernelmodule kompilieren zu können.

Schritt 2: Installationsversuch bzgl. des Nvidia-Kernel-Moduls nach dem Booten des Default-Kernels (nicht des Xen-Kernels)

Auf dem frisch installierten System werkelt der Nouveau-Treiber für Nvidia-Karten und erlaubt den Zugang zu einer graphischen Desktop-Umgebung. Im Gegensatz zum proprietären Nvidia-Treiber erlaubt dieser offene Treiber aber keine 3D-Beschleunigung. Daher holen wir uns nun den aktuellen Nvidia-Treiber (270.41.06) vom Nvidia-Portal.

Anschließend wechseln wir in den “runlevel 3”. Dort starten wir
im Verzeichnis mit dem Treiber die Installation:

sh NVIDIA-Linux-x86_64-270.41.06.run

Diese schlägt fehl – die Installationsroutine beklagt sich über den bereits laufenden Nouveau-Treiber. Die Frage, ob ein File zur Deaktivierung des Nouveau-Treibers installiert werden soll, beantworten wir positiv.

Schritt 3: Deaktivierung von KMS und Installation des Nvidia-Kernel-Moduls für den Default-Kernel (nicht Xen-Kernel)

Wir deaktivieren nun KMS – z.B. mit Hilfe von YAST und des dortigen Editors für die Files in “/etc/sysconfig”. Wir setzen die Option “NO_KMS_INITRD” unter “system > kernel” auf “yes”. (Alternativ kann man den Eintrag auch direkt im File “/etc/sysconfig/kernel” editieren.)

Anschließend führen wir einen Reboot in den Runlevel 3 durch. Dabei setzen wir im Menü des Grub Bootloaders neben “linux 3” noch den Parameter “nomodeset” – dann sind wir hinsichtlich der Deaktivierung von KMS auf der sicheren Seite.

Jetzt steht einer erfolgreichen Installation des NvidiaTreibers nichts mehr im Wege. Wir führen sie durch, wechseln danach in den Runlevel 5 und testen das korrekte Arbeiten der 3D-Beschleunigung in unserer grafischen Desktop-Umgebung über “glxinfo” oder die Einstellungen in der Applikation “nvidia-settings”. Natürlich können wir auch mal “glxgears” staren oder einen 3D-Effekt des KDE-Desktops anschalten.

Damit haben wir uns von der Funktionstüchtigkeit des Nvidia-Treibers für den normalen Kernel des Opensuse 11.4-Systems überzeugt. Jetzt kann man auch die Pakete für den Nouveau-Treiber deinstallieren – wenn man will.

Schritt 4: Booten des XEN-Kernels und Installation des Nvidiatreibers in der Dom0
Wir rebooten das System. Im Grub-Menü wählen wir nun aber die Option für den XEN-Kernel und geben erneut “linux 3” als Option an, um in den Runlevel 3 zu gelangen. Ein Booten in den Runlevel 5 würde scheitern, da der Nvidia-Treiber bislang nicht für den XEN-Kernel kompliert wurde.

Im Runlevel 3 führen wir daher die Installation des Nvidia-Treibers erneut durch – diesmal aber mit einer speziellen Art der Kompilation:

cd Your_Directory_With_THE_Nvidia_Driver
export IGNORE_XEN_PRESENCE=1 SYSSRC=/usr/src/linux-2.6.37.6-0.5 SYSOUT=/usr/src/linux-2.6.37.6-0.5-obj/x86_64/xen

sh ./NVIDIA-Linux-x86_64-270.41.06.run

Die Environment-Variablen IGNORE_XEN_PRESENCE, SYSSRC und SYSOUT werden von der Installationsroutine ausgewertet: Die Präsenz des XEN-Kernels wird ignoriert, die Kompilation erfolgt gegen die Sourcen und Einstellungen des Standard-Kernels – der resultierend Output (das Modul) wird aber gem. der Vorgaben für den XEN-Kernel gelinkt und installiert.

Die Versionsangaben in den obigen Statements müssen ggf. an die tatsächlichen Verhältnissen auf dem System angepasst werden. Sie gelten wie angegeben nur für eine Opensuse 11.4 Installation ohne Kernel-Updates.

Nun haben wir ein geeignetes und bereits geladenes Nvidia-Kernelmodul in der Dom0.

Schritt 5: Starten des X-Servers durch Wechsel in den Runlevel 5
Wir wechseln nun in den Runlevel 5 (init 5). Der XServer sollte anstandslos auf dem tty7 starten. Wir können uns dort einloggen und uns von der Funktionstüchtigkeit der 3D-Beschleunigung überzeugen. Damit ist die erste Hürde für den XEN-Kernel genommen.

Unglücklicherweise hat die Sache einen gravierenden Makel:

Ein Wechsel von der graphischen Oberfläche zu einem der textorientierten Terminals tty1 bis tty6 führt zu schwarzen Bildschirmen. Hier lernen wir gerade die 2te Hürde kennen: Die Ausgabe des angesprungenen Terminals wird nicht auf dem Schirm dargestellt und ist somit nicht sichtbar – obwohl die Terminals als Prozesse faktisch aktiv sind und sogar auf Tastatureingaben reagieren. So ist ein Wechsel zum grafischen tty7 jederzeit durch CTRL ALT F7 oder durch ein Einloggen im Blindflug und anschließendes Tippen von “chvt 7” möglich.

Schritt 6: Prüfe die
Existenz des Moduls “uvesafb”
Wieder in unserer grafischen Umgebung angelangt, überzeugen wir uns davon, dass das Modul “uvesafb.ko” im Verzeichnis “/lib/modules/2.6.37.6-0.5-xen/kernel/drivers/video” vorhanden ist.

Opensuse’s XEN-Kernel ist zusammen mit diesem Modul kompiliert und installiert worden. Das Modul sollte also an seinem Platz zu finden sein. Wenn nicht, bleibt leider nichts anderes übrig, als selbst den Kernel zusammen mit diesem Modul neu zu konfigurieren, zu kompilieren und zu implementieren.

Schritt 7: Installation von “v86d”
“uvesafb” benötigt für seinen Einsatz zwingend den sogenannten Helper Daemon “v86d”. Dieser Daemon ermittelt Daten zum Framebuffer System der Grafikkarte und den Fähigkeiten des Schirms. Ohne “v86d” läuft “uvesafb” nicht !

Leider gibt es zu “v86d” kein geeignetes RPM-Paket, das sich unter Opensuse 11.4 installieren ließe. Zumindest habe ich keines gefunden.

Also müssen wir uns die Sourcecodes besorgen – und zwar von folgender Adresse:

http://dev.gentoo.org/~spock/projects/uvesafb/

Wir laden uns das Archiv “v86d0.1.10.tar.bz2” herunter und expandieren es in einem Verzeichnis unserer Wahl. Wir wechseln dorthin und führen dann die Stadardschritte “./configure” und “make” durch. “./configure” ergänzen wir dabei um die Option “–with-x86emu”.

Die Kompilation und das Linken sollten problemfrei vor sich gehen. Das resultierende Executable “v86d” kopieren wir dann als root in das Verzeichnis “/sbin/”.

Schritt 8: Identifizieren möglicher “uvesafb”-Modes”
Wir informieren uns über mögliche “uvesafb”-Modes durch Absetzen des Befehls

cat /sys/bus/platform/drivers/uvesafb/uvesafb.0/vbe_modes

an irgendeinem Pseudo-Terminal der grafischen Oberfläche.

Schritt 9: Konfigurationsdatei für das “uvesafb”-Modul
Als root erzeugen wir nun ein File “uvesafb.conf” im Verzeichnis “/etc/modprobe.d/”. Wir legen dann den künftig von uns gewünschten “uvesafb”-Modus für die TTYs – z.B. den Modus 1280×800-32 – fest, indem wir folgende Zeile in die Datei einfügen:

options uvesafb mode_option=1280×800-32 scroll=ywrap

Schritt 10: Eliminieren aller Vesa “vga”-Parameter aus der Bootloader-Konfiguration
Als nächstes ändern wir unsere Grub Bootloader-Konfiguration. Dazu könen wir Yast benutze oder aber die Konfigurationsdateien unter “/boot/grub” auch direkt editieren:

Wir eliminieren aus den Zeilen, die den Grub-Eintrag für das Booten des XEN-Kerels beschreiben, alle “vga”-Parameter – etwa “vga=mode-0xnnn” oder “vga=0xnnn”. “nnn” steht hier für den bei der Installation des SUSE-Systems festgelegten Standard VESA Framebuffer Modus für die TTYs.

Diese Entfernung der vga-Paramter ist ein sehr wichtiger Schritt: Die Vesa-Modes sind mit den “uvesafb”-Modes nicht kompatibel. Ein Starten der Standard-Vesa-Modes würde später ein erfolgreiches Laden des “uvesafb”-Moduls und ein Setzen des gewünschten “uvesafb”-Modus verhindern! Das Standard Vesa Setup ist nicht mit “uvesafb” verträglich !

Schritt 11: Erneutes Booten des XEN-Kernels und Laden des “uvesafb”-Moduls
Wir booten den XEN-Kernel erneut in den Runlevel 3. Da wir die vga-Optionen eliminiert haben, erschienen die Boot-Meldungen nun natürlich in der wenig ansehnlichen Terminal-Auflösung von 80×25 Spalten/Zeilen. Davon lassen wir uns aber nicht abschrecken, denn gleich werden wir unseren “uvesafb”-Modus anschalten.

Im Runlevel 3 loggen wir uns als root ein und versuchen dann, das “uvesafb”-Modul zu laden:

modprobe uvesafb

Das Terminal-Layout sollte sich nun deutlich zum Besseren ändern. Zur Sicherheit (oder im Fehlerfall zur Analyse) sehen wir uns nun die letzten Meldungen in “/var/log/messages” zum Laden des Moduls an. “uvesafb” sollte nicht nur geladen worden sein – der ”
v86d”-Daemon sollte relevante Information zur Vesa-Implementierung der Graka und zu Schirm verraten haben. Ferner sollte der Speicherpunkt für den Modus gesetzt worden sein.

May 20 17:24:50 xen kernel: [ 27.172094] uvesafb: NVIDIA Corporation, G92 Board – 03910050, Chip Rev , OEM: NVIDIA, VBE v3.0
May 20 17:24:50 xen kernel: [ 27.288417] uvesafb: VBIOS/hardware supports DDC2 transfers
May 20 17:24:50 xen kernel: [ 27.445892] uvesafb: monitor limits: vf = 75 Hz, hf = 94 kHz, clk = 210 MHz
May 20 17:24:50 xen kernel: [ 27.446342] uvesafb: scrolling: redraw
May 20 17:24:50 xen kernel: [ 27.838652] Console: switching to colour frame buffer device 160×64
May 20 17:24:50 xen kernel: [ 27.870389] uvesafb: framebuffer at 0xf7000000, mapped to 0xffffc90005980000, using 14336k, total 14336k
May 20 17:24:50 xen kernel: [ 27.870390] fb0: VESA VGA frame buffer device

Durch “CTRL ALT Fx” probieren wir nun, ob wir zwischen den TTYs tty1 bis tty6 hn und her wechseln können und das alle Terminals sich im gleichen “uvesafb”-Modus präsentieren.

Schritt 12: Wechsel zwischen der 3D-beschleunigten grafischen Oberfläche der Dom0 und den TTYs im Framebuffer-Modus
Abschließend starten wir nun den Runlevel 5, loggen uns in die grafische Desktop-Umgebung ein, die ja wegen des Nvidia-Treibers 3D-beschleunigt ist. Dort probieren jetzt einen Wechsel zu den anderen TTYs – z.B. zum Konsolen-Terminal tty1. Das sollte nun anstandslos klappen – der Output des Terminals tty1 muss sichtbar sein (im gewählten “uvesafb”-Modus). Auch eine Wechsel zurück zum tty7 sollte nun problemfrei funktionieren.

Damit haben wir unser Ziel erreicht. In der XEN Dom0 von Opensuse 11.4 läuft nun der prorietäre Nvidia-Treiber und verhilft uns zum Genuß einer grafischen Oberfläche mit 3D-Beschleunigung. Zudem können wir den uvesafb-Framebuffer-Modus unserer anderen TTYs über eine Konfigurationsdatei kontrollieren und wie gewohnt zwischen allen Terminals hin und her wechseln.

Bleibt nur noch, den Bootvorgang in den Runlevel 5 durch Manipulation entsprechender Startup-Skripts zu automatisieren. Wir müssen eigentlich nur dafür sorgen, dass das “uvesafb”-Modul vor dem Starten des X-Servers geladen wird. Das führen wir hier aber nicht weiter aus, sondern überlassen es dem Leser, das durch ein entsprechendes Skript unter /etc/init.d/rc5d hinzubekommen.

Nützliche Links:
https://wiki.archlinux.org/index.php/Uvesafb
http://dev.gentoo.org/~spock/projects/uvesafb/

Viel Spaß nun mit XEN und einer grafischen Desktopumgebung der Dom0, bei der auch 3D-Effekte und 3D-Programme hardware-beschleunigt laufen.