Я тут несколько раз жаловался, что в ноутбуке периодически зависает SSD во втором разъеме PCIe (раньше стояли два Samsung SM951 по 120 Гб, потом поставил вторым Samsung 970 EVO Plus на 500 Гб). Пытаясь хоть как-то решить проблему, создал на EVO второй раздел в 120 Гб, скопировал в него раздел системного SM951 с Win 7, и поменял SSD местами, чтобы систама и все рабочее лежали на EVO, а SM951 в проблемном втором разъеме использовать от случая к случаю.
Подобные перестановки-копирования я проделывал десятки раз с самыми разными компьютерами и дисками, и никогда не было особых проблем, но тут нашла коса на камень — за два дня загрузка со второго раздела ни разу не дошла даже до стадии Boot Manager'а — загрузчик VBR во втором разделе EVO стабильно выдает "BOOTMGR is missing".
Уже по десятку раз все проверил:
— Ошибок на томах нет (chkdsk).
— В MBR всех трех дисков (HDD и обоих SSD) лежит один и тот же код, различаются только таблицы разделов, все разделы имеют правильные параметры, сигнатуры дисков разные.
— В VBR всех разделов (один на HDD, два на EVO, один на SM951) тоже лежит один и тот же код (восемь секторов с хвостиком, стандартный для Win 7), различаются только серийные номера томов в областях BPB (серийник на втором разделе EVO я после копирования слегка изменил, чтоб не путался с оригиналом).
— Размер и содержимое файла bootmgr, лежащего в корне второго раздела EVO, полностью совпадают с bootmgr, который остался в корне SM951, который был системным.
И по моему опыту, и по документации, и по сторонним описаниям, там все просто, как мычание — код VBR ищет файл bootmgr в корневом каталоге, затем грузит его в память в реальном режиме, передает управление, а тот уже сам переходит в защищенный 32-разрядный, и достает из себя полноценный PE-загрузчик. То есть, ошибка "BOOTMGR is missing" на исправном томе может возникать только на этапе работы кода VBR, до BCD на этом этапе еще не доходит.
На HDD я недавно положил Win 10 PE, причем сделал это предельно тупо — скопировал в корень ее собственный bootmgr и каталог boot, в котором лежит ее BCD, пометил раздел, как активный, и стандартный семерочный VBR, который изначально лежал на томе HDD, прекрасно грузит десяточный bootmgr. Никаких плясок с bootsect/bootrec не потребовалось, и это ни разу не удивительно.
И VBR на SM951, который переехал из первого разъема во второй, тоже нормально грузит свой bootmgr.
Перечитал хренову гору текстов в интернете — там или банальщина из серии "MBR загружает VBR, тот загружает Boot Manager, тот загружает систему", или дерьмо в стиле "у вас все сломалось, воспользуйтесь утилитами восстановления". Ни малейшего намека на то, где может быть засада, не нашел.
С отчаяния попробовал из-под Win 10 PE "bootsect /nt60" — он записывает в VBR десяточный загрузчик (где-то на килобайт длиннее) — ошибка меняется на "A disk read error occurred". Пробовал класть в корень десяточный bootmgr — без разницы. Добавлял ключ /mbr — он говорит "Successfully updated disk bootcode", но код в MBR не меняется — похоже, он таким и остался с семерки. Возвращаю семерочный загрузчик — снова "BOOTMGR is missing".
Добавил в BCD тома с Win 10 PE на HDD дополнительный OS Loader, задал в device/osdevice кооринаты тома на втором разделе, попробовал загрузить через него — текстовая стадия загрузки прошла, на переходе в графику винда стабильно висла. Способа адекватно проверить, что именно грузит десяточный Boot Manager — семерочный bootmgr, или сразу семерочный winload.exe — я не нашел, а проверять костылями, через переименования/перезагрузки, уже сил не было.
Вернул все обратно, как было — винда нормально грузится с SM951, как и раньше.
У кого-нибудь есть идеи, отчего может обламываться загрузка bootmgr, и куда еще можно посмотреть?
Только не стоит лезть с советами типа "возьми акронис" — я щаз злой, могу обидно послать.
Здравствуйте, m2user, Вы писали:
M>Было ли испправлено значение hidden sectors после перемещении партиции?
Нет — я был уверен, что оно давно не используется. Мелькала мысль попробовать исправить, но я счел это явно абсурдом — поле имело смысл лишь в те времена, когда координаты начала/конца раздела указывались в CHS, а загрузчик нужно было впихнуть в один сектор, так что вычисления туда банально не влезали. После того, как загрузчики стали занимать два сектора и больше, смысл в нем полностью отпал.
Если оно используется до сих пор даже в десяточном коде — это, конечно, полный финиш. И то, что ни одна утилита, которыми я ковырял все эти данные, не исправила, и даже не предупредила — тоже показатель.
Ты помнишь, что BIOS грузит MBR так, что передаёт ей один-единственный параметр — хэндл диска для int 10h — в DL? И что MBR делает то же самое для того VBR, который запускает из активного раздела (по крайней мере, все MBR что я видел — никуда не сохраняют номер раздела, с которого загрузились)?
А теперь вопрос — пусть у тебя установлено две разных NTFS на диск, каждая загрузочная. Как VBR, не имея указания, откуда её запустили, получит, откуда грузить то своё продолжение в виде 8 секторов? Можно тут остановиться и подумать, откуда взять дежурную порцию святого духа для решения этого вопроса.
Я вот порылся и нашёл роспись, что делает VBR. И вот там есть один интересный момент: по 0x001C находится такой 4-байтный параметр, как абсолютный адрес блока, с которого выполнять загрузку хвоста VBR (тех 8 секторов, где уже код чтения NTFS, поиска файла BOOTMGR или ранее NTLDR). Этот параметр должен меняться при установке VBR, чтобы она знала, какую именно FS она грузит. Другого источника этого параметра я не нашёл, всё остальное там одинаково.
Дальше у меня отказывает фантазия, что за проверка могла сработать для защиты от кривой загрузки. Но совпадение VBR у двух загрузочных разделов на одном диске, как я понял из этого, означает, что что-то установлено неверно.
Я таки присоединюсь к советам коллег взять какой-то бутменеджер извне. Acronis, GRUB, кто угодно — по идее они все должны отрабатывать эту ситуацию, грузя BOOTMGR своими силами. Без обид, пожалуйста — но по исходному письму ты как-то явно не докопался до проблемы загрузки и вообще её раньше не представлял себе. (В доке GRUB явно сказано, есть команды: "ntldr /ntldr" для версий раньше 7ки; "ntldr /bootmgr" для версий после.)
Но учти, что у них такая же проблема начального бутстрапа. Её решает EFI, иначе же загрузчику приходится самому это делать, причём в пределах своих ~400 байт после исключения BPB и таблицы разделов. GRUB решает это тем, что собирает в своём загрузочном разделе файл core.img, в него сваливает readonly драйвера FS и прочее что нужно, в него самого пишет его локации на диске, а его локацию пишет в свой VBR. В результате только этот core.img неперемещаемый, остальное может свободно мигрировать. У других загрузчиков свои подходы, но где-то они всё это решают.
(Ну и к тому же у GRUB (+Linux) максимальный упор сейчас на уникальные id файловых систем и GPT разделов, чтобы можно было меньше думать о смещениях.)
Ну или перечитай код VBR и сделай вывод сам. Интересно будет почитать, что ты скажешь про это.
Здравствуйте, Слава, Вы писали:
С>grub поставить? Пускай он винды грузит.
Так винды с любого носителя прекрасно грузит и родной Boot Manager. Она вполне себе начинает грузиться, но почему-то виснет по дороге. Вряд ли grub сможет помочь ей грузиться дальше.
С>нельзя ли всё это в каком-нибудь эмуляторе проэмулировать, с отладчиком?
Долго и муторно. Вот поменял Hidden Sectors (кто бы мог подумать, что он до сих пор используется), попробую на досуге загрузить.
Здравствуйте, netch80, Вы писали:
N>BIOS грузит MBR так, что передаёт ей один-единственный параметр — хэндл диска для int 10h — в DL?
Так для MBR этого достаточно, ничего другого и не нужно.
N>И что MBR делает то же самое для того VBR, который запускает из активного раздела (по крайней мере, все MBR что я видел — никуда не сохраняют номер раздела, с которого загрузились)?
Вроде ж было соглашение о передаче адреса на элемент MBR в DS:SI. Так и похерили его?
N>Я вот порылся и нашёл роспись, что делает VBR.
Я эти исследования видел, хоть и написаны так, что глаза перекашивает. Вдумчиво прочитать такое оформление не осилил, сделал только поиск по "hidden" — не нашел, и уверился в том, что поле Hidden Sectors в BPB давно не используется. Оказалось, что используется, только упомянуто об этом на другой странице.
Я ж еще не поленился посмотреть на другом ноутбуке, где на диске есть несколько первичных разделов — у всех в Hidden Sectors стоит 2048 (0x800). Но там реально загрузочный только первый, на нем семерка с Boot Manager, она и грузит все остальные по выбору. Получается, что при форматировании винда всегда заносит в Hidden Sectors значение 2048, а реальное смещение туда заносит только установщик системы. bootsect, по крайней мере, этого не делает.
Почему они еще 20-30 лет назад не устаканили код MBR с передачей элемента в DS:SI — даже представить не могу.
N>взять какой-то бутменеджер извне
Без крайней нужды — не хочу. Вручную я два дня изгалялся, как хотел, а потом без проблем вернул все взад, ибо знал, что и где менялось. Сторонние утилиты обожают влезать везде, где им удобно, и править под себя так, что потом вычищать замучишься. Нунах.
N>ты как-то явно не докопался до проблемы загрузки и вообще её раньше не представлял себе.
Я в этом копался еще во времена DOS, и загрузчики свои делал, но потом как-то обходился без дизассемблирования. Я ж говорю — много раз таскал диски/разделы туда-сюда, но вот именно ставить первый раздел вторым-четвертым не доводилось.
N>перечитай код VBR и сделай вывод сам. Интересно будет почитать, что ты скажешь про это.
Здравствуйте, Евгений Музыченко, Вы писали:
N>>BIOS грузит MBR так, что передаёт ей один-единственный параметр — хэндл диска для int 10h — в DL?
ЕМ>Так для MBR этого достаточно, ничего другого и не нужно.
Да, если исходить из идеи, которая явно закладывалась при создании всего этого механизма, что не будет одинаковых ОС (и соответственно одного и того же типа раздела в PT) в пределах одного диска.
И вот именно это и не выполняется в твоём случае. И вообще было достаточно быстро нарушено.
N>>И что MBR делает то же самое для того VBR, который запускает из активного раздела (по крайней мере, все MBR что я видел — никуда не сохраняют номер раздела, с которого загрузились)? ЕМ>Вроде ж было соглашение о передаче адреса на элемент MBR в DS:SI. Так и похерили его?
Я в RBIL ничего такого не вижу.
N>>Я вот порылся и нашёл роспись, что делает VBR.
ЕМ>Я эти исследования видел, хоть- и написаны так, что глаза перекашивает. Вдумчиво прочитать такое оформление не осилил, сделал только поиск по "hidden" — не нашел, и уверился в том, что поле Hidden Sectors в BPB давно не используется. Оказалось, что используется, только упомянуто об этом на другой странице.
Да, по крайней мере вики по BPB продолжает называть это "hidden sectors", хотя они давно другое. А раздел по NTFS вообще не упоминает этого параметра. Недоработали.
ЕМ>Я ж еще не поленился посмотреть на другом ноутбуке, где на диске есть несколько первичных разделов — у всех в Hidden Sectors стоит 2048 (0x800). Но там реально загрузочный только первый, на нем семерка с Boot Manager, она и грузит все остальные по выбору. Получается, что при форматировании винда всегда заносит в Hidden Sectors значение 2048, а реальное смещение туда заносит только установщик системы. bootsect, по крайней мере, этого не делает.
Мне сравнить не с чем. Но, похоже, ты прав.
Но мне всё равно непонятно другое. Если у тебя VBR1 второго раздела грузил с того же смещения VBR2-9 первого раздела, почему всё-таки "BOOTMGR is missing"? Наверняка ж последующий код нашёл, что что-то не так. Это он уже заметил расхождение?
ЕМ>Почему они еще 20-30 лет назад не устаканили код MBR с передачей элемента в DS:SI — даже представить не могу.
А зачем сразу два DS:SI? Я больше ожидал бы просто один числовой параметр, от 1 до 4. Всё равно MBR умеет грузить только с первых 4 разделов.
N>>перечитай код VBR и сделай вывод сам. Интересно будет почитать, что ты скажешь про это. ЕМ>Что про это можно сказать, кроме "ужас-ужас"?
Да ну, он для своей цели вполне оптимален. Там много не нужно, только подкачать кусок с известной локации и запустить его. Дальше уже работает другая часть кода.
Здравствуйте, Евгений Музыченко, Вы писали:
N>>взять какой-то бутменеджер извне
ЕМ>Без крайней нужды — не хочу. Вручную я два дня изгалялся, как хотел, а потом без проблем вернул все взад, ибо знал, что и где менялось. Сторонние утилиты обожают влезать везде, где им удобно, и править под себя так, что потом вычищать замучишься. Нунах.
Вдогонку, вот с GRUB такого нет. Всё что ему нужно это 1) каталог в котором создастся фиксированный подкаталог /grub, куда класть текстовый конфиг и где он создаст кроме прочего один неперемещаемый файл, и 2) один сектор на диске, лучше в MBR (всё равно стандартную MBR можно взять откуда угодно). Не понравится — просто возвращаешь стандартную MBR.
Здравствуйте, netch80, Вы писали:
N>если исходить из идеи, которая явно закладывалась при создании всего этого механизма, что не будет одинаковых ОС (и соответственно одного и того же типа раздела в PT) в пределах одного диска.
Не понял, при чем тут одинаковость ОС и/или типа раздела. Единственное, что нужно VBR для загрузки — это адрес начала раздела, он есть в PTE. Ничто не мешает держать в четырех разделах четыре системы одного типа.
N>Если у тебя VBR1 второго раздела грузил с того же смещения VBR2-9 первого раздела, почему всё-таки "BOOTMGR is missing"?
А вот ХЗ. Похоже, там все сшито на живую нитку, и давно уже правится чисто интуитивно. У них ведь и disk read error выдается, если не обнаружена сигнатура NTFS — при чем тут ошибка чтения? Логичнее было бы выдавать сообщения вида "ошибка N" — преобразовать одну цифру в символ проще простого, это позволило бы точнее отображать проблемы, а за счет длинных сообщений освободилось бы место для кода.
N>А зачем сразу два DS:SI?
Почему два? Фактически это один SI, DS предполагается нулевым.
N>Я больше ожидал бы просто один числовой параметр, от 1 до 4.
Ну хорошо — пуст код в MBR, где и так места нет, преобразует адрес PTE в номер, и передаст его VBR. Что с этим номером делать дальше? Адрес, по которому лежит PT, VBR неизвестен. Читать MBR снова? А затем преобразовывать номер обратно в адрес PTE, чтобы достать оттуда смещение? Это точно будет проще и надежнее, чем передача непосредственно адреса PTE?
Здравствуйте, netch80, Вы писали:
N>с GRUB такого нет. Всё что ему нужно это 1) каталог в котором создастся фиксированный подкаталог /grub, куда класть текстовый конфиг и где он создаст кроме прочего один неперемещаемый файл
Который может не дать мне, в случае чего, сжать раздел произвольным образом. То есть, недостаток виден сразу. А достоинства?
Здравствуйте, Евгений Музыченко, Вы писали:
N>>если исходить из идеи, которая явно закладывалась при создании всего этого механизма, что не будет одинаковых ОС (и соответственно одного и того же типа раздела в PT) в пределах одного диска. ЕМ>Не понял, при чем тут одинаковость ОС и/или типа раздела. Единственное, что нужно VBR для загрузки — это адрес начала раздела, он есть в PTE. Ничто не мешает держать в четырех разделах четыре системы одного типа.
И ещё раз: если механизм рассчитан на то, что все PTE type разные, то ОС сама разберётся, с чего ей грузиться. А если PTE одинаковые, то нужен как минимум номер того, с чего MBR взял эту конкретную VBR.
N>>Я больше ожидал бы просто один числовой параметр, от 1 до 4. ЕМ>Ну хорошо — пуст код в MBR, где и так места нет,
Эээ там места более чем достаточно, во всяком случае, команда записать одно число в память — хватит на неё места. Стандартный код типа "перечитать главную PT и дёрнуть один раз read" — пусть даже с поиском, поддерживаются ли LBA extensions — занимает меньше половины от 512 байт. Вот сейчас взял первое доступное под рукой — MBR от DOS 6.20 — последний байт кода это 0x113, и это уже после кода подробных сообщений об ошибках. Точно хватит на ещё 3 байта сохранить что-то в память
EM> преобразует адрес PTE в номер, и передаст его VBR. Что с этим номером делать дальше? Адрес, по которому лежит PT, VBR неизвестен. Читать MBR снова? А затем преобразовывать номер обратно в адрес PTE, чтобы достать оттуда смещение? Это точно будет проще и надежнее, чем передача непосредственно адреса PTE?
Это будет минимум информации, от которого хотя бы можно было бы плясать.
А дальше расширять можно сколько угодно.
Да, можно, например, передать смещение в пределах сектора. Или 0x7C00 плюс оно же.
Или скопировать эти 16 байт в фиксированные адреса (у нас же перед 0x7C00 дохрена места всё равно, и оно гарантированно присутствует? Что нам мешает записать туда кусочек? Или после, начиная с 0x7E00?)
Да что угодно. Я говорил про твёрдый минимум, от которого можно крутить.
Фрёвый boot1, кстати, идёт тут по длинному пути. Он снова читает MBR и дальше применяет такую логику: выбирает первый раздел тип=0xA5 и активный. Если такого нет, выбирает просто первый из тип=0xA5. И дальше от этой точки уже делает похожее на то, что делается в NT: читает 8KB и передаёт управление на следующий шаг, называемый boot2. boot2 способен читать /boot.config с раздела 'a' найденного слайса (это partition в схеме MS-DOS), ждать ввода с консоли, разбирать его и если не изменено — применять тот boot.config или умолчание (/boot/loader). /boot/loader, наконец, серьёзная машина, в которую можно хоть тетрис загнать, но обычно делают небольшое меню режимов. И только после этого он уже грузит ядро.
Ну это всё я к тому, что снова прочитать MBR (LBA=0) это, в общем-то, совсем не проблема. В 512 байт это всё снова влезает даже с затратами на BPB.
N>>Если у тебя VBR1 второго раздела грузил с того же смещения VBR2-9 первого раздела, почему всё-таки "BOOTMGR is missing"?
ЕМ>А вот ХЗ. Похоже, там все сшито на живую нитку, и давно уже правится чисто интуитивно. У них ведь и disk read error выдается, если не обнаружена сигнатура NTFS — при чем тут ошибка чтения? Логичнее было бы выдавать сообщения вида "ошибка N" — преобразовать одну цифру в символ проще простого, это позволило бы точнее отображать проблемы, а за счет длинных сообщений освободилось бы место для кода.
Тут полностью согласен. Если бы задача была критичной для меня, я бы посмотрел в то, что у них в этом "boot sector", точнее, 16 секторах, наворочено... тот же thestarman обломился это разбирать детально. Но у меня точно сейчас такой задачи не стоит.
Здравствуйте, Евгений Музыченко, Вы писали:
N>>с GRUB такого нет. Всё что ему нужно это 1) каталог в котором создастся фиксированный подкаталог /grub, куда класть текстовый конфиг и где он создаст кроме прочего один неперемещаемый файл
ЕМ>Который может не дать мне, в случае чего, сжать раздел произвольным образом.
Ты сжимаешь "произвольным образом" загрузочный раздел?
Ладно, я понимаю, случай он всякий бывает
Вообще выделить по такому случаю один раздел мегабайт на 20 на таких объёмах, как у тебя, не составляет труда. Загнать его в логические разделы в конец списка, чтобы не мешался под ногами у загрузчика NT. (Я говорю про 20, потому что у меня сейчас там 12. Но вообще-то du на /boot/grub/i386-pc показал 2.5MB. Остальное — разные картинки и фонты для убунты, и мусор от моих экспериментов.)
EM> То есть, недостаток виден сразу. А достоинства?
Более умный, чем у стандартных загрузчиков, поиск, с чего грузиться, по меткам и uuidʼам. Как бы диски не перекомпоновывались — он найдёт.
В загрузчике можно войти в командный режим, в котором делать что угодно. Изучить доступные диски и FS. Загрузиться вообще с места, непредусмотренного конфигом. Исправить любые опции запуска. Если есть хоть минимальные познания в его командах — остаться без возможности загрузиться хотя бы в аварийном режиме — это надо очень "постараться".
Если же это не нужно, то загрузочное меню с выбором, с чего грузиться сейчас, с таймаутом, ну и со всем умным поиском, как выше описал.
Здравствуйте, netch80, Вы писали:
N>если механизм рассчитан на то, что все PTE type разные, то ОС сама разберётся, с чего ей грузиться.
Этот "механизм", судя по всему, из того анекдота про обезьяну и математика, который "свел задачу к уже известной".
N>А если PTE одинаковые, то нужен как минимум номер того, с чего MBR взял эту конкретную VBR.
Ну да, вместо того, чтобы тупо передать VBR адрес выбранной PTE, нужно заставить VBR еще раз прочитать MBR, еще раз перебрать все PTE, и при этом еще и не иметь возможности надежно определить, через которую из них его вызвали. Гениально, чо.
N>там места более чем достаточно
Где "там" — в MBR? Покажите пальцем на то место.
N>во всяком случае, команда записать одно число в память — хватит на неё места.
Откуда брать число? Стандартный код MBR использует указатель на PTE и счетчик оставшихся PTE. Номер PTE придется вычислять из них, а это не одна команда.
N>Стандартный код типа "перечитать главную PT и дёрнуть один раз read"
Зачем делать еще раз то, что уже сделано?
N>взял первое доступное под рукой — MBR от DOS 6.20 — последний байт кода это 0x113, и это уже после кода подробных сообщений об ошибках.
В коде MBR от NT всего несколько свободных байт. Я не вникал предметно, чего они туда напихали, но правильнее всего было бы еще в 80-е устаканить передачу адреса PTE. Из него, при желании, код VBR мог бы вычислить адрес начала MBR в памяти, чтобы взять оттуда, например, сигнатуру диска.
N>Это будет минимум информации, от которого хотя бы можно было бы плясать.
Для чего может быть нужно искусственно уменьшать количество передаваемой информации?
N>А дальше расширять можно сколько угодно.
Сперва сузить, а затем героически расширять?
N>можно, например, передать смещение в пределах сектора.
Тогда нужно знать еще адрес начала сектора. Снова искусственное сужение.
N>Или скопировать эти 16 байт в фиксированные адреса
И снова потерять информацию. На этот раз — позицию PTE в таблице. Такое впечатление, что Вам непременно хочется что-нибудь похерить или скрыть.
N>Фрёвый boot1, кстати, идёт тут по длинному пути. Он снова читает MBR и дальше применяет такую логику: выбирает первый раздел тип=0xA5 и активный. Если такого нет, выбирает просто первый из тип=0xA5.
То есть, героически пытается преодолеть последствия чьего-то крайнего идиотизма.
N>снова прочитать MBR (LBA=0) это, в общем-то, совсем не проблема.
Ее и десять раз прочитать не проблема. Только при таком подходе однажды внезапно выясняется, что какой-то софт 100500 раз читает одно и то же значение из реестра. Когда-то читали трижды — проблемы не было, затем стали читать двадцать раз — ее все еще не было, а потом вдруг появилась.
Здравствуйте, netch80, Вы писали:
N>Ты сжимаешь "произвольным образом" загрузочный раздел?
Я любые сжимаю, если надо. Какая разница, загрузочный или нет? Времена VBR из одного сектора, который даже FAT16 толком разобрать не мог, вроде как прошли.
N>выделить по такому случаю один раздел мегабайт на 20 на таких объёмах, как у тебя, не составляет труда.
Не составит, но зачем?
N>Более умный, чем у стандартных загрузчиков, поиск, с чего грузиться, по меткам и uuidʼам. Как бы диски не перекомпоновывались — он найдёт.
Я ж не собираюсь переставлять диски раз в неделю. Я б этим вообще не занимался, но заниматься поиском нового ноутбука, с последующим переходом на десятку, будет сильно геморройнее.
N>Если есть хоть минимальные познания в его командах — остаться без возможности загрузиться хотя бы в аварийном режиме — это надо очень "постараться".
Для аварийного режима у меня Win PE на HDD и загрузочная флешка с нею же.
Здравствуйте, Евгений Музыченко, Вы писали:
N>>если механизм рассчитан на то, что все PTE type разные, то ОС сама разберётся, с чего ей грузиться. ЕМ>Этот "механизм", судя по всему, из того анекдота про обезьяну и математика, который "свел задачу к уже известной".
Тем не менее MBR в виде загрузчика и таблицы разделов были рассчитаны именно на это.
N>>А если PTE одинаковые, то нужен как минимум номер того, с чего MBR взял эту конкретную VBR. ЕМ>Ну да, вместо того, чтобы тупо передать VBR адрес выбранной PTE, нужно заставить VBR еще раз прочитать MBR, еще раз перебрать все PTE, и при этом еще и не иметь возможности надежно определить, через которую из них его вызвали. Гениально, чо.
Во-первых, надёжно определить таки легко, если индекс передан.
Во-вторых, на этом этапе одно чтение одного блока это, откровенно, фигня.
Но я не понимаю, о чём мы спорим. Я сказал, что любой вариант устраивает, хоть 2 бита хоть полные 16 байт из master PT. Лишь бы работал.
Ты, кстати, так и не сказал, что именно в тех DS:SI содержалось и куда они писались, по тому якобы когда-то придуманному (кем? когда? что с ним случилось?) стандарту, следов которого я не нахожу даже в RBIL, где записаны любые кем-то когда-то однажды придуманные хрени.
N>>взял первое доступное под рукой — MBR от DOS 6.20 — последний байт кода это 0x113, и это уже после кода подробных сообщений об ошибках. ЕМ>В коде MBR от NT всего несколько свободных байт.
Я посмотрел по этому. Во-первых, там длинные тексты ошибок. Ты сам говорил, что числовые коды проще и достаточны. Во-вторых, у них ушло аж 70 байт на вызовы TCG, которые вообще не нужны в MBR и в VBR. Никто больше на этом этапе это не делает. Можно было вложить это спокойно в те 16 блоков, которые они назвали "Boot Sector", или вообще в NTLDR/BOOTMGR.
Теперь сравним. Вот тебе пример. Если посмотреть на скомпилированный вариант, филлер перед PT начинается с адреса 0x109. Тебе 150 байт хватит чтобы вставить код сохранения этих данных?FreeBSDʼшный вариант в тех же 512 ещё и умудрился делать CHS вызов, если LBA extensions не нашлись. Виндовый даже при фиксации на LBA-only дико толстый. Это уже настолько неэкономное программирование, что можно его назвать чистым ламерством.
EM> Я не вникал предметно, чего они туда напихали, но правильнее всего было бы еще в 80-е устаканить передачу адреса PTE. Из него, при желании, код VBR мог бы вычислить адрес начала MBR в памяти, чтобы взять оттуда, например, сигнатуру диска.
Полностью согласен. Но поезд ушёл, а сейчас его груз уже не нужен.
[skip бессмысленные спекуляции об объёме вытащенной информации]
N>>снова прочитать MBR (LBA=0) это, в общем-то, совсем не проблема.
ЕМ>Ее и десять раз прочитать не проблема. Только при таком подходе однажды внезапно выясняется, что какой-то софт 100500 раз читает одно и то же значение из реестра. Когда-то читали трижды — проблемы не было, затем стали читать двадцать раз — ее все еще не было, а потом вдруг появилась.
Я не вижу, где тут может быть переход от 2 (3, если учесть, что детектор геометрии уже в запущенном ядре прочитает таблицу разделов) к 100500.
Здравствуйте, netch80, Вы писали:
N>MBR в виде загрузчика и таблицы разделов были рассчитаны именно на это.
Из чего это следует?
N>я не понимаю, о чём мы спорим
На мой взгляд — о том, что можно сделать одновременно просто, удобно и надежно, а можно — извращенно.
N>что именно в тех DS:SI содержалось
Адрес PTE из загруженной в память MBR.
N>куда они писались
Кто "они"? регистры DS:SI?
N>по тому якобы когда-то придуманному (кем? когда? что с ним случилось?) стандарту, следов которого я не нахожу даже в RBIL, где записаны любые кем-то когда-то однажды придуманные хрени.
Но вот на всех моих дисках код MBR откровенно странен — он использует для адресации PTE только BP, хотя традиционно этот регистр предполагается относительно неизменным, и использовать его в качестве регулярно изменяемого указателя — очень своеобразная идея. Обычно такое делается только в условиях жесткой нехватки регистров, но это явно не тот случай. В общем, альтернативно одаренные писали.
N>там длинные тексты ошибок. Ты сам говорил, что числовые коды проще и достаточны.
Так то ж я говорил, а Вы хоть раз видели MBR/VBR с числовыми кодами? Я — ни разу. Серость и примитив преобладают.
N>Виндовый даже при фиксации на LBA-only дико толстый. Это уже настолько неэкономное программирование, что можно его назвать чистым ламерством.
Ламерство и есть.
N>Я не вижу, где тут может быть переход от 2 (3, если учесть, что детектор геометрии уже в запущенном ядре прочитает таблицу разделов) к 100500.
От MBR/VBR до запущенного ядра очень далеко — сохранять копию прочитанной MBR между сменой режимов может быть геморройно. А MBR вызывает непосредственно VBR, поэтому и передать туда уже прочитанную MBR — наиболее адекватное решение.
ЕМ>Если оно используется до сих пор даже в десяточном коде — это, конечно, полный финиш. И то, что ни одна утилита, которыми я ковырял все эти данные, не исправила, и даже не предупредила — тоже показатель.
Я не знаю. используется ли оно в win10.
Просто запомнил ещё со времен NT 5.1, что при перемещении или смещении начала загрузочного ntfs раздела нужно поправить hex-редактором в нём некий offset. Иначе с него не загрузиться.
Здравствуйте, m2user, Вы писали:
M>Просто запомнил ещё со времен NT 5.1, что при перемещении или смещении начала загрузочного ntfs раздела нужно поправить hex-редактором в нём некий offset.
Я, как уже говорил, помнил это во времена досов, но потом как-то незаметно забыл, будучи в полной уверенности, что долго такое убожество продолжаться не должно. Был неправ.
Пробовал класть в корень десяточный bootmgr — без разницы. Добавлял ключ /mbr — он говорит "Successfully updated disk bootcode", но код в MBR не меняется — похоже, он таким и остался с семерки. Возвращаю семерочный загрузчик — снова "BOOTMGR is missing". 
И то, что ни одна утилита, которыми я ковырял все эти данные, не исправила, и даже не предупредила — тоже показатель. 
