Folgende Fehler wurden in KDE 4.5.1 hauptsächlich behoben:

• Stabilitätsprobleme bei einigen Plattform-Komponenten wurde behoben, insbesondere in dem neuen Shared Data Cache, in KHTML und in KNewStuff
• Verbesserung der Ergonomie beim Verschieben der Applets innerhalb der Plasma-Panels
• Die Erfassung von UPnP-Geräten im Netzwerk:/ KIO-Slave wurde behoben
• Ein Regressionsfehler in KWin dem Fenster- und Compositing-Manager wurde behoben, dass die Desktop-Effekte unterbunden hat.
• Das Wetter- und News-Applets können jetzt ihre Daten korrekt aktualisieren, sobald das Netzwerk wieder verfügbar ist.

In folgenden Komponenten wurden weitere Fehler behoben:

• kdelibs (kdecore, kdeui, kio, KHTML, KNewStuff, libplasma
• kdebase (dolphin, network:/ kio-slave, kwin, Plasma workspaces)
• kdeutils (Ark, KGpg)
• kdeplasma-addons (Comic Applet)
• kdenetwork (KGet, Kopete)
• kdegraphics (Okular)
• kdeedu (Marble, KGeography)

Changelog: KDE SC 4.5.1

Wichtiger Hinweis:
Wer bereits nach der unten beschriebenen Anleitung das Repo http://download.opensuse.org/repositories/KDE:/Distro:/Factory/openSUSE_11.3/ eingebunden und aktiviert hat, braucht lediglich nur ein Update per YaST oder zypper durchzuführen:

zypper up

Für alle anderen, die das Repo noch nicht eingebunden haben, empfehle ich die folgende Anleitung.

Installation:

1. YaST2 starten.
2. Im Menü Konfiguration -> Repositories aufrufen.
3. Auf Hinzufügen klicken.
4. “URL angeben” wählen und auf Weiter klicken.
5. Repository-Name eingeben: KDE 4.5.x
6. URL des KDE-Repo für openSUSE 11.3 eingeben: http://download.opensuse.org/repositories/KDE:/Distro:/Factory/openSUSE_11.3/
7. Auf Weiter klicken.
8. Das erstellte Repository “KDE 4.5.x” auswählen und die Priorität auf z.B. 50 ändern.
9. Auf Okay klicken, um die Verwaltung der Software-Repository zu schließen. Ggfs. den GPG-Schlüssel vom Repo importieren.
10. In YaST2 dann auf Anzeigen -> Installationsquellen bzw. auf den offenen Tab Installationsquellen klicken.
11. Auf der linken Seite das “KDE 4.5.x”-Repo auswählen.
12. Im blauen Textfeld auf Switch system packages klicken.
13. Abschließend auf Akzeptieren klicken. Sollte ein Dialogfenster bezüglich des NetworkManager auftauchen, so handelt es sich um ein veraltetes Package (Sprachdatei) und kann gelöscht werden. Das Pendant zum gelöschten Package wird dennoch installiert.
14. Rechner neustarten und KDE 4.5.1 genießen.

Have a lot of fun!

Man kann sich sehr einfach eine sortierte Liste (mittels RPM, grep und sort) über vorhandene “openSUSE 11.2″-Pakete in der Konsole ausgeben lassen:

rpm -qa --qf '%{name}-%{version}-%{release} -> %{distribution}\n' | grep -i -E 'openSUSE[_|-| ]11.2' | sort

Diese Liste zeigt teilweise auch das Repo der installierten Paketen an und man kann so die Pakete im OBS lokalisieren und erneut aktualisieren. Sobald man das erledigt hat, kann man nun die restlichen “openSUSE 11.2″-Pakete entfernen, die man bisher gar nicht auflösen konnte bzw. mit dem gleichen Paketnamen bereits eine neuere Version unter openSUSE 11.3 installiert wurde.

Wenn man ein Upgrade bzw. ein Update von openSUSE hinter sich hat, sollte man sich auch nach neueren Konfigurationsdateien umschauen, die aus logischen Gründen nicht ersetzt wurden (der Zweck ist, dass der laufende Betrieb nach der Installation nicht gestört werden darf und daher die Änderungen von Hand erledigt werden muss):

find /etc -iname "*.rpmnew"

Sind in der o.g. Liste einige Dateien vorhanden, die mit “rpmnew” enden, so sollte man die Konfiguration von der älteren Datei in die neue Datei übertragen. Anschließend löscht man die ältere Datei und benennt die neuere Datei in den Namen der älteren Datei um (also ohne .rpmnew).

Beispiel:
/etc/php5/apache/php.ini <= ältere Datei
/etc/php5/apache/php.ini.rpmnew <= neue Datei

Optional: Unterschiede der Konfiguration anzeigen lassen:

diff -rup /etc/php5/apache/php.ini /etc/php5/apache/php.ini.rpmnew

Konfiguration manuell übertragen. Nachtrag: Die beiden Dateien sollten zur Bearbeitung (root-Rechte) mit einem Editor geöffnet werden und die jeweilige Konfigurationen rüberkopieren. Hat man hier keine Einstellung vorgenommen, kann man zum nächsten Schritt übergehen.
/etc/php5/apache/php.ini => /etc/php5/apache/php.ini.rpmnew

Abschließend die ältere Datei löschen und die neuere Datei umbenennen:

rm /etc/php5/apache/php.ini
mv /etc/php5/apache/php.ini.rpmnew /etc/php5/apache/php.ini

oder noch kürzer

mv -f /etc/php5/apache/php.ini{.rpmnew,}

Viel Spaß beim Aufräumen.

[UPDATE 28.08.2010]
Ich habe das Skript makerpm-ati-10.8.sh aktualisiert. Diesmal kann das Skript nicht nur installieren und konfigurieren, sondern auch mit der Option -u oder –uninstall ATI Catalyst deinstallieren und sämtliche vorhandene ATI-Dateien und Verzeichnisse werden restlos entfernt. In Zukunft sollten solche Dateileichen nicht mehr im System rumfliegen.

Sollte man die neueste ATI-Version installiert haben und der ATI Catalyst Control Center unerklärlicherweise noch die Version vom Vorgänger anzeigt, so sollte man den ATI Catalyst mittels dem Skript im Runlevel 3 komplett entfernen lassen und anschließend den Computer neustarten:

./makerpm-ati-10.8.sh -u

Danach kann man wieder wie gewohnt ATI Catalyst vom Skript installieren lassen:

./makerpm-ati-10.8.sh -i

[/UPDATE 28.08.2010]

Inhaltsverzeichnis

• Einleitung
• Hilfe, es funktioniert nicht!
• RPM mit dem Skript makerpm-ati-10.8.sh bauen (empfohlen)
• RPM manuell bauen (für Fortgeschrittene)
• Troubleshooting
1. Nach dem Booten sieht man die Konsole (Problem mit der Konfiguration des X-Servers)
2. Nach dem Booten hat man einen schwarzen Bildschirm (Problem mit dem Kernel-Mode-Setting)
3. Arbeitsflächen-Effekte (Compositing) in KDE 4.4 bzw. 4.5 ist nicht aktiviert
4. Arbeitsflächen-Effekte (Compositing) in KDE 4.5.0 lassen sich gar nicht mehr aktivieren
5. In Firefox oder Thunderbird erscheinen schwarze Flächen
6. Mein Treiber unterstützt meine Grafikkarte nicht. Was mache ich jetzt?

Einleitung

*** Wichtiger Hinweis zum ATI-Repo ***
Im ATI-Repo befindet sich noch der ältere ATI-Catalyst 10.6 (fglrx 8.741) Treiber. Daher empfehle ich den Treiber nicht unter openSUSE 11.3 zu installieren. Wenn man trotzdem diesen Treiber installiert, kann es unter Umständen passieren, dass das grafische Desktopsystem komplett ausfällt und nicht selten wird auch die Konsole völlig verzerrt, wobei man nur noch über den Failsafe-Modus wieder ins System kommt.

Diese Anleitung wie auch das Skript werden regelmäßig aktualisiert. Es lohnt sich daher öfter mal vorbeizuschauen oder im Feedreader zu speichern.

Es gibt 2 Wege den Bau des RPM-Packages durchzuführen.

1. das RPM mit dem Skript makerpm-ati-10.8.sh bauen (empfohlen)
2. das RPM manuell bauen (für Fortgeschrittene)

Der Vorteil zu Punkt 1: man muss sich nicht um die nötigen Packages für den Bau kümmern und man spart sich die Tipparbeit, die Zeit und die Nerven.

Die Anleitung funktioniert mit geringer Abweichung auch unter openSUSE 11.2 und openSUSE 11.1.

Alle genannten Schritte müssen in der Konsole im Root-Modus ausgeführt werden. Die Installation des RPM-Package “fglrx” kann im Runlevel 3 oder auch im Runlevel 5 durchgeführt werden. Danach ist ein Neustart des Computers auf jeden Fall erforderlich.

Vorhandene fglrx-Treiber aus dem ATI-Repo sind auf jeden Fall zu deinstallieren, sonst kommt es zu Konflikten bei der Installation dieses selbstgebauten RPM-Package.

Mit vorhandene fglrx-Treiber sind z.B. folgende gemeint:
- ati-fglrxG01-kmp-{default,desktop,pae,…}
- ati-fglrxG02-kmp-{default,desktop,pae,…}
- x11-video-fglrxG02

Vorhandene fglrx-Treiber auflisten lassen:

rpm -qa | grep -E 'fglrxG01|fglrxG02'

Wenn hier von RPM eine Ausgabe erscheint, müssen diese Package deinstalliert werden:

zypper rm `rpm -qa | grep -E 'fglrxG01|fglrxG02'`

Alternativ kann man auch in YaST nach fglrxG01 bzw. fglrxG02 suchen und entfernen lassen.

Hilfe, es funktioniert nicht!

Bitte haltet folgende Regel ein:

1. Bei der Eingabe der Befehle auf mögliche Tippfehler überprüfen.
2. Möglicherweise ist die Lösung für das Problem im Troubleshooting vorhanden.
3. In Kommentaren lesen, ob eine Lösung zu einem Problem bereits existiert.

Wenn keines der o.g. Regel greift, dann könnt ihr mit eurem Anliegen an mich wenden. Damit ich euch helfen kann, müsst ihr erst vorarbeiten. Bitte ladet euch das Skript makerpm-ati-10.8.sh herunter und erstellt einen Report von eurem System in der Konsole:

su -c 'sh makerpm-ati-10.8.sh -ur'

Das Skript lädt das Report auf sprunge.us hoch und gibt anschließend einen Link aus. Diesen Link postet ihr in eurem Kommentar zusammen mit einer Beschreibung zu eurem Problem an mich. Ich werde mir euren Report anschauen und Hilfestellung geben, wo evtl. das Problem liegen könnte.

RPM mit dem Skript bauen

Das Skript makerpm-ati-10.8.sh ist sehr mächtig, robust und läuft vollautomatisch. Der ATI-Installer wird automatisch heruntergeladen, falls er nicht schon im Verzeichnis liegt. Zudem wird geprüft, ob die Grafikkarte vom Treiber unterstützt wird. Auf dem System werden nach den nötigen Entwicklungspaketen geprüft und ggfs. installiert. Auf Wunsch wird nach dem Bau des RPM-Packages der fglrx-Treiber installiert.

Folgende Argumente können dem Skript übergeben werden:

Downloads:

• Skript: makerpm-ati-10.8.sh
• SHA1: makerpm-ati-10.8.sh.sha1

Empfohlene Vorgehensweise:

Man benötigt hierfür die Konsole mit root-Rechten, um das Skript auszuführen.

Optional: Das System im Runlevel 3 starten oder wechseln:
Beim Booten: Im Bootmenü den Eintrag von openSUSE 11.3 selektieren und auf der Tastatur die Zahl “3″ und Enter drücken und als “root” einloggen
Im laufenden Desktopsystem: Bitte vom System abmelden. Sobald die grafische Anmeldung erscheint den Tastenkürzel ALT+N oder STRG+ALT+F1 drücken, um in die Konsole umzuschalten. Dann mit dem User “root” einloggen und mit folgendem Befehl in den Runlevel 3 wechseln:

init 3

1. Das Skript herunterladen:

wget http://www.sebastian-siebert.de/downloads/makerpm-ati-10.8.sh

2. Die Prüfsummendatei herunterladen:

wget http://www.sebastian-siebert.de/downloads/makerpm-ati-10.8.sh.sha1

3. Die Prüfsummendatei gegen das Skript prüfen:

sha1sum -c makerpm-ati-10.8.sh.sha1

Idealerweise sollte folgende Ausgabe erscheinen, andernfalls stimmt etwas mit dem heruntergeladenen Skript nicht:

makerpm-ati-10.8.sh: OK

4. Die Rechte des Skriptes ändern und ausführbar machen:

chown root:root makerpm-ati-10.8.sh && chmod 744 makerpm-ati-10.8.sh

5. Das Skript mit dem Argument -i ausführen. Das RPM-Package wird im Anschluß automatisch installiert.

./makerpm-ati-10.8.sh -i

6. Den Rechner neustarten:

reboot

RPM manuell bauen

Das ist der etwas schwierigere Teil. Aber es ist nicht unmöglich.

Für den Bau des RPM-Packages werden folgende Entwicklungswerkzeuge bzw. -packages benötigt:

• gcc
• make
• patch
• kernel-devel (openSUSE 11.2 / openSUSE 11.1: linux-kernel-headers)
• kernel-source
• kernel-{default,desktop,pae,rt,vanilla,xen}-devel
• kernel-syms

Beim Kernel-Entwicklungspackage ist zu beachten, dass man die richtige installiert hat. Welchen Kernel zur Zeit auf dem System läuft, kann man in der Konsole abfragen:

uname -r

Bei mir ergibt beispielsweise diese Ausgabe:

2.6.34-12-desktop

Also muss im o.g. Fall der Kernel-Entwicklungspackage kernel-desktop-devel installiert sein.

Folgende Schritte werden auf einem 32-bit wie auch 64-bit openSUSE-System durchgeführt:

1. Den Installer des proprietären Treiber von ATI herunterladen:
https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/ati-driver-installer-10-8-x86.x86_64.run

Optional: Das System im Runlevel 3 starten und als “root” einloggen oder per init 3 wechseln.

2a. (openSUSE 11.3 32-bit) Den Bau des RPM-Packages anstoßen:
(openSUSE 11.2: SuSE/SUSE112-IA32, openSUSE 11.1: SuSE/SUSE111-IA32)

sh ./ati-driver-installer-10-8-x86.x86_64.run --buildpkg SuSE/SUSE113-IA32

2b. (openSUSE 11.3 64-bit) Den Bau des RPM-Packages anstoßen:
(openSUSE 11.2: SuSE/SUSE112-AMD64, openSUSE 11.1: SuSE/SUSE111-AMD64)

sh ./ati-driver-installer-10-8-x86.x86_64.run --buildpkg SuSE/SUSE113-AMD64

3a. Das RPM-Package installieren (Neuinstallation):

rpm -ihv fglrx*SUSE113-8.762*.rpm

3b. Das RPM-Package installieren (Update):

rpm -Uhv fglrx*SUSE113-8.762*.rpm

4. Den Rechner neustarten:

reboot

Troubleshooting:

1. Nach dem Booten sieht man die Konsole (Problem mit der Konfiguration des X-Servers)
2. Nach dem Booten hat man einen schwarzen Bildschirm (Problem mit dem Kernel-Mode-Setting)
3. Arbeitsflächen-Effekte (Compositing) in KDE 4.4 bzw. 4.5 ist nicht aktiviert
4. Arbeitsflächen-Effekte (Compositing) in KDE 4.5.0 lassen sich gar nicht mehr aktivieren
5. In Firefox oder Thunderbird erscheinen schwarze Flächen
6. Mein Treiber unterstützt meine Grafikkarte nicht. Was mache ich jetzt?

1. Sollte man nach dem Booten in der Konsole landen, dann erstellt man besser eine Konfigurationsdatei des X-Servers. In diesem Fall bitte als “root” in die Konsole einloggen und folgende Schritte durchführen.

   einfache Variante:

   Vorher noch in den Runlevel 3 wechseln:

   init 3

   Bei einem Monitor (Single-Modus):

   ./makerpm-ati-10.8.sh -c single

   Bei zwei Monitore (Dual-Modus):

   ./makerpm-ati-10.8.sh -c dual

   Danach den Rechner neustarten.

   Fortgeschrittene Variante:

   1. X-Server-Konfiguration verschieben, falls vorhanden:

   mv /etc/X11/xorg.conf /etc/X11/xorg.conf.backup

   2. Von aticonfig eine neue Konfigurationsdatei erzeugen lassen: (Das Tool aticonfig kann mittlerweile auch eine X-Server-Konfiguration from Scratch erzeugen, jedoch speziell auf den fglrx-Treiber zugeschnitten. Die restliche Hardware wird vom X-Server automatisch erkannt und geladen. Dies sollte in Zukunft vorgezogen werden, falls die Autoerkennung für den fglrx-Treiber oder X -configure nicht funktioniert):

   Bei einem Monitor (Single-Modus):

   aticonfig --initial --input=/etc/X11/xorg.conf

   oder bei zwei Monitore (Dual-Modus):

   aticonfig --initial=dual-head --input=/etc/X11/xorg.conf

2. Wenn man vor einem schwarzen Bildschirm sitzt und man weder die Konsole noch den Desktop sieht, dann liegt es höchstwahrscheinlich am neueingeführten Kernel-Mode-Setting (auch KMS genannt). Das Problem läßt sich durch Deaktivierung des KMS beheben.

   einfache Variante:

   Mit dem Skript das KMS dauerhaft deaktivieren:

   ./makerpm-ati-10.8.sh -kms no

   Fortgeschrittene Variante:

   Es gibt 2 Möglichkeiten KMS zu deaktivieren:

   • Als Bootparameter in GRUB oder LILO: nomodeset
   • KMS im Initial Ramdisk grundsätzlich deaktivieren. Der nachfolgende Befehl schaltet das KMS in der Konfiguration /etc/sysconfig/kernel auf NO_KMS_IN_INITRD=”yes” aus.

     sed -i 's/NO_KMS_IN_INITRD=.*/NO_KMS_IN_INITRD="yes"/g' /etc/sysconfig/kernel

     Anschließend die Initial Ramdisk neubauen lassen:

     mkinitrd

3. Falls die Arbeitsflächen-Effekte (Compositing) in KDE 4.4 bzw. 4.5 nicht mehr aktiviert sind, weil vermutlich die Erkennung der OpenGL-Schnittstelle von AMD/ATI Catalyst 10.8 fehlschlägt. Hierzu gibt es eine einfache Lösung:
   1. Im KDE-Menü auf Systemeinstellungen klicken
   2. Unter Allgemein / Erscheinungsbild & Verhalten auf Arbeitsfläche klicken
   3. In Arbeitsflächen-Effekte einrichten auf den Tab Erweitert klicken
   4. Die Checkbox Funktionsprüfungen deaktivieren aktivieren
   5. Im Tab Allgemein prüfen, ob Compositing aktiviert ist. Falls nicht, bitte aktivieren.
   6. Abschließend auf Anwenden klicken

   Jetzt sollen die Effekte in KDE wieder funktionieren. Die 3D-Anwendungen bzw. 3D-Spiele sind von diesem Problem nicht betroffen.

4. Wenn das Compositing im OpenGL-Modus in KDE 4.5.0 nicht mehr aktivierbar sein sollte, dann wurde möglicherweise von KWin das Compositing komplett deaktiviert. Schuld ist die Einstellung OpenGLIsUnsafe=true in der Konfiguration /home/USERNAME/.kde4/share/config/kwinrc. Leider gibt es noch keine Möglichkeit diese Option in den Systemeinstellungen von KDE zu ändern.

   Man kann in der Konsole schnell und komfortabel für jeden User im Home überprüfen, ob man von dem Problem betroffen ist. Wenn bei dem nachfolgenden Befehl eine oder mehrere Dateien aufgelistet werden, so ist die Option von KWin bei dem jeweiligen User scharf geschaltet worden:

   grep -l "OpenGLIsUnsafe=true" /home/*/.kde4/share/config/kwinrc

   Es ist wichtig, dass der folgende Befehl im Runlevel 3 ausgeführt wird, sonst werden die Einstellungen von KWin wieder überschrieben. Wie man in den Runlevel 3 kommt, wird oben im Artikel beschrieben. Um das Problem mit “OpenGLIsUnsafe” für alle User im Home-Verzeichnis zu beheben, gibt man folgenden Befehl als root in der Konsole ein:

   sed -i '/OpenGLIsUnsafe=.*/d' /home/*/.kde4/share/config/kwinrc

   Hintergrundinfo:
   Die Option OpenGLIsUnsafe kam mit der Revision 1079919 und wurde vom Autor Lucas Murray (lmurray) geschrieben. Allerdings ist ein Recheck-Button in der KDE-Einstellung laut einer TODO-Anmerkung im Quellcode in Zeile 156 geplant, um ggfs. die Option OpenGLIsUnsafe zurückzusetzen, was leider bisher noch nicht umgesetzt wurde.
   Quellcode von kwincompositing
   der Diff vom Quellcode zur Revision 1079919

5. Falls unter Firefox oder Thunderbird schwarze Flächen erscheinen, dann liegt es in erster Linie an den neuen 2D-Treiber. Um den alten 2D-Treiber zu verwenden, führt man folgende Kommando aus.

   einfache Variante:

   ./makerpm-ati-10.8.sh -old2ddriver yes

   Fortgeschrittene Variante:

   aticonfig --set-pcs-str=DDX,ForceXAA,TRUE

   Hinweis: Falls das Problem mit den schwarzen Flächen in 2D-Anwendungen in der nächsten Version behoben wurde, kann man es wieder deaktivieren:

   einfache Variante:

   ./makerpm-ati-10.8.sh -old2ddriver no

Fortgeschrittene Variante:

aticonfig --del-pcs=DDX,ForceXAA

6. Mein Treiber unterstützt meine Grafikkarte nicht. Was mache ich jetzt? Hier kann man leider nur den Radeon-Treiber verwenden. Man öffnet die Konfigurationsdatei /etc/X11/xorg.conf.d/50-device.conf mit root-Rechten, um diese bearbeiten zu können. Einfach den Krunner mittels Tastenkürzel ALT+F2 öffnen und folgende Befehlszeile eingeben und abschließend mit Enter bestätigen:

   kdesu kwrite /etc/X11/xorg.conf.d/50-device.conf

   In der Zeile 4 bei Driver “radeon” nimmt man vorne die Raute weg und speichert die Datei ab. Anschließend alle Anwendungen schließen und neustarten.

   Sollte man beim Neustart einen schwarzen Bildschirm bekommen, dann muss das KMS abgeschaltet werden. Bitte einmal diesen Workaround zum Abschalten von KMS im Failsafe-Modus durchführen.

Feedbacks sind wie immer willkommen.

Screenshots:

Auf meinem Netbook habe ich die praktische Konsole bereits installiert und täglich im Einsatz, weil mich immer schon von den anderen Konsolen das offene Konsolenfenster und die Platzverschwendung in der Fensterleiste gestört haben. Zudem kann ich mehrere Konsolen als Tabs öffnen und zwischen ihnen per Tastenkombination (Umschalt + Pfeil rechts bzw. links) wechseln. Man kann auch die Konsole horizontal (STRG+Umschalt+T) und vertikal (STRG+Umschalt+L) splitten, was eher auf einem größeren Monitor besser geeignet ist. Die Höhe und die Breite sowie die Animationsgeschwindigkeit des Yakuake-Fensters kann man in den Einstellungen festlegen lassen.

Speicherverbrauch der verfügbaren Konsolen unter openSUSE 11.3:
Konsole: 9,5 MB
Yakuake: 7,6 MB
xterm: 3,0 MB
Terminal (Xfce): 2,9 MB
GNOME-Terminal: 2,9 MB
LXTerminal: 2,3 MB

Das Tool kann man sich über YaST mit dem Paketnamen yakuake installieren oder per zypper:

zypper in yakuake

Nach der Installation braucht man nur Yakuake über das K-Menü System -> Terminal -> Yakuake einmal zu starten. Sobald KDE bei einem Neustart fertig geladen wurde, wird die Konsole ebenfalls gestartet. Yakuake steht dann im Hintergrund zur Verfügung und kann jederzeit per F12 in den Vordergrund geholt werden.

Have a lot of fun!

Konsole für GNOME:
Das Pendant zu Yakuake für das GNOME-Desktop wäre Guake oder Tilda. Leider sind keine Pakete unter openSUSE wie auch im OBS (openSUSE Build Service) verfügbar, was mich doch etwas verwundert.

Persönliche Erfahrung mit KDE 4.5.0:
Ich habe KDE 4.5.0 zuerst auf meinem Netbook installiert. Zuallererst muss ich sagen, dass KDE erheblich an Performance zugelegt hat. Vorallem der Infobereich stört jetzt nicht mehr so z.B. während einer Kopieraktion mit Dolphin von größeren Dateien oder mehreren Dateien. Im Infobereich kann man die Benachrichtigungen filtern lassen und was wirklich ein Plus-Punkt ist, dass die Benachrichtigungen nicht mehr einfach so verschwinden, sondern auch zu einem späteren Zeitpunkt einsehbar sind. Im Systemabschnitt der Kontrollleiste haben die Apps neue Icons und lenken so nicht mehr ab. Wenn man die Systemeinstellungen von KDE startet, dann sieht man deutlich das hier aufgeräumt wurde.

Auf dem Desktop-PC habe ich auch KDE 4.5.0 installiert. Hierzu muss ich ergänzen, dass das Compositing von KDE problemlos mit dem aktuellen ATI Catalyst 10.7 Treiber funktioniert. Ich konnte auch die Einstellung “Funktionsprüfungen deaktivieren” in Arbeitsflächen-Effekte wieder ausschalten.

Mein Fazit: Ich bleibe definitiv bei KDE 4.5.0, denn KDE 4.4.4 war in vielen Bereichen leider wirklich etwas langsam. Vorallem hatte mich der unhandliche Infobereich von KDE 4.4.4 immer schon gestört und kleine Denkpausen waren auf meinem Netbook keine Seltenheit , was unter KDE 4.5.0 nicht mehr passiert.

Screenshots:

• http://www.kde.org/announcements/4.5/plasma.php
• http://www.kde.org/announcements/4.5/applications.php

Installation:

1. YaST2 starten.
2. Im Menü Konfiguration -> Repositories aufrufen.
3. Auf Hinzufügen klicken.
4. “URL angeben” wählen und auf Weiter klicken.
5. Repository-Name eingeben: KDE 4.5.x
6. URL des KDE-Repo für openSUSE 11.3 eingeben: http://download.opensuse.org/repositories/KDE:/Distro:/Factory/openSUSE_11.3/
7. Auf Weiter klicken.
8. Das erstellte Repository “KDE 4.5.x” auswählen und die Priorität auf z.B. 50 ändern.
9. Auf Okay klicken, um die Verwaltung der Software-Repository zu schließen. Ggfs. den GPG-Schlüssel vom Repo importieren.
10. In YaST2 dann auf Anzeigen -> Installationsquellen bzw. auf den offenen Tab Installationsquellen klicken.
11. Auf der linken Seite das “KDE 4.5.x”-Repo auswählen.
12. Im blauen Textfeld auf Switch system packages klicken.
13. Abschließend auf Akzeptieren klicken. Sollte ein Dialogfenster bezüglich des NetworkManager auftauchen, so handelt es sich um ein veraltetes Package (Sprachdatei) und kann gelöscht werden. Das Pendant zum gelöschten Package wird dennoch installiert.
14. Rechner neustarten und KDE 4.5.0 genießen.

In diesem Sinne: Have a lot of fun…

Über das Spiel:

• Im Single-Modus können bis zu 9 Computergegner am Tisch teilnehmen.
• Im Netzwerk-Modus wie auch Internet-Modus können bis zu 10 Spieler teilnehmen.
• Weitere Spieltisch-Styles können heruntergeladen werden.
• Das Spiel wurde in C++/Qt4 geschrieben.

Neu in dieser Version:

• Online-Ranking

Screenshots von PokerTH 0.8 Beta:

Webseite zum Spiel (englisch): http://www.pokerth.net/
Changelog (englisch): http://www.pokerth.net/changelog.html
Online-Ranking-Seite (englisch): http://pokerth.biz/

Installation

Das Spiel kann bequem unter openSUSE per 1-Klick-Installation installiert werden. Einfach auf den Link der genutzten openSUSE-Version klicken und das “YaST Meta Package” direkt öffnen:

• PokerTH für openSUSE 11.1 (32/64-bit)
• PokerTH für openSUSE 11.2 (32/64-bit)
• PokerTH für openSUSE 11.3 (32/64-bit)

Wer die Beta von PokerTH manuell installieren möchte, dem stelle ich folgenden Repos zum Einbinden in YaST zur Verfügung:

• openSUSE 11.1:
  http://download.opensuse.org/repositories/home:/Freespacer:/pokerth/openSUSE_11.1/
• openSUSE 11.2:
  http://download.opensuse.org/repositories/home:/Freespacer:/pokerth/openSUSE_11.2/
• openSUSE 11.3:
  http://download.opensuse.org/repositories/home:/Freespacer:/pokerth/openSUSE_11.3/

Sobald das Spiel den Beta-Status verlassen hat, werde ich es offiziell im Games-Repo updaten:
http://download.opensuse.org/repositories/games/

Viel Spaß beim Spielen.

Kommentare sind wie immer erwünscht.

ATI Catalyst 10.7 unterstützt jetzt offiziell openSUSE 11.3. Da hat AMD/ATI richtig auf die Tube gedrückt. Eine tolle Neuigkeit: der neue 2D-Treiber scheint jetzt zu funktionieren.

[UPDATE 07.08.2010]
*** Achtung! *** Wichtige Meldung! ***
Mittlerweile wurde das ATI-Repo für openSUSE 11.3 aktualisiert bzw. freigegeben. Jedoch muss ich eindringlich warnen, dass es sich um den ältere ATI Catalyst 10.6 bzw. fglrx 8.741 handelt. Diese Version unterstützt nicht offiziell openSUSE 11.3 und kann sehr wahrscheinlich nach der Installation (ohne X-Konfiguration oder bei aktiviertem Kernel-Mode-Setting) zu einem Ausfall des Desktopsystem kommen. Die genannte ATI-Version aus dem ATI-Repo sollte man nach meiner Empfehlung besser NICHT installieren, sondern man nimmt stattdessen die neuere ATI Catalyst 10.7 (fglrx 8.753) mit der offiziellen Unterstützung für openSUSE 11.3.
[/UPDATE 07.08.2010]

Es gibt 2 Wege den Bau des RPM-Packages durchzuführen.

1. das RPM mit dem Skript makerpm-ati-10.7.sh bauen (empfohlen)
2. das RPM manuell bauen (für Fortgeschrittene)

Der Vorteil zu Punkt 1: man muss sich nicht um die nötigen Packages für den Bau kümmern und man spart sich die Tipparbeit, die Zeit und die Nerven.

Die Anleitung funktioniert mit geringer Abweichung auch unter openSUSE 11.2.

Wichtig: Bevor ihr irgendwelche Fragen an mich richtet, lest euch bitte sorgfältig diesen Artikel durch und achtet auch auf eure Eingaben in der Konsole wegen mögliche Tippfehler. Falls es Probleme geben sollte, schaut bitte unter Troubleshooting nach, ob euer Problem dort schon dokumentiert wurde.

Alle genannten Schritte müssen in der Konsole im Root-Modus ausgeführt werden. Die Installation des RPM-Package “fglrx” kann im Runlevel 3 oder auch im Runlevel 5 durchgeführt werden. Danach ist ein Neustart des Computers auf jeden Fall erforderlich.

Vorhandene fremde fglrx-Treiber sind auf jedenfall zu deinstallieren, sonst kommt es zu Konflikten bei der Installation dieses selbstgebauten RPM-Package.

Mit fremde fglrx-Treiber sind z.B. folgende gemeint:
- ati-fglrxG01-kmp-{default,desktop,pae,…}
- ati-fglrxG02-kmp-{default,desktop,pae,…}
- x11-video-fglrxG02

Vorhandene fremde fglrx-Treiber auflisten lassen:

rpm -qa | grep -E 'fglrxG01|fglrxG02'

Wenn hier von RPM eine Ausgabe erscheint, müssen diese Package deinstalliert werden:

zypper rm (packagename)

Alternativ kann man auch in YaST nach fglrxG01 bzw. fglrxG02 suchen und entfernen lassen.

RPM mit dem Skript bauen

Das Skript makerpm-ati-10.7.sh ist sehr mächtig, robust und läuft vollautomatisch. Der ATI-Installer wird automatisch heruntergeladen, falls er nicht schon im Verzeichnis liegt. Zudem wird geprüft, ob die Grafikkarte vom Treiber unterstützt wird. Auf dem System werden nach den nötigen Entwicklungspaketen geprüft und ggfs. installiert. Auf Wunsch wird nach dem Bau des RPM-Packages der fglrx-Treiber installiert.

Folgende Argumente können dem Skript übergeben werden:
-b – Nur das RPM-Package bauen (Standard)
-c <type> – Nur X-Server konfigurieren. Monitor-Typ: single = 1 Monitor, dual = 2 Monitore (Wichtig: Nur ausführen, wenn es Probleme mit der Standardkonfiguration des X-Servers auftreten)
-d – Nur den ATI-Installer downloaden
-i – Das RPM-Package bauen und installieren bzw. updaten
-kms <yes|no> – Kernel-Mode-Setting (KMS) aktivieren oder deaktivieren
-old2ddriver <yes|no> – den alten 2D-Treiber aktivieren oder deaktivieren
-ux – Nur den gepatchten X-Server installieren. Verbessert die Zusammenarbeit mit dem fglrx-Treiber. (dringend zu empfehlen)
-h – Die Hilfe anzeigen lassen
-V – Version des Skript anzeigen

Downloads:

• Skript: makerpm-ati-10.7.sh
• SHA1: makerpm-ati-10.7.sh.sha1

Empfohlene Vorgehensweise:

Optional: Das System im Runlevel 3 starten oder wechseln:
Beim Booten: Im Bootmenü den Eintrag von openSUSE 11.3 selektieren und auf der Tastatur die Zahl “3″ und Enter drücken und als “root” einloggen
Im laufenden System: STRG+ALT+F1 drücken und sich als “root” einloggen. Danach mit folgendem Befehl in den Runlevel 3 wechseln:

init 3

1. Das Skript herunterladen:

wget http://www.sebastian-siebert.de/downloads/makerpm-ati-10.7.sh

2. Die Prüfsummendatei herunterladen:

wget http://www.sebastian-siebert.de/downloads/makerpm-ati-10.7.sh.sha1

3. Die Prüfsummendatei gegen das Skript prüfen:

sha1sum -c makerpm-ati-10.7.sh.sha1

Idealerweise sollte folgende Ausgabe erscheinen, andernfalls stimmt etwas mit dem heruntergeladenen Skript nicht:

makerpm-ati-10.7.sh: OK

4. Die Rechte des Skriptes ändern und ausführbar machen:

chown root:root makerpm-ati-10.7.sh && chmod 744 makerpm-ati-10.7.sh

5. Das Skript mit dem Argument -i ausführen. Das RPM-Package wird im Anschluß automatisch installiert.

./makerpm-ati-10.7.sh -i

6. Den Rechner neustarten:

reboot

Troubleshooting (RPM mit dem Skript bauen):

• Sollte man nach dem Booten in der Konsole landen, dann erstellt man besser eine Konfigurationsdatei des X-Servers. In diesem Fall bitte als “root” in die Konsole einloggen und das Skript mit folgendem Parameter ausführen lassen.

  Vorher noch in den Runlevel 3 wechseln:

  init 3

  Bei einem Monitor (Single-Modus):

  ./makerpm-ati-10.7.sh -c single

  Bei zwei Monitore (Dual-Modus):

  ./makerpm-ati-10.7.sh -c dual

  Danach den Rechner neustarten.

• Falls die Arbeitsflächen-Effekte (Compositing) in KDE 4.4.4 nicht mehr aktiviert sind, weil vermutlich die Erkennung der OpenGL-Schnittstelle von AMD/ATI Catalyst 10.7 fehlschlägt. Hierzu gibt es eine einfache Lösung:
  1. Im KDE-Menü auf Systemeinstellungen klicken
  2. Unter Allgemein / Erscheinungsbild & Verhalten auf Arbeitsfläche klicken
  3. In Arbeitsflächen-Effekte einrichten auf den Tab Erweitert klicken
  4. Die Checkbox Funktionsprüfungen deaktivieren aktivieren
  5. Im Tab Allgemein prüfen, ob Compositing aktiviert ist. Falls nicht, bitte aktivieren.
  6. Abschließend auf Anwenden klicken

  Jetzt sollen die Effekte in KDE wieder funktionieren. Die 3D-Anwendungen bzw. 3D-Spiele sind von diesem Problem nicht betroffen.

• Einige User haben mir berichtet, dass sie Probleme mit dem Kernel-Mode-Setting (KMS) haben. Das Problem läßt sich durch Deaktivierung des KMS-Modus teilweise beheben.

  ./makerpm-ati-10.7.sh -kms no

• Falls unter Firefox oder Thunderbird schwarze Flächen erscheinen, dann liegt es in erster Linie an den neuen 2D-Treiber. Um den alten 2D-Treiber zu verwenden, führt man folgende Kommando aus.

  ./makerpm-ati-10.7.sh -old2ddriver yes

  Hinweis: Falls das Problem mit den schwarzen Flächen in 2D-Anwendungen in der nächsten Version behoben wurde, kann man es wieder deaktivieren:

  ./makerpm-ati-10.7.sh -old2ddriver no

• Wenn das Compositing im OpenGL-Modus in KDE 4.5.0 nicht mehr aktivierbar sein sollte, dann wurde möglicherweise von KWin das Compositing komplett deaktiviert. Schuld ist die Einstellung OpenGLIsUnsafe=true in der Konfiguration /home/USERNAME/.kde4/share/config/kwinrc. Leider gibt es noch keine Möglichkeit diese Option in den Systemeinstellungen von KDE zu ändern.

  Man kann in der Konsole schnell und komfortabel für jeden User im Home überprüfen, ob man von dem Problem betroffen ist. Wenn bei dem nachfolgenden Befehl eine oder mehrere Dateien aufgelistet werden, so ist die Option von KWin bei dem jeweiligen User scharf geschaltet worden:

  grep -l "OpenGLIsUnsafe=true" /home/*/.kde4/share/config/kwinrc

  Es ist wichtig, dass der folgende Befehl im Runlevel 3 ausgeführt wird, sonst werden die Einstellungen von KWin wieder überschrieben. Wie man in den Runlevel 3 kommt, wird oben im Artikel beschrieben. Um das Problem mit “OpenGLIsUnsafe” für alle User im Home-Verzeichnis zu beheben, gibt man folgenden Befehl als root in der Konsole ein:

  sed -i '/OpenGLIsUnsafe=.*/d' /home/*/.kde4/share/config/kwinrc

  Hintergrundinfo:
  Die Option OpenGLIsUnsafe kam mit der Revision 1079919 und wurde vom Autor Lucas Murray (lmurray) geschrieben. Allerdings ist ein Recheck-Button in der KDE-Einstellung laut einer TODO-Anmerkung im Quellcode in Zeile 156 geplant, um ggfs. die Option OpenGLIsUnsafe zurückzusetzen, was leider bisher noch nicht umgesetzt wurde.
  Quellcode von kwincompositing
  der Diff vom Quellcode zur Revision 1079919

RPM manuell bauen

Das ist der etwas schwierigere Teil. Aber es ist nicht unmöglich.

Für den Bau des RPM-Packages werden folgende Entwicklungswerkzeuge bzw. -packages benötigt

• gcc
• make
• patch
• kernel-devel (openSUSE 11.2: linux-kernel-headers)
• kernel-source
• kernel-{default,desktop,pae,rt,vanilla,xen}-devel

Beim Kernel-Entwicklungspackage ist zu beachten, dass man die richtige installiert hat. Welchen Kernel zur Zeit auf dem System läuft, kann man in der Konsole abfragen:

uname -r

Bei mir ergibt beispielsweise diese Ausgabe:

2.6.34-12-desktop

Also muss im o.g. Fall der Kernel-Entwicklungspackage kernel-desktop-devel installiert sein.

Folgende Schritte werden auf einem 32bit openSUSE-System durchgeführt:
(64bit openSUSE-System weiter unten)

1. Den Installer des proprietären Treiber von ATI herunterladen:
https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/ati-driver-installer-10-7-x86.x86_64.run

Optional: Das System im Runlevel 3 starten und als “root” einloggen oder per init 3 wechseln.

2. Den Bau des RPM-Packages anstoßen:

sh ./ati-driver-installer-10-7-x86.x86_64.run --buildpkg SuSE/SUSE113-IA32

3a. Das RPM-Package installieren (Neuinstallation):

rpm -ihv fglrx_7_5_0_SUSE113-8.753*.rpm

3b. Das RPM-Package installieren (Update):

rpm -Uhv fglrx_7_5_0_SUSE113-8.753*.rpm

4. Den Rechner neustarten:

reboot

Folgende Schritte werden auf einem 64bit openSUSE-System durchgeführt:

1. Den Installer des proprietären Treiber von ATI herunterladen:
https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/ati-driver-installer-10-7-x86.x86_64.run

Optional: Das System im Runlevel 3 starten und als “root” einloggen oder per init 3 wechseln.

2. Den Bau des RPM-Packages anstoßen:

sh ./ati-driver-installer-10-7-x86.x86_64.run --buildpkg SuSE/SUSE113-AMD64

3a. Das RPM-Package installieren (Neuinstallation):

rpm -ihv fglrx64_7_5_0_SUSE113-8.753*.rpm

3b. Das RPM-Package installieren (Update):

rpm -Uhv fglrx64_7_5_0_SUSE113-8.753*.rpm

4. Den Rechner neustarten:

reboot

Troubleshooting (RPM manuell bauen):

• Sollte man nach dem Booten in der Konsole landen, dann erstellt man besser eine Konfigurationsdatei des X-Servers. In diesem Fall bitte als “root” in die Konsole einloggen und folgende Schritte durchführen.

  1. X-Server-Konfiguration verschieben, falls vorhanden:

  mv /etc/X11/xorg.conf /etc/X11/xorg.conf.backup

  2. Von aticonfig eine neue Konfigurationsdatei erzeugen lassen: (Das Tool aticonfig kann mittlerweile auch eine X-Server-Konfiguration from Scratch erzeugen, jedoch speziell auf den fglrx-Treiber zugeschnitten. Die restliche Hardware wird vom X-Server automatisch erkannt und geladen. Dies sollte in Zukunft vorgezogen werden, falls die Autoerkennung für den fglrx-Treiber oder X -configure nicht funktioniert):

  Bei einem Monitor (Single-Modus):

  aticonfig --initial

  oder bei zwei Monitore (Dual-Modus):

  aticonfig --initial=dual-head

  Hinweis: Falls man bereits in diesem Schritt das Tool aticonfig für die Erzeugung einer X-Server-Konfiguration verwendet hat, so entfallen die nachfolgenden Schritte 3, 3a, 3b.

  3. Die Konfigurationsdatei von aticonfig für die Nutzung des fglrx-Treibers modifizieren lassen.

  3a. Bei einem Monitor (Single-Modus):

  aticonfig --initial --input=/etc/X11/xorg.conf

  3b. Bei zwei Monitore (Dual-Modus):

  aticonfig --initial=dual-head --input=/etc/X11/xorg.conf

• Falls die Arbeitsflächen-Effekte (Compositing) in KDE 4.4.4 nicht mehr aktiviert sind, weil vermutlich die Erkennung der OpenGL-Schnittstelle von AMD/ATI Catalyst 10.7 fehlschlägt. Hierzu gibt es eine einfache Lösung:
  1. Im KDE-Menü auf Systemeinstellungen klicken
  2. Unter Allgemein / Erscheinungsbild & Verhalten auf Arbeitsfläche klicken
  3. In Arbeitsflächen-Effekte einrichten auf den Tab Erweitert klicken
  4. Die Checkbox Funktionsprüfungen deaktivieren aktivieren
  5. Im Tab Allgemein prüfen, ob Compositing aktiviert ist. Falls nicht, bitte aktivieren.
  6. Abschließend auf Anwenden klicken

  Jetzt sollen die Effekte in KDE wieder funktionieren. Die 3D-Anwendungen bzw. 3D-Spiele sind von diesem Problem nicht betroffen.

• Einige User haben mir berichtet, dass sie Probleme mit dem Kernel-Mode-Setting (KMS) haben. Das Problem läßt sich durch Deaktivierung des KMS-Modus teilweise beheben.

  Es gibt 2 Möglichkeiten KMS zu deaktivieren:

  1. Als Bootparameter: nomodeset
  2. KMS-Modus im Initial Ramdisk grundsätzlich deaktivieren. Einfach die Datei /etc/sysconfig/kernel zur Bearbeitung öffnen und die Zeile mit NO_KMS_IN_INITRD in NO_KMS_IN_INITRD=”yes” ändern. Anschließend die Initial Ramdisk neubauen lassen:

     mkinitrd

• Falls unter Firefox oder Thunderbird schwarze Flächen erscheinen, dann liegt es in erster Linie an den neuen 2D-Treiber. Um den alten 2D-Treiber zu verwenden, führt man folgende Kommando aus.

  aticonfig --set-pcs-str=DDX,ForceXAA,TRUE

  Hinweis: Falls das Problem mit den schwarzen Flächen in 2D-Anwendungen in der nächsten Version behoben wurde, kann man es wieder deaktivieren:

  aticonfig --del-pcs=DDX,ForceXAA

• Wenn das Compositing im OpenGL-Modus in KDE 4.5.0 nicht mehr aktivierbar sein sollte, dann wurde möglicherweise von KWin das Compositing komplett deaktiviert. Schuld ist die Einstellung OpenGLIsUnsafe=true in der Konfiguration /home/USERNAME/.kde4/share/config/kwinrc. Leider gibt es noch keine Möglichkeit diese Option in den Systemeinstellungen von KDE zu ändern.

  Man kann in der Konsole schnell und komfortabel für jeden User im Home überprüfen, ob man von dem Problem betroffen ist. Wenn bei dem nachfolgenden Befehl eine oder mehrere Dateien aufgelistet werden, so ist die Option von KWin bei dem jeweiligen User scharf geschaltet worden:

  grep -l "OpenGLIsUnsafe=true" /home/*/.kde4/share/config/kwinrc

  Es ist wichtig, dass der folgende Befehl im Runlevel 3 ausgeführt wird, sonst werden die Einstellungen von KWin wieder überschrieben. Wie man in den Runlevel 3 kommt, wird oben im Artikel beschrieben. Um das Problem mit “OpenGLIsUnsafe” für alle User im Home-Verzeichnis zu beheben, gibt man folgenden Befehl als root in der Konsole ein:

  sed -i '/OpenGLIsUnsafe=.*/d' /home/*/.kde4/share/config/kwinrc

  Hintergrundinfo:
  Die Option OpenGLIsUnsafe kam mit der Revision 1079919 und wurde vom Autor Lucas Murray (lmurray) geschrieben. Allerdings ist ein Recheck-Button in der KDE-Einstellung laut einer TODO-Anmerkung im Quellcode in Zeile 156 geplant, um ggfs. die Option OpenGLIsUnsafe zurückzusetzen, was leider bisher noch nicht umgesetzt wurde.
  Quellcode von kwincompositing
  der Diff vom Quellcode zur Revision 1079919

Feedbacks sind wie immer willkommen.

Es können folgende Medien jeweils 32- oder 64-bit heruntergeladen werden:

• Installations-DVD
• GNOME Live
• KDE Live
• Netzwerk-Installations-CD

Zudem habe ich eine kleine Übersicht der Packages zusammengestellt. Es sind längst nicht alle aufgelistet.

Desktops:

• KDE 4.4.4
• GNOME 2.30
• LXDE (erstmalig unter openSUSE 11.3 verfügbar)

Programme (GUI):

• Amarok 2.3.0
• Blender 2.49b
• digiKam 1.2.0
• Eric 4.4.2
• FileZilla 3.3.2.1
• Firefox 3.6.6
• GIMP 2.6.8
• Inkscape 0.47
• K3b 1.93.0
• kDevelop 4.0
• KOffice 2.1.2
• Konversation 1.2.3
• KTorrent 3.3.4
• OpenOffice 3.2.1.4
• Qt Creator 1.3.1
• Rosegarden 10.04
• SeaMonkey 2.0.5
• Thunderbird 3.0.5

Konsolen- und Dienstprogramme:

• Apache 2.2.15
• aria2 1.9.1
• Bash 4.1
• CUPS 1.4.4
• cURL 7.20.1
• CVS 1.12.12
• Dovecot 1.2.11
• Emacs 23.1
• Evolution 2.30.1.2
• Firebird 2.1.3.18185
• GCC 4.5.0
• Gutenprint 5.2.4
• Git 1.7.1
• Jetty 5.1.14
• Lighttpd 1.4.26
• Links 2.2
• Lynx 2.8.7
• MariaDB 5.1.44
• Mercurial 1.5
• Mutt 1.5.20
• MySQL Community Server 5.1.46
• Nano 2.2.2
• OpenSSH 5.4p1
• OpenVPN 2.1.1
• Perl 5.12.1
• PHP 5.3.2
• Postfix 2.7.1
• Python 2.6.5
• PostgreSQL 8.4.4
• RCS 5.7
• Ruby 1.8.7p249
• Samba 3.5.4
• SQLite 3.6.23
• Subversion 1.6.9
• Tomcat 6.0.24
• Vim 7.2
• vsftpd 2.2.2
• w3m 0.5.2
• Wget 1.11.4

Eine Anleitung zum Upgrade eines bestehenden openSUSE System:
http://de.opensuse.org/Upgrade

Viel Spaß beim Installieren.

Heute (01.07.2010) wird im Laufe des Tages openSUSE 11.3 RC2 auf DVD veröffentlicht. Download-Seite: http://software.opensuse.org/developer/de

[UPDATE 01.07.2010]
Die ISOs von openSUSE 11.3 RC2 wurden schon auf folgendem Mirror verteilt:
ftp://ftp5.gwdg.de/pub/opensuse/distribution/11.3-RC2/

Gerade wurde das Verzeichnis für die ISOs von openSUSE 11.3 RC2 auf dem openSUSE-Download-Server freigegeben und ebenso auf dem openSUSE-Portal verlinkt:
http://download.opensuse.org/distribution/11.3-RC2/
[/UPDATE 01.07.2010]

Da ich ein offizielles Mitglied bei der openSUSE-Community bin, wünsche ich mir für openSUSE 11.3 einen erfolgreichen und vor allem bugfreien Start. Wir sind jetzt auf der Zielgeraden und der Tag der Veröffentlichung (15.07.2010) von openSUSE 11.3 rückt immer näher. Daher teste ich bereits seit openSUSE 11.3 RC 1 intensiv und suche nach mögliche Fehler.

Zudem möchte ich einen Aufruf starten, um die Distribution gemeinsam mit euch zu testen. Wer mitmachen möchte, ist herzlichst eingeladen und würde mich über eine kurze Vorstellung im Kommentarbereich freuen.

Ich möchte euch folgenden Deal vorschlagen. Wenn ihr irgendwelche Fehler in openSUSE 11.3 RC2 findet, möchte ich euch bitten hier im Kommentarbereich den Fehler und die Schritte zur Reproduzierung des Fehlers zu beschreiben. Ich werde den gemeldeten Fehler nachgehen. Sofern der Fehler sich bestätigt, werde ich mich direkt an die Verantwortlichen in Verbindung setzen oder ein Patch zur Behebung des Problems einliefern.

Warum biete ich euch diesen Deal an? Leider ist es für die meisten deutschsprachigen Tester (auch Linux-Neulinge) eine große Hürde einen Bugreport auf https://bugzilla.novell.com/index.cgi auf Englisch zu verfassen, obwohl sie gerne einen Fehler melden möchten. In dem Fall werden potenzielle Fehler nicht gemeldet und folglich auch nicht behoben oder ggfs. erst nach der Veröffentlichung von openSUSE 11.3, dass würde keinen guten Eindruck vermitteln.

In diesem Sinne viel Spaß beim Testen und bleibt mir treu. (Have a lot of fun)

Das Skript von openSUSE 11.2 kann man ohne Probleme weiterhin verwenden.

Microsoft Core Fonts beinhalten folgende Schriftarten:

• Andale Mono
• Arial
• Arial Black
• Comic Sans MS
• Courier New
• Georgia
• Impact
• Times New Roman
• Trebuchet MS
• Verdana
• Webdings

[UPDATE 29.06.2010]
Das Skript wurde im Update-Test-Repo veröffentlich und kann darüber installiert werden.

Das Update-Test-Repo kann wie folgt per zypper eingebunden werden.

zypper ar -f -n "Update Test 11.3" "http://download.opensuse.org/update/11.3-test/" "Update_Test_11.3"

Anschließend kann man über YaST oder zypper das Package “fetchmsttfonts-11.3″ installieren.
[/UPDATE 29.06.2010]

Installationsanleitung

Hinweis: Bitte nachfolgende Kommandos in der Konsole als root eingeben.

1. Verzeichnis erstellen und wechseln:

mkdir msfonts && cd msfonts

2. Das RPM “fetchmsttfonts” vom openSUSE 11.2 Update-Repo holen:

wget http://download.opensuse.org/update/11.2/rpm/noarch/fetchmsttfonts-11.2-6.6.12.noarch.rpm

3. Skript aus dem RPM ins aktuelle Verzeichnis entpacken:

rpm2cpio fetchmsttfonts-11.2-6.6.12.noarch.rpm | cpio -id *.txt

4. Skript umbenennen und ins aktuelle Verzeichnis verschieben:

mv ./var/adm/update-scripts/fetchmsttfonts-11.2-6.6.12-fetchmsttfonts.sh.txt fetchmsttfonts.sh

5. Die Installation der MS Core Fonts per Skript anstoßen:

./fetchmsttfonts.sh

6. Den Cache für die Schriftarten aktualisieren:

SuSEconfig --module fonts

Somit dürften die Microsoft Schriftarten wie schon unter openSUSE 11.2 systemweit zur Verfügung stehen.

Kommentare wie auch Feedbacks sind immer willkommen.

Folgende Software-Komponenten wurden in KDE 4.4.4 behoben:

• ark
• dolphin
• KAlarm
• KGpg
• KHangMan
• kmines
• knetwalk
• kopete
• kteatime
• libkdegames
• lskat

KDE SC 4.4.4 Changelog

Für die bereits veröffentlichte openSUSE 11.3 RC1 wird demnächst über ein Update-Test-Repo die KDE 4.4.4 verteilt. Jedoch muss man dieses Repo in openSUSE 11.3 RC1 hinzufügen, um diesen gesonderten Update-Kanal zu nutzen.

Um dieses Update-Test-Repo zu nutzen, genügt folgender Zypper-Befehl in der Konsole als root:

zypper ar -f -n "Update Test 11.3" "http://download.opensuse.org/update/11.3-test/" "Update_Test_11.3"

Die Mail [opensuse-kde] KDE SC 4.4.4 for openSUSE 11.3 zum Nachlesen.

Ein paar gute Nachrichten für Besitzer einer ATI Grafikkarte vorne weg. AMD hat still und heimlich einige Bugs behoben, die nicht mal in den Release Notes erwähnt wurden.

Zudem darf ich verkünden, dass endlich ATI Catalyst 10.6 mit XOrg 7.5 (X-Server 1.8.0) läuft. Das Patchen der X-Server-Version (von 1.8.0 auf 1.7.5.0) gehört nun der Vergangenheit an. (AMD war da doch schneller ) Leider bietet AMD noch nicht offiziell die Paketierung unter openSUSE 11.2 bzw. openSUSE 11.3 (RC1, RC2) für XOrg 7.5 an. Daher werde ich diesen Umstand mit einem Patch nachhelfen, um doch das Package zu erstellen. Neu ist, dass ich das Patch auch für openSUSE 11.3 (RC1, RC2) angepasst habe und man kann jetzt unter openSUSE 11.3 ebenfalls fglrx-Package erstellen.

Unter KDE 4.4.x funktioniert die Funktionsprüfung des openGL-Interface über den fglrx-Treiber wieder. Die Option findet man unter Systemeinstellungen -> Arbeitsfläche -> Arbeitsflächen-Effekte -> Erweitert -> Funktionsprüfung deaktivieren (den Haken wieder herausnehmen).

Jetzt kommen wir zu den schlechten Nachrichten, was sich leider nicht vermeiden lässt. Beim X-Server hat sich unter der Haube einiges geändert, so dass die automatische Konfiguration teilweise nicht mehr funktioniert und mit einer Konfigurationsdatei mittels

aticonfig --initial

nachgeholfen werden muss. Danach kann man wie gewohnt über die GUI amdcccle die Konfiguration der Grafikkarte bzw. Monitors einstellen. Zudem muss ich mit Bedauern feststellen, dass die Erstellung einer Konfigurationsdatei mittels

X -configure

auch nicht funktioniert.

Der Vollbildmodus mit einer anderen Auflösung (z.B. 1024×786) gegenüber der Desktopauflösung (z.B. 1680×1050) bei aktiviertem Compositing funktioniert immer noch nicht richtig. Hier muss man nach wie vor das Compositing mittels ALT+SHIFT+F12 vorübergehend deaktivieren, bevor man z.B. ein openGL-Spiel im Vollbildmodus laufen lassen möchte.

Bitte beachtet folgendes: Diese Installation ist nur für Fortgeschrittene, Entwickler oder zu Testzwecken gedacht. In der Regel wird XOrg 7.5 für openSUSE 11.2 noch nicht unterstützt, sondern erst mit openSUSE 11.3.

Hinweis zum SaX (SuSE advanced X Window System): In openSUSE 11.3 wird SaX nicht mehr geben. Der Grund ist, dass XOrg und weitere Komponente eine statische Konfiguration in /etc/X11/xorg.conf zum Teil unmöglich macht bzw. der Aufwand für die Implementierung zu groß ist. Mittlerweile kann XOrg 7.5 vollautomatisch die Eingabe- und Ausgabe-Geräte erkennen und im laufendem Betrieb einbinden. Moderne X-Window-Systeme wie Gnome oder KDE liefern bereits ein Bildschirmkonfigurationstool und weitere relevante Konfigurationstools aus. Novell hat sich daher entschieden SaX sterben zu lassen. Siehe auch http://lists.opensuse.org/opensuse-factory/2009-12/msg00017.html

[UPDATE 19.06.2010]
Dank eines aufmerksamen Leser (Johnny) hat er mich auf ein Fehler beim Bau eines fglrx-Treiber in openSUSE 11.3 (RC1, RC2) aufmerksam gemacht. Ich installierte openSUSE 11.3 (RC1, RC2) auf meinem Computer. Der Bau einer RPM verlief ohne Probleme. Jedoch der Bau eines fglrx-Kernelmodul schlug fehl. Das Problem lag darin, dass openSUSE 11.3 RC1 bzw. RC2 eine neue Kernel-Version 2.6.34 mitbringt, der von AMD/ATI noch nicht angepasst wurde. Ich habe dieses Problem mit einem kleinen Patch behoben, da offensichtlich ein

#include <linux/slab.h>

in kcl_wait.c fehlte. Nachdem ich den Patch nochmal getestet hatte und einwandfrei funktioniert, gebe ich ihn nun hiermit frei. Have a lot of fun.
[/UPDATE 19.06.2010]

[UPDATE 05.07.2010]
Soeben habe ich das Skript makerpm-ati-10.6-beta.sh für openSUSE 11.3 hochgeladen.

Downloads:

• Skript: makerpm-ati-10.6-beta.sh
• SHA1: makerpm-ati-10.6-beta.sh.sha1

Eine Anleitung zur Bedienung des Skriptes befindet sich hier:
http://www.sebastian-siebert.de/2010/06/17/opensuse-11-2-proprietaeren-grafik-treiber-ati-catalyst-10-6-als-rpm-installieren/
[/UPDATE 05.07.2010]

[UPDATE 18.07.2010]
Aufgrund zahlreicher Hinweise habe ich das Skript angepasst, um mögliche Probleme zu beheben.

Manche User haben Probleme mit dem Kernel-Mode-Setting (KMS). Man kann den Modus wie folgt abschalten:

./makerpm-ati-10.6-beta2.sh -kms no

Es wird eine neue Initial Ramdisk (initrd) ohne KMS erstellt.
Alternativ kann man auch einen Bootparameter setzen: nomodeset

Falls unter Firefox oder Thunderbird schwarze Flächen erscheinen, dann liegt es in erster Linie an den neuen 2D-Treiber. Um den alten 2D-Treiber zu verwenden, führt man folgende Kommando aus:

./makerpm-ati-10.6-beta2.sh -old2ddriver yes

Downloads:

• Skript: makerpm-ati-10.6-beta2.sh
• SHA1: makerpm-ati-10.6-beta2.sh.sha1

[/UPDATE 18.07.2010]

Installationsanleitung

1. ATI-Installer 10.6 herunterladen:
http://support.amd.com/us/gpudownload/Pages/index.aspx

2. Patch für den ATI-Installer 10.6 herunterladen:
http://www.sebastian-siebert.de/downloads/ati-10.6-xorg-7.5.patch

3. Nur openSUSE 11.3: Patch für den fglrx 8.741 herunterladen:
http://www.sebastian-siebert.de/downloads/ati-10.6-fixed-missing-include.patch

4. ATI-Installer entpacken:

./ati-driver-installer-10-6-x86.x86_64.run --extract ati-10.6

5. In den ATI-Verzeichnis wechseln:

cd ati-10.6

6. Patch einspielen (Der Patch muss im ATI-Verzeichnis vorhanden sein):

patch -p1 <ati-10.6-xorg-7.5.patch

7. Nur openSUSE 11.3: Patch für den fglrx einspielen (Der Patch muss im ATI-Verzeichnis vorhanden sein):

patch -p1 <ati-10.6-fixed-missing-include.patch

8a. RPM bauen (32bit) unter openSUSE 11.2

./ati-installer.sh 8.741 --buildpkg SuSE/SUSE112-IA32-unofficial-Xorg75

8b. RPM bauen (64bit) unter openSUSE 11.2

./ati-installer.sh 8.741 --buildpkg SuSE/SUSE112-AMD64-unofficial-Xorg75

8c. RPM bauen (32bit) unter openSUSE 11.3

./ati-installer.sh 8.741 --buildpkg SuSE/SUSE113-IA32-unofficial-Xorg75

8d. RPM bauen (64bit) unter openSUSE 11.3

./ati-installer.sh 8.741 --buildpkg SuSE/SUSE113-AMD64-unofficial-Xorg75

9a. RPM installieren:

rpm -ihv fglrx*7_5_0*8.741*.rpm

9b. RPM updaten:

rpm -Uhv fglrx*7_5_0*8.741*.rpm

10. Nur openSUSE 11.2: Das Repository mit dem XOrg 7.5 in YaST hinzufügen:
http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_11.2/

11. Nur openSUSE 11.2: In YaST alle XOrg-Pakete einschließlich Mesa, MesaGLw, libXi6, libdrm, libpciaccess0, libpixman und ggfs. sax2-tools vom o.g. Repo aktualisieren

12. Computer neustarten und freuen.

Kommentare und Erfahrungsberichte sind immer willkommen.

Es gibt 2 Wege den Bau des RPM-Packages durchzuführen.

1. das RPM mit dem Skript makerpm-ati-10.6.sh bauen (empfohlen)
2. das RPM manuell bauen (für Fortgeschrittene)

Der Vorteil zu Punkt 1: man muss sich nicht um die nötigen Packages für den Bau kümmern und man spart sich die Tipparbeit, die Zeit und die Nerven.

Wichtig: Bevor ihr irgendwelche Fragen an mich richtet, lest euch bitte sorgfältig diesen Artikel durch und achtet auch auf eure Eingaben in der Konsole wegen mögliche Tippfehler. Falls es Probleme geben sollte, schaut bitte unter Troubleshooting nach, ob euer Problem dort schon dokumentiert wurde.

Alle genannten Schritte müssen in der Konsole im Root-Modus ausgeführt werden. Die Installation des RPM-Package “fglrx” kann im Runlevel 3 oder auch im Runlevel 5 durchgeführt werden. Danach ist ein Neustart des Computers auf jeden Fall erforderlich.

Vorhandene fremde fglrx-Treiber sind auf jedenfall zu deinstallieren, sonst kommt es zu Konflikten bei der Installation dieses selbstgebauten RPM-Package.

Mit fremde fglrx-Treiber sind z.B. folgende gemeint:
- ati-fglrxG01-kmp-{default,desktop,pae,…}
- ati-fglrxG02-kmp-{default,desktop,pae,…}
- x11-video-fglrxG02

Vorhandene fremde fglrx-Treiber auflisten lassen:

rpm -qa | grep -E 'fglrxG01|fglrxG02'

Wenn hier von RPM eine Ausgabe erscheint, müssen diese Package deinstalliert werden:

zypper rm (packagename)

Alternativ kann man auch in YaST nach fglrxG01 bzw. fglrxG02 suchen und entfernen lassen.

RPM mit dem Skript bauen

Das Skript makerpm-ati-10.6.sh ist sehr mächtig, robust und läuft vollautomatisch. Der ATI-Installer wird automatisch heruntergeladen, falls er nicht schon im Verzeichnis liegt. Zudem wird geprüft, ob die Grafikkarte vom Treiber unterstützt wird. Auf dem System werden nach den nötigen Entwicklungspaketen geprüft und ggfs. installiert. Auf Wunsch wird nach dem Bau des RPM-Packages der fglrx-Treiber installiert.

Folgende Argumente können dem Skript übergeben werden:
-b – Nur das RPM-Package bauen (Standard)
-c <type> – Nur X-Server konfigurieren. Monitor-Typ: single = 1 Monitor, dual = 2 Monitore (Wichtig: Nur ausführen, wenn es Probleme mit der Standardkonfiguration des X-Servers auftreten)
-d – Nur den ATI-Installer downloaden
-i – Das RPM-Package bauen und installieren bzw. updaten
-ux – Nur den gepatchten X-Server installieren. Verbessert die Zusammenarbeit mit dem fglrx-Treiber. (dringend zu empfehlen)
-h – Die Hilfe anzeigen lassen
-V – Version des Skript anzeigen

Downloads:

• Skript: makerpm-ati-10.6.sh
• SHA1: makerpm-ati-10.6.sh.sha1

Empfohlene Vorgehensweise:

Optional: Das System im Runlevel 3 starten oder wechseln:
Beim Booten: Im Bootmenü den Eintrag von openSUSE 11.2 selektieren und auf der Tastatur die Zahl “3″ und Enter drücken und als “root” einloggen
Im laufenden System: STRG+ALT+F1 drücken und sich als “root” einloggen. Danach mit folgendem Befehl in den Runlevel 3 wechseln:

init 3

1. Das Skript herunterladen:

wget http://www.sebastian-siebert.de/downloads/makerpm-ati-10.6.sh

2. Die Prüfsummendatei herunterladen:

wget http://www.sebastian-siebert.de/downloads/makerpm-ati-10.6.sh.sha1

3. Die Prüfsummendatei gegen das Skript prüfen:

sha1sum -c makerpm-ati-10.6.sh.sha1

Idealerweise sollte folgende Ausgabe erscheinen, andernfalls stimmt etwas mit dem heruntergeladenen Skript nicht:

makerpm-ati-10.6.sh: OK

4. Die Rechte des Skriptes ändern und ausführbar machen:

chown root:root makerpm-ati-10.6.sh && chmod 744 makerpm-ati-10.6.sh

5. Das Skript mit dem Argument -ux ausführen. Es wird ein gepatchter X-Server installiert. (Diese Vorgehensweise wird empfohlen. Weitere Informationen findet ihr hier: X-Server und ATI Catalyst Treiber (fglrx) zur Zusammenarbeit bewegen)

./makerpm-ati-10.6.sh -ux

6. Das Skript mit dem Argument -i ausführen. Das RPM-Package wird im Anschluß automatisch installiert.

./makerpm-ati-10.6.sh -i

7. Den Rechner neustarten:

reboot

Troubleshooting (RPM mit dem Skript bauen):

• Sollte man trotz gepatchten X-Server nach dem Booten in der Konsole landen, dann kann es evtl. an einer fehlerhaften Konfiguration des X-Servers liegen. In diesem Fall bitte als “root” in die Konsole einloggen und das Skript mit folgendem Parameter ausführen lassen.

  Vorher noch in den Runlevel 3 wechseln:

  init 3

  Bei einem Monitor (Single-Modus):

  ./makerpm-ati-10.6.sh -c single

  Bei zwei Monitore (Dual-Modus):

  ./makerpm-ati-10.6.sh -c dual

  Danach den Rechner neustarten.

• Falls die Arbeitsflächen-Effekte (Compositing) in KDE 4.4.3 nicht mehr aktiviert sind, weil vermutlich die Erkennung der OpenGL-Schnittstelle von AMD/ATI Catalyst 10.6 fehlschlägt. Hierzu gibt es eine einfache Lösung:
  1. Im KDE-Menü auf Systemeinstellungen klicken
  2. Unter Allgemein / Erscheinungsbild & Verhalten auf Arbeitsfläche klicken
  3. In Arbeitsflächen-Effekte einrichten auf den Tab Erweitert klicken
  4. Die Checkbox Funktionsprüfungen deaktivieren aktivieren
  5. Im Tab Allgemein prüfen, ob Compositing aktiviert ist. Falls nicht, bitte aktivieren.
  6. Abschließend auf Anwenden klicken

  Jetzt sollen die Effekte in KDE wieder funktionieren. Die 3D-Anwendungen bzw. 3D-Spiele sind von diesem Problem nicht betroffen.

RPM manuell bauen

Das ist der etwas schwierigere Teil. Aber es ist nicht unmöglich.

Für den Bau des RPM-Packages werden folgende Entwicklungswerkzeuge bzw. -packages benötigt

• gcc
• make
• patch
• linux-kernel-headers
• kernel-source
• kernel-{default,desktop,pae,rt,vanilla,xen}-devel

Beim Kernel-Entwicklungspackage ist zu beachten, dass man die richtige installiert hat. Welchen Kernel zur Zeit auf dem System läuft, kann man in der Konsole abfragen:

uname -r

Bei mir ergibt beispielsweise diese Ausgabe:

2.6.31.12-0.2-default

Also muss im o.g. Fall der Kernel-Entwicklungspackage kernel-default-devel installiert sein.

Folgende Schritte werden auf einem 32bit openSUSE-System durchgeführt:
(64bit openSUSE-System weiter unten)

1. Den gepatchten X-Server installieren:
Anleitung: http://www.sebastian-siebert.de/2010/03/24/opensuse-11-2-x-server-und-ati-catalyst-display-treiber-fglrx-zur-zusammenarbeit-bewegen/

2. Den Installer des proprietären Treiber von ATI herunterladen:
http://support.amd.com/us/gpudownload/Pages/index.aspx

Optional: Das System im Runlevel 3 starten und als “root” einloggen oder per init 3 wechseln.

3. Den Bau des RPM-Packages anstoßen:

sh ./ati-driver-installer-10-6-x86.x86_64.run --buildpkg SuSE/SUSE112-IA32

4a. Das RPM-Package installieren (Neuinstallation):

rpm -ihv fglrx_7_4_0_SUSE112-8.741*.rpm

4b. Das RPM-Package installieren (Update):

rpm -Uhv fglrx_7_4_0_SUSE112-8.741*.rpm

5. Den Rechner neustarten:

reboot

Folgende Schritte werden auf einem 64bit openSUSE-System durchgeführt:

1. Den gepatchten X-Server installieren:
Anleitung: http://www.sebastian-siebert.de/2010/03/24/opensuse-11-2-x-server-und-ati-catalyst-display-treiber-fglrx-zur-zusammenarbeit-bewegen/

2. Den Installer des proprietären Treiber von ATI herunterladen:
http://support.amd.com/us/gpudownload/Pages/index.aspx

Optional: Das System im Runlevel 3 starten und als “root” einloggen oder per init 3 wechseln.

3. Den Bau des RPM-Packages anstoßen:

sh ./ati-driver-installer-10-6-x86.x86_64.run --buildpkg SuSE/SUSE112-AMD64

4a. Das RPM-Package installieren (Neuinstallation):

rpm -ihv fglrx64_7_4_0_SUSE112-8.741*.rpm

4b. Das RPM-Package installieren (Update):

rpm -Uhv fglrx64_7_4_0_SUSE112-8.741*.rpm

5. Den Rechner neustarten:

reboot

Troubleshooting (RPM manuell bauen):

• Sollte man trotz gepatchten X-Server nach dem Booten in der Konsole landen, dann kann es evtl. an einer fehlerhaften Konfiguration des X-Servers liegen. In diesem Fall bitte als “root” in die Konsole einloggen und folgende Schritte durchführen.

  1. X-Server-Konfiguration verschieben, falls vorhanden:

  mv /etc/X11/xorg.conf /etc/X11/xorg.conf.backup

  2. Von SaX2 eine neue Konfigurationsdatei erzeugen lassen:

  sax2 -a

  oder alternativ mit aticonfig (Das Tool aticonfig kann mittlerweile auch eine X-Server-Konfiguration from Scratch erzeugen, jedoch speziell auf den fglrx-Treiber zugeschnitten. Die restliche Hardware wird vom X-Server automatisch erkannt und geladen. Dies sollte in Zukunft vorgezogen werden, falls die Autoerkennung für den fglrx-Treiber oder X -configure nicht funktioniert):

  Bei einem Monitor (Single-Modus):

  aticonfig --initial

  oder bei zwei Monitore (Dual-Modus):

  aticonfig --initial=dual-head

  Hinweis: Falls man bereits in diesem Schritt das Tool aticonfig für die Erzeugung einer X-Server-Konfiguration verwendet hat, so entfallen die nachfolgenden Schritte 3, 3a, 3b.

  3. Die Konfigurationsdatei von aticonfig für die Nutzung des fglrx-Treibers modifizieren lassen.

  3a. Bei einem Monitor (Single-Modus):

  aticonfig --initial --input=/etc/X11/xorg.conf

  3b. Bei zwei Monitore (Dual-Modus):

  aticonfig --initial=dual-head --input=/etc/X11/xorg.conf

• Falls die Arbeitsflächen-Effekte (Compositing) in KDE 4.4.3 nicht mehr aktiviert sind, weil vermutlich die Erkennung der OpenGL-Schnittstelle von AMD/ATI Catalyst 10.6 fehlschlägt. Hierzu gibt es eine einfache Lösung:
  1. Im KDE-Menü auf Systemeinstellungen klicken
  2. Unter Allgemein / Erscheinungsbild & Verhalten auf Arbeitsfläche klicken
  3. In Arbeitsflächen-Effekte einrichten auf den Tab Erweitert klicken
  4. Die Checkbox Funktionsprüfungen deaktivieren aktivieren
  5. Im Tab Allgemein prüfen, ob Compositing aktiviert ist. Falls nicht, bitte aktivieren.
  6. Abschließend auf Anwenden klicken

  Jetzt sollen die Effekte in KDE wieder funktionieren. Die 3D-Anwendungen bzw. 3D-Spiele sind von diesem Problem nicht betroffen.

Feedbacks sind wie immer willkommen.

Diese Anleitung wurde geschrieben, um den XOrg 7.5 (X-Server 1.8.0) und den Grafiktreiber ATI Catalyst 10.5 (fglrx 8.732) zum Laufen zu bringen.

Bitte beachtet folgendes: Diese Installation ist nur für Fortgeschrittene, Entwickler oder zu Testzwecken gedacht. In der Regel wird XOrg 7.5 für openSUSE 11.2 noch nicht unterstützt, sondern erst mit openSUSE 11.3. Sobald openSUSE 11.3 veröffentlicht wurde, werde ich ggfs. einen gepatchten X-Server (nur die interne Versionsnummer von 1.8.0 auf 1.7.5.0 wurde herunter gepatcht) zur Verfügung stellen (Falls AMD da nicht schneller ist als ich).

Hinweis zum SaX (SuSE advanced X Window System): In openSUSE 11.3 wird SaX nicht mehr geben. Der Grund ist, dass XOrg und weitere Komponente eine statische Konfiguration in /etc/X11/xorg.conf zum Teil unmöglich macht bzw. der Aufwand für die Implementierung zu groß ist. Mittlerweile kann XOrg 7.5 vollautomatisch die Eingabe- und Ausgabe-Geräte erkennen und im laufendem Betrieb einbinden. Moderne X-Window-Systeme wie Gnome oder KDE liefern bereits ein Bildschirmkonfigurationstool und weitere relevante Konfigurationstools aus. Novell hat sich daher entschieden SaX sterben zu lassen. Siehe auch http://lists.opensuse.org/opensuse-factory/2009-12/msg00017.html

Die neue XOrg 7.5 (X-Server 1.8.0) wurde wie auch schon in XOrg 7.4 (X-Server 1.6.5) mit einem Patch für die interne Minimalkonfiguration der fglrx-Section bestückt. Jedoch war der Patch wirkungslos, weil der fglrx-Treiber leider immer noch einen Bug hat und nicht im laufendem Betrieb von 8bit/16bit auf 24bit aufschalten kann. Somit kehrte man unweigerlich wieder in die Konsole zurück. Erst mit einem zusätzlichen Patch, den ich entwickelt und eingeliefert habe, wird eine weitere Option zur Minimalkonfiguration die Farbtiefe direkt festgelegt. Somit wird eine automatische Konfiguration möglich und man kann mit dem grafischen Tool “ATI Catalyst Control Center” amdcccle weitere Einstellungen für die Grafikkarte vornehmen.

Es ist nach wie vor möglich eine Konfigurationsdatei ala /etc/X11/xorg.conf mittels

X -configure

zu erzeugen. Alternativ kann man auch mit

aticonfig --initial

eine o.g. Konfigurationsdatei für den fglrx-Treiber erzeugen.

Installationsanleitung

1. ATI-Installer 10.5 herunterladen:
http://support.amd.com/us/gpudownload/Pages/index.aspx

2. Patch für den ATI-Installer 10.5 herunterladen:
http://www.sebastian-siebert.de/downloads/ati-10.5-xorg-7.5.patch

3. ATI-Installer entpacken:

./ati-driver-installer-10-5-x86.x86_64.run --extract ati-10.5

4. In den ATI-Verzeichnis wechseln:

cd ati-10.5

5. Patch einspielen (Der Patch muss im ATI-Verzeichnis vorhanden sein):

patch -p1 <ati-10.5-xorg-7.5.patch

6a. RPM bauen (32bit)

./ati-installer.sh 8.732 --buildpkg SuSE/SUSE112-IA32-unofficial-XOrg75

6b. RPM bauen (64bit)

./ati-installer.sh 8.732 --buildpkg SuSE/SUSE112-AMD64-unofficial-XOrg75

7a. RPM installieren:

rpm -ihv fglrx*7_5_0*8.732*.rpm

7b. RPM updaten:

rpm -Uhv fglrx*7_5_0*8.732*.rpm

8. Das Repository (mit der gepatchten X-Server-Version) in YaST hinzufügen:
http://download.opensuse.org/repositories/home:/Freespacer:/X11:/XOrg75/openSUSE_11.2/

9. In YaST alle XOrg-Pakete einschließlich Mesa, MesaGLw, libXi6, libdrm, libpciaccess0, libpixman und ggfs. sax2-tools vom o.g. Repo aktualisieren

10. Computer neustarten und freuen.

Kommentare und Erfahrungsberichte sind immer willkommen.

Es gibt 2 Wege den Bau des RPM-Packages durchzuführen.

1. das RPM mit dem Skript makerpm-ati-10.5.sh bauen (empfohlen)
2. das RPM manuell bauen (für Fortgeschrittene)

Der Vorteil zu Punkt 1: man muss sich nicht um die nötigen Packages für den Bau kümmern und man spart sich die Tipparbeit, die Zeit und die Nerven.

Wichtig: Bevor ihr irgendwelche Fragen an mich richtet, lest euch bitte sorgfältig diesen Artikel durch und achtet auch auf eure Eingaben in der Konsole wegen mögliche Tippfehler. Falls es Probleme geben sollte, schaut bitte unter Troubleshooting nach, ob euer Problem dort schon dokumentiert wurde.

Alle genannten Schritte müssen in der Konsole im Root-Modus ausgeführt werden. Die Installation des RPM-Package “fglrx” kann im Runlevel 3 oder auch im Runlevel 5 durchgeführt werden. Danach ist ein Neustart des Computers auf jeden Fall erforderlich.

Vorhandene fremde fglrx-Treiber sind auf jedenfall zu deinstallieren, sonst kommt es zu Konflikten bei der Installation dieses selbstgebauten RPM-Package.

Mit fremde fglrx-Treiber sind z.B. folgende gemeint:
- ati-fglrxG01-kmp-{default,desktop,pae,…}
- ati-fglrxG02-kmp-{default,desktop,pae,…}
- x11-video-fglrxG02

Vorhandene fremde fglrx-Treiber auflisten lassen:

rpm -qa | grep -E 'fglrxG01|fglrxG02'

Wenn hier von RPM eine Ausgabe erscheint, müssen diese Package deinstalliert werden:

zypper rm (packagename)

Alternativ kann man auch in YaST nach fglrxG01 bzw. fglrxG02 suchen und entfernen lassen.

RPM mit dem Skript bauen

Das Skript makerpm-ati-10.5.sh ist sehr mächtig, robust und läuft vollautomatisch. Der ATI-Installer wird automatisch heruntergeladen, falls er nicht schon im Verzeichnis liegt. Zudem wird geprüft, ob die Grafikkarte vom Treiber unterstützt wird. Auf dem System werden nach den nötigen Entwicklungspaketen geprüft und ggfs. installiert. Auf Wunsch wird nach dem Bau des RPM-Packages der fglrx-Treiber installiert.

Folgende Argumente können dem Skript übergeben werden:
-b – Nur das RPM-Package bauen (Standard)
-c <type> – Nur X-Server konfigurieren. Monitor-Typ: single = 1 Monitor, dual = 2 Monitore (Wichtig: Nur ausführen, wenn es Probleme mit der Standardkonfiguration des X-Servers auftreten)
-d – Nur den ATI-Installer downloaden
-i – Das RPM-Package bauen und installieren bzw. updaten
-ux – Nur den gepatchten X-Server installieren. Verbessert die Zusammenarbeit mit dem fglrx-Treiber. (dringend zu empfehlen)
-h – Die Hilfe anzeigen lassen
-V – Version des Skript anzeigen

Downloads:

• Skript: makerpm-ati-10.5.sh
• SHA1: makerpm-ati-10.5.sh.sha1

Empfohlene Vorgehensweise:

Optional: Das System im Runlevel 3 starten oder wechseln:
Beim Booten: Im Bootmenü den Eintrag von openSUSE 11.2 selektieren und auf der Tastatur die Zahl “3″ und Enter drücken und als “root” einloggen
Im laufenden System: STRG+ALT+F1 drücken und sich als “root” einloggen. Danach mit folgendem Befehl in den Runlevel 3 wechseln:

init 3

1. Das Skript herunterladen:

wget http://www.sebastian-siebert.de/downloads/makerpm-ati-10.5.sh

2. Die Prüfsummendatei herunterladen:

wget http://www.sebastian-siebert.de/downloads/makerpm-ati-10.5.sh.sha1

3. Die Prüfsummendatei gegen das Skript prüfen:

sha1sum -c makerpm-ati-10.5.sh.sha1

Idealerweise sollte folgende Ausgabe erscheinen, andernfalls stimmt etwas mit dem heruntergeladenen Skript nicht:

makerpm-ati-10.5.sh: OK

4. Die Rechte des Skriptes ändern und ausführbar machen:

chown root:root makerpm-ati-10.5.sh && chmod 744 makerpm-ati-10.5.sh

5. Das Skript mit dem Argument -ux ausführen. Es wird ein gepatchter X-Server installiert. (Diese Vorgehensweise wird empfohlen. Weitere Informationen findet ihr hier: X-Server und ATI Catalyst Treiber (fglrx) zur Zusammenarbeit bewegen)

./makerpm-ati-10.5.sh -ux

6. Das Skript mit dem Argument -i ausführen. Das RPM-Package wird im Anschluß automatisch installiert.

./makerpm-ati-10.5.sh -i

7. Den Rechner neustarten:

reboot

Troubleshooting (RPM mit dem Skript bauen):

• Sollte man trotz gepatchten X-Server nach dem Booten in der Konsole landen, dann kann es evtl. an einer fehlerhaften Konfiguration des X-Servers liegen. In diesem Fall bitte als “root” in die Konsole einloggen und das Skript mit folgendem Parameter ausführen lassen.

  Vorher noch in den Runlevel 3 wechseln:

  init 3

  Bei einem Monitor (Single-Modus):

  ./makerpm-ati-10.5.sh -c single

  Bei zwei Monitore (Dual-Modus):

  ./makerpm-ati-10.5.sh -c dual

  Danach den Rechner neustarten.

• Falls die Arbeitsflächen-Effekte (Compositing) in KDE 4.4.3 nicht mehr aktiviert sind, weil vermutlich die Erkennung der OpenGL-Schnittstelle von AMD/ATI Catalyst 10.5 fehlschlägt. Hierzu gibt es eine einfache Lösung:
  1. Im KDE-Menü auf Systemeinstellungen klicken
  2. Unter Allgemein / Erscheinungsbild & Verhalten auf Arbeitsfläche klicken
  3. In Arbeitsflächen-Effekte einrichten auf den Tab Erweitert klicken
  4. Die Checkbox Funktionsprüfungen deaktivieren aktivieren
  5. Im Tab Allgemein prüfen, ob Compositing aktiviert ist. Falls nicht, bitte aktivieren.
  6. Abschließend auf Anwenden klicken

  Jetzt sollen die Effekte in KDE wieder funktionieren. Die 3D-Anwendungen bzw. 3D-Spiele sind von diesem Problem nicht betroffen.

RPM manuell bauen

Das ist der etwas schwierigere Teil. Aber es ist nicht unmöglich.

Für den Bau des RPM-Packages werden folgende Entwicklungswerkzeuge bzw. -packages benötigt

• gcc
• make
• patch
• linux-kernel-headers
• kernel-source
• kernel-{default,desktop,pae,rt,vanilla,xen}-devel

Beim Kernel-Entwicklungspackage ist zu beachten, dass man die richtige installiert hat. Welchen Kernel zur Zeit auf dem System läuft, kann man in der Konsole abfragen:

uname -r

Bei mir ergibt beispielsweise diese Ausgabe:

2.6.31.12-0.2-default

Also muss im o.g. Fall der Kernel-Entwicklungspackage kernel-default-devel installiert sein.

Folgende Schritte werden auf einem 32bit openSUSE-System durchgeführt:
(64bit openSUSE-System weiter unten)

1. Den gepatchten X-Server installieren:
Anleitung: http://www.sebastian-siebert.de/2010/03/24/opensuse-11-2-x-server-und-ati-catalyst-display-treiber-fglrx-zur-zusammenarbeit-bewegen/

2. Den Installer des proprietären Treiber von ATI herunterladen:
http://support.amd.com/us/gpudownload/Pages/index.aspx

Optional: Das System im Runlevel 3 starten und als “root” einloggen oder per init 3 wechseln.

3. Den Bau des RPM-Packages anstoßen:

sh ./ati-driver-installer-10-5-x86.x86_64.run --buildpkg SuSE/SUSE112-IA32

4a. Das RPM-Package installieren (Neuinstallation):

rpm -ihv fglrx_7_4_0_SUSE112-8.732*.rpm

4b. Das RPM-Package installieren (Update):

rpm -Uhv fglrx_7_4_0_SUSE112-8.732*.rpm

5. Den Rechner neustarten:

reboot

Folgende Schritte werden auf einem 64bit openSUSE-System durchgeführt:

1. Den gepatchten X-Server installieren:
Anleitung: http://www.sebastian-siebert.de/2010/03/24/opensuse-11-2-x-server-und-ati-catalyst-display-treiber-fglrx-zur-zusammenarbeit-bewegen/

2. Den Installer des proprietären Treiber von ATI herunterladen:
http://support.amd.com/us/gpudownload/Pages/index.aspx

Optional: Das System im Runlevel 3 starten und als “root” einloggen oder per init 3 wechseln.

3. Den Bau des RPM-Packages anstoßen:

sh ./ati-driver-installer-10-5-x86.x86_64.run --buildpkg SuSE/SUSE112-AMD64

4a. Das RPM-Package installieren (Neuinstallation):

rpm -ihv fglrx64_7_4_0_SUSE112-8.732*.rpm

4b. Das RPM-Package installieren (Update):

rpm -Uhv fglrx64_7_4_0_SUSE112-8.732*.rpm

5. Den Rechner neustarten:

reboot

Troubleshooting (RPM manuell bauen):

• Sollte man trotz gepatchten X-Server nach dem Booten in der Konsole landen, dann kann es evtl. an einer fehlerhaften Konfiguration des X-Servers liegen. In diesem Fall bitte als “root” in die Konsole einloggen und folgende Schritte durchführen.

  1. X-Server-Konfiguration verschieben, falls vorhanden:

  mv /etc/X11/xorg.conf /etc/X11/xorg.conf.backup

  2. Von SaX2 eine neue Konfigurationsdatei erzeugen lassen:

  sax2 -a

  oder alternativ mit aticonfig (Das Tool aticonfig kann mittlerweile auch eine X-Server-Konfiguration from Scratch erzeugen, jedoch speziell auf den fglrx-Treiber zugeschnitten. Die restliche Hardware wird vom X-Server automatisch erkannt und geladen. Dies sollte in Zukunft vorgezogen werden, falls die Autoerkennung für den fglrx-Treiber oder X -configure nicht funktioniert):

  Bei einem Monitor (Single-Modus):

  aticonfig --initial

  oder bei zwei Monitore (Dual-Modus):

  aticonfig --initial=dual-head

  Hinweis: Falls man bereits in diesem Schritt das Tool aticonfig für die Erzeugung einer X-Server-Konfiguration verwendet hat, so entfallen die nachfolgenden Schritte 3, 3a, 3b.

  3. Die Konfigurationsdatei von aticonfig für die Nutzung des fglrx-Treibers modifizieren lassen.

  3a. Bei einem Monitor (Single-Modus):

  aticonfig --initial --input=/etc/X11/xorg.conf

  3b. Bei zwei Monitore (Dual-Modus):

  aticonfig --initial=dual-head --input=/etc/X11/xorg.conf

• Falls die Arbeitsflächen-Effekte (Compositing) in KDE 4.4.3 nicht mehr aktiviert sind, weil vermutlich die Erkennung der OpenGL-Schnittstelle von AMD/ATI Catalyst 10.5 fehlschlägt. Hierzu gibt es eine einfache Lösung:
  1. Im KDE-Menü auf Systemeinstellungen klicken
  2. Unter Allgemein / Erscheinungsbild & Verhalten auf Arbeitsfläche klicken
  3. In Arbeitsflächen-Effekte einrichten auf den Tab Erweitert klicken
  4. Die Checkbox Funktionsprüfungen deaktivieren aktivieren
  5. Im Tab Allgemein prüfen, ob Compositing aktiviert ist. Falls nicht, bitte aktivieren.
  6. Abschließend auf Anwenden klicken

  Jetzt sollen die Effekte in KDE wieder funktionieren. Die 3D-Anwendungen bzw. 3D-Spiele sind von diesem Problem nicht betroffen.

Feedbacks sind wie immer willkommen.

Zuallererst extrahierte ich den ATI-Installer 10.4 und spendierte ihm zwei weitere SPEC-Dateien (32bit und 64bit) zur Installation eines inoffiziellen XOrg-7.5-Treibers für openSUSE 11.2. Danach ließ ich vom Installer ein RPM-Paket bauen und installierte es im Anschluss. Die Installation funktionierte problemlos.

Der erste Versuch:
Ich installierte die neuen XOrg-Pakete aus dem bekannten openSUSE-Repo http://download.opensuse.org/repositories/X11:/XOrg/ und startete den Computer neu. Der X-Server quittierte seinen Dienst. In der Logdatei /var/log/Xorg.0.log fand ich folgenden Eintrag:

[atiddxSetup] X version mismatch - detected X.org 7.1.0.0, required X.org 7.5.1.0.

Öhm, detected XOrg 7.1?! Ich fing heftig an zu lachen und fand mich später auf dem Boden wieder. Nach etwa 10 Minuten konnte ich mich wieder beruhigen. Die Abfrage der Versionsnummer vom X-Server scheint bei AMD noch immer ein Problem (von vielen) zu sein. Wie dem auch sei. Ich dachte über mögliche Lösungen nach und hatte zum Schluss folgende Optionen:

1. Den fglrx-Treiber auf binärer Ebene patchen. (Pfui!)
2. Den X-Server selber patchen (Bäh!)

Die 1. Option hatte ich ganz schnell begraben. Denn das wäre wirklich eine Sisyphusarbeit gewesen. Die 2. Option war jedenfalls machbar, aber für mich auch nicht wirklich die ideale Lösung. Es könnten auch andere Programme oder Treiber die X-Server-Version abfragen. Wohl eher eine Notlösung.

Der 2. Versuch:
Um die besagte Notlösung durchzuführen, duplizierte ich das o.g. XOrg-Repo in meinem Repo und ersetzte die Versionsnummer vom X-Server von 1.8.0 auf 1.7.5.1 mit einem Patch. Da AMD anscheinend die Linux-Distribution Ubuntu 10.04 LTS zum Testen der Beta-Treiber den Vortritt gelassen hatte, schien es dort mit dem X-Server (1.7.5) zu laufen. Nachdem die Pakete in meinem Repo gebaut waren, installierte ich sie. Nach einem Neustart … (Trommelwirbel) … startete auch endlich der X-Server und KDE 4.4.2 mit dem fglrx-Treiber.

Okay, dann ging ich gleich auf die Fehlersuche und wurde leider fündig. Es waren noch einige Fehler vorhanden, die auch in der letzten ATI-Version 10.3 nicht behoben waren.

Hier nur einige Bugs mit dem fglrx-Treiber unter KDE 4.4.2:

• Compositing ließ sich nicht aktivieren. Lösung: Systemeinstellungen → Arbeitsfläche → Arbeitsflächen-Effekte → Tab: Erweitert → Funktionsprüfungen deaktivieren
• Bei aktiviertem Compositing im Zusammenspiel mit 3D-Anwendungen oder 3D-Spiele im Vollbildmodus stürzte Compositing ab (Schwarzer Bildschirm). Man konnte nur noch das Compositing per ALT+SHIFT+F12 beenden und die Sitzung neustarten. Besser ist es hier Compositing vorübergehend mit o.g. Tastenkürzel auszuschalten und dann die 3D-Anwendungen oder 3D-Spiele starten. Ausnahme: Wenn die 3D-Anwendung (bzw. 3D-Spiel) die gleiche Bildschirmauflösung wie KDE verwendet, dann scheint es zu laufen.

Allerdings wurden auch einige schwerwiegende Fehler behoben:

• Bei aktiviertem OpenGL-Bildschirmschoner stürzte das Compositing nicht mehr ab.
• Der X-Server hängt sich nicht mehr auf, wenn man zur TTY1-6 (STRG+ALT+F1 – F6) umgeschaltet hatte und dort in den Runlevel 3 (init 3) und später wieder zurück in den Runlevel 5 (init 5) wechselte.

Installationsanleitung

Bitte beachtet folgendes: Diese Installation ist nur für Fortgeschrittene, Entwickler oder zu Testzwecken gedacht. Ich habe mich entschlossen, dass ich das Skript makerpm-ati-10.4.sh nicht erweitere. In der Regel wird XOrg 7.5 für openSUSE 11.2 noch nicht unterstützt, sondern erst mit openSUSE 11.3. Sobald openSUSE 11.3 veröffentlicht wurde, werde ich ggfs. einen gepatchten X-Server zur Verfügung stellen (Falls AMD da nicht schneller ist als ich).

1. ATI-Installer 10.4 herunterladen:
http://support.amd.com/us/gpudownload/Pages/index.aspx

2. Patch für den ATI-Installer 10.4 herunterladen:
http://www.sebastian-siebert.de/downloads/ati-10.4-xorg-7.5.patch

3. ATI-Installer entpacken:

./ati-driver-installer-10-4-x86.x86_64.run --extract ati-10.4

4. In den ATI-Verzeichnis wechseln:

cd ati-10.4

5. Patch einspielen (Der Patch muss im ATI-Verzeichnis vorhanden sein):

patch -p1 <ati-10.4-xorg-7.5.patch

6a. RPM bauen (32bit)

./ati-installer.sh 8.723 --buildpkg SuSE/SUSE112-IA32-unofficial-Xorg75

6b. RPM bauen (64bit)

./ati-installer.sh 8.723 --buildpkg SuSE/SUSE112-AMD64-unofficial-Xorg75

7a. RPM installieren:

rpm -ihv fglrx*7_5_0*8.723*.rpm

7b. RPM updaten:

rpm -Uhv fglrx*7_5_0*8.723*.rpm

8. Das Repository (mit der gepatchten X-Server-Version) in YaST hinzufügen:
http://download.opensuse.org/repositories/home:/Freespacer:/X11:/XOrg75/openSUSE_11.2/

9. In YaST alle XOrg-Pakete einschließlich Mesa, MesaGLw, libXi6, libdrm, libpciaccess0, libpixman, sax2 vom o.g. Repo aktualisieren

10. Computer neustarten und freuen.

Kommentare und Erfahrungsberichte sind immer willkommen.

Es gibt 2 Wege den Bau des RPM-Packages durchzuführen.

1. das RPM mit dem Skript makerpm-ati-10.4.sh bauen (empfohlen)
2. das RPM manuell bauen (für Fortgeschrittene)

Der Vorteil zu Punkt 1: man muss sich nicht um die nötigen Packages für den Bau kümmern und man spart sich die Tipparbeit, die Zeit und die Nerven.

Wichtig: Bevor ihr irgendwelche Fragen an mich richtet, lest euch bitte sorgfältig diesen Artikel durch und achtet auch auf eure Eingaben in der Konsole wegen mögliche Tippfehler. Falls es Probleme geben sollte, schaut bitte unter Troubleshooting nach, ob euer Problem dort schon dokumentiert wurde.

Alle genannten Schritte müssen in der Konsole im Root-Modus ausgeführt werden. Die Installation des RPM-Package “fglrx” kann im Runlevel 3 oder auch im Runlevel 5 durchgeführt werden. Danach ist ein Neustart des Computers auf jeden Fall erforderlich.

Vorhandene fremde fglrx-Treiber sind auf jedenfall zu deinstallieren, sonst kommt es zu Konflikten bei der Installation dieses selbstgebauten RPM-Package.

Mit fremde fglrx-Treiber sind z.B. folgende gemeint:
- ati-fglrxG01-kmp-{default,desktop,pae,…}
- ati-fglrxG02-kmp-{default,desktop,pae,…}
- x11-video-fglrxG02

Vorhandene fremde fglrx-Treiber auflisten lassen:

rpm -qa | grep -E 'fglrxG01|fglrxG02'

Wenn hier von RPM eine Ausgabe erscheint, müssen diese Package deinstalliert werden:

zypper rm (packagename)

Alternativ kann man auch in YaST nach fglrxG01 bzw. fglrxG02 suchen und entfernen lassen.

RPM mit dem Skript bauen

Das Skript makerpm-ati-10.4.sh ist sehr mächtig, robust und läuft vollautomatisch. Der ATI-Installer wird automatisch heruntergeladen, falls er nicht schon im Verzeichnis liegt. Zudem wird geprüft, ob die Grafikkarte vom Treiber unterstützt wird. Auf dem System werden nach den nötigen Entwicklungspaketen geprüft und ggfs. installiert. Auf Wunsch wird nach dem Bau des RPM-Packages der fglrx-Treiber installiert.

Folgende Argumente können dem Skript übergeben werden:
-b – Nur das RPM-Package bauen (Standard)
-c <type> – Nur X-Server konfigurieren. Monitor-Typ: single = 1 Monitor, dual = 2 Monitore (Wichtig: Nur ausführen, wenn es Probleme mit der Standardkonfiguration des X-Servers auftreten)
-d – Nur den ATI-Installer downloaden
-i – Das RPM-Package bauen und installieren bzw. updaten
-ux – Nur den gepatchten X-Server installieren. Verbessert die Zusammenarbeit mit dem fglrx-Treiber. (dringend zu empfehlen)
-h – Die Hilfe anzeigen lassen
-V – Version des Skript anzeigen

Downloads:

• Skript: makerpm-ati-10.4.sh
• SHA1: makerpm-ati-10.4.sh.sha1

Empfohlene Vorgehensweise:

Optional: Das System im Runlevel 3 starten oder wechseln:
Beim Booten: Im Bootmenü den Eintrag von openSUSE 11.2 selektieren und auf der Tastatur die Zahl “3″ und Enter drücken und als “root” einloggen
Im laufenden System: STRG+ALT+F1 drücken und sich als “root” einloggen. Danach mit folgendem Befehl in den Runlevel 3 wechseln:

init 3

1. Das Skript herunterladen:

wget http://www.sebastian-siebert.de/downloads/makerpm-ati-10.4.sh

2. Die Prüfsummendatei herunterladen:

wget http://www.sebastian-siebert.de/downloads/makerpm-ati-10.4.sh.sha1

3. Die Prüfsummendatei gegen das Skript prüfen:

sha1sum -c makerpm-ati-10.4.sh.sha1

Idealerweise sollte folgende Ausgabe erscheinen, andernfalls stimmt etwas mit dem heruntergeladenen Skript nicht:

makerpm-ati-10.4.sh: OK

4. Die Rechte des Skriptes ändern und ausführbar machen:

chown root:root makerpm-ati-10.4.sh && chmod 744 makerpm-ati-10.4.sh

5. Das Skript mit dem Argument -ux ausführen. Es wird ein gepatchter X-Server installiert. (Diese Vorgehensweise wird empfohlen. Weitere Informationen findet ihr hier: X-Server und ATI Catalyst Treiber (fglrx) zur Zusammenarbeit bewegen)

./makerpm-ati-10.4.sh -ux

6. Das Skript mit dem Argument -i ausführen. Das RPM-Package wird im Anschluß automatisch installiert.

./makerpm-ati-10.4.sh -i

7. Den Rechner neustarten:

reboot

Troubleshooting (RPM mit dem Skript bauen):

• Sollte man trotz gepatchten X-Server nach dem Booten in der Konsole landen, dann kann es evtl. an einer fehlerhaften Konfiguration des X-Servers liegen. In diesem Fall bitte als “root” in die Konsole einloggen und das Skript mit folgendem Parameter ausführen lassen.

  Vorher noch in den Runlevel 3 wechseln:

  init 3

  Bei einem Monitor (Single-Modus):

  ./makerpm-ati-10.4.sh -c single

  Bei zwei Monitore (Dual-Modus):

  ./makerpm-ati-10.4.sh -c dual

  Danach den Rechner neustarten.

• Falls die Arbeitsflächen-Effekte (Compositing) in KDE 4.4.2 nicht mehr aktiviert sind, weil vermutlich die Erkennung der OpenGL-Schnittstelle von AMD/ATI Catalyst 10.4 fehlschlägt (Bugreport #601589). Hierzu gibt es eine einfache Lösung:
  1. Im KDE-Menü auf Systemeinstellungen klicken
  2. Unter Allgemein / Erscheinungsbild & Verhalten auf Arbeitsfläche klicken
  3. In Arbeitsflächen-Effekte einrichten auf den Tab Erweitert klicken
  4. Die Checkbox Funktionsprüfungen deaktivieren aktivieren
  5. Im Tab Allgemein prüfen, ob Compositing aktiviert ist. Falls nicht, bitte aktivieren.
  6. Abschließend auf Anwenden klicken

  Jetzt sollen die Effekte in KDE wieder funktionieren. Die 3D-Anwendungen bzw. 3D-Spiele sind von diesem Problem nicht betroffen.

RPM manuell bauen

Das ist der etwas schwierigere Teil. Aber es ist nicht unmöglich.

Für den Bau des RPM-Packages werden folgende Entwicklungswerkzeuge bzw. -packages benötigt

• gcc
• make
• patch
• linux-kernel-headers
• kernel-source
• kernel-{default,desktop,pae,rt,vanilla,xen}-devel

Beim Kernel-Entwicklungspackage ist zu beachten, dass man die richtige installiert hat. Welchen Kernel zur Zeit auf dem System läuft, kann man in der Konsole abfragen:

uname -r

Bei mir ergibt beispielsweise diese Ausgabe:

2.6.31.12-0.2-default

Also muss im o.g. Fall der Kernel-Entwicklungspackage kernel-default-devel installiert sein.

Folgende Schritte werden auf einem 32bit openSUSE-System durchgeführt:
(64bit openSUSE-System weiter unten)

1. Den gepatchten X-Server installieren:
Anleitung: http://www.sebastian-siebert.de/2010/03/24/opensuse-11-2-x-server-und-ati-catalyst-display-treiber-fglrx-zur-zusammenarbeit-bewegen/

2. Den Installer des proprietären Treiber von ATI herunterladen:
http://support.amd.com/us/gpudownload/Pages/index.aspx

Optional: Das System im Runlevel 3 starten und als “root” einloggen oder per init 3 wechseln.

3. Den Bau des RPM-Packages anstoßen:

sh ./ati-driver-installer-10-4-x86.x86_64.run --buildpkg SuSE/SUSE112-IA32

4a. Das RPM-Package installieren (Neuinstallation):

rpm -ihv fglrx_7_4_0_SUSE112-8.723*.rpm

4b. Das RPM-Package installieren (Update):

rpm -Uhv fglrx_7_4_0_SUSE112-8.723*.rpm

5. Den Rechner neustarten:

reboot

Folgende Schritte werden auf einem 64bit openSUSE-System durchgeführt:

1. Den gepatchten X-Server installieren:
Anleitung: http://www.sebastian-siebert.de/2010/03/24/opensuse-11-2-x-server-und-ati-catalyst-display-treiber-fglrx-zur-zusammenarbeit-bewegen/

2. Den Installer des proprietären Treiber von ATI herunterladen:
http://support.amd.com/us/gpudownload/Pages/index.aspx

Optional: Das System im Runlevel 3 starten und als “root” einloggen oder per init 3 wechseln.

3. Den Bau des RPM-Packages anstoßen:

sh ./ati-driver-installer-10-4-x86.x86_64.run --buildpkg SuSE/SUSE112-AMD64

4a. Das RPM-Package installieren (Neuinstallation):

rpm -ihv fglrx64_7_4_0_SUSE112-8.723*.rpm

4b. Das RPM-Package installieren (Update):

rpm -Uhv fglrx64_7_4_0_SUSE112-8.723*.rpm

5. Den Rechner neustarten:

reboot

Troubleshooting (RPM manuell bauen):

• Sollte man trotz gepatchten X-Server nach dem Booten in der Konsole landen, dann kann es evtl. an einer fehlerhaften Konfiguration des X-Servers liegen. In diesem Fall bitte als “root” in die Konsole einloggen und folgende Schritte durchführen.

  1. X-Server-Konfiguration verschieben, falls vorhanden:

  mv /etc/X11/xorg.conf /etc/X11/xorg.conf.backup

  2. Von SaX2 eine neue Konfigurationsdatei erzeugen lassen:

  sax2 -a

  oder alternativ mit aticonfig (Das Tool aticonfig kann mittlerweile auch eine X-Server-Konfiguration from Scratch erzeugen, jedoch speziell auf den fglrx-Treiber zugeschnitten. Die restliche Hardware wird vom X-Server automatisch erkannt und geladen. Dies sollte in Zukunft vorgezogen werden, falls die Autoerkennung für den fglrx-Treiber oder X -configure nicht funktioniert):

  Bei einem Monitor (Single-Modus):

  aticonfig --initial

  oder bei zwei Monitore (Dual-Modus):

  aticonfig --initial=dual-head

  Hinweis: Falls man bereits in diesem Schritt das Tool aticonfig für die Erzeugung einer X-Server-Konfiguration verwendet hat, so entfallen die nachfolgenden Schritte 3, 3a, 3b.

  3. Die Konfigurationsdatei von aticonfig für die Nutzung des fglrx-Treibers modifizieren lassen.

  3a. Bei einem Monitor (Single-Modus):

  aticonfig --initial --input=/etc/X11/xorg.conf

  3b. Bei zwei Monitore (Dual-Modus):

  aticonfig --initial=dual-head --input=/etc/X11/xorg.conf

• Falls die Arbeitsflächen-Effekte (Compositing) in KDE 4.4.2 nicht mehr aktiviert sind, weil vermutlich die Erkennung der OpenGL-Schnittstelle von AMD/ATI Catalyst 10.4 fehlschlägt (Bugreport #601589). Hierzu gibt es eine einfache Lösung:
  1. Im KDE-Menü auf Systemeinstellungen klicken
  2. Unter Allgemein / Erscheinungsbild & Verhalten auf Arbeitsfläche klicken
  3. In Arbeitsflächen-Effekte einrichten auf den Tab Erweitert klicken
  4. Die Checkbox Funktionsprüfungen deaktivieren aktivieren
  5. Im Tab Allgemein prüfen, ob Compositing aktiviert ist. Falls nicht, bitte aktivieren.
  6. Abschließend auf Anwenden klicken

  Jetzt sollen die Effekte in KDE wieder funktionieren. Die 3D-Anwendungen bzw. 3D-Spiele sind von diesem Problem nicht betroffen.

Feedbacks sind wie immer willkommen.

Es gibt 2 Wege den Bau des RPM-Packages durchzuführen.

1. das RPM mit dem Skript makerpm-ati-10.3.sh bauen (empfohlen)
2. das RPM manuell bauen (für Fortgeschrittene)

Der Vorteil zu Punkt 1: man muss sich nicht um die nötigen Packages für den Bau kümmern und man spart sich die Tipparbeit, die Zeit und die Nerven.

[UPDATE 11.04.2010]
Das Skript makerpm-ati-10.3.sh in der Version 2.5 prüft nun automatisch, ob die vorhandene Grafikkarte vom ATI Catalyst unterstützt wird. Hierzu wird der Inhalt vom ATI-Installer extrahiert. Aus dem fglrx-Quellcode wird die ASIC-IDs ausgelesen und mit der vorhandenen AMD/ATI Grafikkarte im Computer abgeglichen. Falls diese nicht unterstützt wird, so wird das Skript sofort mit einer entsprechenden Meldung abgebrochen. Man hat hier auch nochmal eine Bestätigung, ob die Grafikkarte noch vom ATI Catalyst unterstützt wird. Robuster geht es nun wirklich nicht mehr.
[/UPDATE 11.04.2010]

Wichtig: Bevor ihr irgendwelche Fragen an mich richtet, lest euch bitte sorgfältig diesen Artikel durch und achtet auch auf eure Eingaben in der Konsole wegen mögliche Tippfehler. Falls es Probleme geben sollte, schaut bitte unter Troubleshooting nach, ob euer Problem dort schon dokumentiert wurde.

Alle genannten Schritte müssen in der Konsole im Root-Modus ausgeführt werden. Die Installation des RPM-Package “fglrx” kann im Runlevel 3 oder auch im Runlevel 5 durchgeführt werden. Danach ist ein Neustart des Computers auf jeden Fall erforderlich.

Vorhandene fremde fglrx-Treiber sind auf jedenfall zu deinstallieren, sonst kommt es zu Konflikten bei der Installation dieses selbstgebauten RPM-Package.

RPM mit dem Skript bauen

Das Skript makerpm-ati-10.3.sh ist sehr mächtig, robust und läuft vollautomatisch. Der ATI-Installer wird automatisch heruntergeladen, falls er nicht schon im Verzeichnis liegt. Auf dem System werden nach den nötigen Entwicklungspakete geprüft und ggfs. installiert. Auf Wunsch wird nach dem Bau des RPM-Packages der fglrx-Treiber installiert.

Folgende Argumente können dem Skript übergeben werden:
-b – Nur das RPM-Package bauen (Standard)
-c <type> – Nur X-Server konfigurieren. Monitor-Typ: single = 1 Monitor, dual = 2 Monitore (Wichtig: Nur ausführen, wenn es Probleme mit der Standardkonfiguration des X-Servers auftreten)
-d – Nur den ATI-Installer downloaden
-i – Das RPM-Package bauen und installieren bzw. updaten
-ux – Nur den gepatchten X-Server installieren. Verbessert die Zusammenarbeit mit dem fglrx-Treiber. (dringend zu empfehlen)
-h – Die Hilfe anzeigen lassen
-V – Version des Skript anzeigen

Downloads:

• Skript: makerpm-ati-10.3.sh
• SHA1: makerpm-ati-10.3.sh.sha1

Empfohlene Vorgehensweise:

Optional: Das System im Runlevel 3 starten oder wechseln:
Beim Booten: Im Bootmenü den Eintrag von openSUSE 11.2 selektieren und auf der Tastatur die Zahl “3″ und Enter drücken und als “root” einloggen
Im laufenden System: STRG+ALT+F1 drücken und sich als “root” einloggen. Danach mit folgendem Befehl in den Runlevel 3 wechseln:

init 3

1. Das Skript herunterladen:

wget http://www.sebastian-siebert.de/downloads/makerpm-ati-10.3.sh

2. Die Prüfsummendatei herunterladen:

wget http://www.sebastian-siebert.de/downloads/makerpm-ati-10.3.sh.sha1

3. Die Prüfsummendatei gegen das Skript prüfen:

sha1sum -c makerpm-ati-10.3.sh.sha1

Idealerweise sollte folgende Ausgabe erscheinen, andernfalls stimmt etwas mit dem heruntergeladenen Skript nicht:

makerpm-ati-10.3.sh: OK

4. Die Rechte des Skriptes ändern und ausführbar machen:

chown root:root makerpm-ati-10.3.sh && chmod 744 makerpm-ati-10.3.sh

5. Das Skript mit dem Argument -ux ausführen. Es wird ein gepatchter X-Server installiert. (Diese Vorgehensweise wird empfohlen. Weitere Informationen findet ihr hier: X-Server und ATI Catalyst Treiber (fglrx) zur Zusammenarbeit bewegen)

./makerpm-ati-10.3.sh -ux

6. Das Skript mit dem Argument -i ausführen. Das RPM-Package wird im Anschluß automatisch installiert.

./makerpm-ati-10.3.sh -i

7. Den Rechner neustarten:

reboot

Troubleshooting (RPM mit dem Skript bauen):

- Sollte man trotz gepatchten X-Server nach dem Booten in der Konsole landen, dann kann es evtl. an einer fehlerhaften Konfiguration des X-Servers liegen. In diesem Fall bitte als “root” in die Konsole einloggen und das Skript mit folgendem Parameter ausführen lassen.

Vorher noch in den Runlevel 3 wechseln:

init 3

Bei einem Monitor (Single-Modus):

./makerpm-ati-10.3.sh -c single

Bei zwei Monitore (Dual-Modus):

./makerpm-ati-10.3.sh -c dual

Danach den Rechner neustarten.

RPM manuell bauen

Das ist der etwas schwierigere Teil. Aber es ist nicht unmöglich.

Für den Bau des RPM-Packages werden folgende Entwicklungswerkzeuge bzw. -packages benötigt

• gcc
• make
• patch
• linux-kernel-headers
• kernel-source
• kernel-{default,desktop,pae,rt,vanilla,xen}-devel

Beim Kernel-Entwicklungspackage ist zu beachten, dass man die richtige installiert hat. Welchen Kernel zur Zeit auf dem System läuft, kann man in der Konsole abfragen:

uname -r

Bei mir ergibt beispielsweise diese Ausgabe:

2.6.31.12-0.2-default

Also muss im o.g. Fall der Kernel-Entwicklungspackage kernel-default-devel installiert sein.

Folgende Schritte werden auf einem 32bit openSUSE-System durchgeführt:
(64bit openSUSE-System weiter unten)

1. Den gepatchten X-Server installieren:
Anleitung: http://www.sebastian-siebert.de/2010/03/24/opensuse-11-2-x-server-und-ati-catalyst-display-treiber-fglrx-zur-zusammenarbeit-bewegen/

2. Den Installer des proprietären Treiber von ATI herunterladen:
http://support.amd.com/us/gpudownload/Pages/index.aspx

Optional: Das System im Runlevel 3 starten und als “root” einloggen oder per init 3 wechseln.

3. Den Bau des RPM-Packages anstoßen:

sh ./ati-driver-installer-10-3-x86.x86_64.run --buildpkg SuSE/SUSE112-IA32

4a. Das RPM-Package installieren (Neuinstallation):

rpm -ihv fglrx_7_4_0_SUSE112-8.712*.rpm

4b. Das RPM-Package installieren (Update):

rpm -Uhv fglrx_7_4_0_SUSE112-8.712*.rpm

5. Den Rechner neustarten:

reboot

Folgende Schritte werden auf einem 64bit openSUSE-System durchgeführt:

1. Den gepatchten X-Server installieren:
Anleitung: http://www.sebastian-siebert.de/2010/03/24/opensuse-11-2-x-server-und-ati-catalyst-display-treiber-fglrx-zur-zusammenarbeit-bewegen/

2. Den Installer des proprietären Treiber von ATI herunterladen:
http://support.amd.com/us/gpudownload/Pages/index.aspx

Optional: Das System im Runlevel 3 starten und als “root” einloggen oder per init 3 wechseln.

3. Den Bau des RPM-Packages anstoßen:

sh ./ati-driver-installer-10-3-x86.x86_64.run --buildpkg SuSE/SUSE112-AMD64

4a. Das RPM-Package installieren (Neuinstallation):

rpm -ihv fglrx64_7_4_0_SUSE112-8.712*.rpm

4b. Das RPM-Package installieren (Update):

rpm -Uhv fglrx64_7_4_0_SUSE112-8.712*.rpm

5. Den Rechner neustarten:

reboot

Troubleshooting (RPM manuell bauen):

- Sollte man trotz gepatchten X-Server nach dem Booten in der Konsole landen, dann kann es evtl. an einer fehlerhaften Konfiguration des X-Servers liegen. In diesem Fall bitte als “root” in die Konsole einloggen und folgende Schritte durchführen.

1. X-Server-Konfiguration verschieben, falls vorhanden:

mv /etc/X11/xorg.conf /etc/X11/xorg.conf.backup

2. Von SaX2 eine neue Konfigurationsdatei erzeugen lassen:

sax2 -a

oder alternativ mit aticonfig (Das Tool aticonfig kann mittlerweile auch eine X-Server-Konfiguration from Scratch erzeugen, jedoch speziell auf den fglrx-Treiber zugeschnitten. Die restliche Hardware wird vom X-Server automatisch erkannt und geladen. Dies sollte in Zukunft vorgezogen werden, falls die Autoerkennung für den fglrx-Treiber oder X -configure nicht funktioniert):

Bei einem Monitor (Single-Modus):

aticonfig --initial

oder bei zwei Monitore (Dual-Modus):

aticonfig --initial=dual-head

Hinweis: Falls man bereits in diesem Schritt das Tool aticonfig für die Erzeugung einer X-Server-Konfiguration verwendet hat, so entfallen die nachfolgenden Schritte 3, 3a, 3b.

3. Die Konfigurationsdatei von aticonfig für die Nutzung des fglrx-Treibers modifizieren lassen.

3a. Bei einem Monitor (Single-Modus):

aticonfig --initial --input=/etc/X11/xorg.conf

3b. Bei zwei Monitore (Dual-Modus):

aticonfig --initial=dual-head --input=/etc/X11/xorg.conf

Feedbacks sind wie immer willkommen.

Es gibt zusätzlich noch die Möglichkeit per X -configure eine Konfigurationsdatei anlegen zu lassen. Jedoch treten in dieser Konstellation wie auch das automatische Laden des fglrx-Treiber Konflikte auf, in der nicht selten der X-Server nicht mehr startet und man wieder in der Konsole landet. Bei diesem beschriebenen Konflikt wird fälschlicherweise versucht den fglrx-Treiber mit einer niedrigeren Farbtiefe von 8 bit oder auch 16 bit zu initialisieren, woraufhin der Treiber und der X-Server ihre Dienste quittieren. Laut der FAQ auf der AMD/ATI-Webseite wird zur Zeit nur die Farbtiefe von 24 bit unterstützt.

Aus diesem Anlass habe ich mich mit diesem Problem beschäftigt und einen gepatchten X-Servers wegen dem Konflikt mit der Farbtiefe des fglrx-Treibers bereitgestellt. Der X-Server wird gezwungen die Farbtiefe beim fglrx-Treiber auf 24 bit fest zu legen. Danach startet der X-Server mit dem fglrx-Treiber ohne Probleme.

[UPDATE 07.04.2010]
Gute Nachricht für openSUSE-User! Der von mir erstellte Patch für den X-Server wurde für die kommenden openSUSE-Version 11.3 eingepflegt. Nicht desto trotz ist AMD/ATI jetzt am Zug, die Kompatibilität zwischen dem fglrx-Treiber und dem X-Server weiter auszubauen. (Siehe Heise.de) Die Aufnahme des Patches wurde von mir mit einer ausführlichen Begründung für eine Aufnahme beantragt (Nachzulesen im Bugreport https://bugzilla.novell.com/show_bug.cgi?id=593878). Somit dürfte der X-Server in der kommende openSUSE 11.3 mit dem fglrx-Treiber etwas besser zusammenarbeiten.

• 1. Installationsanleitung in YaST2
• 2. Installationsanleitung über die Konsole

Installationsanleitung in YaST2

1. YaST2-Kontrollzentrum starten

2. auf Software-Repositories klicken

3. im Dialogfenster “Konfigurierte Software-Repositorys” unten auf Hinzufügen klicken

4. “URL angeben” markieren

5. folgenden Repository-Name eingeben: X-Server

6. folgende URL eingeben: http://download.opensuse.org/repositories/home:/Freespacer:/X11:/XOrg/openSUSE_11.2/

7. die Einrichtung mit Okay schließen

8. auf den Repo-Namen X-Server klicken und die Priorität auf 90 setzen

9. mit OK die Konfiguration abschließen

10. im YaST2-Kontrollzentrum auf “Software installieren und löschen” klicken

11. folgendes im Suchfeld eingeben: xorg-x11-server

12. unten auf den Tab “Versionen” klicken

13. auf X-Server Repository wechseln (Bitte auf die richtige Systemarchitektur achten!)

14. nun auf Akzeptieren klicken und der gepatchte X-Server wird installiert.

15. Falls eine Konfigurationsdatei /etc/X11/xorg.conf existiert, kann diese für die automatische Konfiguration umbenannt, verschoben oder gelöscht werden.

16. nun den Rechner neustarten

Installationsanleitung über die Konsole

1. zu root werden:

su - root

2. Repository hinzufügen:

zypper ar -f "http://download.opensuse.org/repositories/home:/Freespacer:/X11:/XOrg/openSUSE_11.2/" "X-Server"

Ausgabe von zypper:

Adding repository 'X-Server' [done]
Repository 'X-Server' successfully added
Enabled: Yes
Autorefresh: Yes
URI: http://download.opensuse.org/repositories/home:/Freespacer:/X11:/XOrg/openSUSE_11.2/

3. Priorität des X-Server-Repository erhöhen:

zypper mr -p 90 "X-Server"

Ausgabe von zypper:

Repository 'X-Server' priority has been set to 90.

4. Repository-Cache erneuern lassen. Ggfs. den GPG-Schlüssel vom Repository mit immer (i) akzeptieren:

zypper ref

5. gepatchten X-Server installieren. Downgrade bitte bestätigen (Anmerkung: Es ist kein richtiger Downgrade, lediglich die Patch-Level-Version hat sich geändert):

zypper in -r "X-Server" xorg-x11-server-7.4-61.1

6. Falls eine Konfigurationsdatei /etc/X11/xorg.conf existiert, kann diese für die automatische Konfiguration umbenannt, verschoben oder gelöscht werden.

7. den Rechner neustarten

Nun, dürften die Probleme mit dem X-Server und dem fglrx-Treiber der Vergangenheit angehören.

Falls man doch eine Konfigurationsdatei benötigt, kann man sie sich entweder mittels

X -configure

oder per

sax2 -a

erstellen lassen.

Es kommt öfter vor, dass man den Webserver mit all seinen Webstatistiken nicht alleine nutzt, somit gehen auch andere User in die Falle und verraten sich durch den Browser die Herkunft seines Besuches. Die Spammer könnten ihre eigene Logdateien analysieren, um zu sehen wer die Seite besucht hat und bombardieren dann die ertappten “Webmaster” mit ihren Referrer-Links zu.

In diesem Fall kann es ganz nützlich sein den Referrer-Link über anonym.to zu anonymisieren, um die Herkunft über die Domain bzw. Webstatistik zu verschleiern und habe hierzu einige Ergänzungen im Skript …/cgi-bin/awstats.pl veranlasst. Hier wird zu jedem externen Link noch um den notwendigen Link erweitert: http://anonym.to/?(referrerlink)

Hierzu habe ich einen Patch vorbereitet und man kann ihn sich hier herunterladen.
Download: awstats-6.95-anonym-referer.patch
SHA1: awstats-6.95-anonym-referer.patch.sha1

Der Patch muss ins gleiche Verzeichnis kopiert werden, in der auch das Skript awstats.pl liegt und anschließend wie folgt ausführen:

patch <awstats-6.95-anonym-referer.patch

Danach ist die Welt ein bisschen besser geworden und macht sich auch in der Statistik bemerkbar.