Глава 2. Множественная загрузка

В своей первой системе BIOS, то есть в системах, имеющих установленным BIOS, мы будем устанавливать следующие операционные системы:

Я знаю что эти операционные системы достаточно стары, но я выбрал их по некой причине.

Смотрите, BIOS сам по себе является устаревшим встроенным ПО, а потому если вы желаете разобраться с самим BIOS, вам придётся применять только старые операционные системы. Помните, что вы сможете разобраться с UEFI (современным встроенным ПО) только когда вы поймёте BIOS. Это подобно тому что вы будете лучше понимать Java когда вы также достаточно знакомы с С. Кроме того, применение этих древних операционных систем даст мне шанс также затронуть также и начальные загрузчики Windows и Unix. Кроме того, это также представит мне возможность пояснить наследуемый начальный загрузчик GRUB Linux.

Основная мысль состоит в множественной загрузке нашей системы с BIOS для всех упомянутых ранее операционных систем. Для этого нам потребуется следовать правилам и положениям всех операционных систем.

Таблица 2-2. Правила и положения ОС

ОС	Правила
Unix	Операционные системы Unix (OpenSolaris и BSD) должны устанавливаться только на первичный раздел.
Linux	Linux не обладает никакими правилами установки. Он может устанавливаться на любой первичный или логический раздел.
Windows	Современная операционная система Windows может устанавливаться в любом разделе (первичном или логическом), однако предшественники современного семейства Windows должны быть представленными на самом первом первичном разделе. Это означает, что вы способны установить Windows 7 в неком логическом разделе, однако его предшественник, такой как XP или win2k3, должны быть представленными на самом первом первичном разделе. Кроме того вы не можете ломать последовательность установки операционной системы Windows. Например, невозможно установить сначала Windows 7, а затем более старые win2k3 или XP. Они должны следовать своей последовательности: 98, затем 2000 и потом XP.

Потратьте немного времени и попытайтесь подготовку вашей последовательности установки ОС. Теперь проверьте свою последовательность загрузок.

Окончательная последовательность наших операционных систем выглядит так:

Теперь мы обсудим установку своих операционных систем.

Для системы с BIOS мы можем создать лишь четыре раздела. Но, конечно же, вы видели гораздо большее число разделов нежели это. Итак, позвольте мне видоизменить своё утверждение. В системе на основе BIOS вы можете создать на своём диске только четыре первичных (primary) раздела. Если вы желаете иметь число разделов больше этого, тогда вам требуется превратить свой четвёртый раздел во вторичный (secondary, также имеющего название расширенный - extended) раздел. Этот расширенный раздел будет работать как некий контейнер, а внутри этого контейнера вы можете создавать множество логических (logical) разделов по своему желанию. Почему эти разделы именуются логическими разделами, потому что они не видны для BIOS? Кроме того почему система с BIOS способна делать лишь четыре первичных раздела? На эти вопросы мы ответим при обсуждении Главной загрузочной записи (master boot record).

Давайте вначале разобьём на разделы жёсткий диск своей системы с BIOS. Для этого мы воспользуемся GParted live CD. GParted это некий инструмент из сообщества GNU. Это свободно распространяемый с открытым исходным кодом live ISO образ на основании Debian Linux. Рисунок 2-1 отображает схему разбиения на разделы нашей системы BIOS.

Работа с GParted по разбиению на разделы некого жёсткого диска достаточно прямолинейна. Мы создадим на 75 ГБ дискового пространства схему разбиения на разделы, показанную на Рисунке 2-2.

Для получения дополнительных сведений о том как применять GParted для разбиения на разделы вашего жёсткого диска обратитесь, пожалуйста к документации GParted.

На Рисунке 2-3 вы можете увидеть названия дисков, размеры разделов и связанные с ними флаги (при их наличии).

Давайте установим свою первую операционную систему в самом первом первичном разделе.

На Рисунке 2-4 вы можете увидеть схему разделов, отображаемую установщиком Windows XP.

В самом первом первичном разделе мы установили XP. В терминологии Windows это устройство C:, как это показано на Рисунке 2-4. После завершения этой установки и перезагрузки вашей системы мы получаем на своём экране Windows XP (Рисунок 2-5).

Самое время чтобы разобраться как загрузился Windows XP, но перед этим нам требуется понять построение загрузочного сектора. Загрузочный сектор (boot sector) это первый раздел (512 байт) всякого HDD плюс 31 кБ пространства: иначе говоря, это самые первые 63 сектора вашего носителя загрузки (от 0 до 62). Или же вы можете рассматривать в качестве загрузочного сектора зарезервированным некоторое пространство (512 байт + 31 кБ) каждого из разделов под хранение связанной с начальным загрузчиком информации. Это пространство (снова, 512 байт + 31 кБ) не будет отображаться самой ОС для пользователей. Фактическое хранение данных в разделе начинается после этого зарезервированного пространства. Для лучшего понимания этого обратитесь к Рисунку 2-6.

Имеется удивительное высказывание на санскрите, переводимое так: &qout;Существует лишь одна истина, но разные пути её достижения&qout;. Как показано на Рисунке 2-7, загрузочный сектор имеет различные названия, но в конечном итоге само понятие остаётся тем же самым. Люди именуют эту структуру следующими названиями:

В этой книге мы будем придерживаться именования его загрузочным сектором, потому что устройство жёсткого диска (HDD) всегда делится на сектора, а каждый сектор составляет в размере либо 512 байт, либо 4 кБ. Большинство дисков следуют размеру диска в 512 байт.

В основанной на BIOS системе, всякий производитель ОС (не имеет различия будет ли это Windows, Unix или Linux) должны делить свой начальный загрузчик на три части. Часть 1 начального загрузчика будет оставаться в области самораскрутки, составляющей 440 байт. Часть 2 будет оставаться в разделе начального загрузчика, составляющая в размере 31 кБ, а последняя, часть 3, будет оставаться внутри самого реального раздела, в котором устанавливается конкретная ОС. Итак, проще говоря, при каждой установке ОС (в нашем случае это Windows XP), она делит свой загрузчик новой технологии (NTLDR, New Technology Loader) на три части.

Таблица 2-3. Разбиение начального загрузчика NT

Местоположение	Размер	Часть	Сведения
Область самораскрутки	440 байт	NTLDr part-1	Крошечная часть
Начальный загрузчик	31 кБ	NTLDr part-2	По сравнению с частью 1 имеет больший размер
Внутри раздела реальной ОС	Нет ограничения в размере	NTLDr part-3	Самая большая часть

Но зачем начальный загрузчик делится на три части?

Это происходит по историческим причинам. Первые BIOS обладали техническими ограничениями в том, что они не способны были выполнять доступ к более чем 512 байт или не были способны производить считывание вне своего первого сектора. Поэтому, очевидно, после завершения своей задачи BIOS она просто делала безусловный переход к самым первым 512 байтам всего своего HDD, которые просто и запускали эту программу. К счастью, эта программа будет нашей самораскруткой (440 байт). Поскольку область самораскрутки очень мала в размере, она осуществляет лишь одну вещь, которая состоит в безусловном переходе в некое пространство большего размера, которое и составляет часть 2 нашего начального загрузчика. Он составляет в размере 31 кБ. Эти 31 кБ опять же крайне мало и нам приходится искать ещё дополнительный размер. Этот начальный загрузчик выполняет безусловный переход в часть 3, которая находится внутри некого раздела. Эта часть 3 будет на устройстве C: в файле с названием NTLDR. Такой файл части 3 начального загрузчика XP можно обнаружить на Рисунке 2-8.

Как вы можете видеть, этот файл намного больше в размере (245 кБ). Этот файл выполнит реальное задание своего начального загрузчика по тяжёлому подъёму, состоящее в копировании собственно ядра Windows XP, вызывая winload.exe (этот файл знает где находится ядро XP), из C:\windows в оперативную память. После того как необходимое ядро скопировано в память, задание нашего начального загрузчика выполнено и он уходит прочь. Помните, OS==kernel==OS. После того как наше ядро в памяти, оно позаботится обо всей остающейся последовательности запуска. На Рисунке 2-9 вы можете видеть последовательность запуска XP.

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

Поле подписи производителя служит для производителя HDD. Упоминающиеся здесь сведения сообщают нам о выпустившем этот HDD производителе, таком как Seagate, Western Digital, Samsung и т.п. Поэтому оно в основном содержит информацию о производителе этого HDD.

NULL имеет только 2 байта пространства. NULL означает NULL. Когда он не NULL, наш BIOS будет рассматривать этот диск как отказавший/ сломавшийся в момент процедуры POST и запуск будет прерван. Поэтому он обязан быть NULL. Всякий раз, когда ваша ОС внезапно перезагружается или когда сами ОС или HDD выявляют отказавший сектор или некий вид существенного разрушения, это поле будет помечено как не NULL.

