Здравствуйте, Евгений Музыченко, Вы писали:

Послушал я твои мучения...

Ты помнишь, что BIOS грузит MBR так, что передаёт ей один-единственный параметр — хэндл диска для int 10h — в DL? И что MBR делает то же самое для того VBR, который запускает из активного раздела (по крайней мере, все MBR что я видел — никуда не сохраняют номер раздела, с которого загрузились)?

А теперь вопрос — пусть у тебя установлено две разных NTFS на диск, каждая загрузочная. Как VBR, не имея указания, откуда её запустили, получит, откуда грузить то своё продолжение в виде 8 секторов? Можно тут остановиться и подумать, откуда взять дежурную порцию святого духа для решения этого вопроса.

Я вот порылся и нашёл роспись, что делает VBR. И вот там есть один интересный момент: по 0x012D находится (внутри команды PUSH) такой 4-байтный параметр, как абсолютный адрес блока, с которого выполнять загрузку хвоста MBR. Этот параметр должен меняться при установке VBR, чтобы она знала, какую именно FS она грузит. Другого источника этого параметра я не нашёл, всё остальное там одинаково.

Дальше у меня отказывает фантазия, что за проверка могла сработать для защиты от кривой загрузки. Но совпадение VBR у двух загрузочных разделов на одном диске, как я понял из этого, означает, что что-то установлено неверно.

Я таки присоединюсь к советам коллег взять какой-то бутменеджер извне, не обижайся. Acronis, GRUB, кто угодно — по идее они все должны отрабатывать эту ситуацию, грузя BOOTMGR своими силами. Без обид, пожалуйста — но по исходному письму ты как-то явно не докопался до проблемы загрузки и вообще её раньше не представлял себе.

Но учти, что у них такая же проблема начального бутстрапа. Её решает EFI, иначе же загрузчику приходится самому это делать, причём в пределах своих ~400 байт после исключения BPB и таблицы разделов. GRUB решает это тем, что собирает в своём загрузочном разделе файл core.img, в него сваливает readonly драйвера FS и прочее что нужно, в него самого пишет его локации на диске, а его локацию пишет в свой VBR. В результате только этот core.img неперемещаемый, остальное может свободно мигрировать. У других загрузчиков свои подходы, но где-то они всё это решают.

Ну или перечитай код VBR и сделай вывод сам. Интересно будет почитать, что ты скажешь про это.

Здравствуйте, Евгений Музыченко, Вы писали:

Послушал я твои мучения...

Ты помнишь, что BIOS грузит MBR так, что передаёт ей один-единственный параметр — хэндл диска для int 10h — в DL? И что MBR делает то же самое для того VBR, который запускает из активного раздела (по крайней мере, все MBR что я видел — никуда не сохраняют номер раздела, с которого загрузились)?

А теперь вопрос — пусть у тебя установлено две разных NTFS на диск, каждая загрузочная. Как VBR, не имея указания, откуда её запустили, получит, откуда грузить то своё продолжение в виде 8 секторов? Можно тут остановиться и подумать, откуда взять дежурную порцию святого духа для решения этого вопроса.

Я вот порылся и нашёл роспись, что делает VBR. И вот там есть один интересный момент: по 0x001C находится такой 4-байтный параметр, как абсолютный адрес блока, с которого выполнять загрузку хвоста MBR. Этот параметр должен меняться при установке VBR, чтобы она знала, какую именно FS она грузит. Другого источника этого параметра я не нашёл, всё остальное там одинаково.

Дальше у меня отказывает фантазия, что за проверка могла сработать для защиты от кривой загрузки. Но совпадение VBR у двух загрузочных разделов на одном диске, как я понял из этого, означает, что что-то установлено неверно.

Я таки присоединюсь к советам коллег взять какой-то бутменеджер извне, не обижайся. Acronis, GRUB, кто угодно — по идее они все должны отрабатывать эту ситуацию, грузя BOOTMGR своими силами. Без обид, пожалуйста — но по исходному письму ты как-то явно не докопался до проблемы загрузки и вообще её раньше не представлял себе.

Но учти, что у них такая же проблема начального бутстрапа. Её решает EFI, иначе же загрузчику приходится самому это делать, причём в пределах своих ~400 байт после исключения BPB и таблицы разделов. GRUB решает это тем, что собирает в своём загрузочном разделе файл core.img, в него сваливает readonly драйвера FS и прочее что нужно, в него самого пишет его локации на диске, а его локацию пишет в свой VBR. В результате только этот core.img неперемещаемый, остальное может свободно мигрировать. У других загрузчиков свои подходы, но где-то они всё это решают.

Ну или перечитай код VBR и сделай вывод сам. Интересно будет почитать, что ты скажешь про это.