OSDev

В этом случае будет выдана ошибка "No boot sector found".


MBR не проверяет тип загруженного сектора. Он только загружает первый сектор раздела, проверяет сигнатуру, а дальше загруженный сектор сам разбирается со своим разделом. MBR повесится корректно распознавать и обрабатывать все известные на сегодня типы разделов.


При таком подходе можно дойти до того, что проверять на принадлежность к "своим" даже загрузочный код самой файловой системы. Считаю такую проверку излишней по следующим причинам:
MBR не должен проверять, что он грузит, кроме предписанной общими правилами проверки - сигнатуры 0AA55h. Иначе вероятны неприятности с разделами, о которых MBR и понятия не имеет - NTFS, EXT2/3 и множество других, которые он, тем не менее, мог бы преспокойно загрузить.
EBR также не должен излишне заостряться на проверках. Во-первых, по той причине, что загрузкой с расширенных разделов вообще мало кто занимается, - большинство систем считают эту задачу излишней, во вторых, потому что результат всё равно один - "загрузочный сектор не найден". В-третьих, потому что даже корректной записи MBR+EBR, как ни странно, недостаточно для нормальной загрузки с логического диска.
Нормальную загрузку должна обеспечивать внешняя программа подготовки и форматирования диска. В моём случае это boot.exe (подготовка). Её применение гарантирует корректность всей цепочки.


Да в общем-то, все, или почти все MBR могут передать управление EBR. Не делают этого только по той причине, что ни одна мало-мальски популярная программа управления дисками не даст пометить расширенный раздел в качестве активного, разве что только в режиме низкоуровневого редактирования, но это, как говорится, "сам дурак".


Мне думается, не очень хорошая мысль. Это накладывает дополнительные ограничения на MBR по проверке загруженных данных на некоторую уникальную ситуацию и обязательство предпринимать уникальные действия в этой ситуации. Причём проверка должна быть независима от версий обоих загрузчиков. Более красивое решение - унифицировать поведение MBR, так чтобы ему было без разницы, какой именно код он загрузил, важно, что это загрузочный код.


Предполагаю, что проверка в данном случае излишня (см выше), а вот общий стандарт - вполне ОК.
У меня MBR в регистрах EAX и EBX передаёт LBA-номер загруженного сектора, иными словами, начало раздела. В обоих регистрах одинаковое значение.


Подобная ситуация происходит, как правило, в двух случаях.
1. Первыми в цепочке стоят устройства, с которых иногда возникает необходимость загрузиться, например, флоппи-диск и флешка. За ними HDD. Т.о. если я случайно забыл вынуть флоппи-диск мне совершенно нет нужды перезагружать всё с нуля, чтобы загрузиться с HDD. Я просто нажму пробел и загружусь со следующего устройства, т.е. со своего натруженного HDD.
2. После HDD стоят recovery-устройства, например, флешка или CD-ROM. При этом по каким-то причинам загрузка с HDD временно недоступна, но эта ситуация разрешима загрузкой с CD. Тогда, вместо того, чтобы жать Ctrl-Alt-Del, заходить в настройки BIOS и выносить CD-ROM перед жёстким диском, затем всё сохранять, и ёще раз перегружаться, я просто вставлю recovery-CD и нажму пробел.
Ситуацию, когда мне предпочтительно перезагружаться с начала цепочки, мне представить сложно.


Как раз нет. Выше пример с загрузкой с Recovery или установочного CD.


Вот этот вопрос меня и самого мучает. Я, в целом, неплохо владею английским, но никак не могу представить себе корректной английской технической фразы, означающей продолжение загрузки с других носителей. Boot further? Subsequent boot? В результате оставил пока так, тем более, что каждый байт на счету, а "reboot" существенно короче. Да и в целом, если ситуация встречается раз в год, не велика разница, нажмёт че-к Ctrl-Alt-Del или Any key, а если приходится перезагрузками баловаться часто, попробует и привыкнет, благо его просят: "Press any key...".


Поддерживаются следующие типы расширенных разделов: 5, 6, 0Fh, 15h, 1Fh, 91h, 9Bh, 0C5h, 0CFh и 0D5h. Собственно говоря, коду EBR наплевать, как пометили его раздел. Проверка осуществляется в boot.exe при анализе структуры диска.


Хорошо реагирую! Welcome пожаловать :)
Для тестов я готовил адские смеси разделов, в т.ч. некорректные или невидимые во многих ОС, но формально допустимые. Например, ДВА расширенных раздела (этого не переваривает ни одна известная мне дисковая утилита или ОС), перемежающиеся (или неперемежающиеся) основными разделами, причём в КАЖДОМ расширенном разделе были от одного до нескольких логических дисков. Соответственно, проверялась загрузка со всех без исключения разделов и логических дисков данной мешанки.


