SSD mounted nicht immer

[RalfK72]

Hallo,
eine 4TB Samsung SSD (ext4), die zusätzlich zum Boot-Laufwerk im Debian 11 System angeschlossen ist, wird beim Booten manchmal nicht eingehängt. Meistens funktioniert es einwandfrei, aber vielleicht 1 von 10 Starts ist sie nicht eingehängt. Sie lässt sich dann nicht manuell einhängen, wird aber per lsblk als Laufwerk angezeigt (sda), nicht aber mit der Partition (sda1) und somit eben ohne Mountpoint. Nach einem Neustart ist sie in der Regel wieder eingehängt.

Das Problem scheint auch eher selten bis gar nicht bei Reboots aufzutreten, am häufigsten nach längerem System-Aus. Wenn man nun aber denkt, es könnte ein Hardware-Problem sein… Das habe ich bei zwei Systemen mit gleichem Board (ein NUC11) und gleicher SSD. Einzelfehler also eher unwahrscheinlich.

Hat jemand eine Idee, was hier helfen könnte?

Grüße, Ralf

[Blackbox]

Willkommen!

wird beim Booten manchmal nicht eingehängt.

Den Grund findest du mit Sicherheit im Journal.

Sie lässt sich dann nicht manuell einhängen, wird aber per lsblk als Laufwerk angezeigt (sda), nicht aber mit der Partition (sda1) und somit eben ohne Mountpoint.

Einen Verschleiß, oder Defekt kannst du ausschließen?
Wie ist die SSD angebunden?
Wie alt ist die SSD?

Nach einem Neustart ist sie in der Regel wieder eingehängt.

Schau ins Journal!
Alles andere endet hier nur in Spekulation.
Die relevanten Informationen dann bitte hier im Forum posten, damit können wir etwas anfangen.

[kalle123]

Hi, was mir dazu auf die Schnelle einfällt.

Unter WIN mal die SSD mit SSD-Tool Samsung Magician prüfen, ev. Firmwareupdate ...

Unter Debian mal z.B. mit GSmartControl checken

Was sagen den die journalctl Einträge?

Gruß KH

Seh gerade, Blackbox war schneller, aber ich lass meinen post einfach mal so stehen ...

[RalfK72]

Danke Euch für die schnellen Antworten! Um die Tipps von Kalle 123 kümmere ich mich gleich.
Journal habe ich angeschaut. Kann aber jetzt nur schätzen, welcher der vergangenen Bootvorgänge fehlerhaft war. Hunderprozentig sicher kann ich also nur sein, wenn der Fehler nochmal auftritt. Dann schaue ich direkt ins Journal. Ich denke das könnte aber passen:

Code: Alles auswählen

_ systemd-fsck[309]: fsck.ext4: Bad magic number in super-block while trying to open /dev/sda1
_ systemd-fsck[309]: /dev/sda1:
_ systemd-fsck[309]: The superblock could not be read or does not describe a valid ext2/ext3/ext4
_ systemd-fsck[309]: filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
_ systemd-fsck[309]: filesystem (and not swap or ufs or something else), then the superblock
_ systemd-fsck[309]: is corrupt, and you might try running e2fsck with an alternate superblock:
_ systemd-fsck[309]:     e2fsck -b 8193 <device>
_ systemd-fsck[309]:  or
_ systemd-fsck[309]:     e2fsck -b 32768 <device>
_ systemd-fsck[309]: /dev/sda1 contains a vfat file system
_ systemd-fsck[307]: fsck failed with exit status 8.
_ systemd-fsck[307]: Ignoring error.

Vielleicht wirklich, wie Kalle123 sagt, ein Firmware-Update… Denn wie gesagt, gleiches Fehlerbild auf zwei Systemen mit fast identischer Hardware (nur Bootlaufwerk unterschiedlich). Deshalb ein Defekt eher unwahrscheinlich. Sind aber beides Samsung 870 QVO und von daher könnte es denke ich ein grundsätzliches Hardwareproblem mit der Samsung sein.

[hikaru]

Angenommen, der journalctl-Auszug passt zu deinem Problem, dann widerspricht er deiner Aussage aus dem Eingangsbeitrag:

Meistens funktioniert es einwandfrei, aber vielleicht 1 von 10 Starts ist sie nicht eingehängt. Sie lässt sich dann nicht manuell einhängen, wird aber per lsblk als Laufwerk angezeigt (sda), nicht aber mit der Partition (sda1) und somit eben ohne Mountpoint.

