openSUSE 11.3 – proprietären Grafik-Treiber ATI Catalyst 11.1 als RPM installieren

Hinweis: Dieser Artikel ist veraltet. Ein neuer Artikel befindet sich hier: openSUSE 11.3 – proprietären Grafik-Treiber ATI Catalyst 11.2 als RPM installieren

ATI Catalyst 11.1 (fglrx 8.812) wurde veröffentlicht. Das Skript makerpm-ati-11.1.sh steht ab sofort zum Download zur Verfügung.

Endlich ist es soweit. ATI Catalyst 11.1 beinhaltet jetzt offiziell das von mir geschriebene Packagingskript. Die openSUSE-User, die vorher ATI Catalyst per makerpm-ati-Skript installiert haben, haben bereits die Vorzüge kennengelernt. :-)

Folgende Features sind im ATI Catalyst 11.1 für openSUSE (auch für SLED) enthalten:

  • Verbose-Modus: (1 = Was machst du gerade, 2 = Erzähle mir alles)
    VERBOSE="1" ./ati-driver-installer-11-1-x86.x86_64.run --buildpkg ...
    VERBOSE="2" ./ati-driver-installer-11-1-x86.x86_64.run --buildpkg ...
  • Paketbau einschl. automatische Erkennung der openSUSE-Version:
    ./ati-driver-installer-11-1-x86.x86_64.run --buildpkg SuSE/SUSE-autodetection
  • Paketbau unter openSUSE 11.4 (Factory) freischalten:
    UNSUPPORTED="yes" ./ati-driver-installer-11-1-x86.x86_64.run --buildpkg SuSE/SUSE-autodetection
  • Automatischer Bau eines fglrx-Kernelmoduls via Initskript /etc/init.d/boot.fglrxrebuild nach einem Kernel-Update (Killer-Feature!!!)
  • Erweiterung des fglrx-kernel-build.sh Skript:
    • Erstellung eines Kurzberichts über den Bau und die Installation des fglrx-Kernelmoduls.
    • Unterstützung für Multi-Kernel-Version und Multi-Kernel-Flavor (default, desktop, pae).
    • Bei der Kompilierung werden alle verfügbaren Multi-Cores/Multi-CPUs genutzt (Ein Dank geht an Franz für diese Idee ;-) ).

Inhaltsverzeichnis

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 vorbei zu schauen oder im Feedreader zu speichern.

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

  1. das RPM mit dem Skript makerpm-ati-11.1.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.

Hinweis: 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 wird mit der Installation des ATI Catalyst RPM-Paket automatisch entfernt.

Mit vorhandene fglrx-Treiber sind z.B. folgende gemeint:

  • ati-fglrxG01-kmp-{default,desktop,pae,…}
  • ati-fglrxG02-kmp-{default,desktop,pae,…}
  • x11-video-fglrxG02

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-11.1.sh herunter und erstellt einen Report von eurem System in der Konsole:

su -c 'sh makerpm-ati-11.1.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-11.1.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 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
-r|–report erstellt ein Report und speichert diese in eine Datei namens ati-report.txt
-u|–uninstall entfernt ATI Catalyst restlos vom System. Zuerst wird das fglrx-Package (falls vorhanden) vom System deinstalliert. Danach werden vorhandene ATI-Dateien und -Verzeichnisse entfernt. Hinweis: Falls das Rebuild-Skript installiert wurde, wird es ebenfalls entfernt und das Initskript /etc/init.d/xdm wiederhergestellt.
-ur|–uploadreport wie Option –report nur zusätzlich wird der Report auf einem NoPaste-Service sprunge.us hochgeladen und gibt bei Erfolg den Link zurück.
-ux openSUSE 11.2: Nur den gepatchten X-Server installieren. Verbessert die Zusammenarbeit mit dem fglrx-Treiber. (empfohlen)
-h Die Hilfe anzeigen lassen
-V Version des Skript anzeigen

Downloads:

Empfohlene Vorgehensweise:

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

  1. Das Skript herunterladen:
    wget http://www.sebastian-siebert.de/downloads/makerpm-ati-11.1.sh
  2. Die Prüfsummendatei herunterladen:
    wget http://www.sebastian-siebert.de/downloads/makerpm-ati-11.1.sh.sha1
  3. Die Prüfsummendatei gegen das Skript prüfen:
    sha1sum -c makerpm-ati-11.1.sh.sha1

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

    makerpm-ati-11.1.sh: OK
  4. Die Rechte des Skriptes ändern und ausführbar machen:
    chown root:root makerpm-ati-11.1.sh
    chmod 744 makerpm-ati-11.1.sh
  5. Das Skript mit dem Argument -i ausführen. Das RPM-Package wird im Anschluß automatisch installiert (bzw. aktualisiert).
    ./makerpm-ati-11.1.sh -i
  6. Den Rechner neustarten:
    reboot

