GRUB - GRand мира загрузчиков
         

Содержание


Как, собственно, и Linux - не единственная ОС, созданная и развиваемая сторонниками Open Source. Я бы даже сказал: далеко не единственная. Причём, кроме достаточно близких "родственников" по линии UNIX, есть и "оригиналы", как HURD, например. Вернёмся, однако, к загрузчикам. Из сказанного следует, что раз появляются принципиально новые ОС, то возникает потребность и в новых загрузчиках. Так, в 1995 году Erich Boleyn в попытках загрузить GNU Hurd решил создать новый загрузчик, вместо того, чтобы модифицировать загрузчик FreeBSD. А для того, чтобы работа эта не пропала "втуне", в содружестве с Brian Ford была разработана спецификация мультизагрузки (Multiboot Specification). Любое ядро, построенное в соответствии с данной спецификацией может быть загружено соответствующим мультизагрузчиком. Первым из таковых и стал GRUB - GRand Unified Bootloader. Сильные стороны Open Source можно демонстрировать, среди прочего, и на примере GRUB: хорошие разработки не пропадают. Когда в 1999 году Erich Boleyn перестал уделять своему детищу достаточно внимания, Gordon Matzigkeit и Yoshinori K. Okuji оформили GRUB как официальный пакет GNU, каким он по сей день и является.

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

Кроме уже названного соответствия спецификации мультизагрузки, вот неполный перечень возможностей GRUB:

  • дружественность основных функций к пользователю;
  • высокая функциональность в интересах разработчиков ядер;
  • обратная совместимость для загрузки FreeBSD, NetBSD, OpenBSD и Linux;
  • загрузка DOS, Windows NT и OS/2 методом "по цепи";


  • множество загружаемых форматов;
  • текстовый файл конфигурации;
  • меню-интерфейс;
  • гибкий командный интерфейс;
  • множество поддерживаемых файловых систем;
  • автоматическая декомпрессия;
  • способность читать данные с любого из определяемых BIOS устройств;
  • независимость от геометрии дисков;
  • поддержка LBA;
  • поддержка загрузки по сети;
  • возможность работы с удалёнными терминалами.

Споры между приверженцами LILO и GRUB мало напоминают "религиозные войны", склонность к которым, к сожалению, иногда демонстрирует UNIX-сообщество.
Возможно потому, что "пристрастный" анализ практически неминуемо убеждает, что GRUB превосходит соперника. Оставим в стороне функции, которых нет у LILO, но есть у GRUB: в конце концов, может вам никогда и не требовалось работать с удалёнными терминалами или загружаться исключительно с дискеты (по причине невозможности загрузки с HDD или CD-ROM). Сравним, как эти загрузчики выполняют только одну, общую для них функцию. Причём - основную: собственно загрузку ядер ОС.

Любой из загрузчиков при инсталляции "перехватывает инициативу", записывая начальную порцию своего кода (всё те же 512 байт - больше BIOS просто не прочитает) в главную загрузочную запись устройства. В этом смысле все они одинаковы: другого способа получить управление от BIOS не существует. Эта начальная порция кода в терминологии GRUB называется stage1. Трудно, однако, в 512 байтах (даже, меньше, как мы уже выяснили) разместить код, способный загружать разные ядра или даже ОС, да ещё и в меню-ориентированном режиме. Ближе всех к этому был Илья Евсеев, предложивший код главного загрузчика, способный загружать любой из загрузчиков трёх первичных разделов. Здорово, но при чём тут ядра Linux, BSD и прочая? Чай не DOS... Да и почему ограничиваться только первичными разделами?... "Патовая" ситуация разрешается загрузкой второй порции загрузчика. Вот тут-то и начинаются различия. Где BIOS находит код первой фазы загрузки (для GRUB - stage1) - известно: 0:0:0, как и договаривались, а вот где, в свою очередь, эта первая фаза будет искать своё продолжение (для GRUB - stage2, то есть)? LILO поступает просто: первая часть кода при инсталляции получает адрес продолжения в виде списка блоков, в которых и записано это самое "продолжение". "Продолжение" - не обязательно код. Это может быть и список необходимых файлов, но адресуемых физически, как блоки. GRUB же поступает изощрённее: в блоки, следующие за загрузочным, последовательно записывается код промежуточной фазы: stage1_5.


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

  • реконфигурация загрузчика не требует перезаписи главной загрузочной записи;
  • предназначенные для загрузки ядра адресуются обычным для файловых систем способом;
  • физические операции над содержимым диска (дефрагментация, перенос файлов), никак не отражаются на работе загрузчика;
  • плюс следствие: логическая адресация объектов загрузки делает возможным управление ими не только по заранее определённому сценарию, но и в интерактивном режиме. И возможность эта реализована в виде командного режима работы.

Выше изложенного уже достаточно, что бы предпочесть GRUB. При этом не надо думать, что адресация посредством физических блоков не известна GRUB. Если запись stage1_5 по каким-либо причинам невозможна, то применяется адресация посредством физических блоков. То есть, в этом случае GRUB как бы "опускается" до методологии LILO. Надеюсь, убедил. Перейдём к конкретным деталям.



Содержание раздела