Начальная загрузка компьютера. Азбука админа: процесс загрузки Windows. Какие версии BIOS бывают

А вы никогда не задумывались над тем, что же происходит с операционной системой в тот момент, когда она рисует свой логотип и говорит «Starting Windows»? И вообще, почему она долго загружается? Ведь при старте системы уж точно не решаются никакие задачи, сложные с вычислительной точки зрения!

Что тогда подразумевает под собой загрузка операционной системы? По большей части это проецирование в память исполняемых модулей и инициализация служебных структур данных. Структуры данных живут в памяти, поэтому операции с ними по идее должны быть быстрыми. Все наталкивает на мысль о том, что время съедается именно процессом загрузки исполняемых модулей в память.

Давайте интереса ради разберемся, какие модули, в каком количестве и в каком порядке загружаются при старте ОС. Чтобы выяснить это, можно, например, получить лог загрузки системы. Подопытная ОС в моем случае - Windows 7 Enterprise x64. Логировать процесс загрузки будем при помощи отладчика ядра. Существует несколько вариантов отладчиков ядра, лично я предпочитаю WinDbg. Также нам понадобятся некоторые вспомогательные средства для волшебного превращения лога в нечто более приятное глазу.

Mining and crafting

Настройка отладки хорошо гуглится, поэтому описывать подробно этот процесс я не буду. Поскольку нас интересует все происходящее с момента старта системы, нам нужно отметить пункт «Cycle Initial Break», с помощью чего отладчик остановится, как только в отлаживаемой системе будет загружена подсистема отладки ядра. Дублирование вывода в файл можно осуществить при помощи команд ".logopen" и ".logclose", это просто. Другая полезная команда - ".cls". Она очищает экран команд, и да, только экран команд.

Интересующая нас функция - «MiCreateImageFileMap». Это внутренняя функция менеджера памяти, проецирующая исполняемый файл в память. Проецирование в память происходит при создании секции, например, при запуске исполняемого файла. Однако учтите, что если исполняемый файл проецируется в память, это не гарантия того, что будет выполнен его код! Эта функция просто создает проекцию, чаще всего «про запас», чтобы, если кто-то надумает запустить модуль на исполнение, можно было сэкономить время его загрузки. На эту функцию поставим логирующую точку останова.

Если у вас достаточно маны, вводите следующую команду:
bu nt!MiCreateImageFileMap "dt nt!_EPROCESS -d ImageFileName @$proc; dt nt!_FILE_OBJECT -d FileName @rcx; g"
Магическая строчка буквально означает следующее:

• bu (Set Unresolved Breakpoint) - установить неразрешенную точку останова. Не то чтобы кто-то или что-то не разрешал, просто для ее установки необходимо определиться, по какому адресу ее ставить. Дело в том, что заранее не известно, по какому адресу она должна располагаться. При загрузке любого модуля проверяется присутствие в нем необходимой функции, и если такая функция найдена, точка останова устанавливается автоматически. Такой способ установки незаменим при включенном ASLR - рандомизации адресного пространства, поскольку модули будут загружаться каждый раз по разным адресам, и точка останова, установленная по фиксированному адресу, с большой вероятностью окажется не у дел.
• nt!MiCreateImageFileMap - символ, на котором нужно останавливаться. В WinDbg принята запись в форме "module_name!function_name". В данном случае nt является предопределенным псевдонимом для ntoskrnl.exe.
• далее следует часть WinDbg-скрипта, которая будет выполняться каждый раз при остановке на этой функции. «dt nt!_EPROCESS -d ImageFileName @$proc» по-русски означает «отобразить поле ImageFileName структуры _EPROCESS из модуля nt при условии ее отображения по адресу, определенному в псевдорегистре «текущий процесс»». Следующая после разделителя ";" команда означает примерно то же самое, только адрес структуры берется из регистра rcx, в котором в Microsoft x64 ABI передается первый параметр функции. «g» означает «go», т.е. продолжить исполнение.

Небольшая рекомендация по использованию логирующих точек останова: старайтесь не использовать расширения отладчика (команды, начинающиеся с "!"), поскольку в таком случае логирование будет выполняться на порядок медленнее.

