Partion durch Vergrößern geschrottet?

[McBain86]

Hallo,

eins vorweg, ich habe in Sachen Linux noch nicht allzu viel Erfahrung.
Vor einigen Tagen habe ich aufgrund der Nichtupgrade-Fähigkeit meines alten Windows-PCs die Windows-Partition platt gemacht und darauf Fedora 42 KDE installiert. Bin recht begeistert soweit.

Die SSDs wurden erfolgreich in ein anderes Dateisystem formatiert. Bei der HDD, die ich als Datengrab nutze, gab es Probleme mit den Rechten, daher wollte ich diese auf ext4 umformatieren.

Der Plan war mittels der Partitionsverwaltung die NTFS Partition um den freien Platz zu verkleinern, eine neue Partition in ext4 zu erstellen, Daten soweit wie Platz vorhanden rüber zu schieben, die NTFS weiter zu verkleinern, die ext4 weiter zu vergrößern und das Spiel so lange fortzusetzen bis alles verschoben wäre. Eine andere Möglichkeit ergab sich für mich nicht, da es sich um eine 4TB HDD handelt und ich nicht genug Backup-Platz habe.

Es hat funktioniert, die NTFS-Partition zu verkleinern, eine ext4-Partition zu erstellen, die ersten Daten zu verschieben und die NTFS-Partition weiter zu verkleiner. Nur beim Vergrößern der ext4-Partition /dev/sdc3 kam nach Stunden eine Fehlermeldung.

Sie wurde tatsächlich auf über 900 GB vergrößert wurde, aber ich habe in Dolphin keinen Zugriff mehr auf diese Partition und die Partitionsverwaltung erkennt den Typ nich mehr.

Ich habe das ganze gegoogelt und fsck sagt im Terminal:

fsck from util-linux 2.40.4
e2fsck 1.47.2 (1-Jan-2025)
ext2fs_open2: Ungültige magische Zahl im Superblock
fsck.ext2: Superblock ungültig, Datensicherungs-Blöcke werden versucht ...
fsck.ext2: Ungültige magische Zahl im Superblock beim Versuch, /dev/sdc3 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>

Ich habe mir mit sudo mke2fs -n /dev/sdc3 die Superblock-Sicherungskopien anzeigen lassen um e2fsck mit diesen Nummern zu starten.
Dann kam wieder die gleiche Fehlermeldung bezüglich magische Zahl und unlesbarer Superblock.

Was heißt das nun eigentlich? Hat die Platte einen physischen Schaden, sodass ich mir eine neue besorgen müsste? Hat jemand Ideen wie ich die Partition wieder hinkriege?

Schon mal vielen Dank für jede Unterstützung.

 

[rollmoped]

Also eigentlich würde ich jetzt zuerst eine Backup-Platte besorgen und dann bitweise alles so wie es jetzt ist, also den kaputten Zustand, 1:1 kopieren.

 

[Thorakon]

Bei der HDD, die ich als Datengrab nutze, gab es Probleme mit den Rechten, daher wollte ich diese auf ext4 umformatieren.

Magst du das evtl. noch etwas weiter ausführen? Kommt mir nämlich komisch vor, dass Linux Probleme mit den Rechten hat. Im Zweifel hat es meist erstmal deutlich mehr Rechte als das Windows-Konto, weswegen es z.B. einfach ist, sich sein Windows-Systemlaufwerk damit kaputtzumachen.

Ich kann mit meinem Kubuntu Dateimanager (Dolphin) problemlos auf meine externe HDD aber auch ein geteiltes internes Laufwerk mit NTFS Partition zugreifen, musste nur bis vor kurzem die Partitionen aktiv einhängen. Flatpak-Programme haben oft standardmäßig keine Rechte für bestimmte Verzeichnisse, aber das liegt dann nicht an Ext4 oder NTFS.

Vielleicht war das Rechteproblem schon Hinweis auf einen Defekt?

 

[McBain86]

Die Festplatte hat unter Windows keine Anzeichen gemacht, dass sie beschädigt wäre. Unter Linux hatte ich zuerst keine Schreibrechte und konnte auch nichts löschen. Ich habe dann im Terminal eine ntfsfix-Befehl eingegeben und dann ging es.

Ich habe Musik und andere Dateien auf eine SSD zur Sicherung kopiert und wollte sie dann von der HDD löschen. Das ging erst mal auch, aber im Papierkorb konnte ich nicht alles endgültig löschen. Es blieben vereinzelte leere Ordner im Papierkorb zurück. Ich weiß nicht woran das lag. Das war aber auch ein Grund, warum ich von ntfs auf ext4 wechseln wollte.

Mittlerweile ist der Papierkorb leer. Vielleicht war aber auch das ein Zeichen, dass die Platte eine Macke hat.

 

[JumpingCat]

Der Schnellstart in Windows bzw Hibernate wurde vorher deaktiviert? Sonst macht Windows nur Suspend to Disk und lässt das Dateisystem offen. Unter Linux erscheint es dann als "kaputt" weil das aussieht als wäre Windows abgestürzt.

 

[McBain86]

Einen Schnellstart in Windows habe ich nicht deaktiviert. Komischer Weise ist die NTFS-Partition völlig in Ordnung. Ich habe da weiterhin Zugriff drauf. Auch das Verkleiner hat ja zweimal problemlos funktioniert. Die unter Linux erstellte ext4 Partion spinnt jetzt nach dem Vergrößern. Ich hätte mich nicht gewundert wenn es anders herum gewesen wäre.

 