RPM manuell bauen

Da nun endlich das von mir neugeschriebene Packaging Skript im ATI-Installer enthalten ist, ist die Installation des Treibers ziemlich einfach geworden. :-)

Folgende Entwicklungswerkzeuge bzw. -packages werden vom gebauten RPM-Paket als benötigt eingestuft und von YaST2/zypper automatisch mitinstalliert:

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

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-11-1-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:
    • openSUSE 11.3 (auch unter openSUSE 11.2 / openSUSE 11.1):
      sh ./ati-driver-installer-11-1-x86.x86_64.run --buildpkg SuSE/SUSE-autodetection
    • openSUSE 11.4 (Factory):
      UNSUPPORTED="yes" sh ./ati-driver-installer-11-1-x86.x86_64.run --buildpkg SuSE/SUSE-autodetection
  3. Das RPM-Package installieren:
    zypper install fglrx*8.812*.rpm
  4. Nur beim Update: Falls die Vorgängerversion (ATI Catalyst <=10.12) installiert war und ein Update durchgeführt wurde, ist es notwendig das Rebuildskript manuell zu aktivieren (Nach jedem Kernel-Update wird das fglrx-Kernelmodul automatisch neu gebaut):
    chkconfig -a boot.fglrxrebuild
  5. 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 lassen sich gar nicht mehr aktivieren
  5. In Firefox oder Thunderbird erscheinen schwarze Flächen
  6. Der 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-11.1.sh -c single

    Bei zwei Monitore (Dual-Modus):

    ./makerpm-ati-11.1.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-11.1.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 11.1 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 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-11.1.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-11.1.sh -old2ddriver no
  6. Fortgeschrittene Variante:

    aticonfig --del-pcs=DDX,ForceXAA
  7. Der 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. :-)

Die Domain opensuseusers.de wurde registriert und eingerichtet

Diesmal kamen die Vorschläge direkt aus der deutschen Community, die Domain opensuseusers.de für die neue Community-Plattform community.open-slx.de zusätzlich zu registrieren und diese zu nutzen. Denn die Domain ubuntuusers.de haben sehr viele User im Kopf und könnten womöglich die Domain opensuseusers.de mit der Ubuntu-Community gleichsetzen, was ein netten Synergieeffekt auslöst.

Zuerst haben sich die User darüber gefreut, dass die Domain am gleichen Tag registriert wurde und beim Aufruf der Adresse direkt auf die neue Community umgeleitet wird. Dann kam der Schreck, wer überhaupt die Domain still und heimlich reserviert hat. War es das Kern-Team von open-slx GmbH? Zu dem Zeitpunkt war es für das Kern-Team nicht klar, ob man die Domain reservieren sollte, weil einige Punkte offen sind. Also, wer hat schnell zugegriffen?

Da kann ich beruhigen. Die Domain habe ich kurzfristig registrieren lassen und die Umleitung eingerichtet. Jetzt kommt sicherlich die Frage nach dem Warum. Die Antwort ist einfach. Die schnelle Registrierung meinerseits hat verhindert, dass ein Domaingrabber diese Domain reserviert und sie unserer Community zu einem viel höheren Preis anbietet. Entweder waren diese unbezahlbar oder es musste eine neue Domain gefunden werden, wobei aber der Synergieeffekt verloren geht. Solche Machenschaften gab es leider in der Vergangenheit zu genüge und dient nur letztlich zur Vorbeugung. Da in der neuen Community ein öffentliches Forum existiert, kann jeder das Thread http://forum.open-slx.de/topic/diese-community-seite-ist-schwer-zu-finden/ lesen. Somit stieg gleichzeitig die Gefahr eines Domaingrabbings.

Da nun die Gefahr gebannt ist, kann man jetzt in Ruhe und ohne Zeitdruck abklären, was mit der Domain passieren soll und wie man diese bestmöglich integriert. Eines ist sicher: Die Domain ist für die Community zu wertvoll, um sie gar nicht zu nutzen. ;-)

openSUSE 11.3 – Verzeichnisse wie /tmp automatisch entleeren lassen

