GNU GRUB: загрузчик операционных систем

Введение

Пакет загрузчика GNU GRUB (сокращение от GNU GRand Unified Bootloader, обычно называемый GRUB) — это пакет загрузчика проекта GNU. GRUB является эталонной реализацией спецификации Multiboot от Free Software Foundation, предоставляющей пользователю возможность загрузить одну из нескольких установленных на компьютере операционных систем или выбрать определенную конфигурацию ядра, доступную на разделах конкретной операционной системы. GNU GRUB был разработан на основе пакета под названием Grand Unified Bootloader (игра слов, отсылающая к теории великого объединения). Он преимущественно используется в Unix-подобных системах.

Загрузка

Когда компьютер включается, его BIOS находит основное загрузочное устройство (обычно жесткий диск компьютера) и запускает начальную программу загрузки из главной загрузочной записи (MBR). MBR — это первый сектор жесткого диска. Эта программа загрузки должна быть небольшой, так как она должна помещаться в один сектор. Долгое время размер сектора составлял 512 байт. С 2009 года доступны жесткие диски с размером сектора 4096 байт, называемые дисками Advanced Format, но по состоянию на 2013 год к таким дискам все еще осуществляется доступ в секторах 512 байт с использованием эмуляции 512e. Традиционная таблица разделов MBR поддерживает максимум четыре раздела и занимает 64 байта. Вместе с необязательной подписью диска (четыре байта) и временной меткой диска (шесть байт) это оставляет от 434 до 446 байт, доступных для машинного кода загрузчика. Хотя такого небольшого пространства может быть достаточно для очень простых загрузчиков, его недостаточно для загрузчика, поддерживающего сложные и многочисленные файловые системы, меню выбора вариантов загрузки и т. д. Поэтому загрузчики с большим объемом кода разделяются на части, где самая маленькая часть помещается в MBR, а одна или несколько больших частей хранятся в других местах, например, в пустых секторах между MBR и первым разделом. Код в MBR затем выполняет лишь запуск второй части. Цель оставшейся части загрузчика — фактически загрузить операционную систему, настроив ее и запустив ядро. Ядра в большинстве случаев хранятся как файлы, расположенные в соответствующих файловых системах, но концепция файловой системы BIOS неизвестна. Таким образом, в системах на основе BIOS задача загрузчика — получить доступ к содержимому этих файлов, чтобы их можно было загрузить в оперативную память и выполнить. Один из возможных подходов для загрузчиков — загружать образы ядра, напрямую обращаясь к секторам жесткого диска без понимания базовой файловой системы. Обычно требуется дополнительный уровень косвенности в виде карт или файлов карт, содержащих список физических секторов, занятых образами ядра. Такие карты необходимо обновлять каждый раз, когда образ ядра меняет свое физическое местоположение на диске из-за установки новых образов ядра, дефрагментации файловой системы и т. д. Кроме того, в случае изменения физического местоположения карт их местоположение необходимо обновлять в коде MBR загрузчика, чтобы механизм косвенности секторов продолжал работать. Это не только сложно, но и оставляет систему нуждающейся в ручном восстановлении в случае возникновения проблем во время обновления системы. Другой подход — сделать загрузчик осведомленным о базовых файловых системах, чтобы образы ядра настраивались и к ним обращались с использованием их фактических путей к файлам. Это требует, чтобы загрузчик содержал драйвер для каждой поддерживаемой файловой системы, чтобы он мог понимать и получать к ним доступ. Этот подход устраняет необходимость в жестко закодированных местоположениях секторов жесткого диска и существовании файлов карт, а также не требует обновления MBR после добавления или перемещения образов ядра. Конфигурация загрузчика хранится в обычном файле, к которому также осуществляется доступ в файловой системе для получения конфигураций загрузки перед фактической загрузкой каких-либо образов ядра. Таким образом, во время обновления системы может произойти меньше ошибок. Недостатком является то, что такие загрузчики больше и сложнее. boot.img (этап 1) записывается в первые 440 байт главной загрузочной записи (код загрузки MBR в секторе 0) или, опционально, в загрузочный сектор раздела (PBR). Он адресует diskboot.img с помощью 64-битного LBA-адреса. Фактический номер сектора записывается программой grub install. diskboot.img — это первый сектор core.img, предназначенный исключительно для загрузки остальной части core.img, идентифицированной номерами секторов LBA, также записанными программой grub install. На дисках с разделением MBR core.img (этап 1.5) хранится в пустых секторах (если они доступны) между MBR и первым разделом. Современные операционные системы предлагают здесь промежуток в 1 МиБ для выравнивания (2047 секторов по 512 байт или 255 секторов по 4 КиБ). Этот промежуток ранее составлял 62 сектора (31 КиБ) в качестве напоминания об ограничении номера сектора адресации Cylinder Head Sector (C/H/S), используемой BIOS до 1996 года, поэтому core.img разработан так, чтобы быть меньше 32 КиБ. На дисках с разделением GPT core.img записывается в свой собственный раздел. Он должен быть помечен как "BIOS grub", не должен быть отформатирован и может быть таким же маленьким, как 1 МиБ. Этап 2: core.img загружает /boot/grub/i386-pc/normal.mod из раздела, настроенного программой grub install. Если индекс раздела изменился, GRUB не сможет найти normal.mod и отобразит пользователю запрос GRUB Rescue. В зависимости от того, как был установлен GRUB2, /boot/grub/ находится либо в корневом разделе дистрибутива Linux, либо в отдельном разделе /boot. После загрузки normal.mod: normal.mod анализирует /boot/grub/grub.cfg, опционально загружает модули (например, для графического интерфейса и поддержки файловой системы) и отображает меню.