(Hervorhebung von mir.)
Die Partition (/dev/sda1) wird also durchaus erkannt, aber das darauf befindliche Dateisystem nicht. Das ändert die Symptomatik von "mysteriös" zu "ärgerlich aber verstehbar".

Bitte zeige deine fstab und verrate uns, ob außer dem auf dem NUC installierten Debian noch andere Systeme (versuchen) Dateisysteme auf der SSD (zu) nutzen!

Schuss ins Blaue:
Diese Minirechner haben teils Probleme mit der Kühlung. Wird die SSD vielleicht manchmal zu heiß und produziert dann Schreibfehler, die das Dateisystem beschädigen.

[RalfK72]

Ich lese die Fehlermeldung wie folgt: Es wird versucht /dev/sda1 zu mounten. Das wird nicht versucht, weil sie gefunden wird, sondern weil das ja so in der fstab steht. Das gelingt aber eben nicht, es ist von superblock Fehlern die Rede und vfat, was völliger Unsinn ist, da defintiv ext4.

Das riecht m.E. nach Hardware. Aber zwei fehlerhafte SSDs… dann müsste es ein Serienfehler sein. Wie gesagt, der Fehler ist bei zwei verschiedenen Systemen mit SSDs gleichen Typs aufgetreten. Zu heiß wird die Platte nicht und außerdem hatte ich den Fehler bisher öfter beim ersten Einschalten morgens als bei einem Reboot über Tag. Und ich hatte das meine ich auch schon mal mit einem auf Archlinux basierten System; nur viel seltener. Also irgendein Debian-Ding auch eher unwahrscheinlich.

Ich mache gerade ein Backup der Platte. Das dauert aber bei 3TB etwas. Danach versuche ich ein Firmware-Update. Die Idee von Kalle123 erscheint mir hilfreich. Es gibt von Samsung auch ein ISO-Image, wodurch die Sache ohne Ausbau der Platte gehen sollte. Das hilft dann aber natürlich nur, wenn Samsung den Fehler bereits kennt und korrigiert hat.
Eben kam mir dann noch die Idee, in die fstab vielleicht besser die UUID zu schreiben. Könnte das zuverlässiger sein als /dev/sda1?
Auch sehe ich gerade, dass die Einträge für dump und pass fehlen. Aber soll das ein temporäres Problem verursachen...
fstab sieht so aus:

Code: Alles auswählen

UUID=facb0437-3765-4541-a391-21de3782e1b3 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sdb1 during installation
UUID=867E-A569  /boot/efi       vfat    umask=0077      0       1
# swap was on /dev/sdb3 during installation
UUID=db5909d8-de0a-4cda-9d3f-a49ebfcdf9dc none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0
/dev/sdb4       /home/Ralf/Music   ext4    nofail
/dev/sda1       /home/Ralf/Music4TB        ext4    auto,nofail

[hikaru]

Ich lese die Fehlermeldung wie folgt: Es wird versucht /dev/sda1 zu mounten. Das wird nicht versucht, weil sie gefunden wird, sondern weil das ja so in der fstab steht. Das gelingt aber eben nicht, es ist von superblock Fehlern die Rede und vfat, was völliger Unsinn ist, da defintiv ext4.

Da wäre nun angesichts deiner fstab mit Gerätenamen interessant, welches Dateisystem /dev/sdb1 hat.

Eben kam mir dann noch die Idee, in die fstab vielleicht besser die UUID zu schreiben. Könnte das zuverlässiger sein als /dev/sda1?

Auf jeden Fall! Die Reihenfolge der Gerätenamen (sda bzw. sdb) kann sich je nach Mondphase bei jedem Booten ändern.

Auch sehe ich gerade, dass die Einträge für dump und pass fehlen. Aber soll das ein temporäres Problem verursachen...

Die Felder sind eigentlich optional und es sollte daher kein Problem sein, sie wegzulassen. Ich habe es in freier Wildbahn aber noch nie gesehen, dass sie fehlen.


P.S.:
Kraft meiner Modsuppe habe ich mal code-Tags in deine Beiträge eingefügt. Mach das doch bitte in Zukunft selbstständig! Das kann die Lesbarkeit enorm erhöhen - zumindest wenn die Inhalte vorher sinnvoll formatiert sind (fstab?).

[RalfK72]