Als ich heute auf meinem Netbook (openSUSE 11.3) in das temporäre Verzeichnis /tmp geschaut habe, musste ich feststellen, dass das Verzeichnis auf 3,2 GB angewachsen ist und auch nie manuell entleert wurde. Bestes Beispiel: Firefox speichert heruntergeladene Dateien in diesem Verzeichnis, wenn man z.B. PDF-Dateien oder Archive direkt öffnet. Jedoch werden diese nie beim Beenden gelöscht. Somit sammelt sich mit der Zeit eine Menge Dateien an.

Größe des /tmp Verzeichnises in der Konsole ermitteln:

du -sch /tmp

Ergebnis:

3,2G    /tmp
3,2G    insgesamt

Kein Wunder, ich hatte vorher auch openSUSE 11.2 drauf gehabt. ;-)

Es gibt 3 Möglichkeiten die Verzeichnisse zu entleeren.

1. Möglichkeit: manuell in der Konsole per root löschen

Vorteil: Kontrolle und Gewissheit. :-)

Nachteil: Man muss im Runlevel 1 das Verzeichnis entleeren. Danach ist ein Neustart fällig, weil evtl. laufende Prozesse auf fehlende Dateien zugreifen und unvorgesehene Fehler auslösen können.

find /tmp -maxdepth 1 -mindepth 1 -print0 | xargs -0r rm -rf

2. Möglichkeit: täglich per Cronjob löschen

Verantwortliches Skript: /etc/cron.daily/suse.de-clean-tmp

Vorteil: Die Vorhaltezeit für temporäre Dateien und Verzeichnisse kann nach Tagen bestimmt werden. Hier kann man auch weitere oder andere Verzeichnisse eintragen, die gelöscht werden sollen. Systeme, die Tage lang durchlaufen, werden so auch täglich bereinigt.

Nachteil: Es wird nur teilweise entleert. Dateien, die mit root-Rechten versehen sind, werden nicht gelöscht (Dieses Verhalten kann man zwar ändern, würde ich jedoch nicht empfehlen) und kann daher trotzdem anwachsen, wenn aber auch nicht so schnell.

  1. Krunner per ALT+F2 aufrufen und folgendes eingeben, um den sysconfig-Editor aufzurufen:
    yast2 sysconfig
  2. Auf System / Cron / MAX_DAYS_IN_TMP klicken und die maximale Vorhaltezeit in Tagen (hier als Beispiel: 7 Tage) eintragen (0 = deaktiviert): 7
  3. Optional: Wenn man weitere Verzeichnisse einfügen möchte oder sogar ganz andere Verzeichnisse löschen will, geht man auf System / Cron / TMP_DIRS_TO_CLEAR und trägt dort weitere Verzeichnisse ein. Beispiel: /tmp /home/user/irgendwas /var/abc
  4. Optional, jedoch mit Vorsicht zu genießen: Man kann weitere Eigentümer eintragen (oder entfernen), deren Dateien bzw. Verzeichnisse nicht gelöscht werden dürfen. Hierzu geht man auf System / Cron / OWNER_TO_KEEP_IN_TMP und trägt beispielsweise ein: root dummy itsme
  5. Mit Okay bestätigen und ggfs. nochmal die Änderungen bestätigen lassen.

3. Möglichkeit: beim Booten löschen

Verantwortliches Skript: /etc/init.d/boot.cleanup

Vorteil: Dateien und Verzeichnisse unterhalb von /tmp werden restlos gelöscht. Auf Wunsch können noch weitere Verzeichnisse zum Löschen angegeben werden. Kein Neustart nötig.

Nachteil: Löschvorgang ist nur zur Bootzeit möglich und ist unabhängig vom Eigentümer und Alter.

  1. Krunner per ALT+F2 aufrufen und folgendes eingeben, um den sysconfig-Editor aufzurufen:
    yast2 sysconfig
  2. Auf System / Cron / CLEAR_TMP_DIRS_AT_BOOTUP klicken und folgendes eintragen (no = deaktiviert): yes
  3. Optional: Wenn man weitere Verzeichnisse einfügen möchte oder sogar ganz andere Verzeichnisse löschen will, geht man auf System / Cron / TMP_DIRS_TO_CLEAR und trägt dort weitere Verzeichnisse ein. Beispiel: /tmp /home/user/irgendwas /var/abc
  4. Mit Okay bestätigen und ggfs. nochmal die Änderungen bestätigen lassen.

Ich habe mich für die letztere Variante entschieden. Welche Variante ihr bevorzugt, überlasse ich euch. Have a lot of fun! ;-)

Feedbacks sind erwünscht. :-)

Eine deutschsprachige openSUSE Community-Plattform geht online