Поехали! Отжимаем тормоз точки останова и ждем. Я ждал, пока не прогрузится рабочий стол, т.е. я залогинился. Полученный «урожай» немного редактируется, обрезается все лишнее для удобства дальнейшей обработки и скармливается дружище питону. Не будем заострять внимание на парсинге лога. Отметим только, что граф укладывался в форму спирали Архимеда с дальнейшей коррекцией вручную, поскольку происходило наложение узлов друг на друга. В полученном графе учитывается порядок загрузки библиотек. К сожалению, пришлось пожертвовать учетом порядка загрузки исполняемых файлов относительно библиотек в угоду удобочитаемости графа.

Карта звездного неба

Условно выделим несколько групп загрузки.

Начинается работа OC в модуле ntoskrnl.exe, являющимся ядром ОС. А если еще конкретнее - с функции KiSystemStartup(). Вместе с загружаемыми системными компонентами она формирует фундамент ОС: разделение режимов работы, базовые сервисы для пользовательских приложений и т.п. В эту же группу входят драйверы, отмеченные для загрузки во время старта системы. В двух словах, в этой ракушке зарождается ОС Windows.

Следующий узел - менеджер сессий (session manager). Его представляет первый после системного процесс, стартующий в Windows - smss.exe. Процесс примечателен тем, что является родным (native) процессом Windows, то есть он не использует подсистему Win32, которая в общем-то еще не загружена. Этот процесс использует только нативные сервисы операционной системы посредством ntdll.dll, представляющей собой интерфейс режима пользователя для сервисов ОС. Также этот процесс является доверенным компонентом операционной системы и обладает исключительными правами, например, он может создавать маркеры безопасности (security tokens). Но главное его предназначение - создание сеансов и инициализация подсистем, как графической, так и различных исполняемых (Windows, POSIX). Эта ракушка воздает каждому по потребностям.

Группа входа в систему (logon) состоит из нескольких процессов. В целом они отвечают за инициализацию сеансов. Это включает в себя отображение экрана приветствия, создание рабочих столов, запуск процессов автозагрузки и инициализацию подсистемы безопасности и т.п. Этот веник отметает всех посторонних.

Самой массивной оказалась группа сервисов. Во многом она обязана своим объемом службе SuperFetch. Эта та самая, про которую говорят, что она по выходным заранее прогружает офисный пакет, а в начале рабочей недели - Steam с игрушками. Superfetch прогружает огромное количество модулей при старте системы, чтобы потом «все быстрее работало». Да и кроме него в системе хватает сервисных приложений и автозапускающихся драйверов. Думаю, все видели оснастку «Службы и приложения». Эта звезда жизни заводит в системе все, что нужно и не очень.

Последним отмечу любимый всеми explorer.exe. Примечательно, что к моменту его запуска все используемые им модули уже загружены в память. В скриншот также попал некий vcredist_x64.exe - бедолага лежал на рабочем столе подопытной виртуальной машины и был прогружен в память проводником.

Вообще способов оказаться загруженным в память у модуля много. Например, достаточно запросить информацию из ресурсов исполняемого файла, в том числе его иконку. Конкретно в данном примере проводник проверял, является ли эта программа требующей повышенных привилегий, т.е. стоит ли дорисовывать к иконке соответствующий рисуночек с желто-голубым щитом. Еще раз отмечу, что загрузка модуля в память не означает выполнение его кода!

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

Граф загрузки был построен для ОС Windows 7 Enterprise x64, установленной на виртуальной машине VMware. Ниже приведены векторное изображение графа и непосредственно файл в формате gml, с которым можно поиграться в любом редакторе графов.

А вы никогда не задумывались над тем, что же происходит с операционной системой в тот момент, когда она рисует свой логотип и говорит «Starting Windows»? И вообще, почему она долго загружается? Ведь при старте системы уж точно не решаются никакие задачи, сложные с вычислительной точки зрения!

Что тогда подразумевает под собой загрузка операционной системы? По большей части это проецирование в память исполняемых модулей и инициализация служебных структур данных. Структуры данных живут в памяти, поэтому операции с ними по идее должны быть быстрыми. Все наталкивает на мысль о том, что время съедается именно процессом загрузки исполняемых модулей в память.

Давайте интереса ради разберемся, какие модули, в каком количестве и в каком порядке загружаются при старте ОС. Чтобы выяснить это, можно, например, получить лог загрузки системы. Подопытная ОС в моем случае - Windows 7 Enterprise x64. Логировать процесс загрузки будем при помощи отладчика ядра. Существует несколько вариантов отладчиков ядра, лично я предпочитаю WinDbg. Также нам понадобятся некоторые вспомогательные средства для волшебного превращения лога в нечто более приятное глазу.

