Partitionstyp FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF, Laufwerk kann nicht gemountet werden

Ja, das habe ich bereits versucht: Partitionstyp plötzlich FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF, Laufwerk unmountbar

Meine Hauptpartition ist in diesem ffffffff-ffff-ffff-ffff-ffffffffffff-Format oder was auch immer es ist. Und ich brauche alle Daten auf diesem disk3s2.

Hier ist ein Bild von meiner Festplatte, vor ein paar Stunden:Geben Sie hier die Bildbeschreibung ein

  • disk3s1: EFI
  • disk3s2: Macintosh (ffffffff-ffff-ffff-ffff-ffffffffffff-Partition mit all meinen Daten darauf, ich will diese Daten!)
  • disk3s3: Apple_HFS Recovery HD
  • disk3s4: Neu (Eine weitere nutzlose Partition, sie ist leer.)
  • disk3s5: Apple_Boot Recovery HD

Was ich getan habe, um zu versuchen, meine Festplatte zu reparieren:

diskutil umountDisk /dev/disk3
sudo gpt destroy /dev/disk3
diskutil umountDisk /dev/disk3
sudo gpt create -f /dev/disk3

sudo gpt add -i 1 -b 40 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/disk3

Wenn ich also versuche, eine weitere Partition hinzuzufügen, erhalte ich diesen Fehler:

gpt add: /dev/disk3: error: no space available on device

Bitte helfen Sie, wenn Sie irgendwelche Vorschläge haben, ich habe viele wichtige Daten verloren!!!

Aktualisieren:

diskutil list

führt dazu:

 /dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *120.0 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:          Apple_CoreStorage SSD                     119.2 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

/dev/disk1 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            SSD                    +118.8 GB   disk1
                                 Logical Volume on disk0s2
                                 ...deleted it...
                                 Unencrypted

/dev/disk3 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *320.1 GB   disk3
   1:                        EFI EFI                     209.7 MB   disk3s1

Und

sudo gpt -r show disk3

führt dazu:

    start       size  index  contents
          0          1         PMBR
          1          1         Pri GPT header
          2         32         Pri GPT table
         34          6         
         40     409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
     409640  624732774         
  625142414         32         Sec GPT table
  625142446          1         Sec GPT header
Sie sagten " Ich habe viele wichtige Daten verloren!!! ", sind Sie nicht gesichert? Wenn nein, warum nicht!?
Bitte erläutern Sie alle relevanten Schritte, die zu diesem Ergebnis geführt haben könnten. Ich hatte vor ein paar Monaten einen Kunden, der versuchte, Dual Boot auf seinem Computer für Linux und Mac zu installieren. Er hatte ein ähnliches Problem, das ich schließlich beheben konnte. Wir müssen jedoch wissen, was Sie getan haben , um Ihnen dabei zu helfen, es rückgängig zu machen.
Übrigens gehen Ihre Daten nicht verloren (es sei denn, Sie formatieren oder reparieren ein Volume nicht mit diskutil) - die Partition hat einfach den falschen Typ.
@Zonker.in.Geneva Ich wollte gerade Mac OSX Sierra installieren. Nach Download und Neustart (keine Installation, ging nicht mehr). Alle 320 GB werden atm verwendet, das könnte ein Problem sein. Ich habe oben beschrieben, was ich danach gemacht habe.
@klanomath Danke, ich habe alles hinzugefügt, wonach Sie gefragt haben.
@klanomath Ja, tut mir leid, schon erledigt
@Seliem Hast du noch irgendwo die alte Partitionstabelle von disk3 (vor dem Löschen der falschen GUID-Partitionstabelle) als Ausgabe? Der Screenshot der diskutil-Liste von disk3 reicht nicht aus, um die GUID pt wiederherzustellen. Es ist aber ein Hinweis!
@klanomath Wenn es nicht irgendwo in meinem Terminal gespeichert ist, habe ich keine andere Karte. Warum? Was fehlt?
@Seliem Wenn Sie Ihr Terminalfenster in der Zwischenzeit geschlossen haben, ist es wahrscheinlich verloren.
@klanomath Natürlich habe ich das getan. Was kann ich jetzt tun?
@klanomath in Ordnung, installiert, Benutzer: "Seliem"