Поле MBR может оказаться наиболее востребованным разделом из всех этих полей. MBR устанавливается для "master boot record" и имеет в размере 64 байта. Далее MBR делится на четыре части. Каждая из частей обладает 16 байтами в размере, а каждая из частей содержит сведения об одном из разделов.

Таблица 2-4. Главная загрузочная запись

Размер	Части	Хранит
16 байт	Part 1	Сведения о первом разделе
16 байт	Part 2	Сведения о втором разделе
16 байт	Part 3	Сведения о третьем разделе
16 байт	Part 4	Сведения о четвёртом разделе

Это означает, что 64 байта MBR способны хранить лишь четыре записи своих разделов и это именно та причина, по которой в системе на основе BIOS вы способны сделать лишь четыре первичных раздела.

Подпись fdisk также именуется флагом загрузки; некоторые называют её просто *, или, в стиле Windows, также имеется название флага активный/ пассивный. Флаг fdisk важен в случае множественной загрузки различных операционных систем, о чёи мы не будем говорить сейчас. Теперь я бы хотел чтобы вы запомнили следующие два правила:

Прямо сейчас эти два правила не имеют для вас никакого значения, но мы обсудим их в правильный момент времени. Рисунок 2-11 отражает полную последовательность запуска Windows XP.

Теперь мы будем устанавливать и запускать некую новую ОС, а именно, OpenSolaris 2008.

OpenSolaris 2008

Рисунок 2-12 отображает экран при загрузке установочного носителя OpenSolaris 2008.

Нам требуется установить OpenSolaris во второй раздел. На Рисунке 2-13 вы можете видеть, что мы выбрали именно второй первичный раздел для своей установки.

Но как вы можете наблюдать на Рисунке 2-14, эта установка отказала с некоторыми сообщениями об ошибках.

Эти сообщения об ошибках относятся к состоянию файловой системы. Поэтому мы подготовим эту файловую систему вручную при помощи утилиты fdisk; тем не менее, перед этим нам следует узнать какое имя жёсткого диска было выделено со стороны OpenSolaris. Сведения об имени выделенного HDD предоставит нам вывод команды pfexec format (отображаемый на Рисунке 2-15).

Итак назначенным жёсткому диску имя это c4d1. Нам надлежит передать имя этого устройства в утилиту fdisk. Посмотрите на выполнение этой команды на Рисунке 2-16.

Наше название указывает на контроллер номер 4, диск номер 1 и раздел номер 0. Через свою утилиту fdisk мы вначале удалим свой второй раздел (который был родным ext3/Linux) и создадим новый раздел с файловой системой Splaris2. Этот новый раздел станет разделом с номером 4. К тому же он автоматически превратится в активный раздел (обратите внимание на Рисунок 2-17). Мы пока не обсуждали часть "подписи активного или fdisk", но вскорости мы вернёмся к этому.

Возвращаясь к своей установке, давайте перезапустим эту установку и, как вы можете видеть на Рисунке 2-18, на этот раз мы выбираем файловую систему OpenSolaris - форматированный раздел для установки OpenSolaris 2008.

На этот раз наша установка не испытывает отказа (обратите внимание на Рисунок 2-19), и OpenSolaris 2008 будет установлен.

После этой установки мы перезагрузим свою систему с BIOS. Какая ОС, как вы полагаете, запустится?

Задержитесь и подумайте прежде чем продолжить...

Рисунок 2-20 отражает что мы получим на экране после перезагрузки.

Итак, загружаемой здесь ОС выступает OpenSolaris и у нас имеется возможность также загрузить и XP. Давайте прольём немного света на то что произошло в фоновом режиме. OpenSolaris обнаружил, что он был установлен в своём собственном разделе (во втором разделе), однако существует и другая ОС, доступная в первом разделе, которой является Windows (или по крайней мере "non-Unix OS").

Но как OpenSolaris узнал что существует другая ОС, установленная в самом первом первичном разделе?

При установке OpenSolaris в его собственный раздел, он обнаружил что подпись fdisk была установлена на самый первый первичный раздел. (И опять, такая подпись fdisk также носит название активного флага или просто флага *.) Как мы уже наблюдали в своей схеме спецификации загрузочного сектора (Рисунок 2-21), каждый раздел обладает 512 байтами + 31 кБ пространства зарезервированными для целей запуска и это пространство скрыто от своего пользователя.

Иными словами, при создании некой схемы разделов через GParted, этот инструмент для каждого из разделов выполняет следующие отделения:

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

Обычно будет иметься четыре записи, причём каждая запись будет потреблять 16 байт. Помимо имеющихся подписи производителя и MBR все прочие поля будут пустыми. Кроме того, обратите, пожалуйста, внимание, что GParted подготовит все необходимые отделения (512 байт + 31 кБ), но заполнит лишь поля подписи производителя и MBR для самого первого первичного раздела.

Возвращаясь обратно к полю подписи fdisk, при установке Windows XP было выставлено следующее:

Затем была установлена подпись fdisk в его собственном разделе (2 байта).

Итак, общая схема диска будет примерно как показанная на Рисунке 2-22.

OpenSolaris обнаруживает эту схему диска. После завершения установки OpenSolaris и когда он намерено установить свой начальный загрузчик (GRUB), он обнаруживает звёздочку (*) в первом первичном разделе и именно тут он осознаёт, что уже имеется установленной ОС Windows. Теперь GRUB (начальный загрузчик OpenSolaris) имеет два варианта:

Обратите, пожалуйста, внимание, что флаг запуска вернулся обратно в раздел OpenSolaris. Кроме того, GParted не понимает раздел Solaris2; следовательно, в качестве названия файловой системы он показывает ext3.

Если OpenSolaris выбирает первый вариант, тогда OpenSolaris должен вычистить Часть 1 и Часть 2 начального загрузчика Windows XP. Это также означает, что будет загружаться лишь OpenSolaris, а Windows XP никогда не будет способен выполнить запуск. Таким образом, OpenSolaris выбирает второй вариант, предоставляя равные возможности для загрузки Windows XP. OpenSolaris также выполняет запись для Windows XP в своих собственных файлах (мы обсудим этот файл позднее в данной главе). Всякий раз когда OpenSolaris приступает к запуску, GRUB справляется со сведениями в этом файле и, если он обнаруживает в нём запись Windows, она будет отражена на экране. Рисунок 2-24 показывает окно приветствия OpenSolaris.

Итак, полная последовательность запуска OpenSolaris такова:

Рисунок 2-27 отображает всю последовательность запуска OpenSolaris целиком.

Когда пользователь выбирает вариант загрузки OpenSolaris, тогда Часть 3 GRUB OpenSolaris знает где расположено ядро OpenSolaris, которое присутствует в каталоге /boot. GRUB скопирует необходимое ядро из /boot в оперативную память и передаст управление этому ядру. Именно так завершается задача начального загрузчика GRUB и он покидает сцену. Теперь само ядро OpenSolaris будет заботиться обо всей остающейся последовательности загрузки. Мы обсудим собственно ядро в Главе 4.

Если пользователь выбирает вариант запуска Windows XP, тогда Часть 3 GRUB OpenSolaris выполнит безусловный переход обратно к Части 1 NTLDR (области самораскрутки). Часть 1 NTLDR осуществит безусловный переход к Части 2 NTLDR. Часть 2 выполнит переход к Части 3. Часть 3 NTLDR загрузит winload.exe в оперативную память. Этот файл winload.exe знает где расположено ядро XP. Оно в конечном счёте будет скопировано или загружено в память посредством NTLDR. После того как ядро XP находится в памяти, задание NTLDR выполнено (помните, kernel=OS=kernel). Так как ядро XP в памяти, именно оно заботится обо всей остающейся последовательности запуска.

PC-BSD 9.0

Наша * или флаг запуска находится в разделе OpenSolaris и мы теперь будем устанавливать PC-BSD 9.0. На Рисунке 2-28 установщик PC-BSD отображает общее число разделов в которых может быть установлена PC-BSD 9.0.

Как вы можете видеть, имеющиеся соглашения об именовании жёстких дисков в BSD отличается от предыдущих ОС. Нам требуется установить BSD в третьем разделе, которым является ada0s2. Это сокращение для "“Adapter number zero and slice number 2". Это сечение (slice) может рассматриваться как некий раздел. Рисунок 2-29 отображает установленную схему диска и соглашения об именовании диска.

Назначаем это пространство ada0s2 для / (корня файловой системы). Рисунок 2-30 отображает схему раздела PC BSD 9.0 Вы также можете обратить внимание на то, что значением файловой системы является UFS, что является Unix File System.

