Відновлення GPT від невдалого оновлення Mojave

Передумови: Мій партнер вирішив модернізувати свою роботу iMac на Mojave. Мабуть, наприкінці процесу він висів на чорному екрані, сказав, що сталася помилка і намагатиметься відновити. Він кілька разів циклізував цей процес перед тим, як перервати або просити відновити з резервної копії машини часу або встановити нову ОС.

Не маючи резервного копіювання Time Machine, вона вибрала нову установку. Перший натяк на те, що з накопичувачем щось пішло не так, це те, що єдиним вибором для встановлення був її зовнішній (не машина часу) диск, який вона зробила. Для цього встановлено El Capitan, який не підтримує APFS.

Теорія: Оскільки це привід Fusion, він до цього часу не перетворювався на APFS. Частина цього процесу, мабуть, пішла не так, і тепер диск не впізнаваний. Оскільки резервна ОС, яка встановила себе на вторинний диск, є лише El Capitan, вона не здатна ідентифікувати обсяги APFS. diskutilпоказав два роз'єднані томи SSD та HDD, в яких відсутня група CoreStorage.

У своїх зухвалих спробах виправити це, я не досліджував достроково, щоб дізнатися про перетворення APFS Mojave. Я спробував відтворити розділ HFS +, а потім запустив програму Disk Rescue. Природно, нічого не знайшли. Я взяв образ диска (нерозумно після факту ...) додому, щоб спробувати запустити криміналістику на ньому, але оскільки він, ймовірно, був зашифрований, здається, навряд чи я щось знайду.

Однак я помітив, як виглядає заголовок блоку APFS на початку розділу:

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

Наскільки я можу сказати, ac 45 8d 0e 00 00 00 00вказували б 244,139,436 блоків на 4096 байт, отримуючи 999,995,129,856 байт - приблизно біля розміру диска 1 ТБ.

Оскільки у розділу все ще є деякі заголовки блоку APFS, здавалося б, недоторканими, я сподіваюся, що можливо, можливо, перезаписати GPT, щоб сказати, щоб він розглядав розділи як APFS.

Я бачу кілька підводних каменів цієї теорії:

1. Fusion Drive: Оскільки це Fusion Drive, я, можливо, зможу відновити жорсткий диск самостійно, але це не означає, що він буде функціонувати зовсім ...
2. Шифрування: Оскільки викладачі вимагають, щоб накопичувачі були зашифровані, швидше за все HFS + був зашифрований перед оновленням. Я не знаю, як функціонує шифрування APFS, але така процедура звучить так, що, можливо, це зіпсується.
3. Переписування таблиці розділів: У моїй помилковій спробі відтворити розділи, мені цікаво, чи не вдалося б я зробити непоправними речі. Навіть якщо ми нічого не писали до нових розділів, вони все одно створили звичайні .DS_Storeта пов’язані з ними файли.