Antworten (1)

Die Volumes können in einer TeamViewer-Sitzung wiederhergestellt werden, indem nach speziellen Zeichenfolgen gesucht wird, die der in dieser Antwort beschriebenen Methode ähneln: Meine SATA-Festplatte wurde ausgeworfen und kann aufgrund von Problemen nicht erneut bereitgestellt werden .

Die getroffenen Annahmen:

  • disk3s4 (24,6 GB) und disk3s5 (650 MB) befinden sich am Ende der Platte (siehe diskutil listScreenshot der Frage - beide verschwanden nach dem Zerstören der alten Partitionstabelle mit sudo gpt destroy /dev/disk3)
  • disk3s2 (Macintosh) belegt/belegt den gesamten nicht zugeordneten Speicherplatz (mit Ausnahme der 1. Wiederherstellungs-HD) von ~ 294 GB und ist verschlüsselt.

Um den Startblock der ersten Recovery HD zu erhalten, geben Sie ein (der im Bereich von 271 GiB - 274 GiB oder ~291 GB - ~295 GB der Festplatte liegen muss)

sudo hexdump -s 271g /dev/disk3 | grep "48 46 53 4a"

(Hexdump verwendet GibiBytes statt GigaBytes!), was ergab:

447f801400 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
447f828a00 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
447f840c00 48 2b 00 04 80 00 20 00 48 46 53 4a 00 00 00 06
447f871e00 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
...

0x447f801400 ist Byte 294196876288 (oder Block 574603274) der Festplatte. Da sich die Zeichenfolge HFSJ im dritten Block eines Volumes befindet, beginnt die Wiederherstellungs-HD mit Block 574603272.

Die typische Ausgabe, wenn das vorherige Volume kein FileVault, sondern ein normales HFSJ-Volume war, würde stattdessen so aussehen:

447f800c00 48 2b 00 04 80 00 20 00 48 46 53 4a 00 00 01 ff
447f801400 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
447f828a00 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
447f840c00 48 2b 00 04 80 00 20 00 48 46 53 4a 00 00 00 06
447f871e00 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
...

Die erste und zweite Bytenummer zeigen einen Unterschied von 0xc00-0x1400=0x800 oder 2048 Bytes, da das vorhergehende OS X-Volume einen alternativen Volume-Header im vorletzten Block hat, während FileVault-Volumes keinen haben.

Die Recovery HD hat eine feste Größe von 1269536 Blöcken und kann mit gpt zur Partitionstabelle hinzugefügt werden.

sudo gpt add -i 3 -b 574603272 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC disk3

Überprüfen Sie nun die Lautstärke mit

diskutil verifyVolume disk3s3

Wenn die Partitionsgrenzen und das Volume in Ordnung sind, erhalten Sie einen Exit-Code 0.

Im nicht zugeordneten Speicherplatz zwischen EFI und Recovery HD wurde eine CoreStorage-Partition hinzugefügt:

sudo gpt add -i 2 -b 409640 -s 574193632 -t 53746F72-6167-11AA-AA11-00306543ECAC disk3

Das FileVault-Passwortfenster wurde angezeigt und das Passwort wurde eingegeben - es wurde also wahrscheinlich erfolgreich hinzugefügt.

Die Festplatte und das Volume wurden überprüft mit:

diskutil verifyDisk disk3
diskutil verifyVolume disk3s2

die beide mit Code 0 beendet wurden und alles in Ordnung war.

Später wurde das FileVault-Volume auf die volle Größe der Festplatte erweitert mit:

diskutil cs lvUUID resizeStack 318g #with lvUUID: the Logical Volume UUID of the second CoreStorage container
Partitionstyp FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF, Laufwerk kann nicht gemountet werden
AntwortenHierDatenschutz-Bestimmungen1y, 0v