You are here

Linux

Dinge die auf dem Linux-Kernel aufbauende Betriebssysteme betreffen.

openSUSE 13.1 mit UEFI und Vollverschlüsselung auf openSUSE Leap 42.1 migrieren

Da der offizielle Support für openSUSE 13.1 am 5.1.2015 endet war es höchste Zeit meine Workstation mal auf openSUSE Leap 42.1 zu migrieren. Solche Migrationen mache ich mit SUSE schon seit es noch einstellige Versionsnummern hatte. Diesmal war die Migration allerdings ungewohnt holprig.

Da der offizielle Support für openSUSE 13.1 am 5.1.2015 endet war es höchste Zeit meine Workstation mal auf openSUSE Leap 42.1 zu migrieren. Solche Migrationen mache ich mit SUSE schon seit es noch einstellige Versionsnummern hatte. Diesmal war die Migration allerdings ungewohnt holprig. Meine Workstation nutzt ein vermutlich nicht ganz gewöhnliches Set-Up. OpenSUSE ist parallel zu Windows 10 installiert, und beides wird per UEFI Secure Boot gestartet. Den UEFI-Boot habe ich dann auch gleich mal genutzt um mir mit Anlauf selbst in den Fuß zu schießen: OpenSUSE unterstützt es zwar schon seit Ewigkeiten eine Upgrade aus dem laufenden System durchzuführen, da es mir aber immer als der sauberere Ansatz vorkam – und sicher auch aus Nostalgie – mache ich solche Updates immer noch ganz altmodisch per DVD. Allerdings bietet mein ASUS-EFI in der Bootmedienauswahl das Blu-Ray-Laufwerk immer zwei mal an. Einmal ganz oben in der Liste als BIOS-Boot, und einmal ganz unten als echten UEFI-Boot. Natürlich habe ich – wollte ja nur schnell mal das Update starten – den oberen Eintrag genommen und mein EFI-System dann mal schön im BIOS-Modus aktualisiert. Leider fängt openSUSE diesen PEBKAC aktuell nicht ab und hat mir dann mal schön die Bootloaderkonfiguration kaputtgeschrieben. Zum Glück ist der Fehler – wenn man erst mal verstanden hat, was man falsch gemacht hat – trivial zu korrigieren. Einfach nochmal das Upgrade im UEFI-Modus starten, von Leap 42.1 auf Leap 42.1 aktualisieren (ja, das geht). Danach ist der Bootloader korrekt geschrieben. Leider tritt einem beim Versuch die DVD mit openSUSE Leap 42.1 per UEFI zu booten Bug 950569 in den Weg. Der Bootcode auf der DVD ist nicht korrekt signiert, was auf meinem System zufolge hat, dass der Bildschirm einfach schwarz bleibt. Das Problem lässt sich lösen, indem man Secure Boot im BIOS temporär deaktiviert. Zum Glück installiert openSUSE Leap 42.1 bei der Installation bzw. dem Upgrade bereits die aktuellsten Version aller Pakete. So bleibt Nachzüglern wie mir nicht nur die Updateorgie nach der Installation erspart, sondern es landet auch korrekt signierter Code auf der Platte, so dass Secure Boot nach dem Update gleich wieder aktiviert werden kann. Ein weiteres Problem bei openSUSE Leap 42.1 ist, dass es zumindest bei Upgrades nicht korrekt mit verschlüsselten Root-Partitionen umgehen kann. Beim Boot „vergisst“ das System nach der Passphrase zu fragen. Wechselt man durch die Konsolen findet zeigt sich folgende Fehlermeldung: Failed to start systemd-cryptsetup@luks<codierte ID>.service:. Ich habe die ID in der Fehlermeldung mal gekürzt ;). Wie in Bug 904987 lässt sich das Problem lösen, indem man dem Kernel explizit sagt, dass er die entsprechende Partition entschlüsseln soll, indem man ihm die ID des LUKS-Containers per Kernelparameter rd.luks.uuid mitgibt. Die ID des LUKS-Containers lässt sich mit Cryptsetup herausfinden. Liegt die Root-Partition z.B. auf /dev/sda2, so lässt sich die ID wie folgt herausfinden. > cryptsetup luksUUID /dev/sda207246af2-915a-bd54-6a5s-6a5c35d15f45 Der Bootparameter muss dann in /etc/sysconfig/bootloader zum Wert DEFAULT_APPEND hinzugefügt werden. Dieser sollte dann z.B. wie folgt aussehen: DEFAULT_APPEND="splash=silent quiet showopts rd.luks.uuid=07246af2-915a-bd54-6a5s-6a5c35d15f45" Anschließend einmal den Bootloader neu schreiben lassen und das System fragt wieder nach dem Passwort. Idealerweise wird dieser Workaround schon vor dem Update implementiert. Nicht, weil dann der Bootloader sowieso neu geschrieben wird, sondern weil man sich dann das Herumgewurschtel mit einem Recovery-System spart.