Mining and crafting

Настройка отладки хорошо гуглится, поэтому описывать подробно этот процесс я не буду. Поскольку нас интересует все происходящее с момента старта системы, нам нужно отметить пункт «Cycle Initial Break», с помощью чего отладчик остановится, как только в отлаживаемой системе будет загружена подсистема отладки ядра. Дублирование вывода в файл можно осуществить при помощи команд ".logopen" и ".logclose", это просто. Другая полезная команда - ".cls". Она очищает экран команд, и да, только экран команд.

Интересующая нас функция - «MiCreateImageFileMap». Это внутренняя функция менеджера памяти, проецирующая исполняемый файл в память. Проецирование в память происходит при создании секции, например, при запуске исполняемого файла. Однако учтите, что если исполняемый файл проецируется в память, это не гарантия того, что будет выполнен его код! Эта функция просто создает проекцию, чаще всего «про запас», чтобы, если кто-то надумает запустить модуль на исполнение, можно было сэкономить время его загрузки. На эту функцию поставим логирующую точку останова.

Если у вас достаточно маны, вводите следующую команду:
bu nt!MiCreateImageFileMap "dt nt!_EPROCESS -d ImageFileName @$proc; dt nt!_FILE_OBJECT -d FileName @rcx; g"
Магическая строчка буквально означает следующее:

• bu (Set Unresolved Breakpoint) - установить неразрешенную точку останова. Не то чтобы кто-то или что-то не разрешал, просто для ее установки необходимо определиться, по какому адресу ее ставить. Дело в том, что заранее не известно, по какому адресу она должна располагаться. При загрузке любого модуля проверяется присутствие в нем необходимой функции, и если такая функция найдена, точка останова устанавливается автоматически. Такой способ установки незаменим при включенном ASLR - рандомизации адресного пространства, поскольку модули будут загружаться каждый раз по разным адресам, и точка останова, установленная по фиксированному адресу, с большой вероятностью окажется не у дел.
• nt!MiCreateImageFileMap - символ, на котором нужно останавливаться. В WinDbg принята запись в форме "module_name!function_name". В данном случае nt является предопределенным псевдонимом для ntoskrnl.exe.
• далее следует часть WinDbg-скрипта, которая будет выполняться каждый раз при остановке на этой функции. «dt nt!_EPROCESS -d ImageFileName @$proc» по-русски означает «отобразить поле ImageFileName структуры _EPROCESS из модуля nt при условии ее отображения по адресу, определенному в псевдорегистре «текущий процесс»». Следующая после разделителя ";" команда означает примерно то же самое, только адрес структуры берется из регистра rcx, в котором в Microsoft x64 ABI передается первый параметр функции. «g» означает «go», т.е. продолжить исполнение.

Небольшая рекомендация по использованию логирующих точек останова: старайтесь не использовать расширения отладчика (команды, начинающиеся с "!"), поскольку в таком случае логирование будет выполняться на порядок медленнее.

Поехали! Отжимаем тормоз точки останова и ждем. Я ждал, пока не прогрузится рабочий стол, т.е. я залогинился. Полученный «урожай» немного редактируется, обрезается все лишнее для удобства дальнейшей обработки и скармливается дружище питону. Не будем заострять внимание на парсинге лога. Отметим только, что граф укладывался в форму спирали Архимеда с дальнейшей коррекцией вручную, поскольку происходило наложение узлов друг на друга. В полученном графе учитывается порядок загрузки библиотек. К сожалению, пришлось пожертвовать учетом порядка загрузки исполняемых файлов относительно библиотек в угоду удобочитаемости графа.

Карта звездного неба

Условно выделим несколько групп загрузки.

Начинается работа OC в модуле ntoskrnl.exe, являющимся ядром ОС. А если еще конкретнее - с функции KiSystemStartup(). Вместе с загружаемыми системными компонентами она формирует фундамент ОС: разделение режимов работы, базовые сервисы для пользовательских приложений и т.п. В эту же группу входят драйверы, отмеченные для загрузки во время старта системы. В двух словах, в этой ракушке зарождается ОС Windows.

