Mir hätte jetzt so ne erprobte Vorgehensweise geholfen, bei der man nicht sicherheitshalber die Datensicherung machen muß.
Das ist leider prinzipiell schon unmöglich.
Es kann immer was schief gehen, dann hilft nur ein Backup.
Außerdem zerschießt hier wohl niemand regelmäßig seine Platte und jedes mal ist auch individuell.
Die Partitionierung erfolgte damals mit gdisk.
Dann sollte die GPT maßgebend sein.
An USB wird bei gdisk die ungültige GPT angemeckert, und der Vorschlag gemacht, den korrekten MBR zum Erstellen einer GPT zu verwenden (destructive), und bemeckert die Überlänge.
In dem Fall handelt es sich nur um einen Protective- oder Hybrid-MBR, der dazu dienen soll, dass die Platte von einem Legacy-System nicht als leer erkannt und versehentlich formatiert wird.
Die Informationen aus dieser MBR sind mit Vorsicht zu genießen. Ein einfaches zurückschreiben in die GPT wird nicht empfohlen.
Warning! Secondary partition table overlaps the last partition by 175 blocks!
Für mich sieht es so aus, als ob die Backup-GPT in dem MBR der zweitem Partition zugeschlagen wurde.
Solange man die zweitem Partition nicht formatiert ist das egal, man kann ja nicht über das Dateisystem hinaus schreiben.
Das Dateisystem der zweitem Partition sollte also immer vor der Backup-GPT enden, auch im MBR Modus müssten also am Ende der zweitem Partition entsprechend 175 blocks a 256Byte (oder 4K???) frei sein.
Das sollte sich mit GParted (MBR-Mode) eigentlich anzeigen lassen (sofern das im aktuellen Zustand irgendwas anzeigt).
Mit Testdisk sollte man aber an die korrekte Größe der Dateisysteme und deren erste Sektoren kommen.
Eigentlich sind nur diese Daten wichtig, daher notieren Zwecks Abgleich mit der regenerierten GPT.
Wobei die Partition laut MBR sogar über die Platte hinaus geht und trotzdem freie Sektoren existieren:
Disk /dev/sdd: 1953506646 sectors
last usable sector is 1953506640
Total free space is 506 sectors (2.0 MiB)Number Start (sector) End (sector) Size Code Name
1 256 956825599 3.6 TiB 8300 Linux filesystem
2 956825856 1953506815 3.7 TiB 8300 Linux filesystem
Das ist so eigentlich unmöglich.
Ich vermute mal, dass die Umsetzung MBR in GPT gründlich daneben gegangen ist.
Anderenfalls hätte die HDD ihre Geometrie geändert und das wäre gar nicht gut.
Mal probiert, Backup des GPT ergibt ein File von 17920 Byte, 70*256Byte. ???
Die Größe spielt wohl nicht wirklich eine Rolle, da die Partitionen normalerweise an MiB-Grenzen ausgerichtet werden.
Bei der aus der MBR regenerierten die Ausrichtung scheint zumindest das zu stimmen:
Logical sector size: 4096 bytes
Partitions will be aligned on 256-sector boundaries
256 * 4KiB = 1MiB
Da jetzt ein externes Backup der GPT existiert, könnte man mal versuchen die GPT aus der Backup-GPT der Platte wiederherzustellen. Die sollte normalerweise noch intakt sein.
Expertenmenü R, Taste B und C.
Im Erfolgsfall sollte die Fehlermeldung von gdisk dann verschwunden sein. Auch sollten die fehlenden GUID wieder hergestellt sein.
Wenn die wiederhergestellte GPT zudem mit den Partitionsdaten von Testdisk (Startsektor und ausreichend Platz bis zur nächstem Partition/Ende) übereinstimmt, kann man die eigentlich übernehmen.
Wenn dann e2fsck -fvn (read only) ohne Beanstandung durchläuft und (-ro) Lesetests erfolgreich sind, könnte man es wagen die Platte wieder -rw zu mounten.
gdisk sieht 2 Partitionen
Nein, gdisk sieht nur eine defekte GPT und geht daher in Konvertiermodus.
Wenn Du irgendwie auf die Platte zugreifen kannst, dann aufgrund des Protective- oder Hybrid-MBR.
Mit Schreibzugriff in dem Modus wäre ich aber extrem vorsichtig.
.
