Willkommen zum openSUSE Planeten

Dies ist eine Zusammführung der Blog-Einträge von Mitwirkenden im openSUSE-Projekt.

Zum Hinzufügen eines Blog-Feeds bitte die Anleitung lesen.


Samstag
23. November 2013


face

AMD Catalyst 13.11 Beta V9.4 (fglrx 13.25.18) wurde veröffentlicht und unterstützt Grafikkarten ab Radeon HD 5000 und höher. Das Skript makerpm-amd-13.11-betav9.4.sh steht ab sofort zum Download zur Verfügung und unterstützt openSUSE 11.4, 12.1, 12.2, 12.3, 13.1 sowie bis Kernel 3.12.

Der Beta-Treiber unterstützt jetzt von Haus aus Kernel 3.12. Daher habe ich meinem Patch im Packaging Skript zur neuen Beta-Version wieder entfernt.

Wie gehabt habe ich noch das störende Beta-Wasserzeichen in der unteren rechten Ecke entfernt.

Nachfolgende Release Notes von AMD zum AMD Catalyst 13.11 Beta V9.4:

Folgende Probleme sind im Treiber behoben worden:

  • [372656] : Resolves crash when resizing Konsole
  • [388325] : Resolves brightness adjustment issues
  • [388818] : Resolves kernel module compile failure when CONFIG_UIDGID_STRICT_TYPE_CHECKS is enabled
  • [388335] : Avoids the new GPL symbol acpi_bus_get_device for new kernel support
  • [386897] : Resolves system hang on resume from S4 with OpenGL screen saver running

Link: AMD Catalyst™ 13.11 LINUX Beta V9.4 Driver Release Notes

Eine kleine Bitte habe ich: Wenn irgendwelche Probleme mit dem Treiber auftauchen, scheut euch nicht mir zu berichten (Ich nehme deutsche und englische Bugreports gerne entgegen). ;-) Ich werde versuchen, soweit es mir möglich ist, den gemeldeten Fehler zu reproduzieren. Zusammen mit den nötigen System-Informationen werde ich mich direkt an die richtige Stelle bei AMD wenden, um den Bug in der nächsten Treiber-Version beheben zu lassen. Danke schön. :-D

Für Benutzer älterer AMD Grafikkarten (Radeon HD Serie 2000 – 4000) wird dringend die Installation dieses Treibers abgeraten. AMD hat einen Legacy-Treiber zur Verfügung gestellt. Mehr Informationen zum Legacy Treiber: http://www.sebastian-siebert.de/2013/01/25/opensuse-amd-catalyst-13-1-legacy-treiber-als-rpm-installieren/

Downloads:

Installationsanleitung:
http://de.opensuse.org/SDB:AMD/ATI-Grafiktreiber#Installation_via_makerpm-amd-Skript

Über das makerpm-amd-Skript

Das Skript makerpm-amd-13.11-betav9.4.sh ist sehr mächtig, robust und läuft vollautomatisch. Der AMD-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 AMD-Installer downloaden
-i Das RPM-Package bauen und installieren bzw. updaten
-kms <yes|no> Kernel-Mode-Setting (KMS) aktivieren oder deaktivieren
-nohw Hardware-Erkennung explizit ausschalten. (z.B. beim Bau in einer VM)
-old2ddriver <yes|no> den alten 2D-Treiber aktivieren oder deaktivieren
-r|–report erstellt ein Report und speichert diese in eine Datei namens amd-report.txt
-u|–uninstall entfernt AMD Catalyst restlos vom System. Zuerst wird das fglrx-Package (falls vorhanden) vom System deinstalliert. Danach werden vorhandene AMD-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

Dienstag
19. November 2013


face

AMD Catalyst 13.11 Beta V6 (fglrx 13.20.18) wurde veröffentlicht und unterstützt Grafikkarten ab Radeon HD 5000 und höher. Das Skript makerpm-amd-13.11-betav6.sh steht ab sofort zum Download zur Verfügung und unterstützt openSUSE 11.4, 12.1, 12.2, 12.3, 13.1 sowie bis Kernel 3.12.

Dank eures Feedbacks habe ich folgende Änderungen eingepflegt:

  • Kompatibilitätspatch für Kernel 3.12
  • Fehlerhafter Symlink zum 32-bit OpenGL auf einem 64-bit openSUSE System behoben
  • Der direkte Download des Treiber vom AMD-Server funktioniert mit einem kleinen Hack wieder

Die Installation des Treibers auf dem heute am 19.11.2013 veröffentlichten openSUSE 13.1 verlief ohne Problem. 32-bit wie auch 64-bit OpenGL-Spiele funktionieren einwandfrei. Genauso wurde auch Steam mit meinem Referenzspiel “Euro Truck Simulator 2″ sowohl 32-bit als auch 64-bit getestet und lief genauso flüssig.

Wie gehabt habe ich noch das störende Beta-Wasserzeichen in der unteren rechten Ecke entfernt.

Nachfolgende Release Notes von AMD zum AMD Catalyst 13.11 Beta V6:

Unterstützung von neuen Grafikkarten

  • AMD Radeon R9 290 SeriesX

Folgende Probleme sind im Treiber behoben worden:

  • [387659] Fixes X crash when kill X server with Xserver 1.13 and above
  • [386508] Fixes fd leak with Application Profile feature
  • [386511] Fixes kernel module build failure with kernel 3.9.1

Link: AMD Catalyst™ 13.11 LINUX Beta V6 Driver Release Notes

Eine kleine Bitte habe ich: Wenn irgendwelche Probleme mit dem Treiber auftauchen, scheut euch nicht mir zu berichten (Ich nehme deutsche und englische Bugreports gerne entgegen). ;-) Ich werde versuchen, soweit es mir möglich ist, den gemeldeten Fehler zu reproduzieren. Zusammen mit den nötigen System-Informationen werde ich mich direkt an die richtige Stelle bei AMD wenden, um den Bug in der nächsten Treiber-Version beheben zu lassen. Danke schön. :-D

Für Benutzer älterer AMD Grafikkarten (Radeon HD Serie 2000 – 4000) wird dringend die Installation dieses Treibers abgeraten. AMD hat einen Legacy-Treiber zur Verfügung gestellt. Mehr Informationen zum Legacy Treiber: http://www.sebastian-siebert.de/2013/01/25/opensuse-amd-catalyst-13-1-legacy-treiber-als-rpm-installieren/

Downloads:

Installationsanleitung:
http://de.opensuse.org/SDB:AMD/ATI-Grafiktreiber#Installation_via_makerpm-amd-Skript

Über das makerpm-amd-Skript

Das Skript makerpm-amd-13.11-betav6.sh ist sehr mächtig, robust und läuft vollautomatisch. Der AMD-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 AMD-Installer downloaden
-i Das RPM-Package bauen und installieren bzw. updaten
-kms <yes|no> Kernel-Mode-Setting (KMS) aktivieren oder deaktivieren
-nohw Hardware-Erkennung explizit ausschalten. (z.B. beim Bau in einer VM)
-old2ddriver <yes|no> den alten 2D-Treiber aktivieren oder deaktivieren
-r|–report erstellt ein Report und speichert diese

Dienstag
15. Oktober 2013


face

AMD Catalyst 13.11 Beta V1 (fglrx 13.20.16) wurde veröffentlicht und unterstützt Grafikkarten ab Radeon HD 5000 und höher. Das Skript makerpm-amd-13.11-betav1.sh steht ab sofort zum Download zur Verfügung und unterstützt openSUSE 11.4, 12.1, 12.2, 12.3, 13.1 sowie bis Kernel 3.11.

In eigener Sache: Ich möchte mich bei allen Spendern zur Förderung des Installationsskripts für den AMD Catalyst Treiber unter openSUSE wie auch den Erhalt des Blogs ganz herzlichst bedanken. Somit ist es mir möglich, diesen Blog weiterhin werbefrei zu halten. In der letzten Zeit habe ich nicht gerade wenige Angebote erhalten, über einen einfachen Blog-Artikel zu einem Produkt in Zusammenhang mit Linux in eigenen Worten zu schreiben. Erstens kommt für mich Schleichwerbung gar nicht in Frage und zweitens soll dieser Blog nicht mit irgendwelchen dubiosen Produkten zugemüllt werden. Es kann weiterhin via Flattr, PayPal, Überweisung oder auch per Post gespendet werden. Nochmal vielen Dank für eure Unterstützung. ;-)

Ab sofort habe ich die Unterstützung für openSUSE 13.1 RC1 eingepflegt und wurde von mir ausgiebig getestet. Kleiner Tipp: Sollte es beim Verschieben eines Fensters unter openSUSE 13.1 mit KDE 4.11.2 zum Tearing kommen, dann empfehle ich in der KDE-Einstellung der Arbeitsflächen-Effekte unter Erweitert die OpenGL-Einstellung für “Einzelbild-Zerreißen (Tearing) verhindern (VSync)” auf “Bildschirm-Inhalt wiederverwenden” zu setzen.

