Fedora und das Packagekit Offline Update

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.

 

Pinephone: kleines Fedora Statusupdate

Weil mein Android J3 wohl einen defekten Kondensator im Empfangsschwingkreis hat, kommt Ihr jetzt in den Genuss eines Pinephone Statusreports 🙂

Pinephone: kleines Fedora Statusupdate

Fangen wir mal damit an:

Wenn Eurer Telefon den Funkmast mal findet und meisten gar nichts mehr finden will, dann ist entweder der Standort gut abgeschirmt, oder der Empfänger im Modem des Handies defekt. So oder so, reparieren lohnt nicht, auch wenn das Ersatzteil nur wenige Cents kosten würde, weil man den (wahrscheinlich) defekten SMD Kondensator erst aufwendig finden muß. Da sind die Lohnkosten leider zu hoch für 🙁

Gut, wenn man ein voll installiertes und konfiguriertes Pinephone rumliegen hat. Erstens kann man damit leicht testen, ob der Funkmast defekt ist, oder der Empfänger hin ist. Weniger gut ist, wenn Deine Pinephone DE in eine Endlosschleife wechselt, sobald Du mal rumswipst 🙁

Phosh 0.20.0

Phosh 0.20.0 hat einen, zum Glück behebbaren Bug, daß es in genauso eine Endlosschleife geht, wenn man den Taskmanager zweimal aufrufen will. Das Toppanel bekommen man zwar noch runter geswiped, aber rauf geht nichts mehr und Sound + Volumetasten waren auch nicht mehr reaktiv.

Um rauszufinden, ob Ihr den Fehler selbst beheben könnt, gebt mal als Pineuser per SSH ein:

$ gsettings get org.gnome.desktop.interface enable-animations

Wenn da „false“ rauskommt, dann seid Ihr mit dem Fix hier:

$ gsettings set org.gnome.desktop.interface enable-animations true
$ systemctl restart phosh

schnell auf der Gewinnerseite 😉

Pinephone powered down

Natürlich war die Zeit, als der Bug bei mir aktiv war nicht ganz ohne positiven Nebeneffekt, weil wir gleich das nächste Problem identifizieren konnten:

Wenn phosh oder phoc in so einer Endlosschleife festhängen, können Sie auf Tastenevents nicht mehr reagieren. Da greift dann der systemd-logind ein und behandelt das Event so, wie es in /etc/systemd/logind.conf festgelegt ist. Drückt man in so einer Situation auf die Powertaste, denn fährt der logind das System einfach runter! Das will man natürlich nicht, sondern Systemd soll Phosh neustarten, damit das wieder reagiert.

Das erreichen wir so:

Wir legen eine Datei namens /etc/systemd/logind.conf.d/ignore-power-key.conf an und schreiben da rein:

[Login]
HandlePowerKey=ignore

Dann..

$ systemctl restart systemd-logind phosh

und das Problem sollte weg sein. Da wir das erst heute zusammen mit Purism rausgefunden haben, muß ich noch abwarten wie sich das konkret auswirkt. Da aber min. eine andere Distro das auch schon per Default so blockiert, wird es wohl gehen.

Der aktuelle Stromverbrauch

Heute Nacht bin ich bei ca. 8h DeepSleep des Handies auf folgende Batterydauer bis zum Aufladen gekommen:

4% battery ( 84%->80%) in 8h im DeepSleep

ergibt 12% pro Tag, ergibt eine Woche Deepsleep, bevor man es wieder Aufladen muß. Dabei wird das Handy nicht ganz leer, was gut für den Akku ist. Allerdings verkürzt sich das dramatisch, wenn man es einschaltet 😀

 

Inkorrektes Portswitchen beim Telefonieren

Ihr wisst, daß es im Pinephone 2 Lautsprecher gibt, den zum Telefonieren ( internal Earpiece ) und den Lautsprecher ( Speaker ). Beim Telefonieren ist mir ausgefallen, daß der Callsd mal wieder die Profile nicht richtig schalten würde ( Default <-> Phone ) . Dem war aber nicht so, weil bei den Ports lediglich die falschen Ausgabegeräte eingestellt waren. Nachdem ich das im Pulseaudio-Lautstärkeregler korrekt eingestellt hatte, sprang das Pine wieder zwischen Telefonbetrieb und Lautsprecher, für alles andere, hin und her.

„Sicherheitsproblem“ für den Einen, „paßt schon“ für den Anderen