Mal ein Update:
Ich hätte schon fast eine Entwarnung gepostet. Nach Umstellung in der fstab von /dev/sda1 auf die UUID schien die Sache sehr zuverlässig zu funktionieren. Lief seit Montag bei vielen Bootvorgängen und auch täglichen Kaltstarts einwandfrei. So lange keine Auffälligkeiten, das hatte ich noch nie. Von daher sah die Idee mit der UUID zielführend aus.
Aber heute war´s dann doch wieder so weit. Wieder beim allerersten Start morgens. Das riecht denke ich nach Serienfehler, entweder bei der SSD oder dem Controller. Es passiert zwar nicht nur kalt, aber es ist eine Häufung erkennbar.

[Blackbox]

Aber heute war´s dann doch wieder so weit. Wieder beim allerersten Start morgens.

Wie wäre es dann endlich einmal mit den angeforderten Informationen zu deinem System?

Das riecht denke ich nach Serienfehler, entweder bei der SSD oder dem Controller. Es passiert zwar nicht nur kalt, aber es ist eine Häufung erkennbar.

Auch zu diesem Punkt gab es bereits Lösungsvorschläge.
Könntest du bitte so freundlich sein und nicht nur deine Vermutungen aufschreiben, sondern die Informationen, die wirklich benötigt werden.

[RalfK72]

Wie wäre es dann endlich einmal mit den angeforderten Informationen zu deinem System?

Es wurde nach Journal gefragt; oben geliefert.
Es wurde nach der fstab gefragt; oben geliefert.
(abgesehen davon, dass hikaru so freundlich war, die Formatierung zu ergänzen. Danke für den Hinweis!)
Sorry, ich sehe gerade nicht, nach welchen Infos noch gefragt worden sein soll.

Das riecht denke ich nach Serienfehler, entweder bei der SSD oder dem Controller. Es passiert zwar nicht nur kalt, aber es ist eine Häufung erkennbar.

Auch zu diesem Punkt gab es bereits Lösungsvorschläge.

Hmm... welche denn?

[Tintom]

Es wurde nach Journal gefragt; oben geliefert.
Es wurde nach der fstab gefragt; oben geliefert.

Durch deine Veränderung der fstab ist jetzt eine neue Situation eingetreten. Vorher wurde ein falsches Gerät mit den falschen Mountoptionen gemountet, das ging schief. Jetzt hast du den Bezeichner, ergo die fstab geändert. Folglich passt auch das Journal nicht mehr dazu. Daher wäre jetzt die Ausgabe von der geänderten fstab, ein aktuelles Journal und der Vollständigkeit halber noch die Ausgabe von blkid hilfreich.

[RalfK72]

Danke Tintom! Damit kann ich was anfangen.
Nur leider war wie gesagt erst lange kein Fehler. Bei dem einen Mal, als er dann auftrat, konnte ich mich aber nicht auf weitere Spurensuche machen und momentan habe ich den Rechner nicht im Zugriff. Die Sache muss dann warten.

[GregorS]

Ich habe die Diskussion nur zum Teil gelesen und den Rest überflogen. Eine SSD mit ähnlich seltsamem Verhalten habe ich gerade erst wieder ausgebaut und zur Seite gelegt. Ich tippe auf Inkompatibilität als Fehlerursache.
Sind Motherboard(s) und SSD(s) einigermaßen gleich alt? Bei mir liegen sicher mehr als 5 Jahre dazwischen. Da in den nächsten paar Monaten aber eh ein Rechner-Neukauf ansteht, schrumpft der Abstand deutlich, was Hoffnung macht.

Gruß

Gregor

[mat6937]

Die Sache muss dann warten.

BTW: Die Frage von hikaru:

... und verrate uns, ob außer dem auf dem NUC installierten Debian noch andere Systeme (versuchen) Dateisysteme auf der SSD (zu) nutzen!

hast Du auch noch nicht beantwortet.

[RalfK72]

BTW: Die Frage von hikaru:

... und verrate uns, ob außer dem auf dem NUC installierten Debian noch andere Systeme (versuchen) Dateisysteme auf der SSD (zu) nutzen!

hast Du auch noch nicht beantwortet.

Ich sprach nur von Debian11. Wenn es etwas anderes geben würde, dann hätte ich davon gesprochen.
Ich habe nun aber wieder Zugriff auf die Maschine. Das Journal zeigt folgende Zeilen:

Code: Alles auswählen