Zudem habe ich ein kleinen Bugfix für openSUSE 13.1 RC1 in das makerpm-amd-Skript integriert, dass ein Problem mit der inkorrekten Formatierung von /etc/SuSE-release in Zusammenhang mit dem Kommandozeilten-Tool lsb_release behebt (Siehe Bugreport #845262). Das Tool lsb_release kann dann die korrekten Daten zu openSUSE zurückliefern. Ohne diese Korrektur funktioniert die automatische Erkennung nicht mehr.

Wie gehabt habe ich noch das störende Beta-Wasserzeichen in der unteren rechten Ecke entfernt.

Nachfolgende Release Notes von AMD zum AMD Catalyst 13.11 Beta V1:

Unterstützung von neuen Grafikkarten

  • AMD Radeon R9 280X
  • AMD Radeon R9 270X
  • AMD Radeon R7 260X
  • AMD Radeon R7 250
  • AMD Radeon R7 240

Folgende Probleme sind im Treiber behoben worden:

  • [383176] System hang up when startx after setting up an Eyefinity desktop
  • [384193] Permission issue with procfs on kernel 3.10
  • [373812] System hang observed while running disaster stress test on Ubuntu 12.10
  • [383109] Hang is observed when running Unigine on Linux
  • [383573] AC/DC switching is not automatically detected
  • [383075] Laptop backlight adjustment is broken
  • [383430] Glxtest failures observed in log file with forcing on Anti-Aliasing
  • [383372] Cairo-dock is broken
  • [378333] Severe desktop corruption is observed when enabled compiz in certain cases
  • [384509] glClientWaitSync is waiting even when timeout is 0
  • [382494] C4Engine get corruption with GL_ARB_texture_array enabled

Link: AMD Catalyst™ 13.11 LINUX Beta V1 Driver Release Notes

Eine kleine Bitte habe ich: Wenn irgendwelche Probleme mit dem Treiber auftauchen, scheut euch nicht mir zu berichten (Ich nehme deutsche und englische Bugreports gerne entgegen). ;-) Ich werde versuchen, soweit es mir möglich ist, den gemeldeten


Sonntag
22. September 2013


face

In diesem Artikel beschreibe ich den Umzug von openSUSE 12.3 auf eine SSD. In meinem Fall gehe ich auf die Samsung SSD 840 Pro (512 GB) ein. Die Anleitung funktioniert auch mit anderen SSDs von der Samsung Pro-Serie.

Wichtig: Die Befehle im Artikel müssen als root ausgeführt werden. Hier ist die Partitionszuordnung nur als Beispiel anzusehen und muss an die Gegebenheiten vom eigenen System angepasst werden.

Inhalt:

  • Prolog
  • Aktivierung der Host Protected Area (HPA) / Stichwort: Over-Provisioning
  • Partitionierung / Dateisystem
  • Umzug von openSUSE
  • Anpassung an die neue Umgebung

Prolog

Meine 5 Jahre alte Festplatte (Samsung HD753LJ / 750 GB) hatte nicht nur Windows XP überstanden, sondern auch die Anfänge mit openSUSE und diverse andere Linux-Distributionen, die ich zum Test auch heute noch nebenbei installiert habe. Irgendwann wollte ich ein Kernelmodul unter openSUSE bauen. Dabei kam es immer an derselben Stelle zu einem Lesefehler und der Kompiliervorgang wurde abgebrochen. Leider hat mir das S.M.A.R.T.-Monitoring-Tool nicht gutes mitzuteilen und nach einer Überprüfung der Festplatte via fsck kamen auch weitere fehlerhafte Blöcke zum Vorschein. Herbe Datenverluste waren in meinem Fall nicht zu erwarten, obwohl einige Dateien unwiederbringlich verloren gegangen sind. Zum Glück war nur die root-Partition betroffen und konnte die fehlerhaften Dateien durch die Reinstallation des betreffenden RPM-Pakets wiederherstellen. Meine home-Partition war noch in Ordnung. Im Notfall habe ich noch ein aktuelles Backup. Dennoch ist mein Vertrauen in die Festplatte stark gesunken. So kam prompt die Entscheidung eine SSD zu holen, die ich vor langer Zeit eingeplant habe. Zu diesem Thema habe ich mich intensiv auseinander gesetzt und mich letztendlich für die Samsung SSD 840 Pro mit 512 GB entschieden.

Aktivierung der Host Protected Area (HPA)

Kurz vorweg: Was ist eigentlich HPA bzw. Over-Provisioning?
Das ist für das Betriebssystem ein unsichtbarer Datenbereich (Spare Area). Sie dient dazu Lese- und Schreibvorgänge zu optimieren (Read-Modify-Write), Ersatz für fehlerhafte Blöcke (Badblocks Replacement), optimale Ausnutzung der Speicherzellen (Wear-Leveling).

Bei der Samsung SSD Pro-Serie ist das HPA-Feature werksseitig deaktiviert. Sie lässt sich ohne Probleme aktivieren und wird ausdrücklich empfohlen. Eine nachträgliche Aktivierung von HPA ist mit Datenverlust verbunden. Daher sollte man sich mit diesem Thema früh genug auseinandersetzen. Bei einer nagelneuen SSD ist es ein guter Zeitpunkt das HPA-Feature zu aktivieren und sich über die Größe der Spare Area Gedanken zu machen.

Wie groß darf denn die Spare Area sein?
Es gibt je nach Nutzung unterschiedliche Werte, die lediglich auf Empfehlungen basieren. Wir sprechen hier im Bereich von 7% (Empfehlung von Samsung) bis 27% (Empfehlung von Intel) des reservierten Datenbereichs. Für meine Zwecke habe ich die Empfehlung von Samsung (7%) modifiziert und nochmal 3% daraufgelegt. Meines Erachtens sind 10% Spare Area mehr als genug. 10% von 512 GB entspricht 51,2 GB. Also, habe ich am Ende 460,8 GB nutzbaren Datenbereich.

Jetzt müssen wir herausfinden, auf welchem Device-Pfad die SSD zugeordnet ist:

hwinfo --disk | grep -E 'Model|Device File:'

Die Ausgabe von meinem System:

Model: "Samsung 

Mittwoch
04. September 2013


face

cooltek2 Hier einmal ein Bauvorschlag für einen kleine, aber Leistungsfähigen Computer, der sehr gut durch den Alltag kommt. Ziel von mir war es, einen kleinen, stromsparenden (im Vergleich zu Leistung) und leisen PC zu bauen.

Dazu verwendete ich folgende Bauteile:

  • Mainboard: Asus P8Z77-I DELUXE
  • Prozessor: Intel Core i5-3570K 3400
  • RAM: 8GB Tactical K2
  • Gehäuse: Cooltek Coolcube Mini
  • SATA-Kabel: Nanoxia SATA 3.0 Kabel abgewinkelt 45cm
  • Netzteil: SilvStone SST-ST45SF V2 450W SFX
  • Gehäuselüfter: NB BlackSilentPRO PR-1 60x60x25
  • Kühlkörper: Prolimatech Samuel 17
  • CPU-Kühler: EKL Alpenföhn Wing Boost 12 cm (4,7 Zoll) Lüfter

Das ganze System kommt ohne extra Grafikkarte, sollte aber zwei digitale Grafikausgänge haben. In dem Fall hier ein Displayport und DVI Ausgang. Die aktuellen Ivy-Bridge CPUs unterstützen bis zu zwei Digitale Ausgänge. Ist noch eine analoger Anschluss dabei, kann dieser nicht verwendet werden bzw. es muss auf einen digitalen Anschluss verzichtet werden. Was die Grafikkartentreiber angeht, muss man sich bei Intel keine Gedanken machen, da die Treiber eh OpenSource sind und so standardmäßig im Linuxkernel liegen.

cooltek1

Das Gehäuse ist ein Coolcube Mini von der Marke Cooltek. Zu beachten ist, dass es wirklich ,,Mini” ist. Als Netzteil passen nur SFX-Formfaktor Stromspender hinein. Hier ist der Markt noch relativ dünn gesäht. Auch muss bei dem CPU-Lüfter aufgepasst werden, da dieser nicht höher als ca. 7,5 cm sein darf. Festplatten passen entweder eine 3,5 Zoll oder zwei 2,5 Zoll Festplatten / SSDs hinein. Sollten zwei 2,5 Zoll Platten eingebaut werden, muss darauf geachtet werden, dass der optionale 60mm Gehäuselüfter nicht zu tief ist. Ansonsten stößt dieser gegen eine der beiden Platten, so dass dies dann nicht mehr passt.

