Die proprietären Grafiktreiber von ATI und Nvidia sind oft zu schlecht in ein laufendes System integriert, um ein System-Upgrade zu überleben. EasyLinux zeigt, wie es geht und was hilft, wenn doch mal etwas schiefläuft.

Nicht wenige Urgesteine der Open-Source-Szene befleißigen sich mittlerweile des Zynismus, wenn sie auf das Thema “Linux auf Desktops” angesprochen werden. Das sei doch schon längst da, heißt es, der Desktop sei eben sehr klein und kommt in diesem Fall von Google – gemeint ist freilich Android. Hinter solchen Aussagen steckt immer auch ein Stück Frustration: Trotz aller Anstrengungen, die verschiedene Desktop-Umgebungen in den letzten Jahren unternommen haben, will Linux einfach keine nennenswerten Marktanteile im Desktopmarkt erobern. Wer Linux auf dem Desktop einsetzt, findet das eventuell weit weniger seltsam als die Strategen bei KDE, Gnome und all den anderen Desktopumgebungen – das gilt vor allem für Anwender, die Treiber von ATI oder Nvidia benötigen, um ihre Grafikkarte ordentlich zu betreiben.

Trauerspiel

In der Tat müssen Sie leidensfähig sein, wenn Sie Linux auf dem Desktop in einem halbwegs aktuellen Computer einsetzen. Besitzer von Notebooks sind oft fein raus: In vielen aktuellen Laptops werkelt Intels Grafikchipsatz 3000 oder 4000, der unter Linux mit quelloffenen Treibern eine 3-D-Unterstützung ab Werk bietet. Wer hingegen ein Notebook mit separater GPU oder einen Desktopcomputer im Haus hat, hat damit fast immer eine Nvidia- oder ATI-Grafikkarte. Und genau hier fangen die Probleme an.

ATI und Nvidia weigern sich nämlich seit Jahren, die Treiber für die eigenen Grafikkarten unter eine quelloffene Lizenz zu stellen. Aus Sicht der Firmen ist das nur logisch – schließlich, so die beiden großen Hersteller, fließe deutlich mehr Geld in die Entwicklung von neuen Grafikchipsätzen, als es nach außen hin den Anschein hat. Da sei es nur konsequent, dass man im Anschluss nicht den Konkurrenten die Möglichkeit geben wolle, die eigenen Entwicklungen zu kopieren und so zu verwerten. Genau das wäre nämlich mit offenen Treibern möglich: Aus diesen ließen sich Rückschlüsse auf verschiedene Hardwarefunktionen ziehen. Die Konsequenz ist einfach: Treiber für Linux bieten ATI und Nvidia zwar an, aber die Quelltexte bleiben geheim.

Die proprietären ATI- und Nvidia-Treiber sind in Teilen der Linux-Community sehr unbeliebt. Wer auf OpenSuse setzt, muss sie von Hand nachinstallieren, und auch unter Ubuntu haben die Treiber nicht denselben Status wie quelloffene Software für andere Grafikkarten.

Die Folgen für Anwender sind unangenehm: Ein fertig eingerichtetes System lässt sich zwar mit den ATI- oder Nvidia-Treibern ausstatten, doch wehe, es ändert sich anschließend eine zentrale Komponente der Installation. Dazu kann schon ein Kernel-Update genügen; weit schlimmer wirkt sich ein Upgrade von einer Distributionsversion auf ihren Nachfolger aus. In solchen Fällen bleibt oft kein Stein auf dem anderen, und Benutzer, die nach dem Upgrade ein frisches System erwarten, sehen nur noch ein schwarzes Display und die Meldung “Login” im Textmodus (Abbildung 1). Spätestens dann ist klar: Mit den Treibern für die Grafikkarte ist etwas schief gelaufen, und guter Rat ist teuer.

Abbildung 1: Wenn nach dem Distributions-Upgrade keine grafische Oberfläche erscheint, sondern lediglich die Konsole, sind die Einstellungen für die Grafikkarte falsch.

OpenSuse und Ubuntu: Zwei Welten