Следующий узел - менеджер сессий (session manager). Его представляет первый после системного процесс, стартующий в Windows - smss.exe. Процесс примечателен тем, что является родным (native) процессом Windows, то есть он не использует подсистему Win32, которая в общем-то еще не загружена. Этот процесс использует только нативные сервисы операционной системы посредством ntdll.dll, представляющей собой интерфейс режима пользователя для сервисов ОС. Также этот процесс является доверенным компонентом операционной системы и обладает исключительными правами, например, он может создавать маркеры безопасности (security tokens). Но главное его предназначение - создание сеансов и инициализация подсистем, как графической, так и различных исполняемых (Windows, POSIX). Эта ракушка воздает каждому по потребностям.

Группа входа в систему (logon) состоит из нескольких процессов. В целом они отвечают за инициализацию сеансов. Это включает в себя отображение экрана приветствия, создание рабочих столов, запуск процессов автозагрузки и инициализацию подсистемы безопасности и т.п. Этот веник отметает всех посторонних.

Самой массивной оказалась группа сервисов. Во многом она обязана своим объемом службе SuperFetch. Эта та самая, про которую говорят, что она по выходным заранее прогружает офисный пакет, а в начале рабочей недели - Steam с игрушками. Superfetch прогружает огромное количество модулей при старте системы, чтобы потом «все быстрее работало». Да и кроме него в системе хватает сервисных приложений и автозапускающихся драйверов. Думаю, все видели оснастку «Службы и приложения». Эта звезда жизни заводит в системе все, что нужно и не очень.

Последним отмечу любимый всеми explorer.exe. Примечательно, что к моменту его запуска все используемые им модули уже загружены в память. В скриншот также попал некий vcredist_x64.exe - бедолага лежал на рабочем столе подопытной виртуальной машины и был прогружен в память проводником.

Вообще способов оказаться загруженным в память у модуля много. Например, достаточно запросить информацию из ресурсов исполняемого файла, в том числе его иконку. Конкретно в данном примере проводник проверял, является ли эта программа требующей повышенных привилегий, т.е. стоит ли дорисовывать к иконке соответствующий рисуночек с желто-голубым щитом. Еще раз отмечу, что загрузка модуля в память не означает выполнение его кода!

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

Граф загрузки был построен для ОС Windows 7 Enterprise x64, установленной на виртуальной машине VMware. Ниже приведены векторное изображение графа и непосредственно файл в формате gml, с которым можно поиграться в любом редакторе графов.

При включении питания компьютера управление передается базовой системе ввода/вывода, BIOS.Она выполняет проверку аппаратных узлов компьютера, формирует начальную часть таблицы векторов прерываний, инициализирует устройства и начинает процесс загрузки операционной системы.

Загрузка начинается с того, что BIOS делает попытку прочитать самый первый сектор дискеты, вставленной в дисковод А: (на загрузочной дискете этот сектор содержит загрузчик операционной системы). Если в дисковод вставлена системная дискета, с нее считывается загрузчик и ему передается управление.

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

Если же дискеты в дисководе А: вообще нет, то BIOS читает основную загрузочную запись диска С: (Master Boot Record). Обычно это самый первый сектор на диске. Управление передается загрузчику, который находится в этом секторе. Загрузчик анализирует содержимое таблицы разделов (она также находится в этом секторе), выбирает активный раздел и читает загрузочную запись этого раздела. Загрузочная запись активного раздела (Boot Record) аналогична загрузочной записи, находящейся в первом секторе системной дискеты.

Загрузочная запись активного раздела считывает с диска файлы IO.SYS и MSDOS.SYS (именно в этом порядке). Затем считываются и загружаются резидентные драйверы. Начинается формирование связанного списка драйверов устройств. Анализируется содержимое файла CONFIG.SYS, загружаются описанные в этом файле драйверы. Сначала загружаются драйверы, описанные параметром DEVICE, затем (только в MS-DOS версии 4.х и 5.0) резидентные программы, указанные операторами INSTALL. После этого считывается командный процессор и ему передается управление.

Командный процессор состоит из трех частей - резидентной, инициализирующей и транзитной. Первой загружается резидентная часть. Она обрабатывает прерывания INT 22H, INT 23H, INT 24H, управляет загрузкой транзитной части. Эта часть командного процессора обрабатывает ошибки MS-DOS и выдает запрос пользователю о действиях при обнаружении ошибок.

Инициализирующая часть используется только в процессе загрузки операционной системы. Она определяет начальный адрес, по которому будет загружаться пользовательская программа и инициализирует выполнение файла AUTOEXEC.BAT.