После выполнения установки данная система перезапустится. Теперь потратьте некое время на размышления относительно того, какая именно ОС запустится.

Что из ниже перечисленного произойдёт?

Обратитесь, пожалуйста, к блок- схемам рассмотренных ранее операционных систем и попробуйте выдвинуть свою собственную последовательность запуска.

Как вы можете обнаружить на Рисунке 2-31, загружаемой ОС будет OpenSolaris, которая создаст возможность запуска лишь для Windows.

PC-BSD не запускается. Прежде чем мы пройдём дальше, снова задумайтесь над тем что же произошло.

Вы правы - имеется возможность что PC-BSD могла не оставить * / флаг запуска / подпись fdusk в своём собственном разделе. Давайте проверим что именно это и произошло. Теперь мы загрузимся с GParted (Рисунок 2-32) и проверим свою теорию.

Как вы можете обнаружить на Рисунке 2-33, PC-BSD не обладает установленной * в своём собственном разделе.

Итак, последовательность запуска выглядит как это показано на Рисунке 2-34.

Это означает, что OpenSolaris не знает об установке BSD в своём третьем разделе. Следовательно, надлежащая запись PC-BSD отсутствует в OpenSolaris. Что если мы оставим соответствующий флаг запуска в разделе BSD? Загрузится ли она? Но как нам оставить флаг запуска в своём третьем разделе? Это просто - GParted предоставляет нам такую возможность. Кликните правой кнопкой по своему третьему разделу и выберите необходимый флаг запуска, как это показано на Рисунке 2-35.

Рисунок 2-36 отображает как наша схема диска выглядит после установки флага запуска для третьего раздела BSD.

Теперь, как вы думаете, какая из ОС запустится?

Рисунок 2-37 показывает ответ; после перезапуска загружается лишь PC-BSD, причём она не даёт никаких вариантов запуска каких бы то ни было прочих ОС.

Давайте представим себе как PC BSD управляет запуском.

Занимательная часть запуска BSD состоит в том, что после установки PC-BSD он обнаруживает флаг запуска в своём втором разделе, который выступает разделом OpenSolaris. Теперь у BSD имеются три варианта.

Если BSD выбирает первый вариант (a), тогда способной запускаться будет лишь BSD и это будет несправедливым для прочих установленных операционных систем. Мы бы хотели чтобы BSD выбрал второй вариант (b), так как он установит справедливость для запуска всех прочих ОС, однако BTX является старым начальным загрузчиком и он не обладает возможностью множественного запуска прочих операционных систем. Следовательно, BSD выбирает третий вариант (c). Следовательно именно OpenSolaris и запускается, причём он предоставляет возможность запуска XP. Как вы помните, XP не загружается. Загружается именно OpenSolaris и он считывает свой файл menu.lst и он предоставляет возможность запуска XP. Это также означает, что BSD сам по себе не выбран для запуска.

Что если мы вернёмся обратно и оставим флаг запуска для самого первого раздела Windows XP? Тогда какая ОС запустится? На Рисунке 2-39 мы добиваемся этого.

Именно Windows XP запускается в одиночестве и последовательность запуска проста. Рисунок 2-40 поясняет как Windows XP получает возможность запуска.

Перед установкой своей новой ОС нам надлежит переместить значение флага запуска с третьего раздела BSD на второй раздел OpenSolaris. Рисунок 2-41 Отражает это изменение флага запуска с раздела XP на раздел OpenSolaris.

При данном изменении OpenSolaris приступит к запуску и наряду с ним будет запускаемым также и Windows XP, но BSD не будет иметь возможности загрузки. Итак, означает ли это, что всякий раз,когда мы запускаем BSD нам придётся возвращать флаг запуска обратно в раздел BSD? На данный момент да, но мы автоматизируем всё это при помощи начальных загрузчиков.

Windows Server 2003

Как вы можете наблюдать на Рисунке 2-42, мы будем устанавливать Windows Server 2003 (win2k3) в самом первом логическом разделе. Для win2k3 это будет устройство D:.

Как вы думаете какая ОС запустится после установки?

Прежде чем продолжить, задумайтесь на на минутку и дайте свой собственный ответ. Как вы можете видеть на Рисунке 2-43, загружающейся ОС будет win2k3.

При этом win2k3 предоставит вариант запуска Windows XP. Это означает что запускается лишь семейство операционных систем Windows. Кроме того вот некоторые подлежащие рассмотрению вопросы:

В последующем обсуждении вы получите все необходимые ответы на эти вопросы.

Здесь ясен один момент: win2k3 это единственная запускаемая ОС. Прежде чем обсуждать как она получила возможность для запуска, нам нужно проверить какой сценарий был создан на этом диске для успешного запуска.

После установки win2k3, она обнаружила что она была установлена в неком логическом устройства и что установленный флаг доступа находится в разделе OpenSolaris (согласно Рисунку 2-44).

Чтобы запуститься, win2k3 помещает необходимый флаг запуска в своём собственном разделе при установке частей 1 и 2 своего начального загрузчика (снова, NTLDR) в своих собственных 512 байтах + 31 кБ. Но тут имеется некая проблема. Помните ли вы те правила, которые мы наблюдали в момент установки Windows XP?

По причинам этих двух правил, win2k3 не способна оставлять необходимый флаг запуска в своём разделе и в конечном итоге она не способна запускаться из логического раздела. Рисунок 2-45 отображает почему текущая последовательность запуска, почему win2k3 не способен запуститься с логического раздела. Но в чём причина этих правил?

Это просто: MBR имеет только четыре записи, которые таковы:

Разделом win2k3 является sda5. Иными словами, это диск SATA a (первый) и раздел номер 5. Поскольку наша MBR не обладает записью для логического раздела, часть 2 NTLDR не знает чо существует доступным пятый раздел. Поэтому, даже если win2k3 оставляет необходимый флаг в своём собственном разделе, NTLDR XP не способен его видеть. Следовательно, win2k3 никогда не запустится. Теперь, почему имеющаяся MBR не способна обладать более чем 5 записей? Это по причине того, что 64 байта не способны содержать лишь 4 записи. Почему бы не увеличить имеющийся размер MBR: Действительно, даже если бы разработчики пожелали бы увеличить имеющийся размер установленной MBR, они просто не могут этого. Вы поймёте эту причину когда мы будем обсуждать позднее в этой главе встроенное ПО UEFI.

Теперь когда мы получили для win2k3 проблему курицы и яйца. Она желает запуститься, но для этого ему придётся оставить флаг запуска в своём собственном разделе, но если он это и сделает, то BIOS не сможет обнаружить этот раздел. Как мы разрешим эту проблему?

Какие- то удивительные разработчики разрешили эту задачу и, тот кто придумал это, просто легенда. win2k3 передаёт свой загрузчик NTLDR в самый первый раздел, а именно в Часть 1, Часть 2 и Часть 3. Это также подразумевает, что win2k3 удалит части NTLDR XP, поскольку имеющееся пространство (512 байт + 31 кБ) слишком маленькое и оба начальных загрузчика не смогут там разместиться. (Здесь существует одно сладкое пятно, которое имеет название VBR, что выходит за пределы этой книги.) Тем не менее, при удалении начального загрузчика XP win3k2 делает записи XP в своём текстовом файле и оставляет её в этом самом первом первичном разделе. Этот файл именуется boot.ini, как это отражено на Рисунке 2-46.

При выполнении этого win2k3 оставляет свой флаг запуска только в самом первом первичном разделе. Итак, вот как win2k3 запускается:

Итак, именно таким образом Windows XP и win2k3 способны запускаться. Давайте вернёмся к нашему обсуждению подписей fdisk; загружается лишь win2k3, а прочие ОС не имеют возможности запуска, у меня есть несколько вопросов для ответа:

Задумайтесь на мгновение, повторно рассмотрите блок- схемы и придите к своему ответу.

Готовы? У нас нет возможности загружать только Windows XP. Это невозможно, поскольку в самом Windows XP все части начальных загрузчиков были заменены на NTLDR win2k3. К тому же, win2k3теперь знает где расположен XP и только win2k3 и способен запускать Windows XP. Это также означает, что если Часть 1 начального загрузчика win2k3испорчена или разрушена, мы утратим XP окончательно. Но если мы оставим флаг запуска в PC- BSD, тогда она загрузится как обычно. Рисунок 2-51 отображает последовательность запуска PC-BSD.

Если мы не оставим флаг запуска ни в одном из разделов, загрузка просто не произойдёт. Это походе на ту ситуацию, которую мы обсуждали при рассмотрении того, что произойдёт если в логическом разделе был установлен флаг запуска. Рисунок 2-52 отображает имеющуюся последовательность запуска для пояснения того почему ни одна из ОС не способна запускаться.

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