OpenSuse und Ubuntu gehen unterschiedlich an das Problem mit den proprietären Grafiktreibern heran: Da ist einerseits Ubuntu (oder die KDE-Variante Kubuntu), das keinen Konfrontationskurs im Hinblick auf ATI und Nvidia fährt. Zwar gehören beim dort die Treiber nicht zur Hauptabteilung der Distribution, dem so genannten main-Teil. Allerdings stellt das Ubuntu-Projekt den Treiber über das restricted-Verzeichnis zur Verfügung. Der Treiber lässt sich also direkt aus der Distribution heraus über das Werkzeug für zusätzliche Treiber installieren.

Hinzu kommt, dass der Ubuntu-Hersteller Canonical einen Entwickler angestellt hat, der sich um die Pakete der Nvidia- und ATI-Treiber kümmert. Innerhalb einer Version dürfen Benutzer sich also zumindest einigermaßen darauf verlassen, dass der Treiber bei regulären Updates nicht kaputt geht. Selbst ein Upgrade überlebt diese Kombination meistens – denn der neuen Version des Systems sind auch aktualisierte Treiberpakete beigelegt, so dass böse Überraschungen nach dem System-Neustart ausbleiben.

Ubuntu ist gut, OpenSuse nicht

Ganz anders stellt sich die Situation bei OpenSuse dar. Viel stärker als Ubuntu versteht sich OpenSuse als Community-Distributon, die Suse erst in Form der Enterprise-Schiene kommerziell vermarktet. Bei OpenSuse sucht man fertige Pakete für ATI-Grafikkarten oder Nvidia-Chipsätze zumindest von offizieller Seite vergeblich. Wer die Treiber trotzdem nutzen möchte, greift entweder auf Zusatz-Repositories zurück, die von freiwilligen Entwicklern mehr oder weniger regelmäßig bestückt werden, oder holt sich den Treiber direkt vom Hersteller, der passende Installationsskripte bereithält.

Der große Nachteil beider Lösungen ist, dass niemand offiziell die Integration der Treiber testet; wer auf inoffizielle Repositories setzt, muss auf die Tests der freiwilligen Entwickler vertrauen. Beiden Varianten ist gemein, dass ein Update meist zu großen Probleme führt, weil die Treiberpakete aus fremder Quelle unbeachtet bleiben.

In den Tiefen des Systems

Warum sind die Grafikkartentreiber überhaupt so hakelig im Hinblick auf Updates? Um diese Frage zu beantworten, ist ein Ausflug in die Interna eines Linux-Systems notwendig. Anders als Windows kennt Linux keine Standardprozedur zur Installation von Treibern; im eigentlichen Sinne ist nichtmal genau definiert, was ein Treiber eigentlich ist. Der Kern eines Linux-Systems ist der Kernel, der die Kommunikation zwischen Hard- und Software übernimmt. Wenn Sie z. B. auf Ihr DVD-Laufwerk zugreifen, leitet der Kernel die Anfragen an die Hardware weiter. Linux enthält zahlreiche generische Treiber, die viele Geräte unterstützen. Die Distributoren integrieren den Kernel direkt in ihre Systeme. Deshalb funktionieren viele Geräte unter Linux bereits direkt nach der Installation – zum Beispiel die meisten Netzwerkkarten

Die meisten Linux-Treiber stehen als Module zur Verfügung, die das System im laufenden Betrieb nachladen kann. Auch die Treiberpakete für Nvidia- und ATI-Karten enthalten solche Kernel-Module. Anders als bei Windows gibt es nicht nur eine einzige Linux-Kernel-Version, an dem sich die Hardwarehersteller orientieren können. Einerseits sind zahlreiche Kernel-Versionen im Einsatz, andererseits verändert jeder Distributor “seinen” Kernel noch nach eigenen Vorstellungen. Das bedeutet: Selbst wenn Ubuntu oder OpenSuse einen Kernel 3.2.0 installieren, heißt das noch lange nicht, dass sich ein ATI- oder Nvidia-Modul für Kernel 3.2.0 problemlos unter dieser Ubuntu- oder OpenSuse-Version laden lässt.