Транзитная часть командного процессора располагается в старших адресах памяти. В этой части находятся обработчики внутренних команд MS-DOS и интерпретатор командных файлов с расширением имени.BAT. Транзитная часть выдает системное приглашение (например, А:\>), ожидает ввода команды оператора с клавиатуры или из пакетного файла и организует их выполнение.

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

1.3. Общая схема работы dos

Для того чтобы правильно работать с системным программным и аппаратным обеспечением, нужно четко представлять себе механизм взаимодействия прикладной программы с компьютером. На рис. 1.1 показаны функциональные связи программы с программно-аппаратным обеспечением IBM PC.

Рис.1. Функциональные связи программы для MS-DOS с программно-аппаратным обеспечением ПЭВМ

Как правило, ядро DOS разделяют на несколько подсистем, каждая из которых отвечает за выполнение той или иной задачи. Как показано на рисунке, обычно выделяются следующие подсистемы:

файловая система;

система управления памятью;

система управления программами;

система связи с драйверами устройств;

система обработки ошибок;

службу времени;

систему ввода/вывода консоли оператора.

Эти подсистемы общаются с аппаратурой через BIOS, драйверы или напрямую. Прикладное программное обеспечение может вызывать подсистемы DOS, работать с BIOS или непосредственно с аппаратурой. Обратите, однако, внимание на то, что прикладные программы могут обращаться к драйверам только через соответствующую подсистему DOS.

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

Рассмотрим подсистемы DOS отдельно.

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

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

Загрузчик в ПЗУ

Сразу после включения оперативная память компьютера классической архитектуры девственно чиста. Для того чтобы начать работать, процессору необходима хоть какая-то программа. Эта программа автоматически загружается в память из постоянного запоминающего устройства , ПЗУ (или ROM, read-only memory), в которое она вписана раз и навсегда в неизменном виде 1Современные компьютеры используют программируемые ПЗУ , содержимое которых можно изменять, однако такое изменение всегда считается ситуацией нештатной: например, запись новой версии содержимого ПЗУ , в которой исправлены ошибки (upgrade). . В специализированных компьютерах (например, в дешевых игровых приставках) все, что нужно пользователю, записывается именно на

Обычно в компьютерах общего назначения программа из ПЗУ пользователю ничем полезна не бывает: она невелика, да и делает всегда одно и то же. Слегка изменить поведение программы из ПЗУ можно, оперируя данными, записанными в энергонезависимую память (иногда ее называют CMOS, иногда - NVRAM ). Объем энергонезависимой памяти очень невелик, а данные из нее сохраняются после выключения компьютера за счет автономного электропитания (как правило, от батарейки вроде часовой).

Что должна уметь эта начальная программа? Распознавать основные устройства, на которых может быть записана другая - нужная пользователю - программа, уметь загружать эту программу в память и передавать ей выполнение, а также поддерживать интерфейс, позволяющий менять настройки в NVRAM . Собственно, это даже не одна программа, а множество подпрограмм , занимающихся взаимодействием с разнообразными устройствами ввода-вывода - как с теми, на которых могут храниться программы (жесткие и гибкие диски, магнитные ленты и даже сетевые карты), так и теми, посредством которых можно общаться с пользователем (последовательные порты передачи данных - если есть возможность подключить консольный терминал, системная клавиатура и видеокарта - для простых персональных рабочих станций). Этот набор подпрограмм в ПЗУ обычно называется BIOS (basic input-output system).

BIOS . Сокращение от "Basic Input-Output System", набор подпрограмм в ПЗУ , предназначенных для простейшего низкоуровневого доступа к внешним устройствам компьютера. В современных ОС используется только в процессе начальной загрузки.

Этот этап загрузки системы можно назвать нулевым , так как ни от какой системы он не зависит. Его задача - определить (возможно, с помощью пользователя), с какого устройства будет идти загрузка, загрузить оттуда специальную программу- загрузчик и запустить ее. Например, выяснить, что устройство для загрузки - жесткий диск, считать самый первый сектор этого диска и передать управление программе, которая находится в считанной области.

Загрузочный сектор и первичный загрузчик

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

