Tag Archives: Update

Podman Update verhindert Start alter Container

Posted on by

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

PVA: Updates auf 1.22 bereinigen Problem mit Plugins

Wer Carola über das Repo installiert hat, wird heute ein Update auf die v1.22 bekommen, welches Probleme mit den Plugins bereinigt, die dazu führen, daß die Verarbeitung von Befehlen stockt. Außerdem gibt es noch ein Update von „say“ das die neue Stimme von GTTS im Zaum hält.

Falls das PVA System bei Euch gerade im geistigen Zustand einer Tomate ist, also nicht mehr reagiert, dann Desktopsession beenden und wieder einloggen. Das sollte das im laufenden Betrieb beheben. Update vorher nicht vergessen. Ganz harte können auch im Terminal „killall -9 pva java“ eintippen, aber das könnte bei Euch auch ungewollte Nebenwirkungen haben.

Ab v1.19 ist auch der Piper TTS Support enthalten, den ich im letzten Artikel schon vorgestellt habe:

PVA: Carola hat Ihr eigenes Repo bekommen

Die Sprachfehler wurden soweit das mit einfachsten Mitteln möglich war, kompensiert, aber nicht behoben.

Fedora und das Packagekit Offline Update

Posted on by

Vor einigen Releases hat Fedora ein neues Updateverhalten via Packagekit eingeführt, das verdächtig nach „Windows macht das auch so“ stank. Wie grottig das wirklich laufen kann, kommt unten in Bild & Schrift.

Fedora und das Packagekit Offline Update

Um es gleich mal vorweg zu schicken: Ich bin pro Fedora und achte das, was die da auf die Beine stellen.

Aber nur weil man es mag, muß man nicht mit allem einverstanden sein und die Änderung des Updateverhaltens durch Packagekit’s „Offline Update“ ist eine der Sachen die ich nicht unterstützen kann. Damit Ihr Euch ein Bild von der Sache machen könnt, habe ich da mal was abgelichtet.

Ich bitte die schlechte Bildqualität zu entschuldigen, aber Screenshots sind an der Stelle im Bootvorgang nicht vorgesehen 😉

Gestern

Gestern war ich mit meinem Surface bei einem Kunden. Während ich da gearbeitet habe, hat sich Packagekit mit Updates versorgt, diese aber nicht eingespielt. ich hab es nur gemerkt, weil ich das Bandbreitenwidget im Gnome habe, das plötzlich hektisch aktiv wurde.

Heute morgen

schalte ich mein Tablet ein, weil ich für den nächsten Artikel was testen wollte. Es kommt die Kernel Auswahl, es kommt die Passwortabfrage für LUKS und dann passiert es:

Bitte fahren Sie den Computer nicht runter!

Größtenteils weiß man nicht mal, was da aktualisiert wird.

Es lief ein Offline-Update von Packagekit 🙁 Nicht 10 Sekunden, nicht 30 Sekunden, nicht eine Minute, nicht fünf Minuten, nein, für knappe acht Minuten war das Geräte vollständig blockiert. Weil ein neuer Kernel installiert worden war, mußten auch alle AKMOD Module für alle Kernels neu gebaut werden. Und dann … gingen die Lichter aus und blieben aus.

Achtet mal auf die Zeiten vom packagekit-offline-update.service

Anstatt das Update einzuspielen und durchzubooten, wurde das Tablet danach einfach abgeschaltet. Kommentarlos übrigens 🙁

Wie Ihr oben in den Bildern und hier sehen könnt:

wird einem nicht mal erzählt, was da aktualisiert wurde. Ab und zu blitzt mal ein Name durchs Display, aber das wars dann auch schon.

Per DNF aktualisiert, gibt es ein Logfile, in dem ganz genau drin steht, wann was von welcher Version auf welche neue Version aktualisiert wurde. Da DNF das Update nicht gemacht hat, ratet mal …

Natürlich gibt es von PackageKit auch einen Logeintrag. Den kann man sich aber so nicht ansehen, weil man dazu den GPK Logger aufrufen muß: gpk-log

Das ist ultimativ toll, wenn man von dem Tool noch nie etwas gehört hat, oder? Ein grep über /var/log bringt einem nämlich nur die Einträge von DNF, die zum Packagekit Paket gehören, wenn DNF das updated 😀

Die Krönung des Ganzen

war dann der Umstand, daß ich sowieso noch ein Update vorhatte, um den neuen Surfacekernel einzuspielen. Dazu mußten einige alte LUA Paket entfernt werden, damit das Update überhaupt stattfinden konnte. Als dann das Update endlich ging, war schon wieder ein neuer normaler Kernel verfügbar, der dann natürlich auch alle Kernel-Module neu bauen mußte.

Fazit

Das offline-update ist in diesem Fall lästig und überflüssig gewesen, weil beim nächsten Start schon neue Pakete zur Verfügung standen. Der Sinn und Zweck davon, es beim BOOTEN durchzuziehen, erschließt sich ohnehin nicht, weil für ein Kernelupdate die Kernelmods neugebaut werden müssen und damit die dann auch benutzt werden, muß man ohnehin rebooten, was „Packagekit Offline-Update“ dann ja auch, mit wenig Erfolg, gemacht hat.

Da kann man es doch auch gleich beim Runterfahren installieren, oder??? Dann kann man am nächsten Tag wenigstens sofort arbeiten.

Lösung

Wie bekommen wir das weg?

systemctl disable packagekit packagekit-offline-update
systemctl mask packagekit

„Wir sehen uns wieder, wenn Du wieder vernünftiger geworden bist.“ Denn natürlich gibt es einen Grund, wieso man nicht einfach so GB!weise Daten zieht, nur weil man eine Internetanbindung hat.