Linux Partition kaputt, und dann doch nicht

Stefan ⛄ F. schrieb:
> Hat jemand eine Idee, was das gewesen sein könnte?

Hast Du die Fehlermeldungen mit dmesg angesehen und abgelegt?
Daraus müßte mehr zu schließen sein.

Es gab eine Zeil lang ein Problem mit Ext4 und Ext3 auf USB-Sticks an 
unterschiedlichen Rechnern. Das Filesystem bekam eine Erweiterung 
verpaßt durch eine neue Version, die der andere nicht lesen konnte. Ein 
fsck schmiss daher alle Dateien weg, die gändert wurden.

Könnte bei Dir ein ähnliches Problem gewesen sein.

Was mir dazu als erstes einfällt (weil schon gehabt): Wackelkontakt am 
HD Kabel.
Ansonsten: syslog.

Stefan ⛄ F. schrieb:
> Hast du vielleicht noch einen Tipp, wonach man suchen könnte? (nach
> "error" habe ich schon gesucht, nichts relevantes gefunden).

Das ist anscheinend ein Henne-Ei-Problem in Verbindung mit der 
Optimierung, dass Linux schneller startet. Ich erinnere mich beim 
Informatiker eine Kritik zu Linux gelesen zu haben, dass innerhalb von 
/sys /run /var dev usw. in Verbindung mit dem neuen Kernel wieder 
etwas umgestellt wurde.

Der neue Kernel macht einen Neustart, liest aus was er findet. Die neuen 
gänderte Verzeichnisse werden zwar geschrieben, die Inhalte in der Form 
der neuen Struktur zur Hardware standen beim ersten Schnellboot nicht 
zur Verfügung.

Der alte, aber aktualisierte Kernel kann aber mit den Strukturen des 
vorherigen Kernels umgehen und bekam Erweiterungen, dass der die neuen 
Strukturen verwenden kann, sofern diese gesichtet werden. Das scheint 
der alte Kernel gemacht zu haben, bzw. die Eintragungen sind durch 
diesen nun drinnen und das Henne/Ei-Problem ist dadurch nun weg.

Genau genommen hätte man verschiedene Infos in dem Zustand mit hdparm 
herausgraben müssen, mit mount manuell noch ein paar Fehlermeldungen 
generieren müssen und auch mit "debugging" aufrufen sollen.

Eine Methode wäre zum Beispiel:
https://www.tecmint.com/strace-commands-for-troubleshooting-and-debugging-linux/

Da kann man aber viel Zeit für die Suche versenken. Instinktiv fandest 
Du bereits eine einfache Lösung, die das automatisch erledigte.

Stefan ⛄ F. schrieb:
> Ich hätte Logs vom Fehler sichern sollen, aber da der zweite ...

Einige Fehlermeldungen sind in der Regel noch vorhanden.

/var/log $ ls
 kern.log  kern.log.1 kern.log.2.gz usw.
syslog.log  syslog.log.1 syslog.log.2.gz usw.

Aus diesen hattest Du heute bereits gepostet.

Stefan ⛄ F. schrieb:
> Heute morgen startete er nicht mehr. Fehlermeldung war, dass meine
> Medien-Partition auf der HDD nicht gemounted werden kann, weil sie kein
> gültiges ext4 Filesystem enthält.

Warum startet Linux nicht mehr, wenn eine optionale Partition nicht 
gemountet werden kann? Die ist doch für den Betrieb nicht nötig?

Hallo Stefan,

Stefan ⛄ F. schrieb:
> Mache ich. Habe ein bisschen Schiss, dass die HDD eine Macke hat.

zeig' mal mit smartmontools die SMART-Parameter der verdächtigen 
Festplatte:

smartctl -a /dev/sdX > stefan.txt

Ersetze X durch den Laufwerksbuchstaben der verdächtigen Platte.

>Heute morgen startete er nicht mehr. Fehlermeldung war, dass meine
>Medien-Partition auf der HDD nicht gemounted werden kann, weil sie kein
>gültiges ext4 Filesystem enthält. Also habe ich das root Passwort für
>den abgesicherten Modus eingetippt und es manuell versucht - keine
>Chance.

>Dann habe ich nochmal den mit dem alten Kernel gebootet, was tadellos
>klappte (gut das das bei Linux geht)."

