Ich habe ein externes LW (230GB) mit einer GPT Partitionstabelle und einer einzigen ext4 Partition. Auf diesem LW sichere ich ausgewählte Daten von meinem PC. Zur Sicherung ausgewählter Daten auf das LW benutze ich ein bash script; der entscheidende Befehl in diesem script ist ein duplicity Kommando.
Bei der Ausführung des duplicity Kommandos friert mein Manjaro ein. Shutdown geht nur noch mit SysReq-r-e-i-s-u-o.
Auf einem Zweit-PC (ebenfalls mit Manjaro) konnte ich das Problem mit dem LW reproduzieren. Ich konnte das LW zunächst verbinden, eine Datei erzeugen und (scheinbar) speichern. Beim “Sicheren Entfernen” des LW heißt es aber: " Eine Operation steht noch aus". So ist es kein Wunder, dass auch bei dem Zweit-PC der shutdown nicht ausgeführt wird. Ich muss SysReq-r-e-i-s-u-o anwenden.
Neustart (egal auf welchem PC). Beim Versuch, das LW im Thunar Dateimanager zu verbinden, kreist die Sanduhr, d.h. keine Verbindung. In diesem Zustand lässt sich das LW weder “Aushängen” noch “Sicher entfernen”. Und der PC verweigert den Shutdown - siehe oben.
Nach dem Neustart von Manjaro versuche ich, das LW mit GPARTED zu untersuchen. Es erscheint ein Fehler; ich sage “wiederholen”, danach wird mir das LW mit seiner Partiton angezeigt (siehe unten).
Ich versuche “Dateisystem auf /dev/sda1 überprüfen und reparieren”. Der Versuch endet mit Fehler (siehe unten).
Der Versuch, das LW platt zu machen, d.h. neue GPT und neue ext4 Partition zu estellen, endet ebenso mit Fehler.
Jetzt bin ich ratlos. Welche Info sollte ich noch posten?
Laufwerk: /dev/sda
Modell: ST925082 7AS
Seriennummer: 5RG63XJV
Sektorgröße: 512
Sektoren insgesamt: 488397168
Köpfe: 255
Sektoren/Spuren: 2
Zylinder: 957641
Partitionstabelle: gpt
# Partition Typ Anfang Ende Markierungen Partitionsname Dateisystem Bezeichnung Einhängepunkt
/dev/sda1 Primär 2048 488396799 ext4-232G-Datsich ext4 ext4-232G-Datsic
Dateisystem (ext4) auf /dev/sda1 überprüfen und reparieren 00:01:42 ( FEHLER )
/dev/sda1 kalibrieren 00:01:42 ( FEHLER )
# libparted-Benachrichtigungen ( FEHLER )
Was ist denn der Fehler, wenn Du z.B. das Dateisystem auf Fehler überprüfst? sudo e2fsck -v /dev/sda1
Ich würde das “plattmachen” so machen - und hab das auch schon öfter getan:
man kann dd nehmen und den Beginn der Platte überschreiben, so daß die Partitionstabelle usw. nicht mehr existent ist.
Ich bin faul und nehme cp
lsblk -f
um zu sehen, welchen Gerätenamen meine Platte hat - z.B. /dev/sda in Deinem Beispiel, ich nehme mal lieber /dev/sdf damit keine copy/paste Fehler passieren …
sudo cp /dev/urandom /dev/sdf
Das Kommando breche ich nach ein paar Sekunden mit STRG + C ab - ich will ja nicht die ganze Platte überschreiben.
Danach konnte ich immer problemlos von vorn anfangen (neue Partitionstabelle, neue Partitionen, Dateisystem erstellen)
Sowohl “prüfen und reparieren” als auch “platt machen” habe ich in GParted versucht. Dort gibt es “neue Partitionstabelle anlegen” und “Formatieren”. Wie gesagt, keine der Operationen wird ausgeführt.
sudo e2fsck -v /dev/sda1
e2fsck 1.47.3 (8-Jul-2025)
e2fsck: Eingabe-/Ausgabefehler beim Versuch, /dev/sda1 zu öffnen
Der Superblock ist unlesbar bzw. beschreibt kein gültiges ext2/ext3/ext4-
Dateisystem. Wenn das Gerät gültig ist und ein ext2/ext3/ext4-
Dateisystem (kein swap oder ufs usw.) enthält, dann ist der Superblock
beschädigt, und Sie könnten versuchen, e2fsck mit einem anderen Superblock
zu starten:
e2fsck -b 8193 <Gerät>
oder
e2fsck -b 32768 <Gerät>
$e2fsck -b 8193 /dev/sda1
e2fsck 1.47.3 (8-Jul-2025)
e2fsck: Ungültige magische Zahl im Superblock beim Versuch, /dev/sda1 zu öffnen
Der Superblock ist unlesbar bzw. beschreibt kein gültiges ext2/ext3/ext4-
Dateisystem. Wenn das Gerät gültig ist und ein ext2/ext3/ext4-
Dateisystem (kein swap oder ufs usw.) enthält, dann ist der Superblock
beschädigt, und Sie könnten versuchen, e2fsck mit einem anderen Superblock
zu starten:
e2fsck -b 8193 <Gerät>
oder
e2fsck -b 32768 <Gerät>
Mit 32768 kein brauchbarer output:
$e2fsck -b 32768 /dev/sda1
e2fsck 1.47.3 (8-Jul-2025)
e2fsck: Datei oder Verzeichnis nicht gefunden beim Versuch, /dev/sda1 zu öffnen
Ist das Gerät möglicherweise nicht vorhanden?
so wie ich beschrieben hab: sudo cp /dev/urandom /dev/sda
und nach ein - zwei Sekunden abbrechen mit STRG + C
geht in jedem Zustand und “zerstört” (im Sinne von: überschreiben") zuverlässig und sofort - sei Dir sehr sicher, daß Du den korrekten Gerätenamen hast!
Bei mir z.B. ist /dev/sda die einzige Platte - mein ganzes System
und /dev/sda1 ist meine /boot/efi Partition - das Dateisystem ist fat32 und ein check mit e2fsck wird immer fehlschlagen.
deshalb erwähnte ich: lsblk -f
…
Sicher nicht.
Ich weiß aber, was meine Methode tut und daß sie funktioniert.
und:
so wie ich das verstanden habe, hat gparted ja eben gerade nicht funktioniert für Dich …
… also nehm ich den Holzhammer
Danach würde ich auch gparted nehmen, um neue Partitionen usw. anzulegen.
… es sei denn die Platte ist kaputt - dann geht das mit keiner Methode …
sehr wahrscheinlich hast du den schreibvorgang abgewürgt und damit das dateisystem beschädigt. schreibvorgänge auf externe usb-platten werden im hintergrund ausgeführt. da muss man eben warten bis das laufwerk wieder freigegeben wird und die meldung kommt das man das laufwerk entfernen kann.
stecke das laufwerk mal ein und poste die ausgabe von
Ich hab jetzt den besagten Holzhammer sudo cp /dev/urandom /dev/sda ausprobiert, mit Gparted eine GPT und eine ext4 Partition erzeugt. Hab eine erste Datensicherung drauf geschrieben. Das LW habe ich im Dateimanager “sicher entfernt”, habe die Meldung gesehen, dass Daten aufs LW geschrieben wurden. Manjaro shutdown und reboot gehen wieder.
Ihr dürft mir glauben, dass ich vorher nicht aus Ungeduld etwas abgewürgt hatte! Liegt ein HW Fehler vor, muss er ja wieder auftraten.
Hoffentlich nicht.
Man könnte die “Gesundheit” der Platte prüfen mittels smartmontools smartctl oder der grafischen Oberfläche dafür - aber da sieht man auch nur Daten, die eine gewisse Wahrscheinlichkeit für Fehler nahelegen solange sie noch (jetzt wieder) tadellos funktioniert,
5 = Baujahr 2005 (oder „ab Werk freigegeben 2005“, aber tatsächlich wurden diese Chargen bis 2009/2010 verbaut)
R = interne Charge
G = Werk (meist Thailand oder China)
Die „250“ in der Modellnummer = 250 GB
Die „827AS“-Serie ist die Momentus 5400.4-Generation → offiziell released Mitte 2008 bis Anfang 2010. Das ist für eine rotierende 2,5″-HDD ein biblisches Alter - die meisten von denen sind schon lange tot.
