Podman Update verhindert Start alter Container

Ein Update von Podman verhindert das Starten von alten Containern. Das betrifft auch Toolbox.

Podman Update verhindert Start alter Container

Die Fedora Toolbox benutzt Podman um Container zu erstellen und zu starten. Das geht aber mit Podman 4.6.x nicht mehr für jeden Container, da dazu nicht mehr die nötigen Limits erlaubt werden, die noch mit 4.5.x dem Container zugewiesen wurden. Eine Datenmigration ist das einzige Mittel, alte Container wieder zu starten.

Die meist angesprochene Endlösung war das Löschen und Neuerstellen der betroffenen Container, was aber mit einem Datenverlust einhergehen würden, so man den Daten in dem Container drin hat. Einige Benutzer merkten an, daß Toolbox gar nicht für dauerhafte Container ausgelegt wäre, und man sich nicht wundern müßte, wenn Daten verloren gingen, da gegen den „Sinn“ von Toolbox gehandelt wurde.

Das ist natürlich per se kein Argument, weil Toolbox ja nur das Kontrollwerkzeug ist. Was man mit dem Container dann anstellt, ist ja jedem selbst überlassen 😉

Aber ist das Überhaupt ein Problem? Wir fragen Prof. Dr. Besser-Weiß von der Uni Kassel-Schwarzensee.

Das Interview

„Herr Professor Besser-Weiß, ist das Update von Podman überhaupt ein Problem?“
„Nein.“
„Herr Professor, wir danken für das Gespräch.“

Die Migration

Im Podman Issue[0] gibt es dafür folgende Migrationslösung:

$ podman export $CONTAINER_NAME -o output.tar
$ podman import output.tar $NEW_IMAGE_NAME
$ podman container rm $CONTAINER_NAME
$ toolbox create --image localhost/$NEW_IMAGE_NAME -i $CONTAINER_NAME

Danach kann der Container wieder gestartet werden.

Wer tatsächlich keine Daten in dem Container hat, was bei meinen Experimenten mit Cheese auf dem Surface Tablet z.B. der Fall war, weil Cheese seine  Daten im Home speichert, hat ohnehin kaum Hemmung den Container zu löschen und einfach neu anzulegen.

Da Fedora das Podman Update bereits ins Stable getan hat, solltet Ihr Euch bei Zeiten, also jetzt, darum kümmern, bevor Ihr das Programm im Container nochmal braucht.

[0] Quelle: https://github.com/containers/podman/issues/19634

Red Hat Politikänderungen wirken auch auf Fedora nach

Red Hat hatte ja einige Änderungen am Engagement für Desktopelemente in Aussicht gestellt, die jetzt langsam durchschlagen.

Red Hat Politikänderungen wirken auch auf Fedora nach

Bastien Nocera schreibt in seinem Blog, daß er von Red Hat in ein anderes Team versetzt wurde und die ohnehin schon geringe Arbeit an „fprint, fprintd, gnome, gvfs, iio-sensor-proxy, kernel, libfprint, low-memory-monitor, power-profiles-daemon, rhythmbox, sound-juicer, switcheroo-control, thumbnailer, totem“ einstellen mußte. Das führte zum Verwaisung der Pakete bei Fedora.

Langzeit Maintainer Michael Catanzaro, der auch bei Red Hat angestellt ist, schrieb dazu am Montag auf der Fedora Dev ML:

