Поврежденный раздел macOS после GParted

Я следовал руководству по созданию двойной загрузки с 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 :

Вот другой экран, который у меня был после команд записи:

Терминал 2

Редактировать 3

Последняя проверка

Вы установили rEFInd?

Ответы (1)

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.

Когда я использовал diskutil verifyDisk, меня предупреждали об ошибках, которые могут помешать загрузке. Я попытался загрузиться, и это не работает (но теперь у меня есть mBPR). Но список diskutil cs дает мне одну логическую группу томов, а под ней только один физический том. у меня нет четырех томов
Я потерял свои данные?
Хорошо, я верну все 4 тома. Потом сделал монтирование, все отлично заработало, но последний diskutil verifyVolume выдал ошибки, обновляю свой первый пост
я отредактировал свой первый пост
Как я могу сделать резервную копию? Если я восстановлю его с помощью этой команды, я потеряю свои данные?
Да, но если я клонирую поврежденную часть, я сделаю резервную копию поврежденных данных, нет?
Я не могу удалить свои комментарии... Как я могу их клонировать?
Большое спасибо за ваше терпение и все ваши ответы, я действительно ценю всю вашу работу.
Я не понимаю, почему, потому что я получил ошибку во время проверки тома, но я мог загрузиться на Mac OS !!! БОЛЬШОЕ СПАСИБО !
@MaximeOzenne Он загрузится - это не проблема. Однако некоторые внутренние данные структуры тома повреждены или ложны. Это должно быть исправлено перед использованием тома!
Я смог использовать дисковую утилиту, я использовал помощника SOS, и он сказал, что MACintosh HD поврежден. Я перезагрузился в рекавери и снова и снова использовал SOS-помощник, пока он не сказал мне, что диск в порядке. Наконец, я запускаю терминал и использую список diskutil cs, чтобы получить идентификатор диска LV (это был disk1), затем я запускаю diskutil verifyVolume disk1. Наконец-то я был рад видеть, что мой LV отремонтирован! мой mac теперь отлично работает! Огромное спасибо за всю вашу помощь, вы спасли меня!!
Меня всегда ошеломляет, когда у такого длинного ответа есть один и только один человек, который готов +1 — однако, ОП, отметивший отвеченный чек, является самым удивительным — это намного лучше для сайта в целом.
@bmike Спасибо! ;-) Я думаю, что это общая проблема. Это порог между «личным» устранением неполадок и более или менее общим ответом на более или менее общий вопрос. Я думаю, по крайней мере, у Дэвида Андерсона та же проблема со всеми его немного другими вопросами и ответами Boot Camp. Я все еще думаю о том, чтобы опубликовать вопрос в мета-адресе по этому поводу. Другим хорошим примером является этот вопрос: Ошибка раздела BootCamp!! Помощь. Удалил раздел EFI . Решил только через TeamViewer.
ваши советы будут оценены apple.stackexchange.com/questions/296151/…