Щоб додати відповідь, яка точно відповідає вашій справі, я трохи змінив свою відповідь у пов'язаному " дублікаті " і опублікував її тут ще раз.
Другий, а також третій розділ вашого внутрішнього диска отримали неправильний тип розділу, ваші дані, ймовірно, не втратяться.
Завантажуваний розділ OS X (крім Recovery HD) або має GUID 48465300-0000-11AA-AA11-00306543ECAC для стандартного розділу X X, або GUID 53746F72-6167-11AA-AA11-00306543ECAC для розділу CoreStorage. FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF - це невідомий тип розділу (але не такий розділ, як 000000-0000-0000 .... один).
Перший блок стандартного розділу X X не містить нульових значень, перший блок розділу CoreStorage містить деякі ненулі. Щоб отримати перші 3 блоки розділу, ви повинні використовувати заміну для hexdump / xxd (обидва недоступні в режимі завантаження / OS X Installer). Найкраще, що я знайшов - це dd if=/dev/diskXsY count=3 | vis -c.
Таблицю розділів GUID можна змінити за допомогою gpt. gpt записує лише перші 34 та останні 33 блоки диска (512) або перші 6 та та останні 5 блоків 4k диска. Змінення таблиці розділів (навіть помилково) не змінює вміст будь-якого обсягу на вашому диску, якщо ви не ініціалізуєте або не відновите об'єм / диск за запитом. Ви можете перевірити це.
- Завантажте в режим відновлення Інтернету або завантажувальний диск інсталятора OS X
- Відкрийте термінал у меню Утиліти> Термінал
- Ознайомтеся з оглядом
diskutil list
Ознайомтеся з внутрішнім диском з ідентифікатором диска, знайденим у попередній команді. Нижче я припускаю, що ідентифікатором вашого внутрішнього диска є disk0 (замініть його на той, який ви знайшли у вашому оточенні)
gpt -r show disk0
- Відключіть диск0 с
diskutil umountDisk disk0
щодо перших 3 блоків розділу FFFF ...
dd if=/dev/disk0s2 count=3 | vis -c
Якщо раніше у вас був стандартний розділ, перші 1024 байти містять недруковані (нулі): \ 0 \ 0 ... У ~ Byte 1030 ви побачите таку послідовність: \ 0HFSJ \ 0
Якщо у вас був розділ CoreStorage, в перших 512 байтах та рядку CS ( ...\0CS\^A...) відображаються деякі ненулі :
\^U\^D\^A\M-s\M^?\M^?\M^?\M^?\^A\0\^P\0\0\0\M-W\^A\a\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^B\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\M^Pu\M-\7\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0CS\^A\0\0\0\^D\0\0\^P\0\0\0\0@\0X\M-7}\^C\0\0\0\0X\M-;}\^C\0\0\0\0X\M-?}\^C\0\0\0\0X\M-C}\^C\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^P\0\0\0\^B\0\0\0006j v\^R\M-+\^U\M^[\f\M^CdG\M-y\^]...
Тепер видаліть третій, четвертий та другий розділи:
diskutil umountDisk disk0
gpt remove -i 3 disk0
diskutil umountDisk disk0
gpt remove -i 4 disk0
gpt remove -i 2 disk0
Якщо ви отримаєте повідомлення про помилку типу "ресурс зайнятий", просто знову відключіть диск або відключіть вперті томи diskutil umount disk0sX.
Повторно додайте розділ відновлення відповідним типом, але той самий номер індексу, стартовий блок та розмір, який він мав раніше:
gpt add -i 3 -b 227212504 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC disk0
Повторно додайте головний розділ відповідного типу, але той самий номер індексу, стартовий блок та розмір, який він мав раніше:
Або звичайний розділ OS X (якщо ви знайшли типові сліди нормального розділу на dd ... visкроці):
gpt add -i 2 -b 409640 -s 226802864 -t 48465300-0000-11AA-AA11-00306543ECAC disk0
або (якщо ви знайшли типові сліди розділу CoreStorage):
gpt add -i 2 -b 409640 -s 226802864 -t 53746F72-6167-11AA-AA11-00306543ECAC disk0
Ваш диск повинен нарешті виглядати так, якщо ви знайшли стандартний розділ OS X:
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 226802864 2 GPT part - 48465300-0000-11AA-AA11-00306543ECAC
227212504 1269536 3 GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
228482040 8496103
236978143 32 Sec GPT table
236978175 1 Sec GPT header
або це, якщо ви знайшли том CoreStorage:
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 226802864 2 GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
227212504 1269536 3 GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
228482040 8496103
236978143 32 Sec GPT table
236978175 1 Sec GPT header
Нарешті перевірте / відновіть диск за допомогою diskutil verifyDisk disk0та / або diskutil verifyVolume disk0s2. Якщо потрібен ремонт, використовуйте ремонт (замість підтвердження) як префікс у вищезазначених командах, але зв'яжіться зі мною перед його ремонтом та надішліть мені повідомлення про помилку .
Подальші дослідження через сеанси TeamViewer показали, що розділ EFI та розділ Recovery HD пошкоджені. Основний том зашифрований. Відновлення HD містить спеціальний проміжний ключ FileVault потім. Якщо ключ відсутній, основна система не завантажиться. Можна було розблокувати привід хоч і з diskutil cs unlockVolume ....
Після встановлення повного macOS на палець та завантаження на нього розділ EFI та Recovery HD іншого не-FileVault-накопичувача (фактично тих, що входять у Sierra VM) були порушені. Ще завантажившись з накопичувача великого пальця, том FileVault було повернено до стандартного обсягу, клацнувши правою кнопкою миші на томі в Finder, вибравши "Розшифрувати том" та ввести дійсний пароль користувача. Це має бути паролем відповідного облікового запису користувача на томі FileVault. Інші методи розшифровки тома, як-от diskutil cs revert lvUUIDабо diskutil cs decryptVolume lvUUIDперевірені лише у віртуальній машині, начебто не спрацювали. Це може бути обмеженням VM.
Щоб розгорнути основний розділ (disk0s2) до повного розміру, використовуйте Disk Utility або diskutil resizeVolume ...команду.
Том спочатку не відображався в System Preferences> Startup Disk, але altпри завантаженні Mac було оприлюднено основний том. Це, ймовірно, повторно благословило boot.efi тома належним чином. Зображення (тепер стандартне) знову з’являється на дисплеї запуску.