Теперь, основной вопрос состоит в том, что если мы оставим флаг запуска в разделе OpenSolaris? Запуск OpenSolaris завершится неудачно. Начальный загрузчик OpenSolaris, коим выступает GRUB, выдвинет то сообщение об ошибке, которое отображено на Рисунке 2-53.

Но почему? Он же должен запускаться, не правда ли? В OpenSolaris (512 байт + 31 кБ) ничто не изменено. Просто win2k3 переместил флаг запуска с раздела OpenSolaris на первый первичный. А потому в идеале он должен запускаться, но он не желает этого делать и основная причина состоит в поведении win2k3. Когда win2k3 устанавливался, он столкнулся с ситуацией, аналогичной с той, с которой сталкивались OpenSolaris и PC-BSD. Иными словами, установленный флаг начального запуска находится в ином разделе, а этот раздел обладает иной ОС. Что если OpenSolaris пребывает в той ситуации, когда флаг запуска был перемещён из раздела XP в его собственный раздел, но поскольку это превратит XP в не загружаемую, он щедро делает некую запись для XP в своём собственном файле (menu.lst) OpenSolaris считывает это файл всякий раз и даёт некие равные возможности для запуска XP.

В случае PC-BSD тот выявляет что флаг запуска находится в OpenSolaris и когда он перемещается в его собственный раздел, это сделает OpenSolaris не запускаемым. Следовательно, BSD щедро выбирает не помещать устанавливаемый флаг запуска в его собственном разделе с тем, чтобы другая ОС не превратилась в не загружаемую. Однако win2k3 не обладает такой щедростью. После того, как win2k3 был установлен, он обнаруживает, флаг запуска установлен в ОС не на основе Windows. Поэтому он перемещает флаг запуска в OpenSolaris, но поскольку это не ОС на основе Windows, он не создаёт никакой записи в boot.ini. Продвигаясь далее, win2k3 даже повредил/ удалил Часть 1 GRUB OpenSolaris. Следовательно OpenSolaris не способен теперь запускаться.

Позднее win2k3 прошёл дальше и вычистим начальный загрузчик XP, но он сделал для XP запись в boot.ini, поскольку это операционная система Windows. Именно по этой причине я и сказал, что win2k3 не обладает некой щедростью, которую выказывают OpenSolaris и PC-BSD. Но мы исправим OpenSolaris в разделе Главе 2, этой главы

Windows 7

Как вы можете видеть на Рисунке 2-54 мы устанавливаем в Windows 7 в своём пятом разделе.

Windows не отображает расширенный раздел чтобы на путать обычных пользователей настольных компьютеров.

1st  = XP     2nd = Solaris    3rd  = PC-BSD      4th  = win2k3      5th  = 7
		

Как вы думаете, какая ОС запустится после установки? Как обычно, подумайте какое- то время и предложите свой ответ, прежде чем продолжить с Рисунком 2-55.

Вы верно угадали: Windows 7. Ниже приводится полная последовательность запуска Windows 7:

RHEL 6

Установщик RHEL носит название Anaconda. Установщик Anaconda применяется во всех дистрибутивах на основе Fedora. На Рисунке 2-61 мы запустили установку RHEL 6.

Рисунок 2-62 отображает текущую схему разделов.

Как показано на Рисунке 2-63, нам требуется назначить корень (/) разделу sda7 и переформатировать его ч ext4, которая является файловой системой по выбору RHEL 6.

Как видно из Рисунка 2-64, RHEL 6 (или Anaconda) определила некоторые ОС и она пытается предоставить равные возможности всем прочим ОС (определяемым как Other). Имеется два варианта для записей ОС, которые начальный загрузчик RHEL6 (GRUB) будет показывать в момент запуска.

Что касается RHEL 6, другая ОС будет запускаться с sda5. Это означает следующее:

sda1 = XP
sda2 = Solaris
sda3 = PC BSD
sda4 = Extended partition
sda5 = Win win2k3    <<<-----------
 	   

В момент запуска, если пользователь выбирает вариант Other, предполагается запуск win1k3. Какая ОС запускается после выбора варианта Other? Подумайте немного и приведите собственную последовательность запуска.

Давайте перезапустим эту систему и посмотрим какая ОС запускается. Как показано на Рисунке 2-65, это RHEL 6, которая запускается и предоставляет возможность запуска иной ОС.

Вот как запускается RHEL 6:

Теперь у меня имеется пара вопросов, требующих ответа:

Для всех этих сценариев будет запускаться лишь одна ОС, и это будет RHEL 6 (Рисунок 2-73).

Не имеет значения где вы оставили * или даже когла вы не оставили * ни в одном из разделов, во всех этих случаях будет запускаться только RHEL. Причина этого проста, однако она совсем меняет всю последовательность запуска. Начальный загрузчик Red Hat Enterprise Linux, которым является GRUB, не следует установке * и не проверяет какой из разделов активен перед вызовом Части 3 своего начального загрузчика. На самом деле ни одна из ОС Linux не беспокоится о проверке наличия активного раздела. Они просто пропускают этот шаг. А потому последовательность запуска превращается в такую:

Это также означает, что в настоящее время запускается лишь одна ОС и это RHEL 6. Это плохо! Следовательно, нам требуется подкрутить GRUB для запуска остальных имеющихся операционных систем.

Регулировки GRUB

Наилучшее свойство GRUB состоит в том, что он способен запускать любую прочую операционную систему вне зависимости от того основана она на Linux или нет. Тот трюк, который применяет GRUB для запуска другой ОС прост, но поразителен. Для того чтобы всякий начальный загрузчик загрузил ОС вам не надо ничего иного кроме как загрузить ядро этой соответствующей ОС в память. GRUB знает где располагается ядро ос Linux (/boot/vmlinuz). Однако GRUB не представляет где находится ядро Windows или PC-BSD. Его уловка состоит в том, что начальные загрузчики этих соответствующих операционных систем знают значение местоположения относящихся к ним ядер. А потому GRUB просто вызывает их надлежащие начальные загрузчики; к примеру, если GRUB желает загрузить BSD, он пребывает в третьем первичном разделе. Обратимся к Рисунку 2-74, который отображает схему разделов чтобы получше разобраться в этом.

BSD установил свой начальный загрузчик в зарезервированных 512 байт + 31 кБ своего собственного раздела. Поэтому GRUB вызовет Часть 1 BTX. Это носит название цепочной загрузки (chainloading). Часть 3 начального загрузчика GRUB цепочно загрузит Часть 1 BTX, Часть 1 BTX знает что делать далее, а именно отыскать Часть 2. Часть 2 осуществит безусловный переход к Части 3, а она и запустит ядро BSD в оперативной памяти, а потому BSD начнёт запускаться. Для достижения такой цепочной загрузки нам требуется сообщить GRUB местоположение Части 2 BTX через его файл grub.conf. Этим местоположением будет жёсткий диск номер 1 и раздел номер 3, однако GRUB начинает свой отсчёт с 0, а потому для него местоположением будет жёсткий диск номер 0 и раздел номер 2. Соответствующая запись в /boot/grub.conf выглядит следующим образом:

              title pc-bsd               <<<---- Заголовок записи данной ОС
              rootnoverify (hd0,2)       <<<---- местоположение BTX
              chainloader +1             <<<---- grub будет цепочно запускать BTX
 	   

Как вы можете видеть на Рисунке 2-75, записи всех прочих операционных систем аналогичны BSD; будет изменяться лишь номер соответствующего раздела.

После перезапуска GRUB отобразит записи со значениями title. Обратите внимание на Рисунок 2-76.

Когда пользователь выбирает Windows, он вызовет часть 2 BCD, которым выступает пространство в 31 кБ из самого первого первичного раздела. Это пространство в 31 кБ также имеет название VBR (volume boot record, загрузочной записи тома). Я умышленно опустил объяснение VBR, так как это приводит к излишней путанице. Поэтому, в случае цепочного запуска Windows просто зарубите себе на носу что вместо Части 1 будет вызываться Часть 2. Для тех, кому требуется слегка больше сведений относительно VBR, MBR это главная загрузочная запись для всего жёсткого диска, размещающаяся в самом первом секторе своего жёсткого диска. Каждый том (представляйте его себе как раздел) обладает своей собственной записью запуска, именуемой VBR в качестве самого первого сектора своего раздела. Два названия для двух схожих вещей.

Итак, Часть 2 BCD вызывает Часть 3 BCD, которая расположена в самом первом первичном разделе. Она считает имеющиеся записи BCD ОС (bcdedit.exe), как это отражено на Рисунке 2-77 и выведет их на печать в своём экране.