Das gleiche Problem stellt sich beim Upgrade von einer auf die nächste Version einer Distribution: Fast immer weicht dabei der Kernel der alten Distributionsversion einer neueren Version, und ein altes Modul für ATI oder Nvidia ist mit dem neuen Kernel zumeist nicht mehr kompatibel.

Wenn der Distributor kein Kernel-Modul als fertiges Paket anbietet, das speziell an die Bedürfnisse der benutzten Kernel-Version angepasst ist, muss der Benutzer Hand anlegen und versuchen, eine passende Modulversion für den eigenen Kernel zu erstellen.

Die Sache mit X.org

An und für sich wäre das fehlende Kernel-Modul zwar ein Ärgernis, aber ein lösbares Problem. Was Anwendern beim Distributions-Upgrade meist in die Quere kommt, ist das fehlende Kernel-Modul zusammen mit der Tatsache, dass die grafische Oberfläche X.org trotzdem versucht, spezifische Funktionen des Moduls zu nutzen. Alle Linux-Distributionen verwenden X.org – denn ohne diese Software können KDE, Gnome & Co. nicht auf die Grafikkarte zugreifen. Das Programm redet im Hintergrund mit dem Kernel, um diesen Zugriff zu ermöglichen. Im Falle von Nvidia und ATI ist neben dem Kernel-Modul auch ein weiterer X.org-Treiber notwendig, um die 3-D-Fähigkeiten des Treibers auszunutzen. Anders als die generische 3-D-Bibliothek OpenGL, die X.org ab Werk beiliegt, unterstützen die ATI- und die Nvidia-Version dieser Bibliothek spezifische Features der jeweiligen Chipsätze. Das funktioniert aber nur, wenn das Kernel-Modul geladen wurde. Fehlt es und startet Xorg trotzdem mit der Einstellung für den Chipsatz-spezifischen Treiber, führt das zu einem Fehler, den X.org nicht beheben kann. Dann verweigert die grafische Oberfläche die Arbeit, und außer der Login-Meldung auf der Textkonsole erscheint auf dem Monitor des Systems nichts mehr.

Vorsicht ist angebracht

Wie verhindern Sie als Benutzer also, dass Sie beim Upgrade Ihres Systems eine böse Überraschung mit der Grafikkarte erleben? Zunächst gilt: Wenn Sie die Treiber “richtig” installiert haben, ist die Gefahr deutlich geringer. Bei Ubuntu bedeutet das, dass der ATI-/Nvidia-Treiber direkt über das Werkzeug für zusätzliche Treiber (im K-Menü: Anwendungen / System / Additional Drivers) installiert wurde (Abbildung 2). Findet dieses Tool einen Chipsatz in Ihrem System, für den ein proprietärer Treiber passt, wird es sich ohnehin lautstark melden und fragen, ob es den jeweiligen Treiber installieren soll. Dieses Programm ist ein Frontend für die Paketverwaltung, die Sie sonst auch verwenden – wenn Sie aus dem Programm heraus Treiber installieren, sind diese in die Paketverwaltung des Systems nahtlos integriert, und Sie sehen in Ihrem normalen Paketverwaltungstool Einträge mit nvidia (bei einer Nvidia-Karte) oder fglrx (bei einer ATI-Karte).

Abbildung 2: Ubuntu richtet proprietäre 3-D-Treiber komfortabel ein. In einem Repository liegen die nötigen Pakete, auch wenn sie nicht Teil der offiziellen Distribution sind.

Weniger eindeutig ist die Sache bei OpenSuse. Am besten fahren Sie hier noch, wenn Sie die inoffiziellen Repositories für ATI oder Nvidia in Ihre Systemkonfiguration übernehmen. (Eine ausführliche Anleitung für Nvidia-basierte Karten finden Sie in der OpenSuse-Support-Datenbank [1] – der Vorgang ist dort unter “Der Repository-Weg” ausführlich erläutert. Für ATI-Systeme nutzen Sie eine ähnliche Anleitung [2]). Die Installation der Treiber über das Paketsystem bietet wie bei Ubuntu auch die Möglichkeit, die Treiber schneller wieder los zu werden, als es der Fall wäre, wenn Sie diese unmittelbar über das Skript des Chipsatzherstellers aufs System bringen. Falls Sie doch letzteren Weg wählen, achten Sie jedenfalls darauf, die heruntergeladene Datei (meist enden die Dateien auf .bin) aufzubewahren, denn über sie ist später auch die Deinstallation des Treibers möglich.

