Fedora: wie man mit RPM sein System auf Integrität prüft.

Heute geht es um Dateiintegrität und wie man das mit RPM prüft und ggf. behebt. Grund ist das Pinephone.

Fedora: wie man mit RPM sein System auf Integrität prüft.

Wenn man sein Pinephone zum ersten mal bootet, startet es mit dem Image auf der internen Storage mmcblk2. Will man etwas anderes Booten, so steckt man eine SD Karte rein, auf dem das Bootimage drauf ist. Das ist gerade am Anfang, wenn man viel Testet eine normale Sache, weil man die MicroSD Karte leicht wieder mit einem SD-Kartenreader am PC neu bespielen kann.

Wenn man aber zu an einen Punkt gekommen ist, wo das System gut genug funktioniert, möchte man es auf die interne Speicherkarte kopieren. Das könnt Ihr via rsync machen, oder Ihr kopiert die SD-Karte mit dem Tool dd rüber. Das hat aber einen Haken: Von dem System habt Ihr gerade gebootet und das läuft noch. Da man die Karte im laufenden Betrieb nicht wechseln sollte, steht Ihr vor einem Problem. Rsync umgeht das, aber Systemfiles lassen nicht so einfach syncen. Würde man so z.b. ein Fedora 33 auf ein anderes Fedora 33 syncen, würde es vermutlich laufen, aber (wie hier) ein Fedora auf Manjaro Syncen geht sehr wahrscheinlich voll in die Hose.

Wenn wir also dd steigt zwar die Erfolgschance, aber ein Datenverlust steht im RAM, weil die Programme auf der Partition rumwerkeln und die sich beim Kopieren ändern. Also am besten ALLES was geht beenden: Desktop, Services, alles bis auf SSHd und das Netzwerk.

Schritt 1 – Ermitteln was drauf ist

Dazu führt Ihr „rpm -qa > rpms“ aus. Nicht vergessen das File nachher wieder zu löschen.

Schritt 2 – jedes Paket prüfen

Dazu brauchen wir awk und ein klein wenig Bashmagie:

awk < rpms ‚{print „rpm -V –nolinkto –nomtime –nomode –nouser –nogroup –nordev –nodeps „$1;}‘ | bash > log

Das liest die Liste der RPMs Zeile-für-Zeile ein und prüft das Paket, ob die Checksummen mit den Dateien übereinstimmen. Einige Tests sind absichtlich abgeschaltet worden, weil für den Test, ob eine Datei beschädigt ist oder nicht, nicht nötig. Ob ich da mal dran war und die absichtlich verändert habe, war nicht die Aufgabe, kann man so aber auch machen, wenn man die –no Flags weglässt. „–nodeps“ sollte man aber drin lassen, weil sonst jedes Paket immer mit allen Abhängigkeiten geprüft wird und wir prüfen eh alle einzeln 😉

Schritt 3 – Defekte Dateien finden

Da wir in Schritt 2 eine Log-Datei angelegt haben, werten wir die aus und lassen uns gleich die Paketnamen der defekten Dateien geben. Das „sort -u“ wirft doppelte raus:

grep „\.5\.\.“ log | grep -v “ c “ | grep -v “ d „| grep -v ^S | awk ‚{print „rpm -qf „$2;}‘ | bash | sort -u

.5… ist die Ausgabe, wenn die Datei beschädigt ist und z.b. keine Configdatei ist. Configs können sich natürlich jederzeit ändern, deswegen sind die nicht gleich defekt.

Ein paar Beispiele was die Ausgaben so meinen:

S.5…… c /etc/ssh/sshd_config  Datei hat andere Checksumme, ist aber eine Configdatei
fehlend d /usr/share/man/fr/man1/manconv.1.gz Datei ist eine Dokumentation, nicht tragisch, wenn die nicht da ist.
fehlend /boot/efi/overlays/adau1977-adc.dtbo Datei fehlt und sollte aber da sein.
..5…… /usr/bin/mokutil Datei ist defekt und sollte ersetzt werden.

Schritt 4 – Reparieren

