EOL: Fedora 32 – so upgraded man sein System von Hand

Fedora 32 hat End-of-Live, da kann man mal zeigen wie so ein OS Upgrade von Hand aussieht.

EOL: Fedora 32 – so upgraded man sein System von Hand

Die meisten Fedora Benutzer werden schon lange vor diesem Tag Ihr Updateangebot durch ständiges Nerven bekommen haben. Wer dann auf „Ja, mach doch“ klickt, der verpasst einiges an Aktion und wird nie verstehen, was bei einem Distro-Upgrade so alles passiert.

Für diejenigen, die sich das gerne mal live ansehen wollen, so könnt Ihr dabei sein, aber nur, wenn Ihr auch noch Fedora 32 habt 😉

Den neuen Repo-Key importieren

Da alle Pakete signiert sind, braucht man zum Testen der Signatur einen Key von der neuen Release (33). Praktischerweise ist dieser Schlüssel bereits in der vorherigen Release(32) enthalten und muß nur schnell importiert werden:

rpm –import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-$(uname -i)

Warum das nicht auch automatisch gemacht wird, sobald ein neuer Key da ist, entzieht sich mir. Wenn Ihr vergessen habt, diesen Schlüssel hinzuzufügen, ist das nicht tragisch. DNF wird Euch im Updateprozess nochmal fragen, ob der Schlüssel hinzugefügt werden soll:

Warnung: /var/cache/dnf/rpmfusion-free-updates-f3bb44067d4cef3b/packages/svt-hevc-libs-1.5.1-1.fc33.x86_64.rpm: Header V3 RSA/SHA1 Signature, Schlüssel-ID d651ff2e: NOKEY
RPM Fusion for Fedora 33 – Free – Updates 1.6 MB/s | 1.7 kB 00:00
GPG-Schlüssel 0xD651FF2E wird importiert:
Benutzer-ID : »RPM Fusion free repository for Fedora (2020) <rpmfusion-buildsys@lists.rpmfusion.org>«
Fingerabdruck: E9A4 91A3 DE24 7814 E7E0 67EA E06F 8ECD D651 FF2E
Von : /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-free-fedora-33
Ist dies in Ordnung? [j/N]:

In diesem Fall fragt er nach dem Key von RPMFusion, was man als Fedorabenutzer braucht um z.B. Nvidia-Treiber und MPV zu installieren.

Immer mit screen arbeiten

„screen“ ist ein kleines Konsolen Programm, das Euch im Falle des Falles den Arsch retten kann. Beim Upgradevorgang kann es nämlich passieren, daß der Desktop zusammenbricht. Wenn Ihr jetzt nur in einem Terminalfester die nachfolgenden Befehle eingetippt habt, ohne das Screen an ist, dann bricht der Updatevorgang mitten drin ab.

Im Worst-Case-Fall habt Ihr ein nicht bootbares System vor Euch. Das System kann man reparieren, wenn einen USB-Stick mit einem bootbaren Fedora hat. Kurz beschrieben: die Systemplatte mounten, als Rootuser ein Chroot auf diese Systemplatte, das Update OHNE GRUB ( -x grub2* ) neu starten und zusehen, was weiter passiert.

Screen verhindert das Szenario, weil wenn das Terminal zusammenbricht, läuft Screen im Hintergrund weiter und es kommt gar nicht zur Unterbrechung des Upgradevorganges. Ergo:

screen

Das eigentliche Upgrade

Nun updaten wir erst einmal auf den neuesten Stand:

dnf clean all;dnf -y upgrade;

I.d.R. wird da nichts gemacht, aber falls Updates fehlen sollten, würden die jetzt eingespielt werden. Nun folgt das eigentliche Upgrade:

dnf –allowerasing –releasever=33 –setopt=deltarpm=false distro-sync

DNF wird jetzt zuerst die neuen Paketinformationen von Fedora 33 holen und dann berechnen wie groß und umfangreich das Upgrade wird. Auf einem Desktopsystem kann das schon einmal größer ausfallen:

Transaktionsübersicht
=============
Installieren 200 Pakete
Aktualisieren 4032 Pakete
Entfernen 12 Pakete

Gesamte Downloadgröße: 7.9 G
Ist dies in Ordnung? [j/N]:

Zum Glück habe ich Platz:

LABEL=SYSTEM 909G 184G 680G 22% /

Was jetzt folgt sind der Download und die eigentliche Aktualisierung.  Weil das hier nur so vorbei zischt, ein Bild für Euch:

Wie Ihr sehen könnt, läuft das Update während ich mit dem System arbeite, z.Z. tippe ich den Text hier 😉

Wie man rechts sehen kann, zeigt einem DNF im Gegensatz zu APT und Konsorten an, wieviele Schritte da noch kommen werden. 50% der Updateschritte sind übrigens „Aufräumen“ der alten Pakete. Die Schrittanzeige ist auch für Unbedarfte ein Vorteil, weil die Geduldsprobe „Desktopupgrade“ erträglicher geworden ist.