Vor dem Update: Treiber löschen

Die sinnvollste Herangehensweise an ein Distributionsupdate ist es, den möglichen “Übeltäter” auszuschalten, bevor er Schaden anrichten kann. Auf Ubuntu-Systemen bedeutet das, über das Frontend für zusätzliche Treiber den ATI- oder Nvidia-Treiber zu deaktivieren. Das sorgt automatisch dafür, dass X.org wieder mit dem “normalen” Grafiktreiber arbeitet, der zwar keine 3-D-Funktionen bietet, aber dafür zuverlässig ein Update überlebt. Einen ähnlichen Effekt erreichen Sie auf OpenSuse-Systemen, indem Sie in der Paketsuche von YaST nach Paketen fahnden, deren Name nvidia oder fglrx enthält (Abbildung 3). Gefundene Pakete deinstallieren Sie großflächig.

Abbildung 3: Wer vor dem System-Upgrade die Nvidia- oder ATI-Pakete entfernt, erspart sich möglicherweise einigen Ärger während des Upgrades.

Es gibt noch einen Sonderfall: Falls Sie das Konfigurationsprogramm von Nvidia oder ATI verwendet haben, um spezifische Parameter Ihrer Grafikkarte über die X.org-Konfigurationsdatei festzulegen, dann haben Sie damit eine Datei /etc/X11/xorg.conf angelegt. In Standardinstallationen gibt es diese X.org-Konfigurationsdatei nicht mehr, weil der X-Server fast alle nötigen Parameter (z. B. die optimale Auflösung des Monitors) selbständig herausfindet. Wenn X.org also keine xorg.conf-Datei findet, arbeitet es mit passenden Standardwerten. Andererseits wird die automatische Erkennung deaktiviert, falls die Datei existiert. Und findet sich dort ein Treiber, den es nach der Deinstallation der Pakete – wie im Beispiel beschrieben – nicht mehr geht, verweigert X.org den Dienst. Sollten Sie also die Datei Xorg.conf (mit den Tools der Kartenhersteller oder von Hand) angelegt haben, müssen Sie diese nach der Deinstallation der proprietären Treiber unschädlich machen:

1. Öffnen Sie aus dem laufenden System heraus mit [Alt]+[F2] und dem Befehl konsole ein Terminalfenster.
2. Geben Sie darin den Befehl ls -la /etc/X11/xorg.conf ein und drücken Sie [Eingabe]. Erscheint die Fehlermeldung “Datei oder Verzeichnis nicht gefunden”, sind Sie schon fertig – es gibt keine X.org-Konfigurationsdatei.

3. Finden Sie die Datei, benennen Sie diese mit den Befehlen

   cd /etc/X11; sudo mv xorg.conf xorg.conf.old

   um, dann findet X.org sie beim Start nicht mehr.

Danach ist das Systemupdate problemlos möglich. Vergessen Sie aber im Anschluss an das Update nicht, die 3-D-Treiber erneut auf Ihr System zu holen – mit dem Treibertool für Ubuntu oder über eines der Zusatz-Repositories für OpenSuse.

Wenn Sie nach dem Update später die grafischen Treiber erneut auf dem System installiert haben, können Sie die umbenannte Datei recyclen. Mit

cd /etx/X11; sudo mv xorg.conf.old xorg.conf

geben Sie ihr wieder ihren ursprünglichen Namen, und nach dem nächsten Neustart der grafischen Oberfläche liest X.org sie auch wieder.

Bevor Sie Ihr System aktualisieren, sollten Sie außerdem sicherstellen, dass für Ihren Benutzer ein Passwort gesetzt ist. Nur so ist der Login über die Kommandozeile zu einem späteren Zeitpunkt mäglich, falls doch etwas schief geht.

Im Kasten Wenn alle Stricke reißen finden Sie noch Hinweise zur Fehlerbehebung, wenn Sie bereits ein Distributions-Upgrade durchgeführt haben und nun nach dem Booten im Textmodus landen. (hge)