Если пользователь выберет Earlier Version of Windows (более ранние версии Windows), как мы это наблюдали ранее (в процессе последовательности запуска Windows 7), он запустит Часть 3 NTLDR, которая опять же расположена в этом первом первичном разделе. Как показано на Рисунке 2-78, NTLDR считает необходимый файл boot.ini со своего устройства C и выведет на печать имеющиеся записи ОС.

Когда пользователь выбирает XP, Часть 3 NTLDR знает где расположено необходимое ядро XP. Если вместо этого этот пользователь выбирает win2k3, тогда тот же самый NTLDR загрузит необходимое ядро win2k3 в оперативную память.

Обратите внимание на Рисунок 2-79, который является основным загрузочным экраном, предоставляемым RHEL когда этот пользователь выбирает OpenSolaris.

Ниже приводятся те инструкции, которым будет следовать GRUB:

title Solaris
      rootnoverify (hd0,1)
      chainloader  +1
 	   

Таким образом, Часть 3 GRUB передаст управление области самораскрутки своего второго первичного раздела, но вы помните, что win2k3 вычистил Часть 1 GRUB OpenSolaris. Следовательно, как это видно из Рисунка 2-80, в запуске будет отказано.

Это подразумевает, что нам надлежит в первую очередь исправить начальный загрузчик OpenSolaris. Для такого исправления нам следует загрузиться с образа live CD OpenSolaris, который мы применяли для установки OpenSolaris и после его загрузки установить Части 1 и 2 (Часть 2 этого не требует, но переустановка не испортит нашего предприятия) GRUB с этого live CD в зарезервированные 512 байт + 31 кБ OpenSolaris. Мы применим для этого команду installgrub. Как и предполагает её название, эта команда скопирует Часть 1 (stage1) и Часть 2 (stage2) GRUB со своего live образа и поместит их пространство 512 байт + 31 кБ раздела OpenSolaris. Рисунок 2-81 отображает эту команду в действии.

После очередной перезагрузки RHEL снова отобразит те же самые записи ОС (Рисунок 2-82), так как для RHEL ничего не изменилось.

Когда на это раз мы выбираем OpenSolaris, тогда Часть 3 GRUB RHEL цепочно загрузит Часть 1 GRUB OpenSolaris из своего второго раздела. Часть 1 вызовет Часть 2 и в конце концов та вызовет Часть 3 из реального раздела OpenSolaris. Часть 3 GRUB OpenSolaris считает /rpool/boot/grub/menu.lst и, как это показано на Рисунке 2-83 отобразит на печать на его экране соответствующих заголовков.

Если пользователь выбирает OpenSolaris, тогда Часть 3 GRUB OpenSolaris запустит своё ядро из /boot. Когда пользователь выбирает Windows, тогда Часть 3 GRUB OpenSolaris будет следовать инструкциям из /rpool/boot/grub/menu.lst:

title Solaris
      rootnoverify (hd0,1)
      chainloader  +1
 	   

Теперь мы уже знаем что должно появиться на экране (обратите внимание на Рисунок 2-84).

Наше повествование продолжится если пользователь выберет Earlier Version of Windows, что мы, впрочем, уже обсуждали. Вернёмся обратно к изначальному списку ОС, Рисунок 2-85 отображает что представлено GRUB RHEL.

Когда пользователь выбирает запуск BCD вы в точности знаете что должно произойти. Часть 3 GRUB RHEL цепочно загрузит Часть 1 BTX из своего третьего первичного раздела. Часть 1 BTX вызовет Часть 2, а Часть 2 вызовет Часть 3 BTX. Часть 3 BTX покажет окно приветствия как это отображает Рисунок 2-86.

Когда выбран запуск, Часть 3 BTX загрузит необходимое ядро Unix BCD в оперативную память. Итак, теперь способны запускаться все те операционные системы, которые мы установили на данный момент, причём совершенно не имеет значения какой из разделов является активным. Но можем ли мы взламывать начальные загрузчики Windows и принуждать их к запуску операционных систем Linux и Unix из нашего собственного перечня? Да, это возможно, и именно этим мы сейчас и займёмся.

Взламываем начальный загрузчик Windows

На само деле достаточно просто перехитрить начальные загрузчики Windows. Как мы уже видели ранее, начальные загрузчики выполняют цепочные загрузки; например, Часть 1 вызывает Часть 2 своего начального загрузчика и так далее. Чтобы понять нашу хитрость, давайте выберем в качестве примера BSD. Часть 1 BCD вызывает свою Часть 2 BCD, однако если мы укажем Части 1 BCD цепочно вызвать Часть 1 RHEL, тогда запустится Часть 1 RHEL и она в конечном счёте будет следовать своей собственной последовательности запуска. Часть 1 GRUB (RHEL) вызовет Часть 2 GRUB и в конце концов цепочно запустит Часть 3 GRUB, так как адрес блока Части 3 жёстко закодирован в Части 2. Это означает, что после того как запускается Часть 1 любого начального загрузчика, она далее следует запуску собственной последовательности загрузки, а мы извлекаем преимущества из такого поведения.

Для достижения этого нам требуется получить Части 1 всех не Windows начальных загрузчиков и поместить их в файловую систему самой Windows. По этой причине файловая система может быть FAT32 или NTFS. Очевидно, что размещение Первой части каждого основанного на не Windows начального загрузчика в самом первом первичном разделе имеет наибольшими преимуществами, ибо все операционные системы Windows устанавливают свои соответствующие начальные загрузчики в самом первом первичном разделе. Итак, посредством команды dd мы скопируем самые первые 512 байт (достаточно даже самых первых 440 байт) все основанных не на Windows ОС и поместим их враздел XP. Давайте выполним монтирование самого первого первичного раздела как это отражено на Рисунке 2-87.

Давайте скопируем самые первые 512 байт и поместим их в своём разделе sda1. Для этого отсылаем вас к Рисунку 2-88.

Теперь мы снова выполним запуск XP и, как это показано на Рисунке 2-89, добавим соответствующие файлы записей Частей 1 в свой файл boot.ini. Этот файл boot.ini считывается обоими начальными загрузчиками Windows, и BCD, и NTLDR win2k3.

Ниже приводятся добавленные нами записи:

c:\RHEL.out=&qout;RHEL&qout;
c:\SOLARIS.out = &qout;SOLARIS&qout;
c:\BSD.out=&qout;BSD&qout;
 	   

В точности как и файл grub.conf, всё что записанов двойных кавычках в boot.ini будет рассматриваться как заголовок соответствующей точки ОС. Теперь давайте перезапустим систему и выберем запись ОС из списка ОС RHEL (обратите внимание на Рисунок 2-90).

Как мы достигли этого экрана понять не сложно.

Этот перечень ОС можно увидеть на Рисунке 2-91.

Когда пользователь выбирает Earlier Version of Windows, тогда Часть 3 BCD вызовет Часть 3 NTLDR win2k3. NTLDR снова считает этот файл boot.ini и выведет на печать свой перечень ОС, как это показано на Рисунке 2-92.

Если пользователь выбирает OpenSolaris, тогда Часть 3 NTLDR считает файл Solaris.out с C: (самого первого первичного раздела). Этот файл Solaris.out ни что иное как Часть 1 начального загрузчика OpenSolaris из нашего второго раздела. Часть 1 начального загрузчика OpenSolaris вызывает Часть 2 и в конечном счёте Часть 3 GRUB. Та считывает соответствующий файл menu.lst и выводит на печать свой перечень ОС (Рисунок 2-93).

Если пользователь снова выбирает Windows, тогда Часть 3 OpenSolaris вызовет Часть 2 BCD из самого первого первичного раздела (rootnoverify (hd0,0)). (Часть 2 BCD будет пребывать в соответствующем разделе VBR нашего первого первичного раздела. Мы не обсуждаем в этой книге VBR.) Часть 2 BCD вызывает Часть 3 BCD. Она считывает имеющиеся записи ОС через bcdedit.exe и из boot.ini и выводит на печать эти записи ОС. Такие выведенные на печать на экран записи ОС видны на Рисунке 2-94.

Именнно так мы и создали некий цикл начальных загрузчиков (смотрите на Рисунок 2-95 и Рисунок 2-96).

Как вы можете видеть, Linux запускает Windows, Linux запускает Unix, Unix запускает Windows, Windows запускает Windows и Windows запускает Linux. Однако один момент всё ещё упущен и это Linux, запускающий Linux. Для этого мы установим последнюю ОС из нашего перечня, и это Fedora 15.

Fedora 15

Как показано на Рисунке 2-97, мы устанавливаем Fedora 15 в sda8.

По умолчанию Fedora попытается установить свой начальный загрузчик в самом первом первичном разделе, однако, если допустим это, тогда снова нам потребуется добавлять необходимые записи всех прочих ОС в его grub.conf. Вместо этого мы будем придерживаться иного подхода. Мы установим собственный начальный загрузчик Fedora (GRUB) в его собственном разделе (sda8) вместо sda1. Обратите внимание на Рисунок 2-98.