Sep 16 05:29:48 nuc systemd[1]: dev-disk-by\x2duuid-e239aa9c\x2d5ec1\x2d4902\x2d99e3\x2d70577e1462cc.device: Job dev-disk-by\x2duuid-e239aa9c\x2d5ec1\x2d4902\x2d99e3\x2d70577e1462cc.device/start timed out.
Sep 16 05:29:48 nuc systemd[1]: Timed out waiting for device /dev/disk/by-uuid/e239aa9c-5ec1-4902-99e3-70577e1462cc.
Sep 16 05:29:48 nuc systemd[1]: Dependency failed for File System Check on /dev/disk/by-uuid/e239aa9c-5ec1-4902-99e3-70577e1462cc.
Sep 16 05:29:48 nuc systemd[1]: Dependency failed for /home/ralf/Music4TB.
Sep 16 05:29:48 nuc systemd[1]: home-ralf-Music4TB.mount: Job home-ralf-Music4TB.mount/start failed with result 'dependency'.
Sep 16 05:29:48 nuc systemd[1]: systemd-fsck@dev-disk-by\x2duuid-e239aa9c\x2d5ec1\x2d4902\x2d99e3\x2d70577e1462cc.service: Job systemd-fsck@dev-disk-by\x2duuid-e239aa9c\x2d5ec1\x2d4902\x2d99e3\x2d70577e1462c>
Sep 16 05:29:48 nuc systemd[1]: dev-disk-by\x2duuid-e239aa9c\x2d5ec1\x2d4902\x2d99e3\x2d70577e1462cc.device: Job dev-disk-by\x2duuid-e239aa9c\x2d5ec1\x2d4902\x2d99e3\x2d70577e1462cc.device/start failed with >

Sonst nichts, das zum Problem passen könnte. Danach gibt es auch inzwischen wieder sieben Bootvorgänge ohne diesen Fehler.

Aktuelle FSTAB ist:

Code: Alles auswählen

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sdb2 during installation
UUID=facb0437-3765-4541-a391-21de3782e1b3 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sdb1 during installation
UUID=867E-A569  /boot/efi       vfat    umask=0077      0       1
# swap was on /dev/sdb3 during installation
UUID=db5909d8-de0a-4cda-9d3f-a49ebfcdf9dc none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0
UUID=3b371ddf-e699-4abe-82fa-9672401cf958       /home/ralf/Music   ext4    nofail  0       2
UUID=e239aa9c-5ec1-4902-99e3-70577e1462cc       /home/ralf/Music4TB        ext4    auto,nofail     0       2

[Tintom]

Mal so 'ne dumme Frage: Ist das eine externe Platte?

//edit: Ich sehe gerade, in die Richtung hatte @Blackbox schon gefragt. Habe ich die Antwort überlesen oder gab's noch keine?

[RalfK72]

Ist eine interne SSD per SATA

[Tintom]

Hast du mal ein anderes SATA-Kabel probiert?
Zur Fehlermeldung: Die wird verursacht durch die „2“ in deiner fstab, das System möchte die SSD auf Fehler untersuchen, kann aber keine Platte finden. Im Zusammenhang mit der Option nofail werden da vielleicht einige zielführende Fehlermeldungen unterdrückt. Ersetze das nofail mal durch defaults, vielleicht gibt das noch ein paar mehr Hinweise. Aber sofern die SSD in Ordnung ist würde ich bei solchen sporadischen Aussetzern eher das Kabel im Verdacht haben.

[RalfK72]

Danke Tintom. Ohne nofail bootet die Maschine halt im Falle des Falles gar nicht und das System soll eigentlich "headless", also ohne Monitor und Tastatur genutzt werden. Deshalb hatte ich das geändert. Aber testweise könnte ich das machen. Nur so selten der Fehler kommt... und es ist ja deutlich besser geworden, seit ich mit UUIDs arbeite. Soll das zum Kabel passen... auch hatte ich das Problem ja bei zwei baugleichen Rechnern.

[Tintom]

Danke Tintom. Ohne nofail bootet die Maschine halt im Falle des Falles gar nicht und das System soll eigentlich "headless", also ohne Monitor und Tastatur genutzt werden. Deshalb hatte ich das geändert. Aber testweise könnte ich das machen. Nur so selten der Fehler kommt... und es ist ja deutlich besser geworden, seit ich mit UUIDs arbeite. Soll das zum Kabel passen... auch hatte ich das Problem ja bei zwei baugleichen Rechnern.

Angenommen es liegen keine Probleme mit Kabel o.ä. vor, kannst du das Dateisystem manuell einbinden, wenn es nicht automatisch erkannt wird?