Bei so einem Verhalten wäre mein erster Verdacht eine falsch generierte 
initrd - wenn nicht, wie von anderen Postern bereits beschrieben, ein 
Treiberbug.

Stefan ⛄ F. schrieb:
> Debian 10 Buster (stable) auf Version 11 Bullseye (testing)

Kleine Bugs bei initrd oder Treiber sind durchaus auch möglich. Er hat 
ja auch aktualisiert auf eine Testing-Version.

Das ist es auch überhaupt nicht überraschend, dass nicht alles ganz 
zickenlos funktioniert. Die Sonderroutinen des Schnellstarts husten da 
ganz gerne mal.

Hallo Stefan,

den Fehler mit der Nr. 187 habe ich bei mir noch nicht gesehen.

187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always 
-       8590000128
188 Command_Timeout         0x0032   100   100   000    Old_age   Always 
-       524288

Meine Empfehlung:
Duplizier die Platte mit ddrescue und melde Dich, wenn der Fehler noch 
einmal auftaucht.

Stefan ⛄ F. schrieb:
> Aber wenn die Platte wirklich über 500.000 Timeouts und 8 Milliarden
> Lesefehler hatte, dann hätte das doch längst auffallen müssen.

Das ist ein RAW Wert - wenn Du nicht weißt wie der Hersteller die 
Information codiert hat, kannst Du damit nichts anfangen. Das kann z.B. 
ein 32bit Wort sein, in dessen ersten 8 Bits irgendeine Zusatzinfo 
steckt. Dann bekommst Du große Zahlen und einen Schrecken.
Was zählt sind aber die "normalisierten" Werte (Spalte VALUE). Die 
fangen bei 100 an (manchmal auch bei 200) und werden bei 
Fehlerereignissen runtergezählt bis sie unter dem Threshold landen - 
spätestens dann wird's kritisch.

Ich sehe bei Deiner Platte kein Problem. Aber wenn Du willst, kannst Du 
ja mal einen extended self-test machen.

Hallo Np R.,

Np R. schrieb:
> Was zählt sind aber die "normalisierten" Werte (Spalte VALUE). Die
> fangen bei 100 an (manchmal auch bei 200) und werden bei
> Fehlerereignissen runtergezählt bis sie unter dem Threshold landen -
> spätestens dann wird's kritisch.

das bestreite ich! :)

Peter M. schrieb:
> das bestreite ich! :)
Was genau möchtest Du wie korrigieren?
- dass die normalisierten Werte bei 100, 200 oder manchmal auch bei 253 
anfangen?
- dass sie in der Regel runtergezählt werden?
- dass sich der Threshold auf die normalisierten Werte bezieht?
- dass der Threshold in aller Regel /unter/schritten werden muss (eben 
weil der normalisierte Wert bei Fehlern sinkt, nicht steigt)?

Np R. schrieb:
> Peter M. schrieb:
>> das bestreite ich! :)
> Was genau möchtest Du wie korrigieren?
> - dass die normalisierten Werte bei 100, 200 oder manchmal auch bei 253
> anfangen?
> - dass sie in der Regel runtergezählt werden?
> - dass sich der Threshold auf die normalisierten Werte bezieht?
> - dass der Threshold in aller Regel /unter/schritten werden muss (eben
> weil der normalisierte Wert bei Fehlern sinkt, nicht steigt)?

Ich schaue mir die normalisierten Werte gar nicht an - nur die Rohwerte, 
und die nur für ausgewählte Parameter und die anderen nur, wenn Sie 
auffällig erscheinen.

Peter M. schrieb:
> Ich schaue mir die normalisierten Werte gar nicht an - nur die Rohwerte,

Das kann gut gehen - oder auch nicht. Manchmal kann man die Rohwerte 
direkt lesen, bei einigen Werten/Herstellern immer. Aber manchmal eben 
nicht.
Bei Stefans Platte sind es garantiert keine 500.000 Timeouts und 8 
Milliarden Lesefehler. Da ist in den Datenfeldern an der entsprechenden 
Adresse noch etwas anders mit verwurstet. Sonst wäre der normalisierte 
Wert nicht bei 100.
Wenn man etwas sucht, kann man vielleicht herausfinden, wie Hitachi die 
Rohdaten zu ID 187 formatiert/kodiert und was da noch drinsteckt.
Dazu war ich jetzt zu faul. ;-)