Die open-slx GmbH (maßgeblich an der openSUSE Box beteiligt) hat heute eine neue Plattform für die deutsche openSUSE-Community eröffnet und wird von ihr gesponsert. Die Plattform hat zum Start 500 von 2.000 Wiki-Artikel in Form von Anleitungen und Dokumentationen zu openSUSE im Angebot und ist auf community.open-slx.de für jeden frei zugänglich. Es wird darauf hingewiesen, dass dieses Projekt eine Ergänzung zur englisch-, deutschsprachigen Community-Plattform opensuse.org angesehen wird und daher kein Fork ist.

In Kooperation mit einer anderen deutschsprachigen Community (ubuntuusers.de) wurden die Texte und auch die Technik von dort übernommen. Manche openSUSE-Benutzer wurden in der Vergangenheit öfters auf die qualitativ hochwertigen Wiki-Texte von ubuntuusers.de hingewiesen, um bestimmte Konfigurationsprobleme unter openSUSE zu lösen. Manchmal gibt es gewaltige Unterschiede zwischen Ubuntu und openSUSE. Das wird sich mit diesem neuen Projekt ändern.

Bis zum Ende dieses Jahres (vielleicht auch früher) sollen die restlichen 1.500 Wiki-Texte mit Hilfe der openSUSE-Community auf die Gegebenheiten von openSUSE angepasst werden. Jeder, der sich bei einem bestimmten Thema unter openSUSE auskennt, kann mithelfen. Rupert Horstkötter von der open-slx GmbH hat mich vor dem Launch angeschrieben, ob ich in der Wiki mithelfen kann, um einen Teil der 500 Wiki-Texte zu überarbeiten. Ich habe zugestimmt und einige Wiki-Artikel überarbeitet. Auch nach und während der Portierung werden die Artikel regelmäßig und dauerhaft von der Community gepflegt und erweitert.

Genauso wird ein Forum ebenfalls in deutscher Sprache angeboten, in der man z.B. Fragen rund um openSUSE stellen kann oder auch Probleme mit der Konfiguration oder bestimmte Hardwarekomponenten unter openSUSE berichten kann, um gemeinsam eine Lösung zu suchen. Dort sind Hilfesuchende besonders gut aufgehoben.

Die Plattform bietet folgendes an:

Der offizielle Pressetext zum Projekt:
http://news.open-slx.de/2011/01/17/herzlich-willkommen-bei-community-open-slx-de/

Ich kann nur empfehlen, die Community-Plattform open-slx als Lesezeichen im Browser zu speichern. Früher oder später wird man sie brauchen. ;-)

openSUSE 11.3 – KDE SC 4.5.5

KDE SC 4.5.5 wurde veröffentlicht und die Pakete stehen zum Download für openSUSE bereit. Außerdem wird empfohlen, wie auch in der Ankündigung auf KDE 4.5.5 zu aktualisieren.

Folgende KDE-Komponenten wurden in KDE 4.5.5 aktualisiert:

  • KDE Anwendungen

Hierzu sind weitere Fehler behoben worden:

  • kdebase (Dolphin)
  • kdesdk (Kompare)
  • kdeutils (Ark, KGpg)

Changelog: KDE SC 4.5.5

Wichtiger Hinweis:
Wer bereits nach der unten beschriebenen Anleitung das Repo http://download.opensuse.org/repositories/KDE:/Release:/45/openSUSE_11.3/ eingebunden und aktiviert hat, muss lediglich in YaST im KDE-4.5-Repo auf „Switch system packages“ klicken oder per zypper mit einem Repo-Alias ein „Upgrade“ durchführen:

zypper dup -r "KDE_4.5"

Um die Lesbarkeit zu erhöhen wurde der Name der Repository geändert. Anstatt „KDE_4.5.x“ wird jetzt „KDE_4.5“ hier im Artikel beschrieben.

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

Installation (YaST2):

  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
  6. URL des KDE-Repo für openSUSE 11.3 eingeben: http://download.opensuse.org/repositories/KDE:/Release:/45/openSUSE_11.3/
  7. Auf Weiter klicken.
  8. Das erstellte Repository „KDE 4.5“ 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“-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.5 genießen.

Installation (zypper):

  1. KDE-Repo mit einem Alias hinzufügen:
    zypper ar -f "http://download.opensuse.org/repositories/KDE:/Release:/45/openSUSE_11.3/" "KDE_4.5"
  2. Priorität des KDE-Repo erhöhen:
    zypper mr -p 50 "KDE_4.5"
  3. Upgrade von KDE durchführen:
    zypper dup -r "KDE_4.5"
  4. Rechner neustarten und KDE 4.5.5 genießen.

Have a lot of fun! ;-)