When a computer is turned on, its BIOS finds the primary bootable device (usually the computer's hard disk) and runs the initial bootstrap program from the master boot record (MBR). The MBR is the first sector of the hard disk. This bootstrap program must be small because it has to fit in a single sector. For a long time, the size of a sector has been 512 bytes. Since 2009 there are hard disks available with a sector size of 4096 bytes, called Advanced Format disks, but as of 2013, such hard disks are still accessed in 512 byte sectors, using the 512e emulation. The legacy MBR partition table supports a maximum of four partitions and occupies 64 bytes, combined. Together with the optional disk signature (four bytes) and disk timestamp (six bytes), this leaves between 434 and 446 bytes available for the machine code of a boot loader. Although such a small space can be sufficient for very simple boot loaders, it is not big enough to contain a boot loader supporting complex and multiple file systems, menu driven selection of boot choices, etc. Boot loaders with bigger footprints are therefore split into pieces, where the smallest piece fits in the MBR, while one or more larger pieces are stored in other locations such as empty sectors between the MBR and the first partition. The code in the MBR then does little more than starting the second part. The purpose of the remaining part(s) of the boot loader is to actually boot an operating system by configuring it and starting the kernel. Kernels are in most cases stored as files residing on appropriate file systems, but the concept of a file system is unknown to the BIOS. Thus, in BIOS based systems, the duty of a boot loader is to access the content of those files, so it can be loaded into the RAM and executed. One possible approach for boot loaders is to load kernel images by directly accessing hard disk sectors without understanding the underlying file system. Usually, an additional level of indirection is required, in form of maps or map files auxiliary files that contain a list of physical sectors occupied by kernel images. Such maps need to be updated each time a kernel image changes its physical location on disk, due to installing new kernel images, file system defragmentation, etc. Also, in case of the maps changing their physical location, their locations need to be updated within the boot loader's MBR code, so the sectors indirection mechanism continues to work. This is not only cumbersome, but it also leaves the system in need of manual repairs in case something goes wrong during system updates. Another approach is to make a boot loader aware of the underlying file systems, so kernel images are configured and accessed using their actual file paths. That requires a boot loader to contain a driver for each of the supported file systems, so they can be understood and accessed by the boot loader itself. This approach eliminates the need for hardcoded locations of hard disk sectors and existence of map files, and does not require MBR updates after kernel images are added or moved around. The configuration of a boot loader is stored in a regular file, which is also accessed in a file system aware way to obtain boot configurations before the actual booting of any kernel images. Thus, fewer things can go wrong during system updates. As a downside, such boot loaders are larger and more complex. boot. img (stage 1) is written to the first 440 bytes of the Master Boot Record (MBR boot code in sector 0), or optionally in a partition boot sector (PBR). It addresses diskboot. img by a 64 bit LBA address. The actual sector number is written by grub install. diskboot. img is the first sector of core. img with the sole purpose to load the rest of core. img identified by LBA sector numbers also written by grub install. On MBR partitioned disks, core. img (stage 1.5) is stored in the empty sectors (if available) between the MBR and the first partition. Recent operating systems suggest a 1 MiB gap here for alignment (2047 512 byte, or 255 4KiB, sectors). This gap used to be 62 sectors (31 KiB) as a reminder of the sector number limit of Cylinder Head Sector (C/H/S) addressing used by BIOS before 1996, therefore core. img is designed to be smaller than 32 KiB. On GPT partitioned disks core. img is written to its own partition. It must be flagged "BIOS grub", must not be formatted and can be as tiny as 1 MiB. stage 2: core. img loads /boot/grub/i386 pc/normal. mod from the partition configured by grub install. If the partition index has changed, GRUB will be unable to find the normal. mod, and presents the user with the GRUB Rescue prompt. Depending on how GRUB2 was installed, the /boot/grub/ is either in the root partition of the Linux distribution, or in the separate /boot partition. after normal. mod loaded: normal. mod parses /boot/grub/grub. cfg, optionally loads modules (eg. for graphical UI and file system support) and shows the menu.

Запуск систем с использованием прошивки UEFI

/efi/<distro>/grubx64.efi (для систем UEFI x64) устанавливается как файл в системном разделе EFI и загружается прошивкой напрямую, без использования boot.img в секторе MBR 0. Этот файл выполняет функции этапов 1 и 1.5. Директория /boot/grub/ может быть установлена как в системном разделе EFI, так и в отдельном разделе /boot. Для систем UEFI x64 этапом 2 являются файл /boot/grub/x86_64.efi/normal.mod и другие файлы в директории /boot/grub/.

Идентификация разделов (обходные решения для UID)

Компьютер может иметь несколько жестких дисков, подключенных к нему. Их можно идентифицировать через порт SATA. Каждый раз, когда компьютер проходит POST, жесткий диск, подключенный к порту 1 (материнской платы), может быть назначен одним и тем же идентификатором, например. Но что, если такая согласованность не может быть гарантирована? Что, если состав подключенных жестких дисков изменился с одного запуска на другой? Что, если жесткий диск должен быть подключен к другому компьютеру? Войдя в консоль восстановления GRUB (доступную после загрузки core.img) или консоль GRUB (доступную после загрузки normal.mod), можно получить список всех доступных жестких дисков и разделов. Либо путем предположений, либо путем дальнейшего исследования (например), эти номера можно сопоставить с фактическими жесткими дисками и разделами. Поскольку нельзя гарантировать, что нумерация жестких дисков с помощью простых чисел будет последовательной, GNU GRUB может использовать UUID для идентификации разделов (фактически, экземпляров файловой системы) – если они поддерживают эту функцию. Файловые системы ext2, ext3, ext4 и xfs используют универсальный уникальный идентификатор (UUID) для уникальной идентификации экземпляра. UUID создается при форматировании раздела. UUID является частью файловой системы и записывается в суперблок. Все операции, кроме форматирования, должны оставлять UUID неизменным, но его можно изменить или продублировать (например, с помощью dd для клонирования всего раздела). Файл используется для настройки GRUB. В этом файле хранятся команды, которые должны быть выполнены при каждом запуске. Без существующего и корректного , GRUB отобразит приглашение. Абсолютный минимум может содержать только следующие две команды (см. initial ramdisk):
linux (hd0,1)/kernel/vmlinuz 3.20.1 4 ro # используйте файл с именем "vmlinuz", расположенный в каталоге /kernel на первом разделе первого жесткого диска, в качестве образа ядра Linux.
initrd (hd0,1)/boot/initrd.img 3.20.1 4 # используйте файл с именем "initrd.img", расположенный в каталоге /boot на первом разделе первого жесткого диска, в качестве начального RAM-диска.

A computer can have multiple hard disks connected to it. These could be identified via their SATA port. Each time the computer POSTs, the hard disk connected to port 1 (of the motherboard), could be assigned the same identifier, e. g. But what if such consistency cannot be guaranteed? What if the constellation of connected hard disks changed from one start up to another? What if a hard disk shall be connected to another computer? By entering into either the in GRUB rescue console (available after loading core. img ) or the GRUB console (available after loading normal. mod) a list of all available hard disks and partitions can be obtained. Either by guessing or by further investigation (e. g. ) can these numbers be assigned to actual hard disks and partitions. As it cannot be guaranteed that the numbering of hard disks via dumb numbers is consistent, GNU GRUB can use the UUID to identify partitions (actually file system instances) – that have this feature – instead. The file systems ext2, ext3, ext4 and xfs use an Universally Unique Identifier (UUID) to uniquely identify an instance. The UUID is created when a partition is formatted. The UUID is part of the file system and written to the superblock. All operations but a formatting should leave the UUID unaltered, but it is possible to change it or duplicate it (by using dd to clone an entire partition). The file is used to configure GRUB. It is the file where the commands which shall be executed during each start up are stored. Without an existing and valid , GRUB will present a prompt. An absolute minimal might contain only the following two commands (cf. initial ramdisk):
linux (hd0,1)/kernel/vmlinuz 3.20.1 4 ro # use the file name "vmlinuz " located in the directory /kernel on the first partition of the first hard disk as linux kernel image
initrd (hd0,1)/boot/initrd. img 3.20.1 4 # use the file named "initrd. img– " located in the directory /boot on the first partition of the first hard disk as initial ramdisk

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

История

GRUB был первоначально разработан Эрихом Болейном в ходе работы над загрузкой операционной системы GNU/Hurd, разработанной Фондом свободного программного обеспечения. В 1999 году Гордон Матцигкейт и Йосинори К. Окудзи сделали GRUB официальным пакетом программного обеспечения проекта GNU и открыли процесс разработки для широкой публики.

Разработка

GRUB версия 1 (также известная как "GRUB Legacy") больше не разрабатывается и постепенно выводится из эксплуатации. Разработчики GNU GRUB переключили своё внимание на GRUB 2 – полную переработку, целью которой является создание GNU GRUB более чистым, надёжным, переносимым и мощным. GRUB 2 начинался под названием PUPA. PUPA поддерживался Агентством по продвижению информационных технологий (IPA) в Японии. PUPA был интегрирован в разработку GRUB 2 примерно в 2002 году, когда версия GRUB 0.9x была переименована в GRUB Legacy. Среди целей проекта GRUB 2 – поддержка платформ, отличных от x86, интернационализация и локализация, поддержка символов, отличных от ASCII, динамические модули, управление памятью, мини-язык сценариев, перенос платформенно-зависимого (x86) кода в платформенно-зависимые модули и объектно-ориентированная структура. Версия GNU GRUB 2.00 была официально выпущена 26 июня 2012 года. Три наиболее широко используемых дистрибутива Linux используют GRUB 2 в качестве основного загрузчика. Ubuntu приняла его в качестве загрузчика по умолчанию в версии 9.10, выпущенной в октябре 2009 года. Fedora последовала за ней с Fedora 16, выпущенной в ноябре 2011 года. OpenSUSE приняла GRUB 2 в качестве загрузчика по умолчанию с выпуском 12.2 в сентябре 2012 года. Solaris также приняла GRUB 2 на платформе x86 в релизе Solaris 11.1. Buildroot также использует GNU GRUB для целей x86 и x86 64. В конце 2015 года была обнаружена и быстро исправлена уязвимость, позволявшая обойти пароль входа в систему, 28 раз нажав клавишу Backspace.

Варианты

GNU GRUB — это свободное программное обеспечение с открытым исходным кодом, поэтому было создано несколько вариантов. Некоторые из наиболее заметных, которые не были включены в основную ветку GRUB:
OpenSolaris включает в себя модифицированную версию GRUB Legacy, поддерживающую разделы Solaris VTOC, автоматический выбор 64-битного ядра и загрузку с ZFS (с компрессией и несколькими средами загрузки). В рамках Google Summer of Code 2008 был реализован проект поддержки GRUB Legacy для загрузки с разделов, отформатированных в ext4. Проект Syllable создал модифицированную версию GRUB для загрузки системы из своей файловой системы AtheOS. TrustedGRUB расширяет функциональность GRUB, реализуя проверку целостности системы и безопасности процесса загрузки с использованием модуля Trusted Platform Module (TPM). Intel BIOS Implementation Test Suite (BITS) предоставляет среду GRUB для тестирования BIOS и, в частности, их инициализации процессоров, оборудования и технологий Intel. BITS поддерживает скрипты на Python и включает в себя Python API для доступа к различным низкоуровневым функциям аппаратной платформы, включая ACPI, регистры процессора и чипсета, PCI и PCI Express. GRUB4DOS — это ответвление GRUB Legacy, которое улучшает процесс установки на DOS и Microsoft Windows, помещая все, кроме конфигурационного файла GRLDR, в один файл образа. Его можно загружать непосредственно из DOS или через NTLDR или Windows Boot Manager. GRUB4DOS активно разрабатывается и с 2021 года поддерживает UEFI.

Инструменты конфигурации GRUB

Инструменты настройки, используемые различными дистрибутивами, часто включают модули для настройки GRUB. Например, YaST2 в дистрибутивах SUSE Linux и openSUSE, и Anaconda в дистрибутивах Fedora/RHEL. StartUp Manager и GRUB Customizer — графические редакторы конфигурации для дистрибутивов на основе Debian. Разработка StartUp Manager была прекращена 6 мая 2011 года после того, как ведущий разработчик назвал личные причины прекращения активной разработки программы. GRUB Customizer также доступен для дистрибутивов на основе Arch. Для GRUB 2 существуют модули управления KDE. GRLDR ICE — небольшой инструмент для изменения конфигурации по умолчанию файла grldr для GRUB4DOS.

Утилиты для ремонта загрузки

Boot Repair – это простой графический инструмент для восстановления после распространенных проблем, связанных с загрузкой, в GRUB и загрузчике Microsoft Windows. Это приложение распространяется под лицензией GNU GPL. Boot Repair способен восстанавливать GRUB во множестве дистрибутивов Linux, включая, но не ограничиваясь, Debian, Ubuntu, Mint, Fedora, openSUSE и Arch Linux.

Инсталлятор для Windows

Grub2Win — это программный пакет с открытым исходным кодом для Windows, позволяющий GNU GRUB загружаться из каталога Windows. Программа установки инсталлирует GNU GRUB версии 2.06 на NTFS-раздел. Далее графическое приложение Windows используется для настройки загрузочного меню GRUB, тем оформления, порядка загрузки UEFI, скриптов и других параметров. Все скрипты и команды GNU GRUB поддерживаются как для UEFI, так и для систем с традиционной BIOS. Grub2Win позволяет настроить GRUB для многозагрузочной системы с Windows, Ubuntu, openSUSE, Fedora и многими другими дистрибутивами Linux. Программа распространяется бесплатно под лицензией GNU GPL на SourceForge.