„Indie Game: The Movie“ auf openSUSE

Startet man unter openSUSE, bzw. mit einem KDE-Desktop, von Steam aus „Indie Game: The Movie“, so kommt zwar ein archaisch wirkendes Xterm hoch, welches behauptet einem Adobe AIR zu installieren, allerdings passiert danach nichts mehr. Hat man Adobe AIR bereits installiert startet „Indie Game: The Movie“ ohne Probleme.

Hier kommen gleich mehrere Probleme zusammen:

Startet man unter openSUSE, bzw. mit einem KDE-Desktop, von Steam aus „Indie Game: The Movie“, so kommt zwar ein archaisch wirkendes Xterm hoch, welches behauptet einem Adobe AIR zu installieren, allerdings passiert danach nichts mehr. Hat man Adobe AIR bereits installiert startet „Indie Game: The Movie“ ohne Probleme. Hier kommen gleich mehrere Probleme zusammen: Adobe AIR unterstützt schon seit mehreren Jahren Linux offiziell nicht mehr. Es muss also eine alte Version installiert werden, welche dann natürlich nicht die modernsten Annahmen macht was die Linuxumgebung angeht Die Standardinstallation von Adobe AIR benötigt root-Rechte. Steam führt man allerdings normalerweise nicht als root aus, und das Skript welches die Installation durchführt fordert auch offensichtlich keine an. Adobe AIR will bei der Installation auf KWallet, oder alternativ den Gnome Keyring zugreifen. Auf openSUSE 13.1 mit KDE findet es aber, obwohl natürlich KWallet installiert ist, keinen von beiden. Woran genau die Installation scheitert habe ich nicht herausgefunden. Zur manuellen Installation ist zunächst Adobe AIR von der Archivseite http://helpx.adobe.com/air/kb/archived-air-sdk-version.html herunterzuladen. Es empfiehlt sich die letzte Version mit Linuxunterstützung, also die 2.6 Runtime, zun nutzen. Diese muss mit root-Rechten und Zugriff auf X ausgeführt werden. Hierbei ergibt sich dann das Problem, dass KWallet nicht gefunden wird. Adobe AIR ist eine 32-bit Anwendung, auf den inzwischen üblichen 64-bit-Systemen prüft es offensichtlich im falschen Verzeichnis auf die Existenz der Bibliothek. Legt man, an sich redundant, das korrekte Verzeichnis in die Umgebungsvariable LD_LIBRARY_PATH, so läuft der Installer erfolgreich durch. Nach dem Download ist also folgendes in einer Konsole auszuführen. chmod +x AdobeAIRInstaller.binsu # sudo gibt per default keinen Zugriff auf den laufenden X-ServerLD_LIBRARY_PATH=/usr/lib64 ./AdobeAIRInstaller.bin

Civilization 5, V-Sync und KDE