Der Einbau ist ziemlich frickelig, da hier nur wenig Platz zur Verfügung steht. Als erstes sollte das Mainboard mit CPU-Kühlkörper eingebaut werden. Alle unter dem Kühlkörper liegenden Verkabelungen zuerst vornehmen. Zuerst das Mainboard verschraube, bevor der CPU Kühler angeschraubt wird, da er die Schrauben verdeckt. Nun alle Verkabelungen vornehmen und zuletzt das Netzteil einbauen. Am besten ist es, den CPU-Lüfter so montieren, dass die Luft von der CPU weggeblasen wird (das Netzteil natürlich mit Lüfter zum Mainboard zeigend. So kann die Warme Luft über das Netzteil nach außen transportiert werden. Ein kleiner leiser zusätzlicher Gehäuselüfter transportiert frische kühle Luft in das Gehäuse hinein.

$ sensors
acpitz-virtual-0
Adapter: Virtual device
temp1: +27.8°C (crit = +106.0°C)
temp2: +29.8°C (crit = +106.0°C)
coretemp-isa-0000
Adapter: ISA adapter
Physical id 0: +43.0°C (high = +85.0°C, crit = +105.0°C)
Core 0: +37.0°C (high = +85.0°C, crit = +105.0°C)
Core 1: +42.0°C (high = +85.0°C, crit = +105.0°C)
Core 2: +42.0°C (high = +85.0°C, crit = +105.0°C)
Core 3: +36.0°C (high = +85.0°C, crit = +105.0°C)

Die


Sonntag
01. September 2013


face

froscon13Da ich dieses Jahr arbeitsbedingt Samstag verhindert war, konnte ich nur am zweiten Tag an der FrOSCon teilnehmen. Zum Glück sprang Jörg Stephan noch kurzfristig ein und organisierte einen openSUSE Stand (unter anderem mit ZFS auf openSUSE)

Da es am Sonntag erwartungsgemäß ruhig war, zog ich auch meine Runden und quatsche eine Runde mit den Leuten von Magiea sowie Arch Linux. Letztlich habe ich es sogar noch zu zwei interessanten Vorträgen geschafft. Besonder der Talk von Uwe Ziegenhagen - Python und LaTeX vereint fand ich sehr interessant. Sollte ich mal wieder Luft haben, werde ich mir dies auf jedenfall mal genauer ansehen.

Ansonsten gibt es meinerseits nicht viel von der FrOSCon zu berichten. Sollte nichts dazwischen kommen sehen wir uns im November 2013 auf der OpenRheinRhur.


Mittwoch
14. August 2013


face

AMD Catalyst 13.8 Beta1 (fglrx 13.20.5) wurde veröffentlicht und unterstützt Grafikkarten ab Radeon HD 5000 und höher. Das Skript makerpm-amd-13.8-beta1.sh steht ab sofort zum Download zur Verfügung und unterstützt openSUSE 11.4, 12.1, 12.2, 12.3 sowie bis Kernel 3.10.

[UPDATE 19.08.2013]
Im AMD Catalyst 13.8 Beta1 ist für den fglrx-Kernelmodul eine neue Funktion für den EFI-Teil hereingekommen. Dadurch wurde ich auf einen Kompilierfehler aufmerksam gemacht (Vielen Dank an dieser Stelle an Martin Schröder und Torsten). Der Fehler beim Kompilieren “error: called object ‘efi_enabled’ is not a function” ist nun mit dem neuesten Packaging Skript behoben.

Nun zu den technischen Details:
Die o.g. Fehlermeldung beim Kompilieren des fglrx-Kernelmodul für den Kernel 3.4.47 unter openSUSE 12.2 erschließt sich mir im ersten Moment nicht. Erst als ich openSUSE 12.2 auf einer separaten Partition installiert habe und dann Nachforschungen angestellt habe, kam zu dem Fehler ungeheuerliches zum Vorschein.

Zuerst ist im Kernelcode 3.4.47 ein EFI-Code reingepatcht worden, welches eher dem EFI-Code in neueren Kernelcodes zu finden ist. Dann wurde ein EFI-Patch (kabi-re-add-efi_enabled-variable.patch) von Jiri Slaby (SUSE Niederlassung in Tschechien) angewendet. Der genannte Patch baut quasi die vorhandene Funktion efi_enabled(EFI_BOOT) zu efi_enabled_f(EFI_BOOT) um und ersetzt dann efi_enabled als Variable, um anscheinend das alte Verhalten wegen eines Patch für die Samsung-Laptops wiederherzustellen.

Da EFI_BOOT aber immer noch definiert ist und dieser nur im neuen EFI-Code vorkommt, wird der Patch an der Stelle logischerweise Probleme machen. Das wird nicht nur beim Kompilieren des fglrx-Kernelmodul krachen, sondern woanders auch. Richtig wäre es gewesen, wenn man konsequenterweise EFI_BOOT auch umbenannt hätte. Ein undeklariertes EFI_BOOT wird im entsprechend Code als Variable efi_enabled andernfalls über die Funktion efi_enabled(EFI_BOOT) ausgelesen.

Wieso zum Geier müssen einige Leute im Kernel nur wegen einem Samsung-Laptop mit dem total kaputten UEFI herumpfuschen?! Hier hat der Hersteller die Sorgfaltspflicht ein BIOS-Update herauszubringen und nicht irgendwelche Kernel-Entwickler, die dadurch mehr kaputt machen als reparieren können!!! Ein Bugreport geht auch nochmal separat an die Kernel-Maintainer von openSUSE heraus, um den o.g. “re-add-efi_enabled-variable”-Patch ordentlich machen zu lassen. So kann es definitiv nicht bleiben.
[/UPDATE 19.08.2013]

Auf Grund der großen Nachfrage (Blog, E-Mail, Forum, IRC) nach einem makerpm-amd-Skript für die öffentliche Beta-Reihe, habe ich mich nun dazu entschlossen, diese auch mit dem Skript direkt zu unterstützen. Die Begründung ist, dass die letzte Version (AMD Catalyst 13.4) schon etwas älter ist und die Entwicklung des Treiber natürlich nicht aufgehört hat, sondern in Form eines Beta-Treiber als eine Art “Snapshot” von den AMD-Entwickler zur Verfügung gestellt wird.

Zwischenzeitlich sind ein paar Bugs bekannt geworden, die ein Arbeiten mit dem Treiber unmöglich gemacht haben. Bei einer 3D-Anwendung sind folgende Meldungen aufgetaucht und der Absturz der Anwendung folgte unmittelbar:

libGL error: open uki failed (Operation not permitted)                                                                                                                                                         
libGL error: reverting to (slow) indirect rendering 

Sonntag
21. Juli 2013


face

muninMunin ist ein Hardwaremonitoring Werkzeug für Linux/Unix Systeme, welches sehr einfach zu installieren ist und es ermöglicht, mehrere PCs und Server zu überwachen. Dabei fragt ein Master-Node in regelmäßigen Abständen die Clients und bereitet die Daten grafisch auf.

Installation

Die Installation ist sehr einfach gehalten. Installieren Sie zuerst als root mittels

yum install munin munin-node

die nötigen Pakete.

Klammern Sie nun in der Datei /etc/munin/munin.conf folgendes aus, um die Daten anzeigen zu lassen. Auf Clients müssen Sie dies nicht tuen, wenn nur Daten abgefragt werden sollen.

dbdir /var/lib/munin
htmldir /var/www/html/munin
logdir /var/log/munin
rundir /var/run/munin

Passwortabfrage

Später können Sie unter http://localhost/munin auf die Grafiken zugreifen. Wenn Sie dies durch ein Passwort geschützt haben wollen müssen Sie zuerst eines mittels

htpasswd -c /etc/munin/munin-htpasswd username

erstellen.

Außerdem müssen Sie noch eine Datei unter /etc/httpd/conf.d/munin.conf erstellen bzw. bearbeiten und mit folgenden füllen:

<directory /var/www/html/munin>
AuthUserFile /etc/munin/munin-htpasswd
AuthName "Munin"
AuthType Basic
require valid-user
ExpiresActive On
ExpiresDefault M310
</directory>
ScriptAlias /munin-cgi/munin-cgi-graph /var/www/cgi-bin/munin-cgi-graph

Nach einem

service httpd restart

erscheint nun eine Passwortabfrage.

Plugins konfigurieren

Munin verfügt ab Werk über eine große Anazahl an Plugins. Diese liegen unter /usr/share/munin/plugins
Wenn Sie eines der Plugins verwenden möchten so müssen Sie es nur linken

ln -s /usr/share/munin/plugins/df /etc/munin/plugins

Ob zu kontrollieren, ob ein Plugin konfiguriert werden muss, können Sie es einfach ausführen:

./df autoconf

Erscheint ein Yes müssen Sie nichts mehr vornehmen.

Einige Plugins sind Wildcard Plugins und enden auf einen Unterstrich wie zum Beispiel sensors_. Führen Sie diese mit der Option suggest aus um die möglichen Optionen zu erhalten:

./sensors_ suggest

Nun können Sie ja nach gewünschter Option die Datei umbennen

mv sensors_ sensors_fan

Manche Plugins können in der Datei /etc/munin/plugin-conf.d noch weiter angepasst werden. Dies würde den Artikel aber sprengen, deswegen hier nur ein Beispiel:

[sensors_*]
 
env.ignore_fan3 true
env.ignore_fan4 true
env.ignore_volt3 true
env.ignore_volt7 true
 
[smart_*]
user root
group root
 
[hddtemp_smartctl]
user root
group root
env.ignore "sda"

Andere Systeme verbinden

Munin selber benutzt den Port 4949, den Sie in der Firewall, wenn laufend, frei geben müssen. Andere Munin Installation können dann von der oben eingerichteten Master-Server abgefragt werden. Wenn nur ein Client (Node) installiert wird, können Sie die Einstellungen von munin.conf und dem Apache ignorieren. Auschlaggebeden ist nur die munin-node.conf an der Sie allerdings nichts mehr einstellen müssen. Sie können dort festlegen welche IPs auf die gesammelten Daten zugreifen kann um diese Abzufragen.

Beim Master-Server tragen Sie die zusätzlichen PCs / Server in der munin.conf ein. Hier eine Beispiel:

[Lokal]
address 127.0.0.1
use_node_name yes
[Server_1]
address 10.0.0.5
use_node_name yes
[Server_2]
address 

Mittwoch
10. Juli 2013


face

Zur Erinnerung: Am ersten August-Wochenende (02.08.-04.08.2013) findet in Hesselberg das Anwendertreffen 2013 statt. Es werden noch Leute für den regen Informationsaustausch zu openSUSE wie auch für einen netten Plausch gesucht. ;-) Meine Wenigkeit wird auch vor Ort sein. Am Samstag Abend wird gemeinsam gegrillt. Das Grillgut kann entweder selbst mitgebracht oder bei den Organisatoren bestellt werden.

Folgende Vorträge sind derzeit geplant (Weitere können noch hinzukommen):

  • Freitag (Abend):
    • Einführung in SSH, SSHFS, SCREEN
    • Einführung zur Programmierung eines Bash-Skripts
  • Samstag:
    • Vorstellung der openSUSE Wiki
    • Einführung zur Erstellung eines RPM-Paketes
    • Einführung in die Arbeit mit dem Open Build Service (OBS)
  • Sonntag (Vormittag):
    • Austausch von offenen Fragen und weiteren Tipps & Tricks für die tägliche Arbeit mit openSUSE

Die Organisatoren sind sich bewusst, dass die o.g. Vorträgen sich zum Teil an Semiprofessionelle oder die es gerne werden möchten gerichtet sind. Sie sind gerne für weitere Themenvorschläge auch für den einfachen Anwender offen. Vor Ort können auch aufkommende Fragen, die in anderen Themenbereichen einschlagen, gemeinsam erörtert werden. Auch spezielle Problematiken im Alltag mit openSUSE oder Linux im Allgemeinen können auf diese Weise mit erfahrenen Linux-Usern ausgetauscht werden.