Nun haben wir eine Liste mit Paketnamen und müssen die nur noch reparieren. In meinem Fall waren es vier defekte Pakete:

dnf reinstall dcraw efibootmgr f2fs-tools mokutil -y

Das muß natürlich bei Euch so nicht passen, es könnte auch gut gehen oder andere Dateien betreffen!

Vom efibootmgr wissen wir jetzt, daß er gar nicht nötig ist auf einem Pinephone, weil das U-Boot benutzt und so gesehen kein EFI Bios vorhanden ist.

Ein Wort noch zum Pinephone:

Kopiert das System ruhig auf die interne Karte, weil das dann ca. 5x schneller ist: beim Booten, beim Runterfahren, Apps starten und updaten. Es lohnt sich wirklich.

2 thoughts on “Fedora: wie man mit RPM sein System auf Integrität prüft.

  1. Interessanter Artikel, aber mir ist nicht ganz klar, worauf Du mit dem awk/grep/in-bash-pipen-Kung-Fu hinauswillst. Das ‚awk {print „rpm -qf „$2;}‘ funktioniert ohnehin nicht, wenn der filename ein whitespace enthält. Warum nicht das Wissen nutzen, ab welchem Zeichen der Pfad beginnt (mehr oder weniger: „missing“ mal ausgenommen)?
    Und Du möchtest explizit nicht die Konfigurationsdateien prüfen: rpm -Va […] –noconfig. %ghost files interessieren idR nicht, hänge dann noch ein –noghost ran.

    Kurz also:
    rpm -Va –noconfig –noghost –nodeps –noscripts –nolinkto –nosize –nouser –nogroup –nomtime –nomode –nordev | cut -c 13- | xargs rpm -qf | sort -u

    Und wenn Du einfach nur den Paketnamen haben möchtest, um nicht diese exakte EVRA neu installieren zu müssen, sondern auch neuere Pakete zu erlauben, nimm „rpm -qf –qf ‚%{name}\n'“ statt „rpm -qf“.

    Für Deinen Anwendungsfall mit der nicht sauber entfernten SD-Karte mag dann diese Überprüfung ausreichen. Dann würde ich den Titel des Artikels aber einschränken, weil gerade die von Dir exkludierten Optionen sehr mächtig sind und ein IDS zwar nicht ersetzen, aber wenigstens doch sinnvoll ergänzen.

    Auf meinen Systemen führe ich eine solche Überprüfung täglich per cron bzw. systemd-timer aus, lasse allerdings auch u.a. user, group und permissions prüfen. Wenn sich nur etwas an den letzten drei Attributen geändert hat, ist es overkill, das Paket neu zu installieren, zumal auch etwaige %post-, %postun-, etc. scripts unangenehm ins System eingreifen können (ungewollter restart von services z.B.). Diese Attribute stelle ich dann über rpm –setperms bzw. rpm –setugids wieder her. Hat sich die checksum eines files (bin oder lib, irgendwelche falsch im specfile hinterlegten veränderbaren Dateien interessieren nicht) hingegen geändert, ist entweder das Dateisystem (oder das Blockdevice) kaputt oder jemand hat sich daran zu schaffen gemacht. Dann verlasse ich mich nicht darauf, das Paket einfach neu zu installieren.

    Nur meine 2¢ 🙂

    • Auf dem Pine ist das mit der exakten Version des Pakete extrem wichtig, weil einiges wegen dem RAWHIDE Repo, nicht sauber funktioniert, wenn man die neueste Version des Paketes einspielt. Auf einem stabilen Repopfad, wie F32 und F33, kann man das natürlich machen, weil das i.d.R. eh die neuste Version ist.

      Was wir für Probleme auf dem Pine derzeit wegen glib2 oder Pipewire und seinem Miniupdate von 2 Patchen, findet man ja ausreichend im Blog beschrieben 🙂 Das ist zur Zeit noch so eine.

      Ich finde Deinen Ansatz mit noconfig für das Problem der Dateiprüfung sehr gut, aber leider hätte ich nicht soviel dazu schreiben können, wenn ich das so gemacht hätte 😉

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.