dpkg: Fehler

[TofuWolf]

Hallo erstmal,
dies ist mein Erster beitrag und ich bin recht neu in der Unix Community. Daher bitte verzeiht mir meine Unwissenheit.

Ich betreibe einen (headless) Gameserver auf Debian 12 mit Casaos.

Code: Alles auswählen

max@debian-server:~$ neofetch
       _,met$$$$$gg.          max@debian-server 
    ,g$$$$$$$$$$$$$$$P.       ----------------- 
  ,g$$P"     """Y$$.".        OS: Debian GNU/Linux 12 (bookworm) x86_64 
 ,$$P'              `$$$.     Host: X600-ITX 
',$$P       ,ggs.     `$$b:   Kernel: 6.1.0-31-amd64 
`d$$'     ,$P"'   .    $$$    Uptime: 14 mins 
 $$P      d$'     ,    $$P    Packages: 581 (dpkg) 
 $$:      $$.   -    ,d$$'    Shell: bash 5.2.15 
 $$;      Y$b._   _,d$P'      Resolution: 1920x1080 
 Y$$.    `.`"Y$$$$P"'         Terminal: /dev/pts/0 
 `$$b      "-.__              CPU: AMD Ryzen 5 8600G w/ Radeon 760M Graphics (12) @ 4.350GHz 
  `Y$$                        GPU: AMD ATI 05:00.0 Phoenix1 
   `Y$$.                      Memory: 1754MiB / 31172MiB 
     `$$b.
       `Y$$b.                                         
          `"Y$b._                                     
              `"""

Problem:
Nach circa 30 minuten Betriebszeit hängt sich das Webinterface auf und bei neuladen bekomme ich keine verbindung.
Wenn ich einen Monitor anschließe, wird die ganze zeit einige Fehlermeldungen angezeigt, diese meldungen wurde auch mehrmals in der Sekunde angezeigt. So das dies fast unmöglich zu lesen war.



Im SSH Terminal wurde folgende Fehlermeldung angezeigt:

Code: Alles auswählen

dpkg: nicht behebbarer fataler Fehler, Abbruch:
Aktualisierter Status von »fontconfig« kann nicht synchronisiert werden: Eingabe-/Ausgabefehler
E: Sub-process /usr/bin/dpkg returned an error code (2)
W: Problem beim Entfernen (unlink) der Datei /var/cache/apt/pkgcache.bin - pkgDPkgPM::Go (30: Das Dateisystem ist nur lesbar)

Darauf hin konnte ich dies nur mit einem Neustart beheben, da das system keine Eingabe mehr erkannte hat. Der selbige Fehler ist jedoch nach gewisser Zeit wieder aufgetreten. Ich kann leider auch nichts genaueres in den Logs unter "journalctl" finden es, als wäre nie Etwas passiert.

Dies ist bei einer Frischen Debian Installation aufgetreten. Ich habe bereits geprüft das alle Pakete up to date sind.

In der längern Fehler meldung (siehe bild) wurde meine einzige SSD, eine Samsung 980 pro 2Tb erwähnt. Diese ist laut Smart Data OK und ist geradmal zu 5 GB befüllt.

[debilian]

in deiner Fehlermeldung steht:

EXT4-fs error (device nvme0n1p2)
filesystem read only

d.h. da kann nicht drauf geschrieben werden...

[FBT]

im unteren drittel des screenshots sieht man im journal, dass das ext4 Dateisystem auf der 2. nvme SSD Partition beschädigt ist

EXT4-fs error (device nvme0n1p2)

Vermutlich ist das Dateisystem so beschädigt, dass der kernel es nur noch read only mountet
der dpkg error ist dann nur eine Folge davon

Code: Alles auswählen

E: Sub-process /usr/bin/dpkg returned an error code (2)
W: Problem beim Entfernen (unlink) der Datei /var/cache/apt/pkgcache.bin - pkgDPkgPM::Go (30: Das Dateisystem ist nur lesbar)

ist /dev/nvme0n1p2 die root Filesystem Partiton? Dann solle das Dateisystem beim reboot forced repariert werden, was aber vermutlich nicht funktioniert hat.

An der Stelle würde ich die SSD ausbauen oder von USB ein anderes Linux booten und versuchen manuell das Dateisystem zu reparieren. Es könnte aber dennoch auch die Folge einer defekten SSD sein. Die S.M.A.R.T. Werte kennen wir aber nicht

[MSfree]

An der Stelle würde ich die SSD ausbauen oder von USB ein anderes Linux booten und versuchen manuell das Dateisystem zu reparieren.

Das sollte nicht nötig sein.

Man muß allerdings den Rechner mit angeschloßener Tastatur und Bildschirm booten. Da kommt in so einer Situation die Aufforderung, das root-Passwort einzugeben. Man bekommt dann eine Shell, in der man

Code: Alles auswählen

fsck /dev/nvme0n1p2

ausführen kann.

Ohne Monitor sieht man das natürlich nicht und der Kernel bootet dann irgendwann nach einem Timeout weiter.

Aber auch so, wenn das Dateisystem read-only gemountet wurde, kann man das Dateisystem mit dem o.g. Befehl reparieren. Danach sollte man aber rebooten.

[mat6937]

Darauf hin konnte ich dies nur mit einem Neustart beheben, ...

Mit welchem Befehl/Eingabe hast Du den Neustart gemacht?

[TofuWolf]

Darauf hin konnte ich dies nur mit einem Neustart beheben, ...

Mit welchem Befehl/Eingabe hast Du den Neustart gemacht?

Dies ging lediglich per Powercycle, da meine tastatur eingaben nicht erkannt wurden. normalerweise benutze ich sonst "shutdown"

[TofuWolf]

ist /dev/nvme0n1p2 die root Filesystem Partiton? Dann solle das Dateisystem beim reboot forced repariert werden, was aber vermutlich nicht funktioniert hat.

Ja, dies ist die root Partition. Jedoch wundert es mich das es die 2. Partition ist, bei der Installation habe eine Einzige Partition ausgewählt.

Edit:

Es könnte aber dennoch auch die Folge einer defekten SSD sein. Die S.M.A.R.T. Werte kennen wir aber nicht

Wie bereits erwähnt sind die S.M.A.R.T. Werte alle Perfekt

[TofuWolf]

in deiner Fehlermeldung steht:

EXT4-fs error (device nvme0n1p2)
filesystem read only

d.h. da kann nicht drauf geschrieben werden...

Danke, so weit bin ich auch gekommen.

[rhHeini]

Ja, dies ist die root Partition. Jedoch wundert es mich das es die 2. Partition ist, bei der Installation habe eine Einzige Partition ausgewählt.

Dein Rechner ist mit allerhöchster Wahrscheinlichkeit ein EFI only-System. Dann ist die p1 unvermeidbar die ESP.

[TofuWolf]

Dein Rechner ist mit allerhöchster Wahrscheinlichkeit ein EFI only-System. Dann ist die p1 unvermeidbar die ESP.

Ah okay, danke. Ich dachte mir schon fast das das Systempartition ist, war mir aber nicht ganze Sicher da das bei mit den Partitionen bei UNIX doch noch ein bisschen anders/neu ist. Lehrauftrag erfüllt, würde ich sagen.

[TofuWolf]

Das sollte nicht nötig sein.

Man muß allerdings den Rechner mit angeschloßener Tastatur und Bildschirm booten. Da kommt in so einer Situation die Aufforderung, das root-Passwort einzugeben. Man bekommt dann eine Shell, in der man

Code: Alles auswählen

fsck /dev/nvme0n1p2

ausführen kann.

Ohne Monitor sieht man das natürlich nicht und der Kernel bootet dann irgendwann nach einem Timeout weiter.

Aber auch so, wenn das Dateisystem read-only gemountet wurde, kann man das Dateisystem mit dem o.g. Befehl reparieren. Danach sollte man aber rebooten.

Habe jetzt versucht mit

Code: Alles auswählen

sudo touch /forcefsk

das Problem zu beheben, da es sich hier um die root Partition handelt. Leider erfolglos.

Werde jetzt nochmal den Tipp mit der portable Installation probieren.

[MSfree]

Habe jetzt versucht mit

Code: Alles auswählen

sudo touch /forcefsk

das Problem zu beheben, da es sich hier um die root Partition handelt. Leider erfolglos.

Woher hast du denn den Tip?

Das kann schon deshalb nicht funktioneiren, weil damit versucht wird, auf dem read-only gemounteten Dateisystem eine neue Datei anzulegen.

Führe doch als root einfach

Code: Alles auswählen

fsck -y /dev/nvme0n1p2

aus. Danach ein

Code: Alles auswählen

reboot

und alles sollte wieder laufen.

[TofuWolf]

Woher hast du denn den Tip?

Das kann schon deshalb nicht funktioneiren, weil damit versucht wird, auf dem read-only gemounteten Dateisystem eine neue Datei anzulegen.

Führe doch als root einfach

Code: Alles auswählen

fsck -y /dev/nvme0n1p2

aus. Danach ein

Code: Alles auswählen

reboot

und alles sollte wieder laufen.

1. Ich hatte das in einem Stackoverflow thread gelesen, da ich, wenn ich nicht falsch liege, ja erst das filesystem umounten müsste. Ich habe gelesen dass das auch geht, aber das schien mir aber noch ein stückchen zu fortgeschritten.
2. Doch. Eigentlich ist es ja kein read-only filesystem. Wenn ich das System powercycle, Funktioniert alles wie gewollt. das filesystem ist im read-write oder so, aber wie erwähnt nach 30 oder 45 Minuten uptime, geht nichts mehr.
3. Wenn ich deinen Tipp ausführe kriege ich folgende Rückmeldung:

Code: Alles auswählen

max@debian-server:~$ fsck -y /dev/nvme0n1p2
fsck from util-linux 2.38.1
e2fsck 1.47.0 (5-Feb-2023)
/dev/nvme0n1p2 is mounted.
e2fsck: Cannot continue, aborting.

[MSfree]

1. Ich hatte das in einem Stackoverflow thread gelesen, da ich, wenn ich nicht falsch liege, ja erst das filesystem umounten müsste. Ich habe gelesen dass das auch geht, aber das schien mir aber noch ein stückchen zu fortgeschritten.

Sowas kann nicht funktionieren, wenn das Dateisystem read-only gemountet ist.

Vermutlich bezog sich das auch nicht auf Debian. Es wäre mir zumindest neu, daß man durch anlegen einer Datei einen Dateisystemcheck beim Booten auslösen könnte. Beim Raspberry gibt es so eigentartige Konstrukte.

Solange das Dateisystem read-only ist, braucht man es nicht vorher unmounten. Davon abgesehen, daß man das /-Dateisystem nicht unmounten kann, denn damit entzieht man dem OS die Lebensgrundlage.

2. Doch. Eigentlich ist es ja kein read-only filesystem. Wenn ich das System powercycle, Funktioniert alles wie gewollt. das filesystem ist im read-write oder so

Das solltest du nach dem Reboot aber prüfen.

Code: Alles auswählen

mount | grep " / "

sollte klar ausgeben, ob das Dateisystem rw (read/write) oder ro (read-only it).

Ich hatte es von vorherigen Beiträgen jedenfalls so aufgefaßt, daß das Dateisystem ro ist.

aber wie erwähnt nach 30 oder 45 Minuten uptime, geht nichts mehr.

Ich hoffe, die SSD hat keine Schlag. Es soll da ja gefälschte Ware geben, die nur ein paar GB Speicher haben, sich aber als x Terabyte ausgeben.

3. Wenn ich deinen Tipp ausführe kriege ich folgende Rückmeldung:

Code: Alles auswählen

max@debian-server:~$ fsck -y /dev/nvme0n1p2
fsck from util-linux 2.38.1
e2fsck 1.47.0 (5-Feb-2023)
/dev/nvme0n1p2 is mounted.
e2fsck: Cannot continue, aborting.

Ich hatte ja oben geschrieben, den fsck als root auszuführen. Als "max" hast du keine Berechtigung, das Dateisystem zu manipulieren. Je nachdem, wie du dein System installiert hast, mußt du entweder

Code: Alles auswählen

su -

(unbedingt das Minuszeichen mitgeben) eingeben, um root zu werden, oder dem fsck-Befehl ein sudo voranstellen.

[heisenberg]

@MSfree:

Ich bin doch stark verwundert, dass Du schreibst, dass ein fsck bei (read-only) gemountetem Dateisystem gehen soll. Ich bin der Meinung dass das noch nie ging. Ich habe das nochmal kurz ausprobiert. Das funktioniert bei mir nicht:

Code: Alles auswählen

# dd if=/dev/zero bs=1000 count=1M >looptest.raw
...
# losetup /dev/loop5 looptest.raw
...
# mkfs -t ext4 /dev/loop5
...
# mkdir mountpoint
...
# mount -o ro /dev/loop5 mountpoint
...
# fsck /dev/loop5
fsck from util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
/dev/loop5 is mounted.
e2fsck: Cannot continue, aborting.

Das System, auf dem ich das ausgeführt habe ist ein Testrechner (altes Ubuntu 18.04).

Nachtrag: mit Option -f (=force check) geht es (natürlich als root!).

Also:

Code: Alles auswählen

fsck -f -y /dev/$YOURDEVICE

Hier gibt's dann nur eine Warnung:

Code: Alles auswählen

# fsck -y -f /dev/loop5
fsck from util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
Warning!  /dev/loop5 is mounted.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/loop5: 11/64000 files (0.0% non-contiguous), 8748/256000 blocks

[TofuWolf]

Das solltest du nach dem Reboot aber prüfen.

Code: Alles auswählen

mount | grep " / "

sollte klar ausgeben, ob das Dateisystem rw (read/write) oder ro (read-only it).

Ok, das ist eine sehr gute Spur.

Code: Alles auswählen

max@debian-server:~$ mount | grep " / "
/dev/nvme0n1p2 on / type ext4 (rw,relatime,errors=remount-ro)

Wenn ich das richtig verstehe, wechselt die SSD bei einem Fehler in read-only. Frag ich mich nur wie man das nun "Deaktivieren" kann.

Die SSD hat auch auf jeden Fall keinen Schuss. Und es ist auch eine Echte. Hatte sie bis vor einer Woche noch in meinem Computer benutzt, bevor sie in meinem Server endete.

Und ja, das mit "root fsck" ist mir dann auch aufgefallen, jedoch gleiches Ergebniss. Mein Fehler

Edit: Jetzt ergibt das auch so langsam alles sinn. Nur ist das Standard mäßig in Debian so? Und woher kommt dieser Fehler, der den rw mode wechselt?

[heisenberg]

Wenn ich das richtig verstehe, wechselt die SSD bei einem Fehler in read-only. Frag ich mich nur wie man das nun "Deaktivieren" kann.

Ja. Bei Fehlern (kritischen Hardwarefehlern, oder kritischen Beschädigungen des Dateisystems, ...) wird das automatisch auf Read-Only umgestellt. Das ist ein Schutzmechanisum, da ansonsten möglicherweise Dein Dateisystem und Deine Daten irreparabel beschädigt würden. Dieser Schutzmechanismus ist also etwas sehr Gutes.

Du kannst die Option errors=remount-ro natürlich entfernen. Ich würde stark davon abraten. Wenn Du regelmässig einen remount-ro hast, dann hast Du tatsächlich ein Problem, was ich erst einmal herausfinden wollen würde, statt die Sicherheitsmassnahme abzuschalten.

Als nächstes würde ich auch erst Mal den den fsck machen, damit Dein fs wieder sauber ist. Den Check macht man im Normalfall entweder über ein Rettungssystem, also per USB-Stick mit GRML, System Rescue CD, dem Debian Rescue oder im Single User Mode - beide Methoden wenn das Dateisystem nicht eingehängt ist.

Und nur für den Fall, dass das betreffende System öfters per Knopf hart ausgeschaltet wird:

Dir muss natürlich auch klar sein, dass wenn Du das System einfach per Knopf (lange halten) ausschaltest, Dein Dateisystem erst einmal beschädigt ist. Ext4 ist da meist recht robust und der automatische Check repariert das meistens klaglos. Manchmal aber eben auch nicht. Ist kein Ding. Kann man machen, wenn man weiss, was man tut. Aber normaler Umgang mit einem System ist das nicht.

[TofuWolf]

Okay ich habe jetzt unter Grml eine Fsck lauf gemacht.

Code: Alles auswählen

root@grml ~ # fsck -f -y /dev/nvme0n1p2 
fsck from util-linux 2.40.2 
e2fsck 1.47.2-гс1 (28-Nov-2024) 
Pass 1: Checking inodes, blocks, and sizes 
Inode 67389965 extent tree (at level 1) could be shorter. Optimize? yes 

Pass 1E: Optimizing extent trees 
Pass 2: Checking directory structure 
Pass 3: Checking directory connectivity 
Pass 4: Checking reference counts 
Pass 5: Checking group summary information 

/dev/nvme0n1p2: ***** FILE SYSTEM WAS MODIFIED ***** 
/dev/nvme0n1p2: 161306/122003456 files (0.1% non-contiguous), 10192585/487997184 blocks 
root@grml ~ # 

Danach habe ich mit nochmal die Logs angeguckt.

Code: Alles auswählen

max@debian-server:~$ sudo journalctl -p3 -b -1
Mär 07 18:40:39 debian-server kernel: hub 4-0:1.0: config failed, hub doesn't have any ports! (err -19)
Mär 07 18:40:39 debian-server kernel: iwlwifi 0000:04:00.0: firmware: failed to load iwl-debug-yoyo.bin (-2)
Mär 07 18:40:39 debian-server kernel: firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
Mär 07 18:40:39 debian-server kernel: iwlwifi 0000:04:00.0: firmware: failed to load iwl-debug-yoyo.bin (-2)
Mär 07 18:40:40 debian-server kernel: amdgpu 0000:05:00.0: firmware: failed to load amdgpu/gc_11_0_1_mes_2.bin (-2)
Mär 07 18:40:40 debian-server kernel: amdgpu 0000:05:00.0: firmware: failed to load amdgpu/gc_11_0_1_mes_2.bin (-2)
max@debian-server:~$ sudo journalctl -p3 -b -0
Mär 07 19:17:01 debian-server kernel: hub 4-0:1.0: config failed, hub doesn't have any ports! (err -19)
Mär 07 19:17:01 debian-server kernel: iwlwifi 0000:04:00.0: firmware: failed to load iwl-debug-yoyo.bin (-2)
Mär 07 19:17:01 debian-server kernel: firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
Mär 07 19:17:01 debian-server kernel: iwlwifi 0000:04:00.0: firmware: failed to load iwl-debug-yoyo.bin (-2)
Mär 07 19:17:02 debian-server kernel: amdgpu 0000:05:00.0: firmware: failed to load amdgpu/gc_11_0_1_mes_2.bin (-2)
Mär 07 19:17:02 debian-server kernel: amdgpu 0000:05:00.0: firmware: failed to load amdgpu/gc_11_0_1_mes_2.bin (-2)
max@debian-server:~$

Dort wurden diese Fehler gelistet. Die Fehler beziehen sich auf ein USB hub, mein wifi/bt nic und meine iGPU. Wahrscheinlich bei den letzten beiden Treiber Fehler. Die Fehler wurden aber bei der Boot initialisierung aus gegeben (bei jedem Booten). Weswegen ich nicht glaube das diese Fehler die Ursache für mein Problem, dem remount zu ro waren. Es ist aber auch nicht weiteres Gelistet, außer die startup Prozedur und der Kommunikation zwischen Casaos und dem Webinterface

[heisenberg]

Code: Alles auswählen

journalctl -p3 -b -1
...

...weswegen ich nicht glaube, das diese Fehler die Ursache für mein Problem ... waren.

Sehe ich auch so. Ich würde vermuten, wenn Firmware fehlt, dann gehen manche Geräte oder Funktionen von Geräten nicht. Das hat aber erst einmal weniger mit SSD-/Dateisystemfehlern zu tun.

Zu Deinem Screenshot aus dem 1. Beitrag: Da steht etwas von "Failed to rotate: /pfad/zu/datei: Input/Output error". Das interpretiere ich als Hardwarefehler. Informationen zu Hardwarefehlern findet man vorzugsweise im Kernel-Log:

Code: Alles auswählen

journalctl -t kernel

Also für den Fall, wenn das wieder auftritt.

Ansonsten: Zeige doch Mal die Ausgabe von smartctl -a /dev/$YOURDEV bzw. nvme smartlog /dev/$YOURDEV. Das Paket nvme-cli sollte instaliert sein.

[TofuWolf]

Ansonsten: Zeige doch Mal die Ausgabe von smartctl -a /dev/$YOURDEV bzw. nvme smartlog /dev/$YOURDEV. Das Paket nvme-cli sollte instaliert sein.

smartctl: https://pastebin.com/qT0vXjTE

nvme smart-log: https://pastebin.com/0D850gTH

Wie bereits erwähnt sind die SMART Daten eigentlich in Ordnung. Etwas auffällig sind nur die Power on hours, Power cycles und unsafe shutdowns.

Also für den Fall, wenn das wieder auftritt.

Das Problem ist, wenn es wieder auftritt, lassen sich keine Tastatur Eingaben machen. Und wenn ich nach einem Neustart in die journalctl gucke, finde ich nichts zu einem Fehler.

Edit: Das nvme-cli paket war nicht vorinstalliert. Ich frage mich ob das zu Problemen geführt haben könnte?

Edit2: Jetzt wo ich so drüber nachdenke, kann es sein, das der Server dazu nichts in die Logs schreibt, weil er schon auf RO ummountet?

[heisenberg]

...Etwas auffällig sind nur die Power on hours, Power cycles und unsafe shutdowns.

Ja. 179 Unsafe shutdowns passen mit einem kaputten Dateisystem schon gut zusammen.

Das Problem ist, wenn es wieder auftritt, lassen sich keine Tastatur Eingaben machen. Und wenn ich nach einem Neustart in die journalctl gucke, finde ich nichts zu einem Fehler.

Du kannst Dich nicht mehr per SSH anmelden in so einem Fall? Du kannst keine USB-Tastatur/Monitor anschließen in so einem Fall?

Edit: Das nvme-cli paket war nicht vorinstalliert. Ich frage mich ob das zu Problemen geführt haben könnte?

Sehr unwahrscheinlich. nvme-cli ist vermutlich nur ein Admin-Tool, sonst wäre es im Basis-Umfang installiert.

Jetzt wo ich so drüber nachdenke, kann es sein, das der Server dazu nichts in die Logs schreibt, weil er schon auf RO ummountet?

Hört sich logisch an. Du könntest ja mal temporär /var/log auf einen anderen Datenträger auslagern (UUID -> fstab). Wenn so einer nicht exisitiert, dann tut's temporär vielleicht mal ein USB-Stick. (Langfristig dürfte der USB recht schnell kaputt gehen).

EDIT: Remote-Logging auf ein anderes System ginge auch. [1],[2]

[1] https://deepdoc.at/dokuwiki/doku.php?id ... otelogging
[2] https://cd-portal.sp.ethz.ch/linux/Wiki ... rnald.aspx

[TofuWolf]

Du kannst Dich nicht mehr per SSH anmelden in so einem Fall? Du kannst keine USB-Tastatur/Monitor anschließen in so einem Fall?

Also natürlich kann ich USBTastatur/Monitor anschließen, aber es lässt sich keine Eingaben machen, Videosignal bekomme ich.
SSH habe ich bisher noch nicht richtig ausprobiert, da ich das build in terminal im web interface benutze. Werde ich aber auf jedenfall dann nochmal probieren. Werde jetzt nochmal versuchen das logging auf nen anderen Datenträger zu verlegen. Und danach evt. nochmal das system auf einen anderen Datenträger zu installieren und dann vielleich nochmal eine andere linux distro.

[heisenberg]

Wenn Du noch ein zweite Tastatur hast, könntest Du die ja mal dauerhaft dran lassen. Vielleicht geht sie dann, wenn Du sie brauchst.