Исправление загрузки раздела Windows с помощью инструментов OS X

На моем Mac Book Pro начала 2013 года установлена ​​система тройной загрузки: OS X, Windows 7 и Ubuntu. Я использую rEFInd в качестве менеджера загрузки. Моя установка Windows загружается с использованием устаревшей загрузки BIOS, а OS X и Ubuntu загружаются с собственной загрузкой EFI.

Все работало, пока я не обновился до OS X Yosemite. Это сломало мою Windows:

"Нет загрузочного устройства вставьте загрузочный диск и нажмите любую кнопку"

Думаю, мне следовало сделать резервную копию загрузочного сектора перед обновлением, но теперь уже слишком поздно! Поскольку Windows загружается в режиме BIOS, она считывает гибридную MBR, и действительно, раздел Windows не был помечен как загрузочный. После того, как я пометил его как загрузочный с помощью fdisk, сообщение изменилось на:

"Отсутствует операционная система"

Я проверил MBR с помощью fdisk и GPT с gdisk, и они действительно совместимы и синхронизированы. После нескольких часов гугления и перепробования всего я наконец понял, в чем проблема:

Несколькими неделями ранее я изменил размер раздела Windows, уменьшив раздел OS X в OS X, а затем, используя определенное программное обеспечение Windows, увеличив раздел Windows, чтобы разместить новое свободное пространство, которое теперь находилось перед разделом Windows . Теперь кажется, что эта программа обновила ТОЛЬКО MBR: с точки зрения GPT перед разделом Windows есть нераспределенное пространство, а с точки зрения MBR это пространство используется Windows.

Однако при установке Yosemite он синхронизировал гибридную MBR в соответствии с GPT, пометив верхнюю часть раздела Windows как свободное место. Это «свободное место», конечно же, содержит загрузчик Windows и кучу данных!

Мой вопрос: есть ли способ просканировать, казалось бы, неразмеченную часть диска и определить первый сектор раздела Windows? Я думаю, что это возможно, но мне нужны правильные инструменты для этого.

Для информации, вот мои данные GPT:

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40          409639   200.0 MiB   EF00  EFI System Partition
   2          409640       731723959   348.7 GiB   AF05  Macintosh HD
   3       731723960       732993495   619.9 MiB   AB00  Recovery HD
   4       799528960       906948607   51.2 GiB    0700  WINDOWS 1
   5       906948608       977104895   33.5 GiB    0700  UBUNTU

и данные защитной/гибридной MBR:

 #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
 1: EE 1023 254  63 - 1023 254  63 [         1 -     409639] <Unknown ID>
 2: AC 1023 254  63 - 1023 254  63 [    409640 -  731314320] <Unknown ID>
 3: AB 1023 254  63 - 1023 254  63 [ 731723960 -    1269536] Darwin Boot 
*4: 0C 1023 254  63 - 1023 254  63 [ 732993496 -  173955112] Win95 FAT32L

Обратите внимание, что перед разделом Windows размером 51,2 ГиБ есть сектор 66535465, 31,7 ГиБ. Когда Windows работала, она видела свой раздел размером примерно 80 ГиБ. Таким образом, «настоящее» начало этого раздела Windows находится где-то внутри этого промежутка. Как его отсканировать?

Интересно, существуют ли какие-нибудь магические числа или что-то в этом роде, которые указывали бы на начало раздела Windows. Тогда можно было бы просканировать этот диапазон секторов на наличие такого бинарного файла.
Не ответ, но я копался вокруг, задаваясь вопросом, будет ли полезен iPartition, и обнаружил, что «Версии 3 и выше iPartition будут нормально работать с Windows, однако ни при каких обстоятельствах вы не должны пытаться манипулировать своими дисками из диспетчера дисков Windows. оснастки или из программы установки Windows. Это приведет к поломке диска, что, скорее всего, приведет к повреждению данных; если вы сделаете это, есть большая вероятность, что вам придется переустанавливать все на вашем компьютере, чтобы избежать риска будущей потери данных».
Я столкнулся с подобной проблемой без изменения размера раздела в Windows! У меня двойная загрузка, и я освободил место в первом разделе (OS X), сделал третий раздел между первым и вторым (WIN 7) и отформатировал его в FAT. Теперь он больше не будет загружаться из Windows.

Ответы (1)

Я опубликую это как ответ, хотя это не решило мою проблему - в конце концов, это был проигранный случай. Последствия: я сделал резервную копию раздела Windows в моем разделе OS X:

sudo dd bs=512 if=/dev/disk0 of=windows_backup skip=732993496 count=173955112

Теперь у меня был 80-гигабайтный шестнадцатеричный дамп, который я мог безопасно изучить. Я использовал шестнадцатеричный редактор для поиска всех видов метаданных:

  • «NTFS» (в кодировке ASCII), которая запускает том NTFS.
  • «ФАЙЛ» (закодированный в ASCII), который запускает запись записи файла в $MFT или основной таблице файлов в NTFS.
  • Имена системных файлов NTFS (например, «MFT», пробовали с прямым порядком байтов UTF-16 и ASCII)

... и так далее. Но безуспешно. Мне удалось найти все виды данных из дампа, но все метаданные, включая загрузочную запись (первый сектор тома), файл $Boot (первые 15 секторов после загрузочной записи), файл $MFT который ведет учет всех файлов в файловой системе, исчезли.

Меня сбивает с толку то, что я даже не смог найти файл $MFTMirr, который является файлом резервной копии файлов метаданных и хранится на половине объема.

Мне удалось найти резервную копию загрузочного сектора из его стандартного расположения, последнего сектора тома. Однако данные были старые, из эпохи до изменения размера тома. Загрузочный сектор сохранил смещение файла метаданных $MFT, но проверять ссылки было спорно, там не было ничего ценного.

В конце концов, я пришел к выводу, что том был полностью забит. Мораль истории? Гибридная мастер-загрузочная запись — это зло. Кроме того, кажется, что программа, которая изменила размер тома, выполнила работу не на должном уровне, не сумев обновить некоторые метаданные.

На случай, если другие столкнутся с этим: моя статья может дать больше информации: blog.tempel.org/2017/07/recover-lost-bootcamp-windows.html