Manjaro verweigert den Shutdown wegen eines externen Laufwerks

Ich habe in Manjaro ein bash Skript zur Sicherung ausgewählter Daten auf ein externes Laufwerk geschrieben. Dabei nutze ich das duplicity-Kommando. Das Skript nutze ich bereits seit mehreren Jahren.

Die zu sichernden Daten werden auf eine externe Festplatte „drive-n-go“ gespeichert, ursprünglich mit einer NTFS Partition ausgestattet. Im Laufe der Zeit hat Manjaro immer wieder Fehler mit NTFS gemeldet, die ich nur mit dem Windows Chdsk Kommando beheben konnte, d.h. des öfteren konnte ich in Manjaro das „drive-n-go“ Laufwerk nicht öffnen, deshalb musste ich vor meiner Datensicherung meinen PC mit Windows booten, dort mit chkdsk die NTFS Partition reparieren, wieder Manjaro booten, erst dann konnte mein Skript funktionieren.

Um dieses Prozedere künftig zu vermeiden, habe ich vorige Woche mit GPARTED die NTFS Partition auf „drive-n-go“ gelöscht, eine neue GPT Partitionstabelle und eine ext4 Partition erzeugt, die gleiche Ordnerstruktur wie vorher errichtet. Mein Skript habe ich mit einer kleineren Datenauswahl mehrmals getestet, auch das Einhängen und Aushängen von „drive-n-go“ sowie Shutdown und Reboot meines Manjaro Systems.

Gestern sind mehrere Fehler aufgetreten:
(1) Im Dateimanager THUNAR konnte ich „drive-n-go“ weder einhängen noch aushängen.
(2) GPARTED konnte das „drive-n-go“ Laufwerk nicht zeigen.
(3) Manjaro verweigerte den Shutdown. Auch „systemctl shutdown -i“ führte nicht zum shutdown. Ich konnte nur den PC mit dem Netzschalter abwürgen.

Auf dem PC habe ich noch ein Ubuntu Linux installiert. In Ubuntu konnte ich „drive-n-go“ einhängen, aushängen, konnte mit GPARTED die dortige ext4 Partition sehen.
Nach reboot von Manjaro konnte ich „drive-n-go“ nicht einhängen. Angeblich stand noch eine Operation aus. Das war offenbar der Grund, warum Manjaro vorher nicht hinunter fahren wollte.

Heute erscheinen die gestrigen Probleme wie weggeblasen!

Fazit: Nur Manjaro hatte ein Problem mit „drive-n-go“, und das nur gestern!

Aber welches? Die Probleme, die man nicht zuverlässig reproduzieren kann, sind besonders schwierig zu erkennen!

Wie kann ich sicherstellen, dass die Probleme ein für allemal verschwunden sind?

Das kann schnell mal zu Problemen mit dem Dateisystem führen. Im schlimmsten Fall bis hin zum Totalverlust

Es gibt nur wenige Dateisysteme die das einfach wegstecken können. Ich kenne davon nur jffs2 und btrfs
:footprints:

Gently shut down a frozen PC

to minimize the risk of file system corruption and data loss:

https://wiki.archlinux.org/title/keyboard_shortcuts#Kernel_(SysRq)
https://docs.kernel.org/admin-guide/sysrq.html

Wird höchstwahrscheinlich am lazyinit liegen, wo Inode-Tabellen im Hintergrund geschriebenwerden beim ersten Einhängen. Dieser Prozess kann zu den genannten Problemen führen, gerade bei USB-Verbindungen:

Man hätte den Prozess einfach durchlaufen lassen sollen, bzw. länger eingehängt lassen sollen.

Nebenbei: Insallier dir udev-usb-sync für USB-Verbindungen. Dann musst du nicht so lange warten auf Hintergrundkopiervorgänge.

4 Likes

Zum Glück ist ext4 ein Journalling File-System, da geht normaler Weise nur verloren, was zum Zeitpunkt des Ausschaltens noch geschrieben wurde, ansonsten repariert sich das in der Regel “von alleine”.

Ich würde im beschriebenen Fall, wenn man partout nicht warten will, die laufenden Prozesse sichten und dann nach gründlicher Analyse alles abschießen, was das Runterfahren stört.

Ich habe REISUB in grub.cfg eingebaut und es funktioniert; die SysRq Tastenkombination auf Lenovo thinkpad ist Fn+Alt+Druck.
Auch udev-usb-sync habe ich - mithilfe von chatgpt - installiert. scheint zu funktionieren.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.