Den Teilnehmern wird empfohlen, sich für 2 Übernachtungen einzuplanen. Ob man Vollpension haben möchte, individuelles Frühstück & Mittagessen & Abendessen oder nur das Zimmer mit der Möglichkeit selbst für Verpflegung zu sorgen, ist jedem selbst überlassen.

Preisliste für die Übernachtung und Verpflegung zum Download: Preisliste2013.pdf

Wer am Anwendertreffen 2013 teilnehmen möchte oder weitere Fragen hat, möge sich bitte via E-Mail/IRC an Marcel Kühlhorn a.k.a. tux93 (E-Mail: tux93 (at) opensuse (punkt) org) oder im IRC an Karl Thomas Schmidt a.k.a. }ls{ wenden. Wenn es um die Anmeldung geht, kann ich auch behelfsmäßig einspringen und leite die Informationen an die Organisatoren weiter. Im Moment sind noch Plätze wie auch Zimmer frei. Bitte bedenkt: Je näher der Termin rückt, desto weniger Plätze sind dann noch frei.

Die Organisatoren wie auch ich würden uns auf zahlreiche Teilnehmer freuen.

Quelle:


Sonntag
02. Juni 2013


Christian Boltz: LinuxTag

22:27 UTCmember

face
Bernhard (on the left) answering questions
Jos at Towel day (aren't you exaggerating a bit? ;-)

Vor gut einer Woche ging der LinuxTag zu Ende. Zeit, kurz darüber zu schreiben ;-)

Ich war drei Tage in Berlin. Neben einigen interessanten Vorträgen war ich oft am openSUSE-Stand, um die Fragen der Besucher zu beantworten und habe mit 3 Runden openSUSE Jeopardy dafür gesorgt, das openSUSE-Motto "have a lot of fun" umzusetzen.

Außerdem hatte ich mich mit PostfixAdmin am Stand "einquartiert". Das erwies sich als Vorteil, weil deutlich mehr PostfixAdmin-Benutzer und -Interessenten zu mir kamen als letztes Jahr am Project Meeting Point.

An dieser Stelle vielen Dank an Bernhard, Jos und Sascha, die mit mir den openSUSE-Stand betreut haben, und ans Travel Support Programm für die Unterstützung bei den Reisekosten.

LinuxTag ended about a week ago. Time to write about it ;-)

I was in Berlin for three days. Besides listening to several interesting talks, I often was at the openSUSE booth, answered the visitor's questions and did 3 rounds of openSUSE Jeopardy to put the openSUSE motto "have a lot of fun" into practise.

Besides that, I "accomodated" myself with PostfixAdmin at the openSUSE booth. This turned out to be an advantage because many more PostfixAdmin users and might-become-users came to me (compared to the Project Meeting Point last year).

Thanks a lot to Bernhard, Jos and Sascha who manned the openSUSE booth together with me, and the travel support program for supporting me.


Mittwoch
08. Mai 2013


face

TokuDB von Tokutek.com ist seit ein paar Tagen OpenSource. Erstmal Daumen hoch !. Es handelt sich dabei um eine Storageengine für das DBMS System Mysql, oder eins seiner Derivate, z.B MariaDB. Letztere verschmelzt gerade mit den Entwicklern des Percona Servers. Auch dafür Daumen hoch!.

ABER

Wer Probleme hat das fertige Binary Build von MariaDB + TokuDB unter Centos oder RHEL zum laufen zu bekommen befolge oder besser prüfe den folgenden Sachverhalt, bei mir hat es geholfen, dass der Dienst endlich startet.

Im Errorlog taucht folgendes auf:

130507 13:17:07 [ERROR] Plugin 'TokuDB' init function returned error.
130507 13:17:07 [ERROR] Plugin 'TokuDB' registration as a STORAGE ENGINE failed.
130507 13:17:07 [ERROR] Unknown/unsupported storage engine: TokuDB
130507 13:17:07 [ERROR] Aborting

Das war der einzige erkennbare Fehler, aber entscheidend sind genau die zwei Zeilen im Log davor

Transparent huge pages are enabled, according to /sys/kernel/mm/redhat_transparent_hugepage/enabled
Transparent huge pages are enabled, according to /sys/kernel/mm/transparent_hugepage/enabled

nach Stunden langem googlen habe ich einen Kommentar in einem Blog gefunden, der genau darauf verwiesen hat. Unter den beiden Systemen Centos und RHEL muss man noch folgendes ausführen, damit der Dienst sauber startet

echo never >   /sys/kernel/mm/redhat_transparent_hugepage/enable

Quelle:


Freitag
26. April 2013


face

AMD Catalyst 13.4 (fglrx 12.104) wurde veröffentlicht und unterstützt Grafikkarten ab Radeon HD 5000 und höher. Das Skript makerpm-amd-13.4.sh steht ab sofort zum Download zur Verfügung und unterstützt openSUSE 11.4, 12.1, 12.2, 12.3 sowie bis Kernel 3.8.

[UPDATE 19.08.2013]
Durch den Patch von Kolasa ist eine neue Funktion für den EFI-Teil für den fglrx-Kernelmodul hereingekommen. Dadurch wurde ich auf einen Kompilierfehler aufmerksam gemacht (Vielen Dank an dieser Stelle an Martin Schröder und Torsten). Der Fehler beim Kompilieren “error: called object ‘efi_enabled’ is not a function” ist nun mit dem neuesten Packaging Skript behoben.

Nun zu den technischen Details:
Die o.g. Fehlermeldung beim Kompilieren des fglrx-Kernelmodul für den Kernel 3.4.47 unter openSUSE 12.2 erschließt sich mir im ersten Moment nicht. Erst als ich openSUSE 12.2 auf einer separaten Partition installiert habe und dann Nachforschungen angestellt habe, kam zu dem Fehler ungeheuerliches zum Vorschein.

Zuerst ist im Kernelcode 3.4.47 ein EFI-Code reingepatcht worden, welches eher dem EFI-Code in neueren Kernelcodes zu finden ist. Dann wurde ein EFI-Patch (kabi-re-add-efi_enabled-variable.patch) von Jiri Slaby (SUSE Niederlassung in Tschechien) angewendet. Der genannte Patch baut quasi die vorhandene Funktion efi_enabled(EFI_BOOT) zu efi_enabled_f(EFI_BOOT) um und ersetzt dann efi_enabled als Variable, um anscheinend das alte Verhalten wegen eines Patch für die Samsung-Laptops wiederherzustellen.

Da EFI_BOOT aber immer noch definiert ist und dieser nur im neuen EFI-Code vorkommt, wird der Patch an der Stelle logischerweise Probleme machen. Das wird nicht nur beim Kompilieren des fglrx-Kernelmodul krachen, sondern woanders auch. Richtig wäre es gewesen, wenn man konsequenterweise EFI_BOOT auch umbenannt hätte. Ein undeklariertes EFI_BOOT wird im entsprechend Code als Variable efi_enabled andernfalls über die Funktion efi_enabled(EFI_BOOT) ausgelesen.

Wieso zum Geier müssen einige Leute im Kernel nur wegen einem Samsung-Laptop mit dem total kaputten UEFI herumpfuschen?! Hier hat der Hersteller die Sorgfaltspflicht ein BIOS-Update herauszubringen und nicht irgendwelche Kernel-Entwickler, die dadurch mehr kaputt machen als reparieren können!!! Ein Bugreport geht auch nochmal separat an die Kernel-Maintainer von openSUSE heraus, um den o.g. “re-add-efi_enabled-variable”-Patch ordentlich machen zu lassen. So kann es definitiv nicht bleiben.
[/UPDATE 19.08.2013]

[UPDATE 04.08.2013]
Das Patch von mir habe ich gegen das Patch von Kolasa aus dem GitHub ausgetauscht. Da der Maintainer noch weitere sinnvolle Bugfixes eingebracht hat. Ab sofort wird nun bis Kernel 3.10 unterstützt. Das Packaging Skript habe ich hingehend erneuert. An dieser Stelle vielen Dank an Paolo Marzari für den Hinweis und Kolasa für die Änderungen am fglrx-Code.
[/UPDATE 04.08.2013]

AMD hat erfreulicherweise wieder eine Release Notes für Linux veröffentlicht. ;-)

Neu bei dem Treiber ist:

  • OpenCL Console Mode Support
  • Kernel 3.7 and 3.8 Support

Folgende Probleme sind im Treiber behoben worden:

  • [370253]: Serious Sam 3 – Color of Objects turning into be red when enabling separate shader object
  • [371937]: Team Fortress 2 – Screen black

Sonntag
17. März 2013


face
openSUSE Stand

openSUSE Stand

Das waren sie schon wieder. Die Chemnitzer Linux Tage 2013. Dieses Jahr wie immer gut besucht. Gefühlt sogar etwas mehr als letztes Jahr, was vielleicht auch an dem dieses mal offenen Vortagsprogramm lag, welches inhaltlich wesentlich ausgewogener war. Und natürlich habe ich mir vorgenommen ein paar Vorträge zu besuchen, was letztlich dann doch nur in einem geendet ist (der dann aber auch wirklich interessant war).

Der openSUSE-Stand war die beiden Tage gut besucht, wohl auch weil wir uns den Stand zusammen mit ownCloud geteilt haben. ownCloud ist ein OpenSource Projekt welches von der ownCloud Inc. maßgeblich gefördert wird. Das Projekt erstellt eine Softwarelösung auf Basis von PHP, SQLite / MySQL, die es erlaubt, dass jeder seinen eigenen Cloudspeicher, ähnlich wie Dropbox einrichten kann und auf seinen eigenen Server(n) laufen lässt. Dies kann unter anderem auch auf einem Rapsberry Pi geschehen.