Это означает, что после перезапуска Fedora никогда не будет способна запуститься, поскольку GRUB RHEL не осведомлён об этой новой ОС, поэтому нам потребуется добавить запись Fedora в grub.conf RHEL. Для этого давайте смонтируем sda8, как это отображено на Рисунке 2-99.

Скопируем записи Fedora (смотрите на Рисунке 2-100) из файла настроек grub.conf GRUB Fedora: /mnt/boot/grub.conf.

Эти записи просты. При каждом вызове Части 3 Fedora она будет запускать необходимое ядро Fedora из /boot/vmlinuz-2.6.38.6-26.rc1.fc15.x86_64 в свою оперативную память. После этого она загрузит initramfs из /boot/initramfs-2.6.38.6-26.rc1.fc15.x86_64.img в свою оперативную память.

Рисунок 2-101 отображает /etc/grub.conf файл RHEL после копирования необходимой записи Fedora bp /mnt/etc/grub.conf.

После перезагрузки мы получаем нужную запись Fedora (Рисунок 2-102).

Когда наш пользователь выбирает для запуска Fedora в качестве записи из файла grub.conf RHEL, Часть 3 GRUB RHEL загрузит соответствующее ядро из своего восьмого раздела (sda8 Fedora) и мы также загрузим initramfs из того же самого места (initramfs мы обсудим в Главе 5), а наш начальный загрузчик уйдёт прочь.

Полная блок- схема

Рисунок 2-103 отображает законченную блок- схему всех ОС, которые мы установили на данный момент.

Я надеюсь, теперь вы разбираетесь в том способе, которым начальные загрузчики запускают свои операционные системы в основанных на BIOS системах. Теперь пришло время разобраться с новым встроенным ПО, которым является UEFI (Unified Extensible Firmware Interface, Универсальный интерфейс расширяемого встроенного программного обеспечения).

Вот некоторые ограничения рассматривавшегося нами до сих пор BIOS:

Почему он обладает такими ограничениями? Встроенное ПО BIOS было разработано в 1982 году для IBM PC-5150 (Рисунок 2-104), который обладал такой конфигурацией:

CPU       = 8088 - 16bit x86 processor
Memory    = upto 256KB max
OS        = MS-DOS
 	   

Как вы можете видеть, этот BIOS был спроектирован для такого ПК 38 лет назад. За эти три десятилетия операционные системы выросли с гибких дисков до дисков NVMe и от текстового режима до сиятельных GUI. Сами аппаратные устройства прошли путь от обычных устройств до подключаемых (plug and play), однако BIOS оставался всё тем же самым, который изначально обладал неким набором 16- битных инструкций, а на последующих этапах начал использовать 43- битный набор инструкций. В наши дни мы обладаем 74- битными ЦПУ, однако сам BIOS всё ещё выполнен на 32- битных инструкциях. Основная причина, по которой мы не обновили свой BIOS до 64- битного обусловлена историческими обстоятельствами. Когла всё работает зачем переписывать чтот- то? Эта та философия, к которой адаптируется вычислительная индустрия в любом случае. Когда наши ЦПУ прошли от 18- битных (8088) до 64- битных (i9), их BIOS оставался 16- битным или 32- битным, ибо на момент самых ранних этапов запуска не было потребности обладать 64- битным ЦПУ и именно по этой причине мы обладаем режимами ЦПУ (real - реальный, protected - защищённый и long - длинный).

В реальном режиме наш ЦПУ будет ограничен 16 битами. В этом режиме будут оаботать такие программы, как старый BIOS, обладающие 16- битными инструкциями. Эти программы не способны запускаться ни в одном ином режиме. Позднее наш ЦПУ будет переключён с реального режима на защищённый режим. Этот защищённый режим является 32- битным и программы этих дней, такие как наш BIOS, которые обладают набором 32- битных инструкций будут запускаться в этом режиме, а позднее наш ЦПУ будет помещён в длинный режим, который является 64- битным. Помните, эти режимы не реализуются самим ЦПУ; вместо этого они реализуются встроенным ПО подобным BIOS. Это означает, что мы перемещаем тот же самый ЦПУ из системы с включённым реальным режимом и помещаем его в систему, которая не обладает реальным режимом, далее тот же самый ЦПУ напрямую запустится в защищённом режиме. Мы снова обсудим эти режимы в Главе 4.

Поскольку BIOS запускается в защищённом режиме, то адресное пространство, которое доступно BIOS составляет лишь 4 ГБ. Если система обладает 20 ГБ памяти, наш BIOS будет способен к адресации до 4 ГБ. Хотя наша система обладает 64- битным процессором i9, её BIOS всё ещё будет способен использовать только его 32- бита. По причине этих аппаратных проблем наш BIOS обладал ограничениями.

Ограничения BIOS

Вот некоторые ограничения BIOS:

Итак, чтобы преодолеть все эти ограничения BIOS, Intel в 1998 году выступила с инициативой Intel Boot Initiative (IBI); позже это превратилось в Расширяемый Интерфейс Прошивки (EFI, Extensible Firmware Interface ). К Intel присоединились все рочие возможные поставщики ОС и оборудования (HP / Apple / Dell / Microsoft / IBM / Asus / AMD / American Megatrends / Phoenix Technologies). Они создали форум открытого исходного кода для данного проекта, и, наконец, он стал Unified Extensible Interface (UEFI).

Этот код с открытыми исходниками подписывается по лицензтт BSD, однако базовый код Intel всё ещё частный. UEFI в целом некая платформа с открытым исходным кодом и производители выстраивают собственные решения поверх него, основываясь на спецификации, производимой UEFI.org. Например, American Megatrends собирает APTIO, Phoenix Technologies выстраивает своё встроенное ПО SecureCore UEFI. Apple была первой, кто осмелился запустить системы с прошивкой UEFI. Все недостатки, которыми обладал BIOS проистекали из его 16- битного набора инструкций. Так как этот набор инструкций ограничивал аппаратные средства BIOS использованием адресного пространства до 1 МБ, UEFI нацелился на это ограничение и разрешил его.

Преимущества UEFI

UEFI поддерживает 64- разрядные процессоры; следовательно, он не сталкивается ни с какими аппаратными ограничениями, с которыми сталкивается BIOS.

GUI UEFI

Рисунок 2-105 отображает реализацию GUI от ASUS.

Вот некоторые моменты на заметку:

Конечно, вам потребуется заполучить непростую материнскую плату для обладания такой богатой реализацией UEFI, но даже базовые реализации UEFI намного лучше реализаций BIOS.

Реализация UEFI

Форум UEFI выпустил свою спецификацию UEFI. Текущей спецификацией UEFI на момент написания данной книги была https://uefi.org/specifications. Эта текущая спецификация обладает 2 551 страницей и все производители (материнских плат, ОС, разработчики UEFI и т.п.) эта спецификация принуждает к соблюдению положений которым обязан следовать каждый производитель. Ниже приводятся некоторые основные положения UEFI.

Системный раздел EFI

Всякий производитель ОС обязан создавать один раздел ESP (EFI System Partition, Системный разде EFI) и его начальный загрузчик должен устанавливаться только в этом разделе. Нет необходимости в создании ESP в качестве первого раздела: он может быть создан где угодно, однако ESP обязан обладать файловой системой FAT16/ 32 (предпочтительно FAT32). Рекомендованный размер ESP минимально составляет 256 МБ. Каждый производитель ОС обязан создавать в ESP приводимую ниже структуру каталога:

EFI System Partition
      ├── EFI
      │     ├── <OS_vendor_name>
      │     │         ├── <boot_loader_files> 
		

После создания такой структуры, эта ОС обязана устанавливать свой начальный загрузчик исключительно внутри местоположения /EFI/<OS_vendor_name>/. Рисунок 2-106 показывает вам структуру UEFI.

Это выглядит как зарезервированное под начальные загрузчики пространство 512 байт + 31 кБ, в то же самое время мы обладаем минимально 256 МБ выделенного пространства для начальных загрузчиков в UEFI. Этот раздел ESP будет смонтирован в Linux в точке монтирования /boot/efi.

EFI

Всякий производитель ОС обязан писать файлы загрузчика в исполняемом формате EFI. Также файлы должны обладать расширение .efi.

Безопасная загрузка

Одной из наилучших предоставляемых UEDI функциональных возможностей является Безопасный запуск (Secure Boot). Это свойство было предложено Mirosoft и позднее было добавлено в имеющуюся спецификацию UEFI. Microsoft впервые применил безопасный запуск в Windows 8. Мы обсудим подробнее Безопасный запуск после того как ознакомимся с тем как рабтает UEFI.