[JumpingCat]

Definiere spinnt.

Kannst du manuell un und dannmounten, gibt es dabei Fehler im syslog aka dmesg oder journalctl? Was sagt fsck dazu?

 

[kieleich]

das passiert bei diesen tools (gparted & co ) leider regelmässig

bei der art von vergrößerung "nach links" müssen alle daten verschoben werden

geht dabei was schief. gibts weder ein log, noch resume, noch sonst was

es ist auch gar nicht notwendig. mit lvm kann man sich das daten verschieben sparen. ist halt nicht bunt und nicht zum klicken, daher nutz es keiner. aber technisch möglich, wärs

das jetz noch mal retten ist sauschwer weil, man weiss ja nicht wo es schief gegangen ist und in welchem zu stand das jetzt ist also was von wo her bis wo hin geschoben wurde und wie es wieder richtig zusammen gesetzt gehört

wenn dann schon fsck dran war und sachen verändert hat - ist es nicht rückgängig zu machen mehr. fsck kann ja nicht wissen das geschoben wurde und dem entsprechend auch nur falsch reparieren

 

[McBain86]

mount: /dev/sdc3: can't find in /etc/fstab.
Bezüglich spinnen und fsck steht oben im ersten Beitrag.

@kieleich ok, das heißt die ext4 Partition ist verloren. Aber wenn ich das richtig verstehe, kann ich mit LVM eine NTFS-Partition auch nicht in ext4 umwandeln, richtig?

 

[JumpingCat]

So funktioniert das ned.

Wenn du es so machen willst, dann bitte die UUID in die fstab eingetragen und den mount point aufrufen.

 

[kieleich]

nein.

was man machen muss ist alles runter kopieren, formatierne, neu rauf kopieren.

umwandeln, tools dazu gibts nicht oder wenn es sie gibt dann sind sie riskant. schon das verschieben klappt irgendwie nicht obwohl das im Vergleich ein triviales problem ist, es braucht einfach nur lange zeit

im einfachsten fall ist der vorgang abgeschlossen aber das partition offset falsch, da könnte testdisk helfen

im zweit einfachsten fall hast du jetzt einen unbestimmten teil des dateisystem an neuen partition offset. und den rest weiter hin am alten offset. da müsstest du beide offset kennen und wie groß der schon verschobene teil ist und diese beiden teile wieder zusammen kleben an der richtigen stelle

je nachdem wie dieses tool arbeitet, irgendwelche ausgelagerten zonen... hat das puzzel hier noch mehr teile

und wenn ein teil davon einfach gar nicht mehr auf platte sondern nur im ram gecached oder sonstwo abgelegt wurde. dann ists ein puzzel dem teile fehlen

ich kann dir da leider auch nicht wirklich helfen, an so einem Problem würd ich selber, das ganze wochenende sitzen ohne Erfolg Garantie

hast du ein backup oder warens nur spiele die du neu laden kannst? augen zu und weg

 

[rollmoped]

das heißt die ext4 Partition ist verloren.

Nicht unbedingt. Deshalb würde ich, je nachdem, wie wichtig die Daten sind, zuerst ein bitweises Backup machen. Dann kann man mit Wiederherstellungstools arbeiten. Ohne Backup würde ich da nicht empfehlen irgendetwas auszuprobieren.

Eine Partition kann man zum Beispiel so mounten (ohne fstab Eintrag):

sudo mount /dev/sdc3 /mnt

Dann kann man über den Ordner /mnt auf die Daten zugreifen, wenn es funktioniert hat.

Vorschau:
Ein Backup könnte man dann so machen (auf eine Platte die mindestens gleich groß ist):

umount /dev/sdc
sudo dd if=/dev/sdc of=/dev/sdX status=progress bs=4M

Wichtig: Statt /dev/sdX den richtigen Pfad zur Backupplatte angeben.

So, und wenn man das Backup gemacht hat, dann kann man auf der Backupplatte die dritte Partition reparieren.

sudo umount /dev/sdX
sudo fsck -p /dev/sdX3

 

[McBain86]

@JumpingCat sorry, musste erst mal googlen. Habe die UUID mit mount point etc in fstab eingetragen und gespeichert, dann sudo mount -a , sudo systemctl daemon-reload und wieder sudo mount -a im Terminal eingegeben.

Kommt die Meldung: can't find UUID=2a8a43bd-ba1e-4998-8cdf-fbcb528d15dc

@rollmoped habe soeben sudo mount /dev/sdc3 /mnt ausprobiert. Dann kommt:

mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sdc3, missing codepage or helper program, or other error.
dmesg(1) may have more information after failed mount system call.

Ich schätze die Partition ist hin, was aber nicht so schlimm ist. Die ganz wichtigen Daten habe ich auf einer SSD geparkt. Ich denke, ich werde mir für EUR 40 eine gebrauchte 4 TB Platte als Backup holen und dort die Daten zwischenspeichern. Dann mach ich /dev/sdc platt und prüfe sie mit irgendwelchen Tools auf ihren Zustand.

Leute vielen Dank für eure Unterstützung. Ich wünsche euch noch einen schönen Abend.