Не понял вопрос.


Устанавливаю и проверяю флаг активности раздела. Соответственно, в дополнительном разделе также должен быть вписан загрузочный код EBR.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Первая задача загрузить ОС и не важно какую. А вот после уже пусть пользователь разбирается, что не так.
Если загрузилось не то что нужно он заметит. И начнёт разбираться.
Главное восстановить живучесть системы. Тогда пользователь сможет и справку прочитать и бутсектор поправить.
А если нечего не грузится, то вам ещё придется объяснять пользователю где у него кнопка "anykey". И они ещё будут говорить что система не исправная.

В том году во всех компах отдела поменял батарейку. А то людей в ступор вводило что надо нажимать F1. И вообще они хотят чтобы компьютер как джин выполнял бы их мысли.

Как именно ты распознаешь (не) свой EBR-код?

Под "наоборот" я имел в виду, что EBR-загрузчик тоже должен проверять на "родство" MBR-загрузчик, от которого он получает управление, чтобы быть уверенным в корректности передаваемых параметров (не так даже важно, "родной" MBR-загрузчик или нет, но важно иметь гарантию корректности передаваемых параметров). Что касается проверки типов разделов, то я не предлагаю проверять все типы. Я говорил о том, что явное использование расширенного раздела, как загрузочного, является ошибочным. Короче я проверяю, чтобы первичный загрузочный раздел не имел тип 0, 5 или 0Fh. А когда происходит загрузка из дополнительного загрузочного раздела, то специально выполняю поиск расширенного раздела, чтобы запустить EBR-код (но только в том случае, если помимо стандартной загрузочной сигнатуры он также содержит и специальную сигнатуру, идентифицирующую EBR-загрузчик).

Речь идет только о расширенных разделах DOS.

Дело в том, что если расширенный раздел ошибочно помечен активным, то многие MBR-загрузчики будут грузить его EBR, не гарантируя передачи данных, которые ты ожидаешь получить в своем EBR. Чтобы обсуждение этого вопроса было менее отвлеченным, скажи, какие данные ты передаешь EBR-загрузчику и как именно ты это делаешь.

Как ни странно, мне этого достаточно, по крайней мере для загрузки из дополнительных разделов с FAT/NTFS, а также с файловыми системами, в BR которых вообще не содержится привязки к физическому местоположению раздела на диске.

Это понятно, но кто будет обеспечивать нормальную загрузку или хотя бы нормальную незагрузку (т.е. оповещение об ошибке), когда будет заменен лишь один из двух компонентов MBR/EBR сторонним. Или ты за это уже ответственности не несешь? О, я забыл (я читал твое "пользовательское соглашение"), ты же вообще ни за что ответственности не несешь! )))

Да, но все же... Кроме того, есть загрузчики, которые могут выполнять загрузку не только с активного раздела.

Я использую другой способ, но этот все равно представляется более-менее адекватным.

К сожалению использование EAX конфликтует с моим способом (я через AX целенаправленно передаю значение, отличное от "!G"("PT"), - обычно 0AA55h). К тому же для совместимости с древними процами я не использую 32-разрядные регистры. Также мне кажется, что механизм подтверждения достоверности (если я правильно понял, это именно равенство двух значений) слишком слабый.

"Recovery-устройства" находятся в начале загрузочной цепочки перед основным загрузочным устройством.

В том-то и дело, что нужно было хотя бы слово какое-то новое придумать, потому что "reboot" будет постоянно сбивать с толку. В упомянутом выше загрузчике для CD/DVD я использую слово "continue".

А что после установки загрузчиков структура расширенного раздела меняться не может? Я делаю проверки в загрузчиках, хотя и проверяю только два распространенных типа.

Моя ось поддерживает ))) У меня сейчас имеется ограничение только на количество дополнительных разделов (251), но не на их размещение (можно использовать и четыре расширенных раздела). Правда, загрузчиками поддерживается (точнее обрабатывается) только один расширенный раздел. Хочешь загрузиться с дополнительного раздела внутри второго и последующих расширенных разделов, поменяй местами в таблице разделов дескрипторы этого и первого расширенных разделов.

Между разделами типа 5 и типа 0Fh есть одна большая разница, которая отражается в том числе и на трактовке поля HiddenSectors в BR FAT/NTFS. В BR дополнительного раздела внутри расширенного раздела типа 5 нужно выполнять корректировку, чтобы код BR смог нормально работать.