Im Lockscreen von Phosh kann man ohne Authentifizierung WLAN, Bluetooth und Mobile Daten abschalten. Einer kleinen Umfrage gestern bei Linux am Dienstag, konnten wir entnehmen, daß sich die OSe dahingehen nicht ganz einige sind, ob es ein Sicherheitsproblem darstellt oder nicht. AOS 5+ ist z.b. der Meinung, daß darf man ohne Authentifizierung nicht, iOS war da anderer Meinung.

Ich denke, es ist ein Sicherheitsproblem, weil wenn ich z.b. einen Tracker installiert habe, der mein Telefon wieder finden soll, wenn es geklaut wird oder verloren geht, dann sollte der Dieb das nicht abschalten können. Ok, er könnte das Telefon komplett abschalten, aber sobald er es bootet, würde der Tracker das melden.

Der entsprechende Bugreport bei Purism wurde nicht sofort geschlossen, was bedeutet, meine Argumente scheinen gewirkt zu haben. Der Kompromissvorschlag sieht vor, daß es „sicher“ ausgeliefert wird, aber per Control-Center in den „unsicheren“ Modus geändert werden kann. So haben alle den Zustand, den sie möchten.

Keine CoreDumps mehr nach Update

Stand Vorgestern, 15.8.2022, stürzt Evolution beim Start nicht mehr ab, wenn man auf dem neuesten Softwarestand ist. Das Booten geht damit auch wieder deutlich schneller 😉

Verbesserungen zur Kenntnis genommen

Phosh 0.20.0, oder auch schon 0.19.x, haben im Lockscreen beim Angerufen werden eine deutliche optische Verbesserung erfahren. Das sieht richtig schick aus. Weiter so!

„Entschuldigung für die vielen Security Fixe“

Aus der Schmunzelecke von Fedora … könnte man meinen …

Update Chromium to 99.0.4844.51. Fixes, well, a LOT of security bugs. Sorry
about that.  CVE-2021-22570 CVE-2022-0096 CVE-2022-0097 CVE-2022-0098
CVE-2022-0099 CVE-2022-0100 CVE-2022-0101 CVE-2022-0102 CVE-2022-0103
CVE-2022-0104 CVE-2022-0105 CVE-2022-0106 CVE-2022-0107 CVE-2022-0108
CVE-2022-0109 CVE-2022-0110 CVE-2022-0111 CVE-2022-0112 CVE-2022-0113
CVE-2022-0114 CVE-2022-0115 CVE-2022-0116 CVE-2022-0117 CVE-2022-0118
CVE-2022-0120 CVE-2022-0789 CVE-2022-0790 CVE-2022-0791 CVE-2022-0792
CVE-2022-0793 CVE-2022-0794 CVE-2022-0795 CVE-2022-0796 CVE-2022-0797
CVE-2022-0798 CVE-2022-0799 CVE-2022-0800 CVE-2022-0801 CVE-2022-0802
CVE-2022-0803 CVE-2022-0804 CVE-2022-0805 CVE-2022-0806 CVE-2022-0807
CVE-2022-0808 CVE-2022-0809

… ist es aber nicht 🙁

„Entschuldigung für die vielen Security Fixe“

Der Hintergrund ist, daß vor einigen Tagen festgestellt wurde, daß Chromium bei Securityfixen weit hinten lag bei Fedora, weil wichtige Security-Fixe nicht durch Updates verteilt wurden. Der Maintainer war leider nicht so aktiv, wie es das Projekt erfordert.

Das wurde nun offensichtlich von Tom nachgeholt, der in der Vergangenheit eigentlich als sehr aktiver Maintainer aufgefallen war. Man weiß nicht, was dazu führte und spekulieren will ich da auch nicht.

Ich fordere analog zum Sysadmin-Tag noch den Maintainer-Tag einzuführen. Wer nicht so lange warten will, kann seinen Lieblingsmaintainern ja auch einfach mal ein dickes „Thank You“ per Email schicken, was deutlich zur Langzeitmotivation der Menschen beiträgt, die für uns die Arbeit machen!

Und so kommt man die Mailadressen ran

Unter Fedora ist das relativ einfach: Entweder Ihr abonniert die Package-Announce Mailingliste „package-announce@lists.fedoraproject.org“ oder Ihr schaut ins Changelog des Pakets auf Eurem PC rein:

# rpm -qi –changelog httpd | grep „@“ | head -n 1
* Do Okt 07 2021 Patrick Uiterwijk <patrick@puiterwijk.org> – 2.4.51-1

Ich glaube, den muß ich auch mal motivieren 😀