Я следовал руководству по созданию двойной загрузки с macOS Sierra 10.12 и Kali-Linux 2.0.
Я создал загрузочный USB-накопитель и загрузился в живом сеансе Kali-Linux, чтобы использовать GParted и изменить размер раздела macOS.
Я выбрал раздел macOS и изменил его размер с 239 ГБ до 200 ГБ. У меня есть 2 раздела, причем раздел размером 39 ГБ отформатирован как «нераспределенный».
Но теперь, когда я пытаюсь загрузиться в macOS, я получаю логотип Apple, затем белый крест и не могу загрузиться в macOS.
Я попытался загрузиться в Recovery HD, удерживая cmdR, затем я попытался использовать SOS, но он говорит, что мне нужен диск восстановления Assistant. Мы можем создать USB-диск восстановления, подключив USB-накопитель к нашему MacBook, а затем с помощью помощника создав загрузочный USB-накопитель, который может восстанавливать диски, но, как я уже сказал, мой MacBook не может загружаться в macOS, поэтому я не могу создать это ... Есть ли способ загрузить iso-образ USB-накопителя для восстановления напрямую, чтобы создать из него свой собственный USB-накопитель для восстановления?
Я где-то читал, что мне нужно переписать правильные загрузочные коды, и мои данные не потеряются. Это правда?
Как вы думаете, что я могу сделать?
Изменить:
вот вывод diskutil/gpt:
(Извините за низкую степень сжатия, у меня нет репутации 10, чтобы публиковать более 2 фотографий)
Я не ожидал результата от Дискутил. Так много разделов нормально?
Редактировать2 :
Вот другой экран, который у меня был после команд записи:
Редактировать 3
GParted на самом деле не создавал нераспределенного дискового пространства. Вместо этого MBR стал поддельным. CoreStorage LVG и все последующие контейнеры также были повреждены, потому что размер всего стека не был изменен должным образом. Обычно в macOS весь стек изменяется с помощью команды diskutil cs resizeStack ...
. Насколько я могу сказать удаленно, конечная граница второго раздела была просто перемещена на более низкие номера блоков, что обычно работает с обычными томами HFS+ в GParted, но не в этом случае со стеком CoreStorage. К счастью, некоторые невидимые структуры данных стека CS не были перезаписаны.
Кроме того, раздел восстановления не был перемещен должным образом. Но это другая проблема.
Вместо MBR у вас должна быть pMBR. После удаления фиктивной MBR вам необходимо уничтожить и воссоздать таблицу разделов GUID:
Получите обзор (особенно важна команда gpt !):
diskutil list
gpt -r show disk0
Размонтировать диск0:
diskutil umountDisk /dev/disk0
Удалить MBR:
dd if=/dev/zero of=/dev/disk0 bs=512 count=1
Уничтожьте таблицу разделов GUID и создайте новую (это также создаст новую pMBR):
gpt destroy disk0
gpt create -f disk0
Восстановите все предыдущие разделы GUID:
gpt add -i 1 -b 40 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B disk0
gpt add -i 3 -b 488965176 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC disk0
gpt add -i 2 -b 409640 -s 409602008 -t 53746F72-6167-11AA-AA11-00306543ECAC disk0
Если после одного из шагов вы получите сообщение об ошибке, связанной с занятостью ресурсов, просто снова размонтируйте disk0 с помощью
diskutil umountDisk /dev/disk0
Проверьте диск diskutil verifyDisk disk0
потом.
Введите diskutil cs list
и проверьте, отображаются ли все четыре контейнера CoreStorage: группа логических томов, физический том и семейство логических томов и логический том.
С помощью UUID логического тома смонтируйте LV:
Пример:
+-> Logical Volume 9A7B21AA-F9FE-4E65-8C7E-ED2A73744C15
---------------------------------------------------
Disk: disk17
Status: Online
Затем используйте:
diskutil mount 9A7B21AA-F9FE-4E65-8C7E-ED2A73744C15
Затем, после получения идентификатора диска смонтированного LV, diskutil list
проверьте том:
diskutil verifyVolume disk17 # probably it's disk17, disk16 or disk18
Ниже я предполагаю, что идентификатор диска — disk17.
Если семейство логических томов и логический том не отображаются, попробуйте следующее:
Получите обзор (особенно важна команда gpt !):
diskutil list
gpt -r show disk0
Размонтировать диск0:
diskutil umountDisk /dev/disk0
Удалите текущую запись раздела для второго раздела:
gpt remove -i 2 disk0
Добавьте новую «расширенную» запись второго раздела:
gpt add -i 2 -b 409640 -s 488555536 -t 53746F72-6167-11AA-AA11-00306543ECAC disk0
Затем повторите все шаги проверки:
Проверьте диск diskutil verifyDisk disk0
потом.
Введите diskutil cs list
и проверьте, отображаются ли все четыре контейнера CoreStorage: группа логических томов, физический том и семейство логических томов и логический том.
С помощью UUID логического тома смонтируйте LV:
Пример:
+-> Logical Volume 9A7B21AA-F9FE-4E65-8C7E-ED2A73744C15
---------------------------------------------------
Disk: disk17
Status: Online
Затем используйте:
diskutil mount 9A7B21AA-F9FE-4E65-8C7E-ED2A73744C15
Затем, после получения идентификатора диска смонтированного LV, diskutil list
проверьте том:
diskutil verifyVolume disk17 # probably it's disk16, disk17 or disk18
Если вы получаете ошибки, создайте резервную копию данных или всего раздела на внешнем томе, а затем восстановите том с помощью diskutil repairVolume disk17
.
Одной из возможностей резервного копирования данных является dd
. Подключите диск в формате HFS+ со свободным пространством не менее 250 ГБ. Получите путь к внешнему тому с расширением ls /Volumes
. Затем размонтируйте disk17 и disk0 с помощью diskutil umountDisk disk17
и diskutil umountDisk disk0
.
Затем клонируйте раздел в файл:
dd if=/dev/disk0s2 of=/Volumes/ExternalDriveName/disk0s2.rawdevice bs=4m
Если имя тома содержит пробелы, экранируйте пробелы обратной косой чертой: ...of=/Volumes/ExternalDriveName\ With\ Spaces/disk0s2.rawdevice...
.
Вы также можете использовать asr
для восстановления раздела на другой диск (в качестве временной «резервной копии»). Проверить man asr
.
кланомат