Festplatte scannen und 'reparieren'

[Isegrimm666]

Hallo zusammen ...

Ich fahre Siduction auf einem Dual-Boot-System mit 'Win10'. Es kommt manchmal vor, dass eine eingesteckte SSD nicht korrekt unmounted werden kann, weil entweder der 'kioworker' oder 'glycin' sie nicht los lässt. Das Beenden der Prozesse via tty lässt ein unmount dann wieder zu.

Es kann aber auch vorkommen, das sich die Platte beim nächsten mount dagegen sperrt: 'Gerät kann nicht eingehängt werden'.

Meine bisherige Lösung war dann immer, das System herunterzufahren, den Windowszweig zu booten und die dortige Fehlermeldung mit 'Laufwerk scannen und reparieren' wieder gangbar zu machen.

Danach mountet sie sich wieder ordnungsgemäß.

Aber das muss doch auch in Linux möglich sein, oder?

Hat jemand von Euch eine Idee, wie man das bewerkstelligen kann ... entweder via Konsolenbefehl oder Tool?

[edlin]

Aber das muss doch auch in Linux möglich sein, oder?

Kurze Antwort: Ja!

Frage: Willst du wissen, wie man ein Dateisystem unter Linux überprüft und repariert (zum Beispiel mit fsck) oder wie du ohne rohe Gewalt das Laufwerk aushängen kannst?

Ich denke, dass es sinnvoll ist zu klären, warum sich glycin/kioworker sträuben, das Dateisystem für ein umount freizugeben. Es kann ja nicht der Weg sein, dass du mit einem kill das Laufwerk mit offenen Dateien etc. den Anwendungen entreißt und danach den Schaden wieder reparierst (egal, ob mit Win oder Linux). Also vorher mit lsof/fuser klären welche Dateien noch offen sind und welcher Prozess darauf zugreift.

edlin

[der_bud]

Wenn ein Windows-Scan reicht, reicht vielleiht auch ein Linux-Fsck:
- Du könntest beim booten mit ESC im Grub anhalten, mit 'e' den Meüauswahl editieren und in der Kernel-Cmdline ein 'fsck.mode=force' anhängen. Bin mir nur nicht sicher, ob das alle oder nur das Rootfilesystem checkt.
- Alternativ per /etc/fstab in der Zeile für das Filesystem das letzte Feld von (vermutlich) 0 (=Null) auf 2 umstellen, sollte eigentlich auch ein fsck auslösen.

[Edit: aber zuerst edlins Vorschlag abarbeiten ]

[Isegrimm666]

Guten Morgen:

@edlin: Das ist der Plan ... Ursachenforschung.

Ich schildere das mal etwas detaillierter:

An meinem TV hängt ein Raspi mit Libre-Elec. Am PI selbst hängen 3 HDDs über einen aktiven USB-Hub.

In der Verbindung vom Raspi zum Hub ist ein USB-B Y-Schalter angebracht. Der zweite Zweig des Y-Schalters geht zum Siduction-Notebook.

Soweit die Hardware.

Usage:

Auf dem Notebook werden die Dateien (Audio/Video) für den Raspi erzeugt. Danach wird - natürlich bei ausgeschaltetem Raspi - der Schalter betätigt, damit die Platten am Notebook gemountet und nach erfolgtem Mounting die Dateien kopiert.

Nach erfolgtem Kopiervorgang werden die Platten wieder unmountet und danach - durch Betätigen des Schalters - wieder auf den Raspi gelegt.

Klappt auch.

Dateipflege:

Die eine Platte ist für die neuen Sachen, die anderen beiden für die Archivierung. Sind die Platten am Notebook gemountet, nutze ich das manchmal, um Dateien von der einen Platte auf eine andere zu schieben ... die aber beide am gleichen Zweig (USB-Port des Notebooks) hängen.

DABEI kommt es manchmal zu den genannten Problemen.

[ro_sid]

Zunächst nur ein bißchen besserwisserisch - bitte um Entschuldigung:

[...]
- Alternativ per /etc/fstab in der Zeile für das Filesystem das letzte Feld von (vermutlich) 0 (=Null) auf 2 umstellen, sollte eigentlich auch ein fsck auslösen.

aber die '2' legt nur fest, in welcher Reihenfolge ein Dateisystem-Check erfolgen soll (0 ist (richtig) keiner, 1 für root ('/') und wichtige(re) vorbehalten, etwa wenn 'auf ihnen gemounted' werden soll), aber nicht ob überhaupt oder wann dieser erfolgen soll. Bei alten 'ext3'ern war so eine Standardregel "alle 180 mounts" und "alle sechs Monate". Die '2' schließt nur aus, dieses Dateisystem vom "Check" auszuschließen und 'zu früh' zu machen🙂. Auch höhere "Nummern" sind möglich (eben wegen der Reihenfolge).

Nun hoffentlich etwas hilfreicher: Ich habe/hatte auch solche Erlebnisse mit NTFS-Systemen, da bei mir das ganze Siduction-Live-System 'darauf' auf einem externen Datenträger liegt und ich öfter auch NTFS-Volumes damit "mounte". Meine Tipps für so einen Fall dazu:

• Wenn man es rechtzeitig bemerkt oder Probleme vermutet, auf jeden Fall vorher noch einen 'sync'-Befehl in einer Kommandozeile absetzen. Hilft sehr oft.
• "Von Hand" ein 'umount' (als root) versuchen. Selbst wenn es nicht funktioniert, bekommt man eventuell einen Hinweis, worin das Problem besteht.
• Ein 'fsck' hilft nicht, solange das Dateisystem als "gemounted" gilt.
• Falls nicht mehr gemounted, hilft ein 'fsck' eines NTFS-Dateisystems aus einem Linux manchmal; bei mir nur sehr selten. Dieses Kommando ist einfach noch zu unfertig und unvollkommen. Ganz selten hat es die Situation sogar noch verschlimmert.
• Letztlich bleibt nur noch das Bereinigen durch ein MS-Windows. Das kann man natürlich mit 'seinem' Windows tun. Da ich aber seit Jahren (fast keines) mehr in Lizenz benutze, verwende ich dann die HBCD-ISO (https://www.hirensbootcd.org/). Ein wenig veraltet, aber hat bei mir bei der Reparatur - etwa per Ventoy gestartet - noch nie versagt.

Die häufigste Ursache bei mir war stets eine 'kurzzeitige' Unterbrechung der USB-Verbindung zum Datenträger. Das könnte hier am Hub oder vielleicht noch eher an dem "Y-Schalter" liegen.

[edlin]

Abhängig vom Fehler kann ntfsfix aus dem Paket ntfs-3g unter Linux helfen, zum Beispiel beim Rücksetzen des dirty flag.
Es ist allerdings kein vollständiger Ersatz für chkdsk.
Mit

Code Select Expand

doas ntfsfix -b -d -n /dev/sdc3 wird nur angezeigt, was gemacht würde.
Beispiel (intakte Partition):

Code Select Expand

doas ntfsfix -b -d -n /dev/sdc3
Mounting volume... OK
Processing of $MFT and $MFTMirr completed successfully.
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
NTFS partition /dev/sdc3 was processed successfully.Ohne den Schalter -n wird dann echt gewerkelt.

Wenn das nicht hilft, dann bleibt wohl nur Windows letzte Rache ...

edlin