Jetzt braucht Ihr natürlich trotzdessen noch Geduld, weil auch mit SSDs brauchen die 8000 Schritte eine ganze Weile und die Hammerpakete wie 0AD, die gleich mal 1-2 GB hinzufügen, sind bei mir schon entfernt. Ich sollte trotzdem mal aufräumen 😉

Bei mit kommt in 4 Minuten der spannende Teil: Der Reboot 😉

Firefox: Sicherheitsloch „Memory-Dump“

Im Zuge eines Bugreports für Jitsi Meet kam raus, daß die Speicherfunktion im Firefox Modul „about:memory“ nicht nur den eigenen Speicherinhalt, sondern wohl auch den von anderen Prozessen abspeichern kann. So oder so, muß man aufpassen, was man heraus gibt.

Firefox: Sicherheitsloch „Memory-Dump“

Eine aktuelle Instanz von Jitsi Meet führt zusammen mit der „Hintergrund Blur“ Funktion der Videokonferenzsoftware zu einem massiven Speicherverbrauch von Firefox, der das System nach einiger Zeit zum Swap-of-Death treiben kann. Ob und wann das passiert, hängt natürlich stark von Eurem PC-Setup ab. Bei mir waren es 16 GB Hauptspeicher, die Firefox in knapp 3 Stunden mit 8+ GB eigenem Speicher gefüllt hatte, der Rest war vom System und OBS belegt, als das Problem aus heiterem Himmel auftrat. Da es sich um das LPD Live-Streaming handelte, hatte ich zum Glück noch eine zweite OBS Instanz in der Hinterhand, die das Streaming dann direkt übernommen hat.

Im Zuge des Bugreports an Mozilla wurde ein Speicherdump angefordert, der allerdings (aller Wahrscheinlichkeit nach) auch Daten des laufenden Matrixclientens enthielt, sowie sensible Zugangsdaten, die Firefox gerade in Benutzung hatte. Die teilweise 190 MB großen Textfiles von Hand nach sensiblen Informationen zu durchsuchen würde viel zu lange dauern. Insgesamt sprechen wir hier über eine etwas weniger als 1 GB große Textfilesammlung.

URLs, Userids und Matrixdaten

In den Files habe ich besuchte URLs mit GET Parametern, UserIDs für Jitsi und sämtliche Nutzernamen von dem Clienten bekannten Matrixbenutzern gefunden. Da Firefox nur mit einem Testbenutzer in Kontakt kam, kann es fast unmöglich Firefox gewesen sein, dessen Speicher die Benutzerkennungen von anderen Matrixaccounts enthielt.

Ich kann Euch nur raten, diese Textfiles vor dem Übersenden an den Support von Mozilla in Augenschein zu nehmen, damit Euch nicht sensible Daten abhanden kommen. Wenn der Bugreport im Tracker nicht als „Security“ Report markiert ist, kann jeder diese Datenfiles runterladen und darin nach Herzenslust rumstöbern.

Am Wochenende hatte erst von Golem den neuen Firefox-Absturzreport als „positiv für andere Software-Projekte“ bezeichnet. Nachdem was in meinem Dump ( nicht vom Absturztool erzeugt ) drin war, glaube ich das sofort, nur bin ich da anderer Ansicht. Ein Browser ist heute ein sehr sensibles Stück Datenhalde, da kann man nicht mehr einfach alles zum Hersteller schicken und schon gar nicht von an dem Problem unbeteiligten Prozessen.

Kleiner Lacher am Rande: Das angeforderte „Mozilla-Regressiontool“ 4.0.17 muß wohl auch erst einmal gefixt werden, es crasht nämlich beim Start hart und schmeißt einen Coredump 😉


Fontconfig warning: „/etc/fonts/conf.d/90-synthetic.conf“, line 5: unknown element „its:translateRule“
Fontconfig error: „/etc/fonts/conf.d/90-synthetic.conf“, line 5: invalid attribute ‚translate‘
Fontconfig error: „/etc/fonts/conf.d/90-synthetic.conf“, line 5: invalid attribute ’selector‘
Fontconfig error: „/etc/fonts/conf.d/90-synthetic.conf“, line 6: invalid attribute ‚xmlns:its‘
Fontconfig error: „/etc/fonts/conf.d/90-synthetic.conf“, line 6: invalid attribute ‚version‘
Fontconfig error: Cannot load config file from /etc/fonts/fonts.conf
Fontconfig warning: FcPattern object weight does not accept value [0 205)
Speicherzugriffsfehler (Speicherabzug geschrieben)

Da ist wohl „einiges“ im Argen bei Mozilla 😉

Quelle: https://github.com/mozilla/mozregression/releases

Linux am Dienstag: Programmauszug für den 25.5.

Linux am Dienstag Programmauszug für Morgen, den 25.5. ab 19:

Datenleak bei Impfzentrum in Niedersachsen
Bandit 10->11
Das Freenode Deaster
Linux Kernel 5.13 und die Uni Minasotta
Pinephone: „OMG – Ich hab es getan.“

und zu allem Überfluss geht es am Ende noch über UFOs und wie die den Amis auf den Keks gehen 😉

Wie immer auf https://meet.cloud-foo.de/Linux .