macOS Ventura Ventura OCLP startet nicht mehr...

iMaxer

Aktives Mitglied
Thread Starter
Dabei seit
26.10.2021
Beiträge
3.062
Reaktionspunkte
2.628
Moin...,
ich habe plötzlich ein Problem, nachdem ich im FDP versucht hatte, eine unbenutzte 40 GB Partition einer meiner beiden anderen P. zuzuschlagen. System sitzt auf externer USB3 SSD, aktuelles Timeshift Backup ist auf der internen HDD.

System ist Ventura (OCLP). Das FDP behauptete zunächst, das Zuschlagen ginge weder zur MacOS Sytempartition noch zur exFAT Datenpartition. Löschen ging aber. Als ich das machte, wollte es die 40 GB trotzdem zur MacOS Part. zuschlagen und scheiterte. Danach war die 40er nicht mehr sichtbar, aber die anderen beiden behielten scheinbar ihre vorherige Größe.

In diskutil waren die 40 GB aber als unused angezeigt. Dann startest du doch mal neu und schau, ob die Diskrepanz dadurch verschwindet... das hätte ich wohl lieber nicht tun sollen, denn nun bootet Ventura nicht mehr!

Beim Start kommt erst der OCLP Bootpicker, dann aber ist im nächsten Screen der Ventura Eintrag nicht mehr da.

Was tun sprach Zeus?!??

Zum Glück habe ich noch meinen Stick mit dem alten Monterey Image, davon schreibe ich jetzt. Habe ich eine Chance, den Fehler einfach zu beheben? Danke sehr für eure zielführenden Hinweise!!

PS: ich nehme an, ein Wiederherstellen des TM Backups bringt hier nichts, weil nur der Inhalt des MacOS Volumes zurückgespielt wird und der anscheinend fehlende Efi Eintrag nicht?

PPS: da ich im Monterey auch die exFAT Datenpartition nicht sehe sieht es für mich so aus, als ob die Partitionstabelle der externen SSD beschädigt ist?! Gibt es da eine Reparaturoption? Was genau macht das "Wiederherstellen" aus dem FDP heraus? Und gibt es per Terminal da vllt. Möglichkeiten?
 
Zuletzt bearbeitet:
Code:
rainer@iMac ~ % diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI ⁨EFI⁩                     209.7 MB   disk0s1
   2:                 Apple_APFS ⁨Container disk1⁩         1000.0 GB  disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +1000.0 GB  disk1
                                 Physical Store disk0s2
   1:                APFS Volume ⁨timemachine⁩             585.5 GB   disk1s2

/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *128.0 GB   disk2
   1:                        EFI ⁨EFI⁩                     209.7 MB   disk2s1
   2:                 Apple_APFS ⁨Container disk3⁩         127.8 GB   disk2s2

/dev/disk3 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +127.8 GB   disk3
                                 Physical Store disk2s2
   1:                APFS Volume ⁨Monterey⁩                15.5 GB    disk3s1
   2:              APFS Snapshot ⁨com.apple.os.update-...⁩ 15.5 GB    disk3s1s1
   3:                APFS Volume ⁨Monterey - Data⁩         69.0 GB    disk3s2
   4:                APFS Volume ⁨Preboot⁩                 532.6 MB   disk3s3
   5:                APFS Volume ⁨Recovery⁩                1.1 GB     disk3s4
   6:                APFS Volume ⁨VM⁩                      1.1 MB     disk3s5

/dev/disk4 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *512.1 GB   disk4
   1:                        EFI ⁨EFI⁩                     209.7 MB   disk4s1
   2: FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF ⁨⁩              140.3 GB   disk4s2
                    (free space)                         40.0 GB    -
   3: FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF ⁨⁩              331.6 GB   disk4s3

rainer@iMac ~ %
Was ich da rauslese ist, dass der Partitionstyp auf der disk4 nicht mehr stimmt. Gibt es dafür Reparaturtools? die 140er ist MacOS und die 331er die Datenpartition. "Erste Hilfe" hat nichts verändert, es behauptet, die Tabelle wäre in Ordnung.

Ich versuche jetzt erstmal mit Disk Drill voran zu kommen, das erkennt schon mal den Typ der Datenpartition und scheint alle Daten retten zu können.
 
Zuletzt bearbeitet:
Nimm Testdisk oder setz den Type neu mit gptfdisk.
 
Danke, ich schau mal, ob ich damit klar komme. Meine Hoffnung ist ja, dass das Setzen des richtigen Typs ausreicht.
 
Hoffentlich ist da nicht auch die Größe überschrieben usw
 
Die Angaben von Disk Drill stimmten augenscheinlich. Mit Fedora kann ich die Datenpartition mounten und korrekt lesen. :)
 
Zuletzt bearbeitet:
Wie lautet der 4stellige Partitionstyp eines Apfs Container für MacOS System? Ist af0a korrekt? Google bringt mich da leider nicht weiter...
Bin derzeit auf Linux, weil ein Update mir das Monterey zerschossen hat. Wiederherstellung aus einem Image dauert leider.....
 
Zuletzt bearbeitet:
Leider klappt das wiederherstellen aus dem tm Backup auch nicht, da die interne HDD nicht als tm Laufwerk erkannt wird. Im FDP wird sie als nicht initialisiert angezeigt, erste Hilfe nutzt auch nichts.
Gibt's noch eine Chance für mich, nicht alles komplett neu aufsetzen zu müssen? :unsure:
 
Hast du versucht die TM Platte zu initialisieren?
 
Versucht ja, aber ich weiß nicht wie das geht.
 
Er startet wieder Ventura!! :D(y)
Das Setzen des korrekten Typs mit gdisk unter Fedora auf af0a hat offenbar gereicht.

Das Sahnehäubchen wäre jetzt, wenn mir jemand erklären könnte, wieso so was passieren kann?! Man will nur eine eigentlich unbeteiligte Partition löschen und das FPDP zerhaut die GPT Tabelle. :unsure:

Sinn der ganzen Aktion war es übrigens, die 40 GB unpartitioniert zu lassen, damit sie evtl. für das Wear Levelling benutzt werden. Aber das ist wohl eh überflüssig, weil dafür ein spezieller Bereich genutzt wird, der für die Betriebssysteme gar nicht erreichbar ist? Richtig?
 
Zurück
Oben Unten