Ich weiß, dass dies hier schon einmal gefragt wurde, und ähnlich wie bei den anderen habe ich meine Daten nicht gesichert ... Ich habe dieses Duplikat gefunden und mich in der Antwort verloren und wollte nicht zu viel mit den Tabellen herumspielen, ohne es herauszufinden ob das überhaupt die richtige Lösung für mein Problem ist.
Das Laufwerk ist mein internes Laufwerk von meinem alten Macbook Pro (Anfang 2011 Modell, starb aufgrund des Grafikkartenproblems, nachdem die Hauptplatine vor etwa einem Jahr ausgetauscht wurde), das mit Windows 10 doppelt gebootet wurde, aber mein Computer blieb beim Versuch hängen booten und musste zwangsweise heruntergefahren werden. Habe das Laufwerk herausgenommen und an ein anderes Macbook angeschlossen und die MacOS-Partition wurde nicht gemountet.
sudo diskutil list
Erträge:
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.1 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Macintosh HD 394.0 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
4: Microsoft Basic Data BOOTCAMP 105.2 GB disk0s4
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.1 GB disk1
1: EFI EFI 209.7 MB disk1s1
2: FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF 419.9 GB disk1s2
3: Microsoft Basic Data BOOTCAMP 80.0 GB disk1s3
Ebenso gut wie
sudo gpt -r show disk1
Erträge:
gpt show: disk1: Suspicious MBR at sector 0
start size index contents
0 1 MBR
1 1 Pri GPT header
2 32 Pri GPT table
34 6
40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
409640 820115416 2 GPT part - FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF
820525056 156248064 3 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
976773120 15
976773135 32 Sec GPT table
976773167 1 Sec GPT header
Vielen Dank für jede Hilfe, die gegeben werden kann!
Das Problem wurde basierend auf dieser Antwort behoben: Das Betriebssystem-Volume wird als Typ „FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF“ angezeigt.
Es ist unklar, warum der Partitionstyp geändert wurde. Auf dem ursprünglichen Startlaufwerk (disk0) ist Yosemite installiert. sudo dd if=/dev/disk1s2 count=3 | hexdump
Auf dem zweiten "kaputten" Laufwerk (diisk1) wurde mit der Methode aus der verlinkten Antwort eine APFS-Partition erkannt .
Nach dem Entfernen der zweiten Partition auf Laufwerk 1 mit sudo gpt remove -i 2 disk1
blockiertem MBR fügen Sie die Partition mit dem richtigen Typ hinzu. Also musste das gpt zerstört werden:
sudo gpt -r show disk1 #get the details
sudo gpt destroy disk1
sudo gpt create -f disk1 #create a new partition table
Hinzufügen aller vorherigen Partitionen mit den richtigen Typen:
sudo gpt add -i 1 -b 40 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B disk1
sudo gpt add -i 2 -b 409640 -s 820115416 -t 7C3457EF-0000-11AA-AA11-00306543ECAC disk1
sudo gpt add -i 3 -b 820525056 -s 156248064 -t EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 disk1
Überprüfen Sie die Festplatte:
diskutil verifyDisk disk1
Da die Version des Bootsystems 10.10.5 (Yosemite) ist, die nicht mit APFS-Volumes umgehen kann, war es nicht möglich, das Volume zu überprüfen.
Weitere ähnliche Fragen (und Lösungen) auf dieser Seite deuten darauf hin, dass das Problem mit dem SIP-geschützten MBR zusammenhängt. Yosemite erkennt keine SIP-geschützten Elemente, neuere Systeme jedoch schon. Hier war es möglich, den MBR zu killen, aber auf neueren Systemen muss SIP deaktiviert werden.
Dillon Esponda
klanomath
Monomet
Monomet
Monomet
klanomath