Das mit dem langsamen Anlaufen der Platte könnte passen: ich habe auch 
einige HGST-Travelstar verbaut und da kommt es immer wieder mal vor, 
dass der Rechner beim booten hängt und erst nach drücken des Reset 
Knopfes sauber startet.

Kommt allerdings auch manchmal bei einer SSD (Crucial MX500) vor, da 
kann ich mir das weniger erklären. Netzteil habe ich mal überprüft, die 
Spannungen sind ok und haben auch keinen Dip beim hochfahren.

Peter M. schrieb:
> Ich schaue mir die normalisierten Werte gar nicht an - nur die Rohwerte,
> und die nur für ausgewählte Parameter und die anderen nur, wenn Sie
> auffällig erscheinen.

Im Prinzip mache ich das auch so. Das Problem bei SMART ist allerdings, 
dass eben jeder Hersteller da machen kann, was er will und der Rohwert 
deshalb mit Vorsicht zu genießen ist.
Diese "normalisierten" Werte sollen wohl angeben, wieviel im Bezug auf 
diesen Wert noch von der Lebensdauer der Festplatte übrig ist. Das ist 
nicht bei jedem der SMART-Werte wirklich sinnvoll.

Ich hatte vor einiger Zeit ein ähnliches Problem:

Mein Laptop hat eine SSD (sda, mit Boot- und Root-Partition) und eine
HDD (sdb, mit Var-, Swap- und Home-Partition). Irgendwann bootete der
Rechner nicht mehr und zeigte irgendwelche Mount-Probleme an. Nach einem
Reboot funktionierte wieder alles, aber alle paar Tage wiederholte sich
dieses Spiel aufs Neue.

Ich dachte zuerst an einen Hardwarefehler. Als ich die Sache aber näher
untersuchte, stellte ich fest, dass im Fehlerfall die Devicenamen der
beiden Disks (sda und sdb) vertauscht waren, so dass beim Mounten der
Root-Partition statt auf die SSD auf die HDD zugegriffen wurde, wo an
der entsprechenden Partitionsnummer die Swap-Partition liegt.

Ich weiß nicht genau, wie im Kernel die Namensgebung der sd*-Devices
erfolgt. Möglicherweise hängt (oder hing) sie davon ab, welche der
beiden Disks zuerst hochläuft. Das würde zumindest erklären, dass nach
einem Reboot (ohne Ausschalten des Rechners) die Namen meist wieder
richtig waren.

Schließlich ersetzte ich in der Boot-Konfiguration und in /etc/fstab die
sd*-Namen durch die eindeutigeren UUIDs. Seither trat das Problem nicht
wieder auf.

Yalu X. schrieb:
>
> Schließlich ersetzte ich in der Boot-Konfiguration und in /etc/fstab die
> sd*-Namen durch die eindeutigeren UUIDs. Seither trat das Problem nicht
> wieder auf.

Dass die Device-Namen auch mal wechseln können ist ja eigentlich ein 
alter Hut, davor wird man überall gewarnt.

Darf ich fragen welches System du benutzt? Hast du die fstab selber von 
der Pike auf geschrieben?
Alle aktuellen Installer tragen da eigentlich direkt die UUID ein.
Auch "genfstab" aus dem Arch-Umfeld macht das.

Le X. schrieb:
> Dass die Device-Namen auch mal wechseln können ist ja eigentlich ein
> alter Hut, davor wird man überall gewarnt.

Ich hatte bisher nie Probleme damit, deswegen war ich mir dessen nicht
bewusst.

> Darf ich fragen welches System du benutzt?

Arch-Linux, aber es ist schon eine ältere Installation.

> Hast du die fstab selber von der Pike auf geschrieben?

Ich habe den Installer benutzt, der mir m.W. auch die Standardeinträge
in fstab generiert hat. Aber wie gesagt, das ist schon eine ganze Weile
her.

Yalu X. schrieb:
> Ich hatte bisher nie Probleme damit, deswegen war ich mir dessen nicht
> bewusst.

Ich auch nicht, bin aber schon mehrmals über die Warnung gestolpert, 
möglichst keine device-Namen zu verwenden ;-)

Yalu X. schrieb:
> Ich habe den Installer benutzt, der mir m.W. auch die Standardeinträge
> in fstab generiert hat. Aber wie gesagt, das ist schon eine ganze Weile
> her.

OK dann wurde das zwischenzeitlich geändert, genfstab trägt aktuell die 
UUID in die fstab ein.