Hacking, Spiele, Physik und Politik

Devpi-Cleaner 0.2.0

Wer einen größeren Devpi-Server betreibt kommt immer wieder mal in die Situation Pakete von diesem löschen zu müssen. Für einzelne Pakete lässt sich dies mit dem normalen Devpi-Client noch leidlich komfortabel lösen, aber schon nichtvolatile Indices machen daraus ein aufwendiges Unterfangen mit mehreren manuellen Schritten, bei dem leicht Fehler unterlaufen.

Wer einen größeren Devpi-Server betreibt kommt immer wieder mal in die Situation Pakete von diesem löschen zu müssen. Für einzelne Pakete lässt sich dies mit dem normalen Devpi-Client noch leidlich komfortabel lösen, aber schon nichtvolatile Indices machen daraus ein aufwendiges Unterfangen mit mehreren manuellen Schritten, bei dem leicht Fehler unterlaufen. Um diese Problem zu lösen gibt es Léon, den Devpi-Cleaner, der es beispielsweise ermöglichte alle alten Enwicklungsversionen zu entfernen oder den Index nur für die Dauer der Löschoperation volatil zu schalten. Die Notwendigkeit auf dem Devpi aufzuräumen ergibt sich nicht nur, wenn mal ein Paket falsch hochgeladen wurde. Auch Änderungen der Indexstruktur können eine Aufräumaktion sinnvoll machen. Und wer Continuous Integration ernst nimmt und zu jedem erfolgreichen Build ein Paket hochlädt, dem blähen alte, nicht mehr benötigte Entwicklungsversionen die Backupgröße, und damit auch die Erstellungsdauer auf. Bei meinem Arbeitgeber Blue Yonder ist es glücklicherweise gerne gesehen allgemein nutzbare Software als Open Source zu veröffentlichen. So konnte ich letzte Woche Version 0.2.0 von Léon, dem Devpi-Cleaner veröffentlichen. Nicht nur sind jetzt komplexere Auswahlkriterien möglich, sondern das Löschen geht jetzt auch deutlich schneller und dank Fortschrittsbalken mit Restzeitabschätzung hat man eine Chance seine Kaffeepausen zeitoptimiert einzulegen. Eine komplette Liste der Änderungen findet sich im Changelog.

Kein CUDA nach dem Update auf openSUSE Leap 42.1

Nachdem ich meine Workstation von openSUSE 13.1 auf openSUSE Leap 42.1 migriert hatte funktionierten lies sich die Grafikkarte nicht mehr zum Rechnen nutzen. Irgendwie hatte es einen Fehler bei der Installation des neuen Grafiktreibers gegeben. Seine Neuinstallation löste das Problem.

Nachdem ich meine Workstation von openSUSE 13.1 auf openSUSE Leap 42.1 migriert hatte funktionierten lies sich die Grafikkarte nicht mehr zum Rechnen nutzen. Irgendwie hatte es einen Fehler bei der Installation des neuen Grafiktreibers gegeben. Seine Neuinstallation löste das Problem. Das Problem Nach dem Update fanden CUDA nutzende Anwendungen keine Grafikkarte. So meldete Boinc No usable GPUs found. Prinzipiell funktionierte die Grafikkarte aber. So hatte ich volle 3D-Beschleunigung, und auch nvidia-smi meldete die erwarteten Daten: +------------------------------------------------------+                       | NVIDIA-SMI 340.93     Driver Version: 340.93         |                       |-------------------------------+----------------------+----------------------+| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC || Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. ||===============================+======================+======================||   0  GeForce GTX 580     Off  | 0000:01:00.0     N/A |                  N/A || 43%   49C   P12    N/A /  N/A |    494MiB /  1535MiB |     N/A      Default |+-------------------------------+----------------------+----------------------+                                                                            +-----------------------------------------------------------------------------+| Compute processes:                                               GPU Memory |                                                                                                              |  GPU       PID  Process name                                     Usage      |                                                                                                              |=============================================================================|                                                                                                              |    0            Not Supported                                               |                                                                                                              +-----------------------------------------------------------------------------+                                                                                                              Die Analyse NVIDIA bietet CUDA zwar für einige SUSE-Varianten zum Download, aber leider nicht für Leap 42.1. Es gibt zwar Pakete für das unterliegende SLE 12, aber diese verlangen einen Grafikttreiber welcher nicht zum Kernel von Leap 42.1 passt. Deshalb habe ich mich für die Analyse auf OpenCL-Beispiel-Code zurückgezogen. Denn für OpenCL benötigt man nur die Header, welche man einfach direkt zum Code legen kann, und einen C-Compiler. Schon der erste Versuch mit einem Beispielprogramm welches nur die OpenCL-Runtime initialisiert zeigt das Problem:     > sudo ./platform     modprobe: FATAL: Module nvidia-uvm not found.    Failed to get platforms: -1001 Das sudo ist hier übrigens nur vorangestellt um es zu ermöglichen Kernel-Module nachzuladen. Ohne sudo erhält man den gleichen Fehler, aber ohne die essentielle Information zum Kernelmodul. Schnell konnte ich herausfinden, dass eigentlich alle Kernelmodule installiert sind: > rpm -ql nvidia-gfxG03-kmp-default-340.93_k4.1.12_1-36.7.x86_64 | grep \.ko/lib/modules/4.1.12-1-default/updates/nvidia.ko > rpm -ql nvidia-uvm-gfxG03-kmp-default-340.93_k4.1.12_1-36.7.x86_64 | grep \.ko/lib/modules/4.1.12-1-default/updates/nvidia-uvm.ko > ls /lib/modules/4.1.12-1-default/updates/nvidia.ko  nvidia-uvm.ko Allerdings war das nicht das Modulverzeichnis des aktuell laufenden Kernels: > uname -aLinux eddie 4.1.13-5-default #1 SMP PREEMPT Thu Nov 26 16:35:17 UTC 2015 (49475c3) x86_64 x86_64 x86_64 GNU/Linux Wo liegen also dessen Module? /lib/modules/4.1.13-5-default/updates existiert nicht. Das NVIDIA-Modul ist aber schnell gefunden: > ls /lib/modules/4.1.13-5-default/weak-updates/updates/nvidia.ko Nur fehlt in diesem Verzeichnis das nvidia-uvm.ko. Die Lösung Eine Neuinstallation des dazugehörigen Paketes lässt dann endlich auch OpenCL wieder richtig initialisieren: > zypper in in -f nvidia-uvm-gfxG03-kmp-default > ls /lib/modules/4.1.13-5-default/weak-updates/updates/nvidia.ko  nvidia-uvm.ko > modprobe nvidia-uvm > ./platform                                                                                                                                              Failed to get platforms: -1001                                                                                                                                                               > sudo ./platform NVIDIA CUDA - OpenCL 1.1 CUDA 6.5.51 - NVIDIA Corporation - FULL_PROFILE > ./platform NVIDIA CUDA - OpenCL 1.1 CUDA 6.5.51 - NVIDIA Corporation - FULL_PROFILE Um die Grafikkarte tatsächlich zu verwenden war dann allerdings noch ein Neustart notwendig.

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.

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 Marix.org RSS