dpkg Problem nach Stromausfall

  • Hallo Foristen,

    ich habe seit Jahren zwei alte Raspis im Einsatz. Vor kurzem hatten wir einen Stromausfall, nachdem der eine von beiden zunächst nicht mehr startete. Es handelt sich um einen Pi 2 Model B Rev 1.1, auf welchem 32-bit bullseye-lite Kernel 6.1.21-v7+ läuft und nur ein Radicale CalDav-Server.

    Ich habe die SD-Karte mit GParted geprüft und so Fehler behoben und ihn dann an den TV angeschlossen und festgestellt, dass er bei einem Login stehen blieb. Nach Eingabe der Logindaten fuhr er weiter hoch. Dann habe ich zum Test ein sudo apt update gemacht, was auch normal lief. Dann habe ich ihn herunter gefahren und wieder an seinen Platz gebracht.

    Am nächsten Tag funktionierte dann das Synchronisieren mit dem CalDav nicht mehr. Ich konnte mich zwar im Browser an dem Server anmelden, er war aber bei Synchronisationen mit Thunderbird oder DAVx-App nicht erreichbar.

    Bei einem Versuch mit sudo apt upgrade trat ein Fehler mit der man-db auf, welcher bisher nicht behoben werden konnte. Ich habe folgendes schon versucht:

    Code
    pi@raspicaldav:~ $ sudo apt --fix-broken install
    E: Der dpkg-Prozess wurde unterbrochen; Sie müssen manuell »sudo dpkg --configure -a« ausführen, um das Problem zu beheben.
    pi@raspicaldav:~ $ sudo dpkg --configure -a
    man-db (2.9.4-2) wird eingerichtet ...
    Updating database of manual pages ...

    An der Stelle bleibt er immer hängen.

    Code
    pi@raspicaldav:~ $ apt-cache policy man-db
    man-db:
      Installiert:           2.9.4-2
      Installationskandidat: 2.9.4-2
      Versionstabelle:
     *** 2.9.4-2 500
            500 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf Packages
            100 /var/lib/dpkg/status

    Dann dieses probiert:

    Code
    pi@raspicaldav:~ $ sudo dpkg --dry-run --remove --ignore-depends --force-remove-reinstreq man-db
    dpkg: Fehler: --ignore-depends benötigt einen gültigen Paketnamen. »--force-remove-reinstreq« ist kein solcher; ungültiger Paketname in Spezifizierer »--force-remove-reinstreq«: muss mit alphanumerischem Zeichen beginnen

    Da bieb er wieder hängen!

    Jetzt weiß ich nicht mehr weiter. Nach Löschen und Neuanlegen der Kalender scheint die CalDav-Funktion wieder zu laufen.

    Aber wie bekomme ich das dpkg Problem weg?

  • Mach einmal einen richtiges fs-chk des root Filesystems, einschl. der -f und allenfalls der -c Option.

    RTFM
    February 11, 2021 at 11:19 AM

    Möglicherweise war Dein GParted-Frontend wirkungslos.


    Servus !

    RTFM = Read The Factory Manual, oder so

  • Erstmal danke für Deine Antwort!

    Dazu ein paar Fragen:

    1. Raspi shutdown, SD-Karte entnehmen und in den Kartenleser vom PC stecken, korrekt?

    2. Diese Eingabe im Terminal machen: sudo e2fsck -nfv /dev/mmcblk0p2 ?

    3. Kann dabei etwas auf dem Raspi-OS zerstört werden?

    4. Steht das Ergebnis dann im Terminal?

  • Das ist das Ergebnis:

  • Ich habe folgendes schon versucht:

    Code
    pi@raspicaldav:~ $ sudo dpkg --configure -a
    man-db (2.9.4-2) wird eingerichtet ...
    Updating database of manual pages ...

    An der Stelle bleibt er immer hängen.

    Was genau meinst Du mit "bleibt er immer hängen"?

    Was hast Du gemacht, als er "hängen geblieben ist" bzw. wie viele "Sekunden" hast Du gewartet?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden
    "Das dauert plötzlich ½ Sekunde länger. Das muss ich mir anschauen!" - Andres Freund

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.5 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server, botamusique, ample

  • Die Anzeige bleibt an dem Punkt "Updating database of manual pages ..." stehen. Ich habe 30 Minuten gewartet und dann mit Strg+c abgebrochen.

    OK. Das nächste mal mit:

    Code
    ps aux | grep -i [d]pkg
    # und mit
    top

    nachschauen ob er hängt und evtl. länger als 30 Minuten warten.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden
    "Das dauert plötzlich ½ Sekunde länger. Das muss ich mir anschauen!" - Andres Freund

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.5 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server, botamusique, ample

  • Könnt ihr mir bitte nochmal die exakte Eingabe vorgeben?

    Siehe im Beitrag #8:

    Code
    ps aux | grep -i [d]pkg
    Code
    top

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden
    "Das dauert plötzlich ½ Sekunde länger. Das muss ich mir anschauen!" - Andres Freund

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.5 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server, botamusique, ample

  • Alles klar, danke!

    Ich habe das jetzt nochmal gestartet. Es läuft mittlerweile seit über einer Stunde!

    Code
    sudo dpkg --configure -a
    man-db (2.9.4-2) wird eingerichtet ...
    Updating database of manual pages ...
    Code
    ps aux | grep -i [d]pkg
    root     13655  0.0  0.4  13112  4260 pts/0    S+   11:22   0:00 sudo dpkg --configure -a
    root     13656  0.0  0.3  10352  3528 pts/0    S+   11:22   0:00 dpkg --configure -a
    root     13657  0.0  1.4  20684 13356 pts/0    S+   11:23   0:01 /usr/bin/perl -w /usr/share/debconf/frontend /var/lib/dpkg/info/man-db.postinst configure 2.9.4-2
    root     13666  0.0  0.0   1972   408 pts/0    S+   11:23   0:00 /bin/sh /var/lib/dpkg/info/man-db.postinst configure 2.9.4-2

    Sind die Prozesse wirklich noch am Laufen? Kann das sein?

  • Es läuft immer noch! =O

    Kann ich das ssh-Terminalfenster schließen, ohne den Prozess abzubrechen?
    Wenn nicht, müsste ich ja meinen PC immer weiter laufen lassen, was ziemlich blöd ist. ?(

  • Kann ich das ssh-Terminalfenster schließen, ohne den Prozess abzubrechen?

    Evtl. ja. Schau nach was die PPID von den bzgl. dpkg/man-db-Prozesse ist und wenn die mit sshd nichts zu tun hat, kannst als user pi, mit kill die ssh-Verbindung trennen:

    Code
    ps -o ppid= <PID> # Leerstelle zwischen = und PID; ohne spitze Klammern!
    kill -15 14077

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden
    "Das dauert plötzlich ½ Sekunde länger. Das muss ich mir anschauen!" - Andres Freund

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.5 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server, botamusique, ample

  • Also hier sehe ich die PID 13675 und 9500 von den mandb-Prozessen.
    Die PID 15500 und die PID 15512 ist das zweite ssh-Terminal, in welchem ich gerade "TOP" aufgerufen habe. Die sind nämlich bei jedem neuen Öffnen eines zweiten Fensters wieder neue höhere Nummern.

    Ich sehe keinen weiteren sshd-Task in der TOP-Liste.
    Welche PID soll ich nun hier ps -o ppid= <PID> eingeben?

    Bei diesem Befehl kill -15 14077 ist die 14077 die PID von dem 2. Terminal, welches ich um 12:37 Uhr geöffnet hatte, um TOP aufzurufen! Die gibt es schon lange nicht mehr.

    Code
      PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL     
    13675 man       20   0    9396   3396   2280 R 100,0   0,4 272:42.29 mandb      
     9500 man       39  19   11268   5612   3572 R 100,0   0,6 955:13.67 mandb      
    15512 pi        20   0   11332   3192   2644 R   0,7   0,3   0:03.77 top        
    15500 pi        20   0   14516   4640   3700 S   0,3   0,5   0:01.38 sshd       
        1 root      20   0   33788   8800   7024 S   0,0   0,9   0:20.57 systemd    
        2

    Edited once, last by Neptun62 (March 24, 2024 at 4:17 PM).

  • Welche PID soll ich nun hier ps -o ppid= <PID> eingeben?

    Code
      PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL     
    13675 man       20   0    9396   3396   2280 R 100,0   0,4 272:42.29 mandb      
     9500 man       39  19   11268   5612   3572 R 100,0   0,6 955:13.67 mandb      

    Diese:

    Code
    13675      
     9500

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden
    "Das dauert plötzlich ½ Sekunde länger. Das muss ich mir anschauen!" - Andres Freund

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.5 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server, botamusique, ample

  • Ergebnis:

    Code
    pi@raspicaldav:~ $ ps -o ppid= 13675
    13666
    pi@raspicaldav:~ $ ps -o ppid= 9500
        1

    Beim ps -e sieht es so aus:

    Hier zur Übersicht:

    Edited once, last by Neptun62 (March 24, 2024 at 5:01 PM).

  • So, es erschien mir merkwürdig, dass da zwei mandb-Prozesse waren, wovon einer viel älter war, als der den ich zuletzt gestartet hatte. Ich habe dann den PID 9500 mit kill beendet und zunächst geschaut, was passiert. Dann habe ich den laufenden Prozess in der ersten Shell mit Strg+c beendet und schließlich den Raspi neu gestartet.

    Als er fertig war, habe ich in der ps -e und mit top nachgeschaut, ob da irgendwas von "mandb" zu finden war. Das war nicht der Fall. Dann habe ich den sudo dpkg --configure -a wieder gestartet und anschließend in einer 2. shell geschaut, welche Prozesse laufen. Und siehe da: es läuft nur ein "mandb"-Prozess.
    Jetzt werde ich wieder warten und bin gespannt, ob es jetzt durchläuft.

  • Nachdem der Raspi die ganze Nacht durch mit diesem mandb-Prozess erfolglos gelaufen war, habe ich dann aufgegeben und ihn komplett neu mit dem aktuellen bullseye eingerichtet. Jetzt läuft alles wieder fehlerfrei!

    Es war also weder die SD-Karte noch der Raspi defekt! Lediglich Daten wurden beim Stromausfall beschädigt.

    Schade! Ich hatte gedacht, bei Linux-Systemen könnte man durch entsprechende Eingriffe ins Dateisystem solche Fehler beheben. Da habe ich wohl zu viel erwartet. Einfach nur stumpf das ganze System neu installieren, das erinnert mich leider an MS!

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!