Нужно четко разделять два варианта загрузки (BIOS и UEFI), и два варианта разметки(MBR и GPT). Это две независимых вещи и 2х2 дает 4 варианта загрузки:
1. BIOS + MBR: самый первый сектор (обычно с номером 0) загружается биосом в память и запускается. Все. Больше от биоса ничего не зависит - всем остальным рулит код в 0-м секторе. И далее все зависит от того - код какого загрузчика туда записан.
В случае dos/windows там записан код, который из таблицы разделов (которая в конце 0-го сектора записана и считана в ОЗУ вместе с кодом) находит активный(boot) раздел, загружает первый сектор из этого раздела и передает ему управление. Дальше уже от кода MBR ничего не зависит - всем рулит код с раздела, а тот уже знает где взять io.sys/ntldr и как их загрузить и запустить. Далее уже загрузка идет утилитами из файловой системы, котрые уже умеют с этой FS работать. Такой механизм может загрузить только загрузчик винды и если надо загрузить что то иное - то надо уже виндовому загрузчику накручивать конфиг.
В случаае GRUB - он бесцеремонно занимает не только 0-й сектор но и весь остаток 0-го трека (он не используются - первый раздел начинается с 1-го трека). Это уже приличный объем кода (не то что 400+ байт в MBR) и там уже размещен более толковый код, который знает где (на каком разделе) лежит следующая фаза загрузки GRUB (причем знает это не по флагам в таблице разделов а по абсолютному пути и даже, если это логический раздел в расширенном). Кроме того там есть простенький (read only) драйверочек для той ФС где лежит следующая фаза GRUBа. Ну и эта следующая фаза загружена - дело в свои руки берет груб со всеми своими причиндалами и наворотами и грузит все, что угодно.
2. BIOS + GPT: На самом деле оригинальный BIOS GPT не знает, он в принципе и MBR разметки не знает (работает с таблицей разделов код в MBR) Правильно называть это уже не BIOS, а модуль обратной совместимости UEFI. Так вот в GPT уже нет места в 0-м секторе на 0-м треке и нельзя пользоваться таблицей разделов в конце MBR - таблица раздело в начале диска и она на несколько секторов. И тут этот модуль совместимости начинает обманывать и установщик ОС и процесс загрузки. При установке ос, все то что установщик попробует записать на 0-й трек, он перенаправляет и записывает в специальный бинарный раздел. А для инициализации системы он берет первый сектор из этого бинарного раздела и передает ему управление, но если этот сектор захочет прочитать 0-й трек, то ему подсунут данные из бинарного раздела.
Ну, а дальше - принципиальной разницы с вариантом 1 - нет.
3 и 4. UEFI + MBR и UEFI + GPT, а вот эти два варианта еще меньше различаются: Тут загрузкой рулит UEFI, который из коробки умеет читать fat32, помнит варианты загрузки и порядок их перебора, позволяет автоматом подгружать различные драйвера (например для других ФС), еще умеет проверять подписи у загружаемого кода (режим SecureBoot)
Так вот для загрузки через UEFI установщик ОС должен свой начальный загрузчик положить на служебный раздел UEFI и еще создать пункт загрузки (в NVRAM переменных uefi), котрый будет ссылаться на этот загрузчик. По дефолту же (если нет пунктов загрузки) загружается EFI\BOOT\BOOTx64.EFI (…x32.EFI для 32-х битных платформ).
А дальше уже загрузчик загруженный со служебного раздела отвечает за загрузку ОС.
Но надо отметить, что загрузчик тут уже не в вакуме полном загружается с примитивным набором прерываний что обеспечивает BIOS, загрузчик это - обычное приложение и выполняется он в окружении мини-ос, которой является сам UEFI. UEFI (как уже было сказано выше) может не только загрузчик запустить, но, например, и предварительно загрузить драйвера ФС тех разделов к которым будет нужен доступ загрузчику.
С UEFI вообще открываются огромные возможности, и в частности можно ядро LINUX прямо из UEFI загрузить (смотри по ссылке UEFI-Boot в подписи). Но если интересно про UEFI - почитайте
эту статью.
Тема: Физическое местоположение загрузчика grub (Прочитано 4034 раз)