Таблица разделов

Рекомендуемой таблицей разделов является GPT, которая является GUID partition table (Таблицей разделов GUID), в то время как BIOS применяет таблицу разделов MS-DOS.

Для лучшего понимания UEFI мы будем применять тот же самый подход, который мы использовали с системой BIOS. Мы будем применять новую систему с названием UEFI, которая обладает внутри себя встроенным ПО UEFI и мы установим в ней пару ОС.

Перечень операционных систем

Как вы знаете, UEFI применяет таблицу разделов GPT; следовательно, не существует понятия никаких первичных или вторичных/ логических разделов. Это также подразумевает что не существует никакого определённого приоритета для вашей установки операционных систем. Вы можете устанавливать операционные системы любым способом, каким пожелаете. {Прим. пер.: На самом деле это уже не совсем так по причине ограничений Безопасного запуска Windows.} Мы установим их в следующем порядке:

Ubuntu 18.04 LTS

У нас имеется почти 64.4 ГБ HDD. Для создания аналогичной применявшейся нами в системе BIOS схемы разделов нет нужды использовать инструментарий, аналогичный GParted. Вместо этого мы воспользуемся предоставляемой по умолчанию Ubuntu утилитой диска. Ваше внимание на Рисунок 2-107.

Как это отображено на Рисунке 2-109, вначале мф создаём 3 ГБ раздел ESP.

После создания ESP мы сделаем ещё один дополнительный раздел для (10 ГБ) для файловой системы корня Ubuntu. Рисунок 2-109 показывает окончательную схему разделов Ubuntu.

После установки мы можем наблюдать на Рисунке 2-110 что ESP смонтирована в /boot/efi, а наша корневая файловая система смонтирована в sda2.

Помимо этого, в соответствии со спецификацией UEFI Ubuntu создал некую структуру каталога /EFI/ubuntu в точке монтирования /boot/efi (sda1) и установил в нём необходимый начальный загрузчик GRUB. Обратите внимание на Рисунок 2-111.

Кроме того, заметьте расширения .efi для файлов этого начального загрузчика. Ниже приводится вся последовательность запуска Ubuntu в системе UEFI:

В случае с BIOS использовались безусловные переходы подобные следующим:

При применении UEFI безусловный переход (a) пропускается. UEFI напрямую выполняет безусловный переход к (b). Используемому BIOS приходится обладать поделённым на три части начальным загрузчиком по причине ограничений в пространстве, однако UEFI не обладает никакими пространственными ограничениями. Следовательно, весь начальный загрузчик целиком доступен в одном отдельном исполняемом файле. Например, в случае Ubuntu, grubx64.efi имеет все части один, два и три добавленными в единственный исполняемый файл, которым и выступает grubx64.efi.

Этот файл grubx64.efi в конечном счёте загрузит необходимое ядро (vmlinuz) из /boot в свою оперативную память, причём далее задание начальных загрузчиков GRUB Ubuntu выполнено. Рисунок 2-114 отображает полную блок- схему последовательности запуска Ubuntu.

Windows 10

Как вы можете наблюдать на Рисунке 2-115, разделом й выступает ESP, а разделом 2 является корень (/) Ubuntu.

Теперь мы создадим некий новый раздел для Windows. При создании какого- то нового раздела Windows зарезервирует некое пространство для инструмента восстановления Windows с наименованием MSR (Microsoft Recovery, раздел 4). Обратите внимание на Рисунок 2-116.

Как показано на Рисунке 2-117, в соответствующем вновь создвнном разделе 4 мы установим Windows 10.

Windows по умолчанию обнаружит установленный раздел ESP и, следуя спецификации UEFI, он создаст каталог с наименованием Microsoft и установит в нём свой начальный загрузчик (BCD). Если Windows не обнаружит ESP, тогда он создаст его для нас. Поскольку Windows в основном предназначен для пользователей настольных систем, он не будет отображать раздел ESP (обратитесь к Рисунку 2-118) тем способом, которым показывает его Ubuntu.

Вот как Windows 10 будет запущен в системе на основе UEFI:

Fedora 31

Последней устанавливаемой нами ОС является Fedora 31. Как показано на Рисунке 2-122, мы снова создадим некий стандартный раздел, которым выступает sda5 и мы смонтируем /dev/sda1 (ESP) в /boot/efi.

Помните, нельзя форматировать sda1, коим является ESP. Утрата ESP означает утрату установленных начальных загрузчиков Windows и Ubuntu. После установки нам будет представлен GRUB Fedora с имеющимся списком ОС (Рисунок 2-123).

При установке GRUB, установщик Fedora Anaconda определяет в ESP прочие операционные системы. Чтобы предоставить им равные возможности запуска, Fedora добавляет записи Ubuntu и Windows в grub.cfg. Ниже приводится вся последовательность запуска Fedora:

Оболочка UEFI

UEFI это небольшая операционная система. Как и обычные операционные системы, UEFI предоставляет для запуска своих приложений некую необходимую среду. Естественно, UEFI не будет способна запускать все исполняемые файлы, однако те исполняемые файлы, которые собраны в исполняемом формате EFI будут запросто запускаться. Одним из самых наилучших прикладных приложений UEFI является её оболочка. Как показано на Рисунке 2-128, вы можете обнаружить её главным образом в настройках приоритета запуска UEFI.

Если ваша реализация UEFI не предоставляет своей оболочки, тогда вы можете выгрузить необходимое прикладное приложение оболочки с сайта проекта TianoCore со страницы GitHub EDK-II:

https://www.tianocore.org/

https://github.com/tianocore/edk2/blob/UDK2018/ShellBinPkg/UefiShell/X64/Shell.efi

Отформатируйте своё устройство USB под файловую систему FAT32 и поместите там свой выгруженный файл Shell.efi. Снова загрузитесь с тем же самым USB устройством и UEFI предоставит вам в своём окне приоритета запуска оболочку UEFI. Обратите внимание на Рисунок 2-129.

Здесь стоит отметить удивительный момент, состоящий в том, что UEFI не отображает факт, что ваша система обладает неким подключённым устройством. Вместо этого UEFI проходит вовнутрь этого устройства USB и обнаруживает известную ему файловую систему FAT32. Оно видит соответствующий файл Shell.efi и осознаёт, что это не обычное прикладное приложение; вместо этого оно будет представлять свою оболочку соответствующему пользователю. Если бы имелся BIOS, он бы отобразил лишь то, что система обладает подключённым диском USB, но в нашем случае UEFI отображает некую оболочку внутри какого- то подключённого USB диска.

В тот момент когда вы выберете вариант Launch EFI Shell from USB drives (Запуск оболочки с USB устройства), будет выполнен файл Shell.efi и вам будет представлена некая оболочка (Рисунок 2-130) и при этом не представлена некая ОС. Это поразительно.

Записи blk* являются названиями имеющихся устройств, в то время как fs* это соглашение о присвоении имён файловым системам. Так как эта оболочка UEFI способна считывать файловую систему FAT32 (раздел ESP), мы способны просматривать каталог ESP, как это показано на Рисунке 2-131.

fs0 это сокращение для файловой системы с номером 0. Это внутренняя команда оболочки, которую мы можем применять для изменения своего раздела. Как вы можете видеть из Рисунка 2-132 и Рисунка 2-133, fs2 это наш ESP.

Мы можем просто запускать свой файл grubx64.efi из нашей оболочки и на экране появится GRUB. Посмотрите на Рисунок 2-134.

Для оболочки UEFI grubx64.efi это просто прикладное приложение. Аналогичным образом, как это показано на Рисунке 2-135 мы можем запускать также и начальный загрузчик Windows. Обратите также внимание на Рисунок 2-136.

Наша оболочка может оказаться полезной в разрешении ситуаций "can’t boot". Рассмотрим ситуацию, отображаемую на Рисунке 2-137, при которой наша система выдаёт некую ошибку в строке приглашения GRUB.

Воспользовавшись некой оболочкой UEFI мы получаем возможность проверки будут ли присутствовать относящиеся к GRUB файлы или нет.

Недоразумения относительно UEFI

Далее приводятся некоторые неверные представления об UEFI.

Недоразумение 1: UEFI это некий новый BIOS или UEFI и есть BIOS

Люди продолжают говорить что UEFI это новый BIOS. Действительно, когда вы заходите вовнутрь встроенного программного обеспечения (ПО) UEFI, это встроенное ПО само по себе сообщает что оно является UEFI BIOS. Подтверждением является Рисунок 2-138.

Нет, UEFI это и не BIOS, и не новый BIOS. UEFI здесь для замены BIOS. UEFI это совершенно новое встроенное ПО и вы не можете обладать в одной и той же системе BIOS и UEFI. Вы имеете либо UEFI, либо BIOS.

