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


4

Я следовал руководству по созданию двойной загрузки с macOS Sierra 10.12 и Kali-Linux 2.0.

Я создал загрузочный USB-накопитель и загрузился в сеансе Kali-Linux Live, чтобы использовать 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 фото)

Я не ожидал результата Дискутила. Столько разделов нормально?

Edit2 :

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

Терминал 2

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

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


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

Ответы:


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.


Когда я использовал diskutil verifyDisk, меня предупреждали об ошибках, которые могут помешать загрузке. Я попытался загрузиться, и это не работает (но у меня есть mBPR сейчас). Но список diskutil cs дает мне одну логическую группу томов, а под ней - только один физический том. У меня нет четырех томов
М. Озн

Я потерял свои данные?
М. Озн

Хорошо, я вернусь все 4 тома. Затем я сделал монтирование, все работало замечательно, но последний дисктул verifyVolume дал мне ошибки, я обновляю свой первый пост
M. Ozn

Я отредактировал свой первый пост
М.Озн

1
@bmike Спасибо! ;-) Я думаю, что это общая проблема здесь. Это порог между «личным» устранением неисправностей и более или менее общим ответом на более или менее общий вопрос. Я думаю, что, по крайней мере, у Дэвида Андерсона та же проблема со всеми его слегка отличающимися вопросами Boot Camp. Я все еще думаю о публикации вопроса в мета-адрес. Еще одним хорошим примером является этот вопрос: Ошибка раздела BootCamp !! Помогите. Удаленный раздел EFI . Я мог решить это только через TeamViewer.
klanomath
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.