In Civilization 5 gibt es zwar eine V-Sync-Option, allerdings ist im Spiel dann bei mir doch das hässliche Tearing zu sehen gewesen. Die Lösung: Die Arbeitsflächeneffekte für Vollbildfenster deaktivieren. Diese, bzw. deren V-Sync-Einstellung scheint mit der von Civilization 5 zu kollidieren. Die Einstellung findet sich in den Systemeinstellungen unter „Arbeitsflächen-Effekte“->„Erweitert“.

ACLs – Dann klappt auch das Inotify bei Mediatomb

Die traditionellen Unix-Dateiberechtigungen stoßen öfter mal an ihre Grenzen. Zum Beispiel bei meinem Versuch Mediatomb auf meinem Homeserver Inotify verwenden zu lassen. Die Lösung für diese Limitierung sind ACLs. Hier zeige ich, wie man diese für Mediatomb sinnvoll setzen kann.

Die traditionellen Unix-Dateiberechtigungen stoßen öfter mal an ihre Grenzen. Zum Beispiel bei meinem Versuch Mediatomb auf meinem Homeserver Inotify verwenden zu lassen. Die Lösung für diese Limitierung sind ACLs. Hier zeige ich, wie man diese für Mediatomb sinnvoll setzen kann. Den Inotify-Modus möchte ich in Mediatomb aus zwei Gründen verwenden. Ersten muss man dann nicht warten bis der nächste Scan nach neuen Dateien abgeschlossen ist, denn meistens möchte man die Datei ja sofort anschauen. Zweitens muss Mediatomb dann nicht immer wieder den Verzeichnisbaum ablaufen wenn sich gar nichts geändert hat. Im Idealfall können die Festplatten also deutlich länger schlafen. Das Problem mit dem Inotify-Modus besteht darin, dass Mediatomb hierfür Schreibberechtigung auf den Verzeichnissen benötigt, welche es auf Änderungen überwachen soll. Klassisch kann man aber ja nur die drei Berechtigungen – Eigentümer, Gruppe und den Rest – setzen. Prinzipiell kann man natürlich immer wenn man ein Verzeichnis anlegt anschließend Eigentümer oder Gruppe passend umsetzen, dann ist Mediatomb aber schon gescheitert. Eine bessere Lösung sind ACLs, mit denen man beliebig viele Berechtigungen vergeben kann. Außerdem ist es mit ACLs auch einfach Default-Werte zu setzen welche anschließend für alle im Verzeichnis angelegten Dateien und Unterverzeichnisse übernommen werden. Meine ACL für das oberste Verzeichnis sieht aus wie folgt: user::rwxuser:mediatomb:rwxgroup::rwxmask::rwxother::r-xdefault:user::rwxdefault:user:mediatomb:rwxdefault:group::rwxdefault:mask::rwxdefault:other::r-x Der Nutzer und die Gruppe können im Verzeichnis lesen und schreiben, dadurch kann zum Beispiel meine Frau auch die Fotos umsortieren. Alle anderen können das Verzeichnis lesen. Dies könnte man auch restriktiver handhaben, aber da Mediatomb den Inhalt dieser Verzeichnisse aller Welt verfügbar macht hat eine weitere Einschränkung wenig Sinn. Der Benutzer mediatomb bekommt explizit Lese- und Schreibberechtigung für dieses Verzeichnis. Dadurch kann Mediatomb dann Inotify verwenden um das Verzeichnis auf Veränderungen zu überwachen. Besonders wichtig sind die mit default: beginnenden Einträge. Diese legen wiederum die ACL fest welche in diesem Verzeichnis neu angelegte Dateien und Unterverzeichnisse bekommen. Bei Unterverzeichnissen werden diese außerdem wieder als Default übernommen. Das hier ein x in den Berechtigungen steht macht übrigens nicht jeden Datei ausführbar. Diese Berechtigungen werden immer mit dem vom anlegenden Programm angegebenen Berechtigungen kombiniert. So sind Verzeichnissen dann automatisch ausführbar (sonst könnte man ihre Inhalte nicht sehen), und normale Dateien nicht – es sei denn sie werden explizit als ausführbar angelegt. Um diese ACL auf einen bestehenden Dateibaum anzuwenden packt man sie am besten in eine Datei, in meinem Fall habe ich sie einfach acl genannt, und wendet sie mit setfacl rekursiv an. setfacl -R --set-file acl /OberstesVerzeichnis/ Hierbei gibt es noch einen kleinen Trick. Die Berechtigung X, anstelle von x macht eine Datei nur ausführbar wenn sie Verzeichnis oder bereits ausführbar ist. So verhindert man mit folgender ACL, dass alle Dateien ausführbar werden, stellt aber sicher, dass Verzeichnisse angezeigt werden können. user::rwXgroup::rwXother::r-Xmask::rwXuser:mediatomb:rwXdefault:user::rwxdefault:group::rwxdefault:other::r-xdefault:mask::rwxdefault:user:mediatomb:rwx