„Red Hat has instructed us to stop work on several core desktop components. All of these components need new maintainers now. The switcheroo-control repo has now been archived, and a future new maintainer will need to recreate the repo in a new location. It’s certainly not good news. :(„

Cinnamon & Nvidia Maintainer Leigh Scott nahm das zum Anlass um wenigsten einige der Pakete von der LinuxMint Gruppe übernehmen zu lassen. Dutzende andere Pakete warten aber noch auf einen neuen Maintainer.

Der ‚Umorientierung‘ bei Red Hat, der mutmaßlich von IBM inszeniert wurde, geht also weiter und wird sicherlich noch spürbare Ausmaße annehmen, weil Red Hats Engagement weitest gehend im  Stillen abgelaufen ist. Das wird sich sicherlich jetzt ändern.

NVIDIA: Durchbruch beim proprietären Nvidiatreiber \o/

Ihr erinnert Euch an diese Sache:

Fedora: Kernel 6.1.5 & 6.2.0.alpha ohne Nvidia Grafikkartensupport

NVIDIA: Durchbruch beim proprietären Nvidiatreiber \o/

Wie Ihr den Artikeln dazu entnehmen könnt, hatten einige Benutzer überhaupt keine Probleme mit dem proprietären Treiber von Nvidia, andere konnten nichts mehr sehen, weil der Bildschirm schwarz blieb.

In einer fast schon spektakulären Tag & Sonnenschein Aktion sind wir heute der Ursache endgültig auf die Spur gekommen und konnten den Kernel 6.1.5 , der ohne efifb / vesa Framebuffertreiber kompiliert wurde, erfolgreich booten, trotz Nvidia Treibern.

Das liegt darin, daß die Nvidia-Treiberversion 525.xx schon mit SimpleDRM Support ausgerüstet ist, und daher auch ohne efifb/vesa Support geladen werden kann. Ein Umstand, der sehr sehr lange in der Gemeinde für Frust und Wut über Nvidia gesorgt hat. „Emotionsgeladene Argumentationen“ wäre als Beschreibung völlig untertrieben, wenn Ihr mich fragt 😉

Wieso konnte man dann aber trotzdem nichts sehen?

Da Nvidiainstallationen nicht vom Baum fallen, sondern über die Zeit gewachsen sind und mit dem OpenSource Treiber nouveau nicht gleichzeitig genutzt werden können, muß man nouveau in der Kernel Command Line ausschalten und aktiv den Nvidiatreiber ansprechen.

Da sah bisher so aus:

nouveau.modeset=0 rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1 initcall_blacklist=simpledrm_platform_driver_init

Wie Ihr sehen könnt, ist auch die simpledrm Factory abgeschaltet, so daß man efifb/vesa braucht. Lässt man initcall_blacklist=simpledrm_platform_driver_init weg, könnte man schon den 6.1.5 Kernel booten, würde aber erst beim Init von X was sehen, z.b. wenn GDM startet. Alles was im initramfs passiert, bleibt unsichtbar. Da in dieser Phase die Festplattenverschlüsselung nach dem Passwort fragt, muß man das blind eingeben oder ist aufgeschmissen. Das ist Erklärung #1 , wieso einige Benutzer von dem Problem nichts mitbekommen haben: Keine Festplattenverschlüsselung!

ein goldener Pinguin in einem technisch angehauchten Raum mit Glasboden und Monitoren reißt die Flügel hoch vor Freude.

erstellt mit: https://you.com – Stable Diffusion 2.1

Und so booten man normal mit dem 6.1.5 Kernel

Wie Ihr oben sehen könnt, steht in der Kernel Command Line noch mehr drin, nämlich: nvidia-drm.modeset=1

Und das ist der Grund, wie man im Initramfs nichts sehen kann, weil darüber auch efifb/vesa aktiviert wird, was nicht geht, weil es nicht mehr einkompiliert ist. Ergo, lassen wir auch diesen Eintrag weg und booten nur noch mit:

nouveau.modeset=0 rd.driver.blacklist=nouveau modprobe.blacklist=nouveau

und alles funktioniert \o/ Woher ich das weiß, weil ich es ausprobiert habe und Ihr seid die ersten, die das erfahren 🙂 Naja, fast, die Kernelgang von Redhat weiß es seit 15 Minuten 😉

$ uname -a
Linux charming.knuddelpc.de 6.1.5-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jan 12 16:10:44 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
$ date -R
Tue, 28 Feb 2023 15:34:36 +0100

Aber wieso, waren einige gar nicht davon betroffen?

Weil neuere Installationen beim Eintragen in die Grub Default andere Kernelparameter eingetragen haben!

Das ist die Erklärung, wieso einige Benutzer von dem Problem nichts mitbekommen haben! Sie hatten einfach die richtigen Anweisungen in der Config stehen!

How To FIX!

Damit Ihr in Zukunft gewappnet seid, ändert Ihr als root die Datei /etc/default/grub und werft dort „nvidia-drm.modeset=1 initcall_blacklist=simpledrm_platform_driver_init“ komplett raus.

Dann könnt Ihr gelassen auf das nächste Kernelupdate warten, daß Euch eine neue Bootconfig baut. Deswegen extra eine zu erstellen ist nicht nötig, Ihr habt ja gerade ein Bild, oder? 😉