Что-то я не понял. Я дополнительными разделами называю не "контейнеры", а сами логические диски. "Контейнеры" вообще никак не называю или иногда говорю "вложенные расширенные разделы (в структуре первичного расширенного раздела)". Ты вписываешь код EBR в дополнительный раздел? Это вряд ли, т.к. там должен находиться оригинальный ФС-специфичный код BR. Может, ты имел в виду, что вписываешь копию EBR-загрузчика в каждый вложенный расширенный раздел? У меня один экземпляр EBR-загрузчика обрабатывает все дополнительные разделы внутри расширенного. Кроме того, я считаю некорректным использование флага активности для дополнительных и расширенных разделов.

Т.е. ты и сообщения об ошибке не выводишь и ожидания нажатия на клавишу не делаешь? Представляю физиономии людей, у которых при возникновении ошибки вместо любимой системы будет грузиться что-то другое. Или ты для каждого компа дублируешь рабочую систему на отдельном физическом диске, регулярно копируя в эту резервную копию данные пользователей?

В случае ошибки сообщение выводиться и нажатие кнопки жду.
Но отсутствие загрузочной записи(сектора) не трактуется, как ошибка. Просто трактуется что на диске отсутствует загрузчик. И в этом случае молча переходим к другому диску.

MBR грузит BR
BR грузит KLoader.exe
KLoader.exe читает настройки KLoader.cfg
Затем KLoader.exe загружает ядро "kernel.sys".

Далее идея уйти от всех неясностей и неточностей чётким описанием возможных протоколов загрузки. Как сторонних загрузчиков так и загрузка моего загрузчика сторонними.

Варианты загрузки настраиваются в KLoader.cfg по факту может заменить таблицу разделов.
НО даже если пользователь поленился и не прочитал протоколы основной вариант загрузки будет автоматический. И в случае сбоя выбор альтернативных путей.

Загрузочный раздел с KLoader.exe должен располагаться в начале жёсткого иметь размер 512 мб и ФС должна быть FAT. Это не ограничения, а пожелания. В виду того чтобы не бороться с глюками биосов и прочих загрузчиков.

Теперь по поводу загрузки сторонних загрузчиков моим.
Варианта 3.
1) Загрузка com или bin файла, с раздела указанного в конфиге.
2) Загрузка сектора и трактовка его как mbr
3) Загрузка файла bin и трактовка его как mbr
Загрузить мой загрузчик можно аналогично.

Совместимость со всем и вся я не ставлю. Хотя если кому понадобиться сможет сделать своё расширение в виде COM файла.

Буквально на днях довёл свой "KLoader.exe" до кондиции.
На данный момент KLoader.exe умеет грузит с первого раздела kernel.sys. А файл настроек KLoader.cfg не задействован. Пока дальнейшую разработку приостанавливаю займусь ядром.

Опять свой путь :) Хотя это уже вполне приемлемо. Я бы только выдавал сообщение и делал ожидание. Основная твоя ошибка в неправильном использовании int 19h в MBR-загрузчике. Как раз в случае отсутствия активного раздела нужно вызывать int 18h без вывода каких-либо сообщений и ожидания. В любом случае кроме неверной загрузочной сигнатуры есть и другие ошибки, которые трудно трактовать, просто как отсутствие ОС (и чтобы унифицировать обработку ошибочных и близких к ним ситуаций, обычно выбирают наиболее универсальный способ завершения такой обработки, а именно Ctrl-Alt-Del, через который можно и повторной загрузки добиться и изменения загрузочной цепочки посредством вызова BIOS Setup/Boot Menu). Кроме того, и ты, и Yoda не понимаете различий между MBR-загрузчиком и первичным загрузчиком в плане обработки ошибок. С точки зрения BIOS запуск ОС - это запуск ОС-специфичного загрузчика, т.е. ошибка внутри первичного загрузчика должна трактоваться, как ошибка внутри ОС, а не как ошибка при загрузке ОС.

Мы тут говорим о более низких материях, чем вторичные загрузчики. Наша основная цель добиться наиболее гибкой загрузки вторичного загрузчика/ядра, оставаясь в рамках существующих стандартов. А там уже можно вытворять все, на что только хватит фантазии. Кстати, мой вторичный загрузчик не предъявляет никаких требований к ФС раздела, на котором находится его конфигурационный файл.

Никак не распознаю. Не дело это MBR-загрузчиков, распознавать, что именно они загрузили. Идеальный МБР должен грузить любую, в т.ч. будущую систему и не закладываться, что именно он может встретить в загрузочном секторе. А то именно от избыточного интеллекта и возникают некоторые проблемы.