wildes Weltraumspektakel gegen Ende der CLT

wildes Weltraumspektakel gegen Ende der CLT

Alexander Graf brachte am Samstag im Zuge seines ARM Vortrags auch noch einiges an Hardware unter anderem ein Chromebook von Google mit, welches allerdings auch von SD-Karte ein openSUSE booten konnte.

Am Fedora-Stand konnte man eine 3D-Drucker bei der Arbeit beobachten, der im Akkord Fedora Logos, Bausteine, Trillerpfeifen und andere Modelle produzierte.

Letztendlich waren wir mit der CLT wieder sehr zufrieden. Die Organisation hat auf der Seite der CLT super geklappt. Nur das Wetter wollte nicht so wirklich mitspielen. Letztes Jahr konnten wir noch mit dem T-Shirt draußen herumlaufen. Dieses Jahr war es da doch ein wenig kälter.


Dienstag
12. März 2013


face

(Kleine Werbeeinlage auf speziellen Wunsch von Michal Hrušecký ;-)

Die meisten Leute wissen wahrscheinlich schon, dass openSUSE 12.3 diesen Mittwoch (also morgen) releast wird.

Um das zu feiern, gibt es (ebenfalls am Mittwoch, also morgen) ab 19:00 Uhr eine Release Party im Artefakt in Nürnberg, bei der jeder willkommen ist. Dort kann man viele Geekos treffen, auch das openSUSE-Team von SUSE hat sich angekündigt und freut sich darauf, viele openSUSE-Begeisterte, Unterstützer und Benutzer zu sehen. Für Essen und openSUSE-Bier ist laut Michal gesorgt.

Natürlich ist auch der Star des Tages da - openSUSE 12.3 wird auf einem Demo-Rechner gezeigt. Mit etwas Glück gibt es auch ein Google Hangout für alle, die nicht nach Nürnberg kommen können - Infos dazu auf der openSUSE G+-Seite.

Ich selbst kann leider nicht zur Party kommen, wünsche aber allen viel Spaß ;-)


Samstag
23. Februar 2013


face

idp13Heute ist, wie schon in verschiedenen Medien berichtet, der Tag für Datenschutz und Privatsphäre  Im Zuge dessen gab es in mehreren Städten Kundgebungen und Demonstrationen. Unter anderem auch in Düsseldorf, wo ca. 50 bis 60 Leute für die Privatsphäre bei eisigen Temperaturen auf die Straße gingen. Neben zwei Kundgebungen, in der Altstadt sowie vor dem Landtag, wurde Passanten mit Flugblättern aufgeklärt was sich hinter Acta und INDECT verbirgt. Einer der Redebeiträge kann hier nachgelesen werden.


Freitag
22. Februar 2013


face
Cisco IP Phone 7960

Cisco IP Phone 7960

Das das Cisco IP Phone ein schönes Gerät ist, scheint in vielen Kreisen bekannt zu sein. Das gute ist, dass es sich als IP Telefon sogar an der Fritzbox nutzen lässt. Auch wenn es ein wenig Spielerei und Gefummel ist.

Die Geräte gibt es bei eBay für 30 bis 50 Euro gebraucht bzw. neu für etwa 120 bis 200 Euro.

Bitte zuerst die Anleitung komplett lesen. Auch den unten aufgeführten Link lege ich sehr ans Herz. Durch das flashen mit der falschen Firmware kann das Gerät u.U. nicht mehr funktionieren. Die Konfigurationsdateien können immer wieder neu eingespielt werden. Falsche Konfigurationsdateien sollten das Gerät nicht unbrauchbar machen.

Fritzbox vorbereiten

Einfach unter Telefonie > Telefoniegeräte > Neues Gerät einrichten klicken und dann Telefon auswählen. Im nächsten Dialog wählen Sie LAN/WLAN (IP-Telefon) aus und geben Sie dem Gerät einen Namen. Drücken Sie dann weiter. Im nächsten Dialog notieren Sie sich die Angaben und wählen ein Passwort aus. Dann noch die Rufnummer einrichten und das war es an der Fritz!Box auch schon.

TFTP Server einrichten

Windows

Für Windows empfehle ich TFTPD32.

Linux

Diese Anleitung bezieht sich auf CentOS / Scientific Linux.

yum install tftp-server
chkconfig --level 345 xinetd on
chkconfig --level 345 tftpd on

Die benötigten Dateien können dann später nach

/var/lib/tftpboot

abgelegt werden.

(Falls noch eine Firewall läuft muss der Port noch freigegeben werden. Dies kann mit system-config-firewall-tui geschehen.)

Konfigurationsdateien

Je nachdem welche Firmware Sie auf dem Gerät installiert haben müssen Sie dieses erst flashen. Die nötigen Dateien finden Sie, wen Sie einen Supportvertrag mit Cisco haben in deren Downloadbereich oder z.B. unter

http://radiotwenterand.nl/~graver/cisco/SIP-7960/

Ich habe mich für die Release P0S3-8-12-00.zip entschieden. Dies funktionierte auch bei mir ohne Probleme. Entpacken Sie das Archiv einfach in den tftpboot Ordner.

Nun kommt die schwierigere Aufgabe. Die Konfigurationsdateien für das Telefon. Hier habe ich bei http://www.europott.org/2009/05/31/cisco-7960g-und-fritzbox-fonwlan abgeschaut. Die Anleitung ist sehr gut gemacht und die zum Download bereitstehenden Konfigurationsdateien haben bei mir funktioniert. Dort beachten Sie einfach die Kommentare in den ersten Zeilen der Dateien. Die bennenung der der SIP[MAC].cnf wird auf der oben genannten Webseite erklärt.

Allerdings müssen Sie an der SIPDefault.cnf eine änderung vornehmen. Klammern Sie

# image_version: "P0S3-08-8-00" Auskommentiert da SIP Firmware schon geladen ist

aus und ändern Sie die Zeile so ab wie die Firmware heisst. In unserem Falle

image_version: "P0S3-8-12-00"

Wenn Sich das Telefon dann die Konfiguration abholen möchte wird es sich direkt flashen. Die beiden Konfigurationsdateien kommen dann nach dem Ändern der entsprechende Zeilen auch in den tftpboot Ordner. Ändern Sie die Rechte noch mit

chmod 777 /var/lib/tftboot

ab.

Telefon einrichten

Wenn Sie jetzt das Gerät richtig angeschlossen haben (Netzwerkkabel gehört in den mit Switch beschrifteten Anschluss) wird erstmal nicht viel passieren


Donnerstag
07. Februar 2013


face
kfritz1

Anrufliste von KFritz

Nach Umzug und Vertragswechsel bei meinem Provider gab es ein neues Modem. In meinem Fall ein AVM Fritz!Box 6360 Cable. Das schöne dabei ist die Möglichkeit, die Anrufliste aus der Fritz!Box auszulesen. Besonders auf KDE angepasst gibt es das Programm KFritz zu finden unter http://www.joachim-wilke.de/kfritz.htm. Der Vorteil an diesem Programm liegt noch dabei, dass es Benachrichtigungen (KNotify) beherrscht.

kfritz2

KFritz benachrichtigt bei Anrufen

So bekommt man beim Anruf direkt zu sehen wer anruft. Ist die Nummer nicht im Telefonbuch der Fritz!Box hinterlegt so sucht das Programm automatisch in Telefonnummerdatenbanken nach dem Namen des Besitzers. Das Systemabschnittssymbol passt sich auch gut in die Standardsymbole ein.

Das einzige was man Einstellen muss ist eventuell die IP der Fritz!Box (wenn nicht unter fritz.box erreichbar) sowie das Passwort für jene.

Leider hat es bei mir nicht funktioniert neue Kontakte zu den Fritz!Box Kontakten hinzuzufügen. Zwar werden die Kontakte in der Liste angezeigt, sind aber nach einem Refresh nicht mehr vorhanden. Auf der Fritz!Box tauchen sie garnicht auf. Stört mich allerdings weniger. Die Hauptsache der Meldung für ein- und ausgehende Telefonverbindungen reicht mir hier völlig.

Installation

Das Programm gibt es für alle großen Linuxdistribution.
openSUSE User laden sich das Programm von http://download.opensuse.org/repositories/home:/rbos/openSUSE_12.1/i586/ herunter.

