Ripristino GPT da un aggiornamento Mojave fallito

Sfondo: il mio partner ha deciso di aggiornare il suo lavoro con iMac a Mojave. Apparentemente, verso la fine del processo, è appeso a uno schermo nero, ha detto che si era verificato un errore e avrebbe cercato di recuperare. Ha ripetuto questo processo alcune volte prima di interrompere e chiedere di eseguire il ripristino da un backup di Time Machine o di eseguire una nuova installazione del sistema operativo.

Non avendo il backup di Time Machine, ha optato per l'installazione recente. Il primo suggerimento che qualcosa è andato storto con l'unità è che l'unica scelta di installazione era la sua unità esterna (non macchina del tempo), che ha fatto. Questo ha installato El Capitan, che non supporta APFS.

Teoria: poiché si tratta di un'unità Fusion, non è stata convertita in APFS fino ad ora. Parte di questo processo deve essere andata storta e ora l'unità è irriconoscibile. Poiché il sistema operativo di backup che si installa sull'unità secondaria è solo El Capitan, non è in grado di identificare i volumi APFS. diskutil ha mostrato due dischi SSD e HDD disgiunti senza alcun gruppo CoreStorage presente.

Nei miei bizzarri tentativi di risolvere il problema, non ho fatto ricerche in anticipo per scoprire la conversione di APFS Mojave. Ho provato a ricreare una partizione HFS +, quindi eseguendo Disk Rescue su quello. Naturalmente, non ha trovato nulla. Ho scattato un'immagine di guida (stupidamente dopo il fatto ...) a casa per provare a eseguire forensics su di esso, ma poiché probabilmente era crittografata, sembra improbabile che trovassi qualcosa.

Tuttavia, ho notato l'aspetto di un'intestazione di blocco APFS all'inizio della partizione:

1+0 records in
1+0 records out
512 bytes copied, 7.4092e-05 s, 6.9 MB/s
00000000  68 4b 56 14 14 fc fd 0c  01 00 00 00 00 00 00 00  |hKV.............|
00000010  04 00 00 00 00 00 00 00  01 00 00 80 00 00 00 00  |................|
00000020  4e 58 53 42 00 10 00 00  ac 45 8d 0e 00 00 00 00  |NXSB.....E......|
00000030  01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  02 00 00 00 00 00 00 00  64 b8 83 b0 64 92 43 35  |........d...d.C5|
00000050  b9 07 a5 af d1 9d 31 78  06 04 00 00 00 00 00 00  |......1x........|
00000060  05 00 00 00 00 00 00 00  18 01 00 00 5c 6c 00 00  |............\l..|
00000070  01 00 00 00 00 00 00 00  19 01 00 00 00 00 00 00  |................|
00000080  08 00 00 00 0e 00 00 00  06 00 00 00 02 00 00 00  |................|
00000090  0a 00 00 00 04 00 00 00  00 04 00 00 00 00 00 00  |................|
000000a0  93 9a 28 00 00 00 00 00  01 04 00 00 00 00 00 00  |..(.............|
000000b0  00 00 00 00 64 00 00 00  02 04 00 00 00 00 00 00  |....d...........|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

Per quanto ne so, ac 45 8d 0e 00 00 00 00 indicherebbe 244,139,436 blocchi di 4096 byte, producendo 999,995,129,856 byte - solo attorno alla dimensione dell'unità da 1 TB.

Poiché la partizione ha ancora alcune intestazioni di blocco APFS apparentemente intatte, spero che sia possibile sovrascrivere il GPT per dirgli di trattare le partizioni come APFS.

Vedo alcune insidie a questa teoria:

1. Fusion Drive: Poiché si tratta di un'unità a fusione, potrei riuscire a ripristinare l'unità HDD da sola, ma ciò non significa che funzionerà affatto ...
2. Crittografia: poiché la facoltà richiede che le unità siano crittografate, era probabile che HFS + fosse crittografato prima dell'aggiornamento. Non so come funzioni la crittografia APFS, ma questo tipo di procedura suona come se fosse probabile che avrebbe potuto rovinare tutto.
3. Sovrascrittura della tabella delle partizioni: nel mio tentativo errato di ricreare le partizioni, mi chiedo se avrei potuto rendere le cose irrecuperabili. Anche se non avessimo scritto nulla sulle partizioni fresche, avremmo comunque creato il solito .DS_Store e i relativi file.