EBR не проверяет MBR на родство душ. Здесь мы возвращаемся к вопросу об избыточности проверок, когда результат этих проверок ничего не даёт. Результат один - невозможность загрузить ОС, о чём пользователь и уведомляется.


Ну хорошо, проверил, убедился, что MBR не родной или данные не валидны. Что делать дальше? А всё то же самое - разводить руками с возгласом "опс!"


Это почему? Я нигде не нашёл явного запрета на использование расширенного раздела в качестве загрузочного. Более того, встречаются упоминания того, что потенциально он может быть загрузочным. Другое дело, что утилиты общего назначения не хотят делать его загрузочным, но это ведь не запрет.


Как ты поступаешь с количеством скрытых секторов в загрузочном секторе расширенного раздела?


Да никто не будет. Изначально структура расширенных разделов крива до безобразия. Тут может быть два подхода. Либо весь анализ зашить в MBR (так понимаю, твой случай) тогда MBR будет парсить структуру диска и выполнять несвойственные ему проверки с риском или что-то упустить или что-то пропатчить лишнего, либо разбить код на две специализированные части, с риском подмены одной из них. Так и так какие-то неприятности есть.


В принципе, пока нет категорической привязки к EAX. Я подумаю.


Ну это совершеннейший атавизм. Т.е. предполагается, что кто-то до сих пор использует музейную XT или AT/286 и ты разрабатываешь новую ОС, которая будет работать на этом пугале прогресса? :))) Это несерьёзно.


Ммм, тогда может добавить проверку CRC32? )
Нет, конечно. Не для проверки достоверности. Второй и дальнейшие сектора EBR для своей работы используют два значения - начало своего раздела и начало всего расширенного раздела. Для первого сектора эти два значения совпадают.


Пусть так. А Int 18 в данном случае чем мешает?


Попробую исследовать этот вопрос более тщательно.


Может. Поменял, набрал в командной строке, например, "boot.exe -d5 -a7" и покатили дальше. Не часто пользователи меняют структуры диска и в целом должны понимать, что если ты "потрогал" активный раздел, то загрузка с него может сломаться. В моей ОС всё предполагается прозрачно - переразбил или переформатировал, всё автоматом синхронизируется.


Вооот, видишь - пошли искусственные ограничения :). Ещё одно не упомянутое ограничение - не загрузишься со скрытого раздела. В моей архитектуре этих ограничений нет.
Я не говорю, что твой подход плохой. Просто хочу отметить, что в каждом случае есть свои достоинства и недостатки и мой подход вполне имеет право на жизнь.


Теперь понял. EBR ничего не патчит в загруженном BR раздела. Уже наступил на грабли некорректных патчей и считаю это вредоносным. Утилита boot.exe правит количество скрытых секторов в BR тех файловых систем, которые гарантированно распознала. На самом деле это не вопрос трактовки. Это ошибка в старых ОС. В официальной документации MS указывается, что это поле, вообще говоря, OS specific и ни на что не влияет кроме начальной загрузки.


Да.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Так стандартов нет, есть специфичные вещи.
Загрузчик win 98 отличается от загрузчика win XP и win Vista. Есть GRUB, есть загрузчик акроникса. И тьма других.
Если win 98 поддерживал разделы 5h 0fh, то winxp и win Vista не факт. WinXP хранит настройки на первом логическом диске. В Win Vista как раз для загрузки отвели первый раздел в несколько сот мегабайт.

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

Акроникс просто видимо делает копию MBR и начало первого раздела отмечает от начала диска. Не проверял но видимо так. По другому загрузчик не обманешь.

Тем самым нет надобности в MBR разбирать все возможные структуры дробления диска на разделы. Это делается во вторичном загрузчике.
Тем более это и не требуется. Просто передаём управление в стороннему загрузчику, который умеет обрабатывать свою структуру.

Не согласен с отсутствием сообщений и ожидания. Предпринята попытка загрузиться с незагружаемого носителя, - пользователь должен быть уведомлён, что он не загружаем.


Так и не должно быть разницы. Вся цепочка загрузчиков преследует только одну конечную цель - загрузка ОС. Если где-то, не важно где, цепочка оборвалась, надо переходить к следующей цепоке.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Поразмыслил.
Согласен, надо ввести проверку в EBR на валидность передаваемых данных, иначе можно очень долго искать причину незагружаемости по сообщению "No boot sector found". Место есть.
Надо определиться с двумя вещами.
1. Как передавать данные?
2. Как известить пользователя о подменённом MBR?

Вообще, конечно, свинство, что изначально не предусмотрена стандартизованная передача от MBR начала раздела.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>