Достаточно просто выяснить обладаете ли вы BIOS или UEFI. Если вы способны применять мышь как устройство ввода внутри своего встроенного ПО, тогда вы имеете UEFI и когда вы обладаете богатым GUI, тогда у вас присутствует UEFI. Самый правильный способ для проверки состоит в применении подобия команды efibootmgr:

# efibootmgr -v

Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables.
Try 'modprobe efivars' as root.
		

Когда вы получаете в системе Linux из команды efibootmgr вывод, подобный отображённому, тогда вы обладаете BIOS. В случае когда вы имеете UEFI вы получите нечто подобное следующему:

# efibootmgr -v

BootCurrent: 0005
Timeout: 2 seconds
BootOrder: 0005,0004,0003,0000,0001,0002,0006,0007,000A
Boot0000* EFI VMware Virtual SCSI Hard Drive (0.0)
      PciRoot(0x0)/Pci(0x15,0x0)/Pci(0x0,0x0)/SCSI(0,0)
Boot0001* EFI VMware Virtual SATA CDROM Drive (1.0)
      PciRoot(0x0)/Pci(0x11,0x0)/Pci(0x4,0x0)/Sata(1,0,0)
		

Именно это самый верный способ выявления какое именно встроенное ПО имеет ваша система. Возвращаясь к нашему обсуждению UEFI BIOS, применяющие это производители используют совместно термины UEFI и BIOS потому что большинство пользователей не понимают термин UEFI. Например, некая статья, сообщающая "измените параметры в вашем UEFI" может оказаться обескураживающим для большинства пользователей, однако сказав "измените параметры в вашем BIOS", вы сделаете это хорошо понятным всякому. Таким образом, производители применяют такой термин UEFI/ BIOS ради понимания, однако помните, что в некий момент времени вы обладаете только одним встроенным ПО, а не обоими.

Недоразумение 2: Microsoft это зло

Как мы уже видели, UEFI - это собрание, в котором участвуют поставщики операционных систем, включая Microsoft. Для осуществления более безопасной загрузки Microsoft предложила в UEFI функцию Безопасной загрузки (Secure Boot). Безопасная загрузка остановит выполнение несанкционированных или скомпрометированных исполняемых файлов во время загрузки. Это решает следующие три задачи:

Вот как работает Безопасная загрузка:

Достаточно клёвая реализация Microsoft, не так ли? Да, несомненно. Однако когда свойство Безопасной загрузки включено, а вы выбираете для загрузки Linux, возникнет ещё одна проблема. UEFI будет получать общедоступный ключ Microsoft и вырабатывать значение цифровой подписи для grubx64.efi. Такая выработанная цифровая подпись, естественно, не будет соответствовать файлам начальной загрузки Microsoft. Иначе говоря, Linux или любая отличная от Windows ОС никогда не будет способна загружаться. Поэтому, в чём состоит решение? Самое простое? UEFI обязан предоставлять некий вариант для отмены того свойства Безопасной загрузки которое он применяет. Обратите внимание на Рисунок 2-139. На самом деле вариант отключения свойства Безопасной загрузки должен быть представлена во встроенном ПО UEFI. Именно это выставляется в требованиях спецификации UEFI.

Однако Microsoft ясно заявила, что сертифицированными будут лишь те системы, у которых включена Безопасная загрузка. Это означает, что если вы поставщик оборудования и желаете чтобы ваша система была сертифицирована для Windows, тогда для неё обязательно должна быть включена Безопасная загрузка. Некоторые лидеры в отрасли сочли этот шаг "злом", поскольку отличные от Windows операционные системы не будут иметь возможности запуска на этом оборудовании. Мы вернёмся к обсуждению является Microsoft злом или нет, но вначале давайте рассмотрим какие возможности имеются у отличных от Windows ОС.

Производители Linux должны выпускать свою собственную пару ключей

Да, всякий производитель ОС Linux обязан делать свою собственную пару ключей и затем подписывать свои начальные загрузчики собственным частным ключрм и оставлять свой общедоступный ключ во встроенном ПО UEFI. Всякий раз, когда пользователь выбирает для загрузки Windows, UEFI будет применять имеющийся общедоступный ключ Windows, а если этот пользователь выбирает для загрузки Linux, UEFI будет применять общедоступный ключ этого Linux для восстановления значения цифровой подписи файлов начального загрузчика своего Linux. Кажется что это будет неким простым решением, но это не сработает. На современном рынке присутствует почти 200 с лишком активных дистрибутивов Linux и они имеют новые версии, выпускаемые каждые шесть месяцев. Это означает, что почти каждые шесть месяцев вы будете иметь более новые версии дистрибутива Linux на устоявшемся рынке. Грубо говоря, это подразумевает, что производители Linux будут иметь почти 400 ключей в год, а потому очевидно, что вы не сможете поместить такое большое число ключей в UEFI. Даже если бы вы и могли, это будет препятствовать одному из основных лозунгов UEFI - быстрой загрузке. Короче говоря, это не может быть решением.

Все производители Linux обязаны выпускать лишь единственную пару ключей

Это также не может быть решением. Имеется 200+ активных дистрибутивов Linux, а их офисы разбросагы по всему миру. Если бы все производители Linux собрались вместе и сделали бы лишь одну пару ключей, тогда эту пару следовало бы отгружать через Интернет имеющимся разработчикам по всему миру. Это стало бы ночным кошмаром безопасности. Поэтому, если кратко, это было бы сложным для сопровождения; следовательно это не является решением.

Отключение свойства безопасной загрузки UEFI

Это выглядит как единственный рабочих подход. UEFI предоставляет некую возможность отключения функциональности Безопасного запуска, а Microsoft не имеет никаких причин для протеста против этой возможности. Например, сажем, у вас имеется система с дуальной загрузкой, в которой установлены Windows 10 и Fedora 31. Когда вы желаете загружать Windows, тогда Безопасная загрузка включается в UEFI, а если в следующий раз вы пожелаете загружать Linux, тогда вам придётся пройти вовнутрь UEFI и изменить такую включённую Безопасную загрузку в сотсояние отключённой. Вы можете рассмотреть такой окольный путь, но он не практичен; следовательно, он не может рассматриваться в качестве некого решения.

Итак, как Linux способен воспользоваться преимуществом Безопасной загрузки? Имеется лишь одно решение и оно состоит в применении частного ключа Microsoft для цифровой подписи соответствующих файлов начальной загрузки Linux и предвкушая это Microsoft согласился на это. Итак, на данном этапе Linux имеет возможность Безопасной загрузки при помощи пары ключей Microsoft, а следовательно Microsoft определённо не выступает злом. Они просто хотели бы сделать свою последовательность загрузки безопасной.

Однако при таком урегулировании имеется одна проблема; разработка GRUB будет зависеть от пары ключей Microsoft. Когда в GRUB фиксируется новое изменение, нам требуется его повторная подпись при помощи ключа Microsoft. Ubunru разрешил эту проблемы введя начальный загрузчик меньшего размера с названием Прокладка (shim). Предполагается, что этот начальный загрузчик подписан ключом Microsoft, а затем задание этого начального загрузчика состоит в вызове реального начального загрузчика, коим и является GRUB. При таком подходе мир Linux разрывает зависимость от подписи Microsoft. Поскольку Прокладка никогда не изменяется (по крайней мере это не должно происходить часто), разработчики GRUB продолжают имеющийся у них способ развития.

Итак, когда Безопасная загрузка включена, тогда необходимая последовательность загрузки Linux такова:

Чтобы увидеть весь список вовлечённых в данную последовательность запуска файлов отсылаем вас к Рисунку 2-140.

Недоразумение 3: Отключаем UEFI

Одним из самых больших неверных представлений является то, что вы имеете возможность отключить UEFI и запустить BIOS. Нет, вы не способны запрещать имеющееся встроенное ПО своей системы; также вы не можете обладать двумя встроенными ПО в одной системе. У вас есть либо UEFI, либо BIOS. Когда люди произносят "отключаем BIOS", это означает, что они хотели бы сказать пусть UEFI загрузится с BIOS или неким совместимым образом. Одной из самых крупных функциональностей UEFI является её обратная совместимость, что подразумевает что она действительно понимает способ загрузки BIOS, который заключается в подходе 512 байт + 31 кБ. Поэтому, когда вы изменяете настройки со способа UEFI на наследуемый порядок, это всего лишь означает, что UEFI не будет следовать предписываемому ESP способу запуска. Вместо этого, имеющееся встроенное ПО будет следовать способу запуска BIOS, однако это не означает что вы отключаете само встроенное ПО UEFI. Когда вы запускаете свою систему способом BIOS, тогда вы теряете все те функциональные возможности, которые предоставляет UEFI.

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