Patch für die Hercules DJ Console-Treiber für Linux 2.6.30 und neuer

Die Treiber für die DJ Controller von Hercules gibt es zwar in Paketen für so ziemlich alle Distributionsarten, aber leider nicht für die aktuellsten Version. Unter openSUSE 11.2 funktioniert der Treiber zunächst nicht, da dieses Kernel 2.6.31 verwendet, der Treiber aber eine ALSA-Funktion nutzen möchte welche in dieser Version aus dem Kernel flog. Ein kleiner Patch behebt das Problem indem er den entscheidenden Aufruf auf die neue Funktion ändert.

Die Treiber für die DJ Controller von Hercules gibt es zwar in Paketen für so ziemlich alle Distributionsarten, aber leider nicht für die aktuellsten Version. Unter openSUSE 11.2 funktioniert der Treiber zunächst nicht, da dieses Kernel 2.6.31 verwendet, der Treiber aber eine ALSA-Funktion nutzen möchte welche in dieser Version aus dem Kernel flog. Ein kleiner Patch behebt das Problem indem er den entscheidenden Aufruf auf die neue Funktion ändert. Hat man den Treiber nach der Anleitung auf der Webseite installiert, so kann man mit dkms status prüfen ob dieser im System erfolgreich installiert wurde. Auf System mit Kernel 2.6.30 aufwärt bekommt man hier nur die enttäuschende Meldung: hdjmod, 1.28: added. Wäre die installation erfolgreich gewesen müsste hier installed stehen. Der nächste Schritt nach dem add ist der build. Ein Blick in das Logdatei /var/lib/dkms/hdjmod/1.28/build/make.log zeigt das Problem: /var/lib/dkms/hdjmod/1.28/build/device.c:1663: error: implicit declaration of function ‘snd_card_new’ Der Patch behebt das Problem indem er für neuere Kernel den Funktionsaufruf durch auf die neue Funktion snd_card_create ändert. Um ihn anzuwenden wechselt man in das Verzeichnis /usr/src/hdjmod-1.28 und ruft dort sudo patch -p1 < /path/to/hdjmod_kernel_2.6.30.patch auf. Anschließen baut man mit sudo dkms build -m hdjmod -v 1.28 das Modul und installiert es mit sudo dkms install -m hdjmod -v 1.28. Anschließend kann man im DJ Control Panel sehen, dass der Treiber beim Anschließen der Konsole erfolgreich geladen wird. Insgesamt ein gutes Beispiel dafür, wieso man Treiber Open Source halten sollte, aber leider auch ein gute Beispiel, wieso man Treiber nicht außerhalb des Kernels pflegen sollte. >Hier kann man den Patch herunterladen<

Seiten

Sollten dir die Artikel auf dieser Seite gefallen und du Bitcoin für ein interessantes Experiment halten, so schicke doch eine kleine Spende an 14pQyjx5EFQCwPBkXMTz5nTcfPsnjHmWqA.

Subscribe to RSS - Linux