Если бы первичный загрузчик был побольше, он, наверное, и сам мог бы разобраться, где находится ядро операционной системы , и смог бы самостоятельно считать его, разместить в памяти, настроить и передать ему управление. Однако ядро операционной системы имеет довольно сложную структуру - а значит, и непростой способ загрузки; оно может быть довольно большим, и, что неприятнее всего, может располагаться неизвестно где на диске, подчиняясь законам файловой системы (например, состоять из нескольких частей, разбросанных по диску). Учесть все это первичный загрузчик не в силах. Его задача скромнее: определить, где на диске находится "большой" вторичный загрузчик , загрузить и запустить его. Вторичный загрузчик прост, и его можно положить в заранее определенное место диска, или, на худой конец, положить в заранее определенное место карту размещения , описывающую, где именно искать его части (размер вторичного загрузчика ограничен, поэтому построить такую карту возможно).

Карта размещения . Представление области с необходимыми данными (например, вторичным загрузчиком или ядром системы) в виде списка секторов диска, которые она занимает.

В случае IBM-совместимого компьютера размер загрузочного сектора составляет всего 512 байтов , из которых далеко не все приходятся на программную область. Загрузочный сектор IBM PC, называемый MBR ( master boot record ), содержит также таблицу разбиения диска , структура которой описана в лекции 11. Понятно, что программа такого размера не может похвастаться разнообразием функций. Стандартный для многих систем загрузочный сектор может только считать таблицу разбиения диска , определить так называемый загрузочный раздел ( active partition ) и загрузить программу, расположенную в начале этого раздела . Для каждого типа диска может быть своя программная часть MBR , что позволяет считывать данные из любого места диска, сообразуясь с его типом и геометрией. Однако считывать можно все же не более одного сектора: неизвестно, для чего используются установленной на этом разделе операционной системой второй и последующие сектора. Выходит, что стандартная программная часть MBR - это некий предзагрузчик , который считывает и запускает настоящий первичный загрузчик из первого сектора загрузочного раздела .

Существуют версии предзагрузчика , предоставляющие пользователю возможность самостоятельно выбрать , с какого из разделов выполнять загрузку 2Например, BOOTACTV из пакета pfdisk или стандартный для FreeBSD предзагрузчик boot0 , которые, в силу их досистемности , можно применять где угодно. . Это позволяет для каждой из установленных операционных систем хранить собственный первичный загрузчик в начале раздела и свободно выбирать среди них. В стандартной схеме загрузки Linux используется иной подход: простой первичный загрузчик записывается прямо в MBR , а функция выбора передается вторичному загрузчику .

Первичный загрузчик . Первая стадия загрузки компьютера: программа, размер и возможности которой зависят от аппаратных требований и функций BIOS . Основная задача - загрузить вторичный загрузчик .

Загрузчик ядра

В задачу операционной системы . Как правило, ядро системы записывается в файл с определенным именем. Но как вторичному загрузчику прочитать файл с ядром , если в Linux эта операция и есть функция ядра ? Эта задача может быть решена тремя способами.

Во-первых, ядро может и не быть файлом на диске. Если загрузка происходит по сети, достаточно попросить у сервера "файл с таким-то именем", и в ответ придет цельная последовательность данных, содержащая запрошенное ядро . Все файловые операции выполнит сервер, на котором система уже загружена и работает. В других случаях ядро "загоняют" в специально выделенный под это раздел, где оно лежит уже не в виде файла, а таким же непрерывным куском, размер и местоположение которого известны. Однако в Linux так поступать не принято, так как места для специального раздела на диске, скажем, IBM-совместимого компьютера может и не найтись.

Во-вторых, можно воспользоваться описанной выше картой размещения : представить ядро в виде набора секторов на диске, записать этот набор в заранее определенное место, а загрузчик заставить собирать ядро из кусков по карте . Использование карты размещения имеет два существенных недостатка: ее создание возможно только под управлением уже загруженной системы, а изменение ядра должно обязательно сопровождаться изменением карты . Если по какой-то причине система не загружается ни в одной из заранее спланированных конфигураций, единственная возможность поправить дело - загрузиться с внешнего носителя (например, с лазерного диска). А система может не загружаться именно потому, что администратор забыл после изменения ядра пересобрать карту : в карте указан список секторов, соответствовавших старому файлу с ядром , и после удаления старого файла в этих секторах может содержаться какой угодно "мусор".

В-третьих, можно научить вторичный загрузчик распознавать структуру файловых систем и находить там файлы по имени. Это заметно увеличит его размер и потребует "удвоения функций" - ведь точно такое же, даже более мощное, распознавание будет и в самом