Arch Linux Nutzer finden im AUR ein PKGBUILD (https://aur.archlinux.org/packages/?O=0&K=kfritz). Das kompilieren dauert nicht lange.

Andere Distributionen haben auch passende Pakete zur Hand. Genaueres gibt es auf der Entwicklerseite.


Freitag
25. Januar 2013


face

AMD Catalyst 13.1 Legacy (fglrx 8.97.100.7) wurde veröffentlicht und unterstützt nur ältere Grafikkarten der Serie Radeon HD 2000 bis einschließlich HD 4000. Das Skript makerpm-amd-13.1-legacy.sh steht ab sofort zum Download zur Verfügung und unterstützt openSUSE 11.4, 12.1 und 12.2 sowie bis Kernel 3.8. Das Packaging Skript wurde im Zuge der Kernel-Patches für 3.5 bis einschließlich 3.8 aktualisiert (offiziell wird von AMD nur bis Kernel 3.4 unterstützt).

Im IRC-Chat habe ich um einen Test mit dem Legacy-Treiber auf openSUSE 12.3 Beta 1 gebeten. Freiwillige User haben hierzu Feedback gegeben. Leider sah es nicht besonders gut aus. Auf openSUSE 12.3 ist der X-Server in der Version 1.13.1 im Einsatz und der Legacy-Treiber unterstützt jedoch nur bis 1.12.x.

Da bin ich wie auch viele andere User dem Artikel von Michael Larabel (Phoronix) auf den Leim gegangen. Der Artikel wurde trotz der Beschwerden und Hinweise im Forum immer noch nicht korrigiert. Daher der Hinweis: Der Legacy-Treiber läuft nicht auf openSUSE 12.3 in Verbindung mit dem X-Server 1.13.1.

Man kann den Legacy-Treiber noch mit openSUSE 12.2 bis zum 15. Januar 2014 betreiben, dann endet die Lebenszeit von openSUSE 12.2 und jegliche Updates werden eingestellt. Für Tumbleweed-Benutzer endet es bereits mit der Veröffentlichung von openSUSE 12.3 voraussichtlich am 13. März 2013. Hier wird empfohlen, nach dem Release von openSUSE 12.3 auf entsprechende Repos für openSUSE 12.2 umzusteigen. Alternativ kann man sich openSUSE 12.3 installieren und lässt es mit dem Kernel-Treiber radeon laufen und aktualisiert entsprechend den Kernel, um neuere und stabilere radeon Treiber zu erhalten.

Zu diesem Legacy-Treiber gibt es momentan noch keinen Changelog.

Downloads:

Installationsanleitung:
http://de.opensuse.org/SDB:AMD/ATI-Grafiktreiber#Installation_via_makerpm-amd-Skript

Über das makerpm-amd-Skript

Das Skript makerpm-amd-13.1-legacy.sh ist sehr mächtig, robust und läuft vollautomatisch. Der AMD-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 AMD-Installer downloaden
-i Das RPM-Package bauen und installieren bzw. updaten
-kms <yes|no> Kernel-Mode-Setting (KMS) aktivieren oder deaktivieren
-nohw Hardware-Erkennung explizit ausschalten. (z.B. beim Bau in einer VM)
-old2ddriver <yes|no> den alten 2D-Treiber aktivieren oder deaktivieren
-r|–report erstellt ein Report und speichert diese in eine Datei namens amd-report.txt
-u|–uninstall entfernt AMD Catalyst restlos vom System. Zuerst wird das fglrx-Package (falls vorhanden) vom System deinstalliert. Danach werden vorhandene AMD-Dateien und -Verzeichnisse entfernt. Hinweis: Falls das Rebuild-Skript installiert wurde, wird es ebenfalls entfernt

Freitag
18. Januar 2013


face

AMD Catalyst 13.1 (fglrx 9.012) wurde veröffentlicht und unterstützt Grafikkarten ab Radeon HD 5000 und höher. Das Skript makerpm-amd-13.1.sh steht ab sofort zum Download zur Verfügung und unterstützt openSUSE 11.4, 12.1 und 12.2 sowie bis Kernel 3.8. Das Packaging Skript wurde im Zuge der Kernel-Patches für 3.7 und 3.8 (offiziell wird von AMD nur bis Kernel 3.6 unterstützt) und der vorläufigen Unterstützung von openSUSE 12.3 Beta 1 aktualisiert. Der Treiber kann auch unter openSUSE 12.3 Beta 1 installiert werden (Feedback erwünscht).

Ursprünglich sollte AMD Catalyst 12.12 (fglrx 9.011) im Dezember 2012 herauskommen. Jedoch habe ich einige Mängel zu dieser Treiberversion bei AMD gemeldet und darum gebeten, diese AMD Version zu überspringen. Offenbar haben die AMD-Entwickler es ebenso gesehen und war auch einer der Gründe für die Verspätung des Treibers.

AMD hat erfreulicherweise wieder eine Release Notes für Linux veröffentlicht. Es hat sich gelohnt, bei AMD regelmäßig mit diesem Anliegen auf der Matte zu stehen. ;-)

Neu ist bei dem Treiber die X-Server 1.13 Unterstützung.

Folgende Probleme sind im Treiber behoben worden:

  • [368958]: Driver release version is added to GL_VERSION
  • [367282]: Bblank VGA display after resume from suspend
  • [367245]: X crash for AMD PowerXpress™ A+I High-Performance mode on Ubuntu 12.10
  • [366820] Performance of Valve Linux games
  • [366805]: Segmentation fault when exit QtOpenGL applications such as AMD CodeXL
  • [366425]: Xserver getting exit upon resume from suspend on RHEL 5.8
  • [364107]: VariBright not working when change AMD PowerPlay™ settings in AMD Catalust Control Center:LE
  • [363638]: VariBright doesn’t work after resume from suspend on “Trinity” platform
  • [350759]: Flickering cursor when run some full-screen OpenGL games with CrossFire enabled
  • [347895]: OpenGL performance on “Southern Islands” ASICs
  • [344996]: 16 re-frames doesn’t work for H.264 @Level 5.1
  • [337240]: Corruption when resize the Konsole window
  • [304016]: One display goes black after changing from multi-display desktop from single independent

Link: AMD Catalyst™ 13.1 Proprietary Linux® Graphics Driver Release Notes

Eine kleine Bitte habe ich: Wenn irgendwelche Probleme mit dem Treiber auftauchen, scheut euch nicht mir zu berichten (Ich nehme deutsche und englische Bugreports gerne entgegen). ;-) Ich werde versuchen, soweit es mir möglich ist, den gemeldeten Fehler zu reproduzieren. Zusammen mit den nötigen System-Informationen werde ich mich direkt an die richtige Stelle bei AMD wenden, um den Bug in der nächsten Treiber-Version beheben zu lassen. Danke schön. :-D

Für Benutzer älterer AMD Grafikkarten (Radeon HD Serie 2000 – 4000) wird dringend die Installation dieses Treibers abgeraten. AMD hat einen Legacy-Treiber zur Verfügung gestellt. Mehr Informationen zum Legacy Treiber: http://www.sebastian-siebert.de/2013/01/25/opensuse-amd-catalyst-13-1-legacy-treiber-als-rpm-installieren/

Downloads:

Installationsanleitung:
http://de.opensuse.org/SDB:AMD/ATI-Grafiktreiber#Installation_via_makerpm-amd-Skript

Über das makerpm-amd-Skript

Das Skript makerpm-amd-13.1.sh ist sehr mächtig, robust und läuft vollautomatisch. Der


Donnerstag
10. Januar 2013


face

Die HMM Deutschland GmbH sucht zur Verstärkung ihres Teams einen Linux Admin.
Wenn also jemand Interesse hat bitte eine Bewerbung an:

bewerbung (at) hmmdeutschland.de senden.

Informationen zum Unternehmen gibt es unter der Adresse www.hmmdeutschland.de


Dienstag
08. Januar 2013


face

Die Planung zum nächsten openSUSE Anwendertreffen 2013 ist bereits angelaufen. Der Termin für das Treffen steht in der ersten Runde fest und ist der 03. August 2013. Die meisten Teilnehmer haben dieses Datum gewählt. Meine Wenigkeit wird auch anwesend sein und freue mich riesig alle aus der openSUSE-Community kennenzulernen. Wer kommen möchte, ist herzlichst zum openSUSE Anwendertreffen 2013 eingeladen und würde mich über rege Teilnahme freuen. ;-)

Nun ist noch der Veranstaltungsort offen und kann ab sofort über eine Umfrage via Mehrfachauswahl (Multiple Choice) öffentlich abgestimmt werden (Link). Die vorgeschlagenen Orte wurden so gewählt, dass diese in etwa zentral in Deutschland gelegen sind und über eine gute Verkehrsverbindung und/oder Übernachtungsmöglichkeit verfügt, um möglichst viele an der Teilnahme des Anwendertreffen zu ermöglichen. Der Veranstaltungsort mit den meisten Stimmen zum Abschluss der Umfrage am 28. Februar 2013 gewinnt.

Um die Abstimmung zu erleichtern, wurde zu jedem Veranstaltungsort ein Link zur Webseite sowie ein Link zu Google Maps für die Routenplanung angegeben:

  1. Ökomarkt Vachdorf (Veranstaltungsort auf Google Maps / Vorschlag von Kanonentux)
  2. EBZ-Hesselberg (Veranstaltungsort auf Google Maps / Vorschlag von boser)
  3. Unperfekthaus Essen (Veranstaltungsort auf Google Maps / Vorschlag von mir / Sebastian Siebert)
  4. Bildungsstätte Bundeshöhe Wuppertal (Veranstaltungsort auf Google Maps / Vorschlag von yogie)

Link zur Umfrage: openSUSE Anwendertreffen Veranstaltungsort

Link zum Forum: openSUSE Anwendertreffen 2013

Link zum Forum (ursprünglicher Post): openSUSE Anwendertreffen 2013


Montag
31. Dezember 2012


face
Mediacenter mit XBMC

Mediacenter mit XBMC

Frisch zu Weihnachtszeit Anfang Dezember, habe ich mir mal ein kleines Mediacenter gegönnt. Nach nun mehreren erfolgreichen Abenden der Nutzung nun einen kleinen Blogartikel darüber.

Aber erst etwas Theorie meinerseits. Ich wollte für das Mediacenter auf der einen Seite nicht viel Geld ausgeben, denoch auf Standardkomponenten setzen die nicht viel Strom verbrauchen. Dolby oder ähnliches sind für mich nicht von belang. Letztlich habe ich mich für folgenden Komponenten entschieden die ich bei einem großen Onlinecomputerhandel erworben habe:

  • Intel D2550DC2 Mainboard mit aufgelöteten Atom D2550
  • SO-DIMM 2 GB DDR3-1333
  • Antec ISK 300-150 Mini ITX
  • GeForce GT 610 PCI pasiv (dazu später mehr)

Eine alte aber noch gute 2,5″ Festplatte hatte ich noch zur Hand, so das ich hier nichts mehr einkaufen musste. Viel Speicher muss die Platte bei mir nicht haben, da sich das Mediacenter die Medien vom Homeserver holt. Die entsprechenden Ordner sind per SMB freigegeben. Insgesamt hat mich der Einkauf (ohne Festplatte) knapp 215 Euro gekostet.

An dieser Stelle muss ich nun kurz vorgreifen warum ich zusätzlich zu der mit auf dem Atom eingebaute Grafikkarte (eine PowerVR Grafikkarte) eine nVidia Karte eingebaut habe.
Die schon eingebaute Karte des Atom D2550 wird vom Linuxkernel 3.6 aktuell nicht unterstützt. Aus diesem Grund sollten Linux Nutzer die aktuelle Atom Version erstmal meiden, da die Treiber für PowerVR Grafikkarten noch nicht stable sind.

Hardware

PCI Slot mit wenig Luft

PCI Slot mit wenig Luft

Bei dem Zusammenbau ist selber nicht viel zu beachten. Das Gehäuse selber kenne ich noch aus meinem ersten Homeserver. In der neuen Revision ist das Netzteil nun geschlossen und aktiv gekühlt.
Blöderweise lag bei dem Mainboard der Anschluss für den Gehäuselüfter so weit weg, das das Kabel zu kurz war. Aus diesem Grund musste ich mir erstmal eine Verlängerung zusammenlöten damit der Stecker passt.
Die Grafikkarte mit ihrem passiven Kühlkörper ist etwas wuchtig, da der Kühlkörper auch auf der anderen Seite

Grafikkarte ist gut durchlüftet

Grafikkarte ist gut durchlüftet

noch ausgebaut ist. Erst nach dem umlegen von ein paar Kabeln passte die Grafikkarte zufriedenstellend. Hier ist zu beachten, dass nur Grafikkarten mit LowProfile-Blende passen. Von der Hitzeentwicklung her ist die Karte in Ordnung. Sie wird zwar warm aber nicht heiss.

Software

Als Betriebssystem ist ein minimales Arch Linux installiert. Zusätzlich werden über den Befehl

pacman -S xorg-server xorg-xinit xorg-utils xbmc

die nötigen Pakete für XBMC installiert. Damit XBMC automatisch beim Hochfahren mitstartet müssen folgenden Befehle ausgeführt werden:

systemctl enable xbmc
systemctl enable graphical.target

Anfangs hatte ich Probleme dem richtigen Sound. Eventuell müssen Sie hier mit

pacman -S alsa-utils
alsamixer

erst noch die Lautstärke von Hand hochdrehen.

Für die Grafikkarte verwende ich die properitären Grafkikkartentreiber. Diese installieren Sie mit

pacman -S nvidia libvdpau

Vergessen Sie hier nicht die VDPAU Bibliothek zu installieren, wie oben beschrieben, und das XBMC diese auch nutzt (unter Einstellungen > Wiedergabe > Video), ansonsten werden 1080p Videos nur


Sonntag
30. Dezember 2012


face

Wie angekündigt habe ich versucht auf das Galaxy Tab 2 KDE zum laufen zu bringen, leider erfolglos.
Nachdem das Gerät erfolgreich gerootet wurde (dies wird für Installation von Ubuntu benötigt, bzw. für alle Anwendungen die im chroot Kontext laufen sollen) habe ich Ubuntu per Installer darauf installiert. Ich wurde nach dem Booten auf der Shell begrüßt und habe danach ein apt-get install kde-desktop eingegeben. Alle Pakete wurde runter geladen und installiert. Leider fährt das Ubuntu danach nicht richtig hoch, man sieht kurz den Bildschirm flackern und landet danach in einem Blackscreen. Im Logfile des Grafikservers ist leider kein Hinweis zu finden, was schief gelaufen ist, auch die sonstigen Logfiles sehen sauber aus. Leider fehlt mir nun die Zeit mich damit weiter zu beschäftigen, aber einen Versuch war es wert.


Montag
24. Dezember 2012


face

An dieser Stelle wünsche ich euch heute Abend und die nächsten Weihnachtstage ein besinnliches und ruhiges Fest.


Freitag
07. Dezember 2012


face

Ich habe mich dazu entschlossen zwischen den Feiertagen ein kleines Projekt zu realisieren.

Es existiert für Android Geräte ein Ubuntu Installer. Den werde ich einmal ausprobieren. Sollte das auf dem Galaxy Tab gelingen werde ich versuchen den KDE Desktop darauf zu installieren. Natürlich werde ich hier im Blog darüber berichten ob alles reibungslos funktioniert :-)

Hat von euch schon jemand Erfahrungen mit einer Ubuntu Installation auf dem Galaxy Tab ?

 


Sonntag
28. Oktober 2012


Christian Boltz: openSUSE conference

21:17 UTCmember

face

emacs-based music at the party - maybe vi would have been better? ;-)
Letztes Wochenende (bis Dienstag) war ich bei der openSUSE conference, die diesmal in der "goldenen Stadt" Prag stattfand. Die Konferenz war sehr interessant - zum Einen die Vorträge, zum Anderen der "hallway track", bei dem ich viele Leute persönlich traf, die ich sonst nur namentlich aus Mailinglisten oder Bugzilla kenne.

Mein Workshop zu AppArmor wurde von rund 15 Personen besucht, die jetzt mehr über AppArmor wissen. Es wurden auch Fragen zum Packaging von Profilen gestellt - mit etwas Glück bekommen also ein paar Programme ein AppArmor-Profil in ihr Paket oder das Profil wird upstream zur Aufnahme zu den Standard-Profilen vorgeschlagen. Die Folien zum Workshop gibt es am Ende dieses Eintrags.

The "golden town" prague, with the Charles Bridge on the left

Zum openSUSE Jeopardy kamen nur 5 Personen. Diese haben aber alle mitgespielt und hatten sichtlich Spaß, die passenden Fragen zu meinen Antworten rund um Linux und openSUSE zu finden - vor allem Jan, der beide Runden (und somit zwei Flaschen Wein) gewann. Der IRC-basierte "Buzzer" hat dabei gut funktioniert und kommt mit etwas Glück beim nächsten LinuxTag nochmal zum Einsatz.

Am Montag  war ich einer der wenigen Teilnehmer der BoF zur openSUSE landing page, die wir spontan etwas verlängerten. Daher fiel die admin@-BoF mehr oder weniger aus, was mangels anwesender Admins auch nicht wirklich schlimm war. Danach wurde ich von Coolo noch zum Filmen freiwillig gemeldet ;-) - die schrecklichen Publikums-Bilder vom Montag Nachmittag (Project Meeting etc.) und Dienstag (hauptsächlich Raum Riker) stammen von mir ;-)

Vielen Dank an alle, die zur openSUSE Conference beigetragen haben, and für die Unterstützung bei den Reisekosten!

AppArmor workshop

Last weekend (until tuesday) I visited the openSUSE conference which was in the "golden town" Prague this year. The conference was very interesting. One part are the talks, the other part is the "hallway track" where I met lots of people I only knew from mailinglists or bugzilla.

About 15 persons took part in my AppArmor workshop, which means they now know more about AppArmor. Some also asked about packaging of AppArmor profiles. If we are lucky, some applications will receive a profile in their package, or their profile will be proposed for inclusion the the upstream set of default profiles. The slides I used in the workshop are available for download at the end of this post.

Jürgen's UFO advertising openSUSE TV

Only 5 persons came to my openSUSE jeopardy, but they all played and had fun in finding the matching questions for my answers about Linux and openSUSE. Jan must have had most fun - he won both rounds (and two bottles of wine). The IRC based "buzzer" worked quite well and will probably be used again at next LinuxTag.

On monday, I was one of the few participants of the BoF about the openSUSE landing page, which we extended time-wise. This also means the admin@ BoF was more or less dropped, which wasn't really


Donnerstag
25. Oktober 2012


face

AMD Catalyst 12.10 (fglrx 9.002) wurde veröffentlicht und unterstützt Grafikkarten ab Radeon HD 5000 und höher. Das Skript makerpm-amd-12.10.sh steht ab sofort zum Download zur Verfügung und unterstützt 11.4, 12.1 und 12.2 sowie bis Kernel 3.6.

[UPDATE 13.12.2012]
Das Packaging Script wurde aktualisiert und ein Patch wurde zwecks Kompatibilität zum Kernel 3.7 hinzugefügt.
[/UPDATE 13.12.2012]

Eine kleine Bitte habe ich: Wenn irgendwelche Probleme mit dem Treiber auftauchen, scheut euch nicht mir zu berichten (Ich nehme deutsche und englische Bugreports gerne entgegen). ;-) Ich werde versuchen, soweit es mir möglich ist, den gemeldeten Fehler zu reproduzieren. Zusammen mit den nötigen System-Informationen werde ich mich direkt an die richtige Stelle bei AMD wenden, um den Bug in der nächsten Treiber-Version beheben zu lassen. Danke schön. :-D

Für Benutzer älterer AMD Grafikkarten (Radeon HD Serie 2000 – 4000) wird dringend die Installation dieses Treibers abgeraten. AMD hat einen Legacy-Treiber zur Verfügung gestellt. Mehr Informationen zum Legacy Treiber: http://www.sebastian-siebert.de/2012/07/28/opensuse-amd-catalyst-12-6-legacy-treiber-als-rpm-installieren/

Downloads:

Installationsanleitung:
http://de.opensuse.org/SDB:AMD/ATI-Grafiktreiber#Installation_via_makerpm-amd-Skript

Über das makerpm-amd-Skript

Das Skript makerpm-amd-12.10.sh ist sehr mächtig, robust und läuft vollautomatisch. Der AMD-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 AMD-Installer downloaden
-i Das RPM-Package bauen und installieren bzw. updaten
-kms <yes|no> Kernel-Mode-Setting (KMS) aktivieren oder deaktivieren
-nohw Hardware-Erkennung explizit ausschalten. (z.B. beim Bau in einer VM)
-old2ddriver <yes|no> den alten 2D-Treiber aktivieren oder deaktivieren
-r|–report erstellt ein Report und speichert diese in eine Datei namens amd-report.txt
-u|–uninstall entfernt AMD Catalyst restlos vom System. Zuerst wird das fglrx-Package (falls vorhanden) vom System deinstalliert. Danach werden vorhandene AMD-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.
-h Die Hilfe anzeigen lassen
-V Version des Skript anzeigen

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 Wiki 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


Sonntag
14. Oktober 2012


face

Eigentlich wollte ich nur ein paar Apps ausprobieren, und das ganze im Firmenumfeld. Ich bin dann relativ schnell gescheitert, die Apps haben immer die Verbindungsparameter für invalide gehalten, und geschrieben ich solle die Einstellungen überprüfen. Nach einiger Recherche, denn ich bin mir sehr sicher das die URLs und die Credentials stimmen, habe ich heraus gefunden, dass viele Apps nicht berücksichtigt haben, dass man Zertifikate selber signieren kann. Dies wird oft bei internen Applikationen gemacht.

Lösung

Um den ganzen Herr der Lage zu werden, habe ich mir das “root” Zertifikat mit dem unsere IT alle selbst signierten Zertifikate unterschreibt geben lassen. Man muss dieses physisch auf dem Android Gerät speichern und mit der Dateiendung “.crt” versehen. Klickt man nun mit einem Dateiexplorer auf diese Datei wir einem das öffnen mit dem Zertifikatsimporter von Android geöffnet. Einmal damit im Gerät hinterlegt, kann man problemlos mit jedem App via https auf die internen Systeme zugreifen.

Besserer Lösungsvorschlag an App Entwickler

Liebe App Entwickler da draußen, bitte seht bei euren Apps vor, dass es auch Zertifikate gibt, die nicht von einem offiziellen Trustcenter signiert sind. Man kann dazu, wie beim Webbrowser, eine Rückfrage an den Anwender stellen, ob er dem Zertifikat dennoch vertrauen möchte, anstelle ihn mit “Bitte überprüfe deine URL sowie Usernamen und Kennwort” zu belasten.

 

Was denkt ihr?


Dienstag
18. September 2012


face

Da es anscheinend noch keine Anleitung auf deutsch gibt wie man sein Arch Linux auf systemd umstellt, werde ich mich nun daran versuchen. Folgend werden wir ein Arch Linux vom alten init-System auf systemd umstellen.

Pakete installieren

Zu allererst ein volles Update des Systems mit dem Befehl:

pacman -Syu

Nun installieren wir systemd mit dem Befehl:

pacman -S systemd

Konfigurationsdateien erstellen

Jetzt legen wir folgende Dateien an mit dem jeweiligen Inhalt:

/etc/hostname
#hostname vom Rechner

 

/etc/vconsole.conf
KEYMAP="de-latin1.map.gz"
FONT=lat9w-16
FONT_MAP=8859-1_to_uni

 

/etc/locale.conf
LANG=de_DE.utf8
LC_COLLATE=C

 

/etc/timezone
Europe/Berlin

Kernelmodule eintragen

Wenn zusätzliche Kernelmodule geladen werden müssen die in der /etc/rc.conf stehen, so müssen diese noch extra eingerichtet werden, da die rc.conf bei systemd in diesem Falle ignoriert wird.

Legen Sie für jedes Kernelmodul das geladen werden soll im Ordner

/etc/modules-load.d/

eine Datei an. Hier am Beispiel vom vboxdrv

touch /etc/modules-load.d/vboxdrv.conf

und schreiben Sie in die Datei den Namen des Kernelmoduls

vboxdrv

Dies wiederholen Sie mit allen zu ladenen Kernelmodulen.

systemd einrichten

Nun kommen wir zur eigentlichen systemd Konfiguration. Zuerst müssen wir das target, also das Ziel festlegen, was in unserem Fall das Ursprüngliche init 5 oder bei systemd das graphical.target ist.

Mit dem Befehl

systemctl enable graphical.target

geben wir dies an systemd weiter.

Nun müssen wir noch alle Deamons die beim Start geladen werden sollen, angeben. Schauen Sie dazu in die /etc/rc.conf hinein und übertragen Sie alle zu startenden Deamons in systemd.

Steht in der rc.conf zum Beispiel

DAEMONS=(syslog-ng acpid dbus iptables networkmanager ntpd alsa cupsd crond kdm)

sehen die Befehle an systemd so aus:

systemctl enable syslog-ng.service
systemctl enable acpid.service
systemctl enable apcid.socket
systemctl enable iptables.service
systemctl enable NetworkManager.service
systemctl enable ntpd.service
systemctl enable cupsd.service
systemctl enable cronie.service
systemctl enable kdm.service

Ohne NetworkManager benutzen Sie einfach

systemctl enable dhcpcd@eth0.service

Tipp: Manche Deamons haben andere Namen im systemd. So heisst zum Beispiel cupsd bei systemd cups.service. Um den richtigen Namen zu finden kann mit

systemctl --all | grep cups

gesucht werden.

Altes init-System löschen

Nun müssen Sie noch das alte init-System löschen

pacman -R initscripts
pacman -S systemd-sysvcompat

Das war es auch schon. Nach einem Neustart sollte systemd den Rechner nun ohne Probleme hochfahren. Sollte ein Deamon nicht starten können Sie die Fehlermeldung mit

systemctl status [deamon].service

abrufen.

Mehr Informationen zum Thema systemd in Arch Linux gibt es in dem sehr ausführlichen Artikel unter https://wiki.archlinux.org/index.php/Systemd

Wichtig: Wer auf der sicheren Seite sein möchte kann initscripts auch erstmal behalten und mit dem Kernelparameter

init=/bin/systemd

ausprobieren ob systemd wie erwartet funktioniert. Ist dies der Fall kann dann das alte init-System wie im letzen Kapitel beschrieben gelöscht werden.


Freitag
07. September 2012


face

Mein Netbook musste wieder als Testobjekt für ein Live-Upgrade von openSUSE 12.1 auf openSUSE 12.2 herhalten. Das ist jetzt für das Netbook das 4. Live-Upgrade seit openSUSE 11.2 und nutze es immer noch produktiv. :-) Das Upgrade ist an und für sich recht flüssig über die Bühne gegangen. Keine nennenswerte Probleme wie bei den anderen Upgrades auch. Außerdem ist mir der Geschwindigkeitszuwachs zwischen openSUSE 12.1 und openSUSE 12.2 aufgefallen, sehr wahrscheinlich würde man es nur auf einer etwas schwächeren Hardware wie z.B. auf einem Netbook bemerken. ;-)

Bevor man ein Upgrade vornimmt, sollte man sich die Versionshinweise aufmerksam durchlesen:
http://www.suse.de/relnotes/i386/openSUSE/12.2/RELEASE-NOTES.de.html

Möglicherweise gibt es noch andere Probleme, die zu umschiffen gilt:
http://en.opensuse.org/openSUSE:Most_annoying_bugs
http://en.opensuse.org/openSUSE:Most_annoying_bugs_12.2_dev

Auch ein Blick im Bugreport zu openSUSE 12.2 ist zu empfehlen:
http://bugzilla.novell.com/buglist.cgi?…

Sollte einer der offenen Bugs möglicherweise zu einem Problem führen, die man selbst nicht beheben kann. Dann ist es besser im Bugreport, in der Mailingliste oder im IRC nachzufragen, ob dafür eine Lösung ggfs. ein Workaround existiert. Je nach Schweregrad sollte man das Upgrade lieber verschieben, bis das Problem behoben wurde.

Anbei noch eine Empfehlung für den Fall der Fälle die folgende von mir gepflegte Seite zu bookmarken (Feedbacks sind erwünscht):
http://www.opensuseusers.de/

Upgrade-Anleitung

Hinweis: Alle Befehle sind als root-User in der Konsole bzw. im Terminal auszuführen. Um Tippfehler zu vermeiden, empfiehlt es sich die Befehle zu kopieren und in die Konsole/Terminal einzufügen.

  1. Vor dem Upgrade wird empfohlen, ein Backup vom System zu machen.
  2. Alle eingebundenen Repos in /etc/zypp/repos.d vorübergehend deaktivieren:
    zypper mr -a -d

    oder alternativ:

    sed -i 's/enabled=.*/enabled=0/g' /etc/zypp/repos.d/*.repo
  3. Die alten Standard-Repos von openSUSE in /etc/zypp/repos.d vorsichtshalber entfernen:
    for REPOFILE in `grep -rliE '/distribution/12.1|/update/12.1' /etc/zypp/repos.d`; do rm -v "${REPOFILE}"; done
  4. Alle deaktivierten Repos in /etc/zypp/repos.d auf openSUSE 12.2 umschreiben:
    sed -i 's/openSUSE_12.1/openSUSE_12.2/g' /etc/zypp/repos.d/*.repo
  5. Die neuen Standard-Repos für openSUSE 12.2 einfügen:
    zypper ar -t yast2 -f -c http://download.opensuse.org/distribution/12.2/repo/oss/ "openSUSE 12.2 OSS"
    zypper ar -t yast2 -f -c http://download.opensuse.org/distribution/12.2/repo/non-oss/ "openSUSE 12.2 NON-OSS"
    zypper ar -t rpm-md -f -c http://download.opensuse.org/update/12.2/ "openSUSE 12.2 OSS Update"
    zypper ar -t rpm-md -f -c http://download.opensuse.org/update/12.2-non-oss/ "openSUSE 12.2 NON-OSS Update"
  6. Cache bereinigen:
    zypper clean -a
  7. Repo-Cache aktualisieren:
    zypper ref
  8. Upgrade starten (Abhängigkeiten auflösen):
    zypper dup
  9. Sicher gehen, dass auch alles upgegradet wurde. Wenn nicht, so oft wiederholen bis nichts mehr zum Upgraden da ist.
    zypper dup 

<- Aktuelle Artikel