архив
... И всё начинается с рестарта.
Загрузка и инициализация системы
Глава из книги Сага о FreeBSD
Алексей Федорчук
2008-10-29
Конфигурирование загрузчика
Пользователь, успевший проникнуться духом Unix Way (или хотя бы почувствовавший его), вправе спросить: если в процесс загрузки можно вмешаться интерактивно, нельзя ли определенные при этом руками параметры раз и навсегда зафиксировать? И ответом ему будет: ну конечно же, можно.
Интуитивно ясно, что, поскольку вмешательство пользователя возможно на первом (boot0) и последнем (loader) этапах загрузки, именно они и поддаются настройке. Так оно и оказывается.
Правда, на первом этапе загрузки можно настроить не так уж и много, а именно:
- изменить время ожидания выбора раздела (по умолчанию оно равно странной цифре 18,2 секунды — так в документации сказано);
- зафиксировать один из разделов в качестве загрузочного по умолчанию — без этого, как уже говорилось, умолчальным выступает раздел, выбранный при предыдущем старте машины;
- еще кое-какие мелочи, практического значения не имеющие.
Приведенным целям служит команда boot0cfg. Стоит помнить только, что ее использование связано с изменением Главной Загрузочной Записи (MBR), разрушение которой приводит к невозможности старта машины с диска. Вероятность запороть этой командой MBR чрезвычайно мала, да и страшных последствий не имеет. Однако (береженого Бог бережет) — лучше держать под рукой один из дисков дистрибутива FreeBSD -- тот, который носит имя livefs.iso, и который я настоятельно рекомендовал скачать, вне зависимости от выбранной методы установки.
Итак, изменить время ожидания можно с помощью опции -t #, где # — значение в секундах (нулевое значение не допускается). С помощью опции -s # один определенный раздел диска делается загружаемым по умолчанию на веки вечные (а не тот, с которого был выполнен старт при последнем включении машины). Очевидно, что здесь допустимы значения 1-4 (по числу возможных первичных разделов) плюс 5 — передача управления на MBR второго диска. А опция -v даст нам более подробную информацию о результатах выполненной операции. Ну и, конечно, требуется аргумент — имя дискового устройства, MBR которого мы меняем. То есть команда
$ boot0cfg -t 30 -s 2 -v -f /boot/boot0.old ad0
модифицирует MBR первого IDE-диска (аргумент ad0) так, что 2-й его слайс станет умолчально-загрузочным, время на выбор раздела возрастет до 30 секунд, и выдаст отчет о результатах своей работы в виде примерно следующем:
# flag start chs type end chs offset size 1 0x00 0: 1: 1 0x83 850:254:63 63 13671252 2 0x80 851: 0: 1 0xa5 261:254:63 13671315 23438835 version=187.102 drive=0x80 mask=0xf ticks=30 options=packet,noupdate,nosetdrv default_selection=F2 (Slice 2)
Ах да, опция -f создаст копию текущей загрузочной записи в каталоге /boot; правда, файл /boot/boot0 и представляет собой копию MBR свежеинсталлированной системы, но — для страховки еще один дубль не повредит. Особенно, если мы уже подвергали MBR модификациям.
Обратим внимание на опцию noupdate в итоговом выводе команды: именно она фиксирует один из слайсов в качестве загружаемого по умолчанию. Если такое положение по каким-либо причинам не понравится — это легко изменить, повторив команду в такой форме:
$ $ boot0cfg -o update ad0
Ну а смысл прочих возможных опций (и другие способы применения команды) можно уточнить у тети Мани: man (8) boot0cfg.
Вот мы и добрались до настройки собственно loader'а. Я как-то раньше обмолвился, что до появления меню и возможности перехода в интерактивный режим, уже успевает загрузиться ядро с неким положенным набором параметров, и обещал рассказать, где и кем эти параметры положены. Пора исполнить свое обещание.
Так вот, параметры загрузки ядра положены сценарием инициализации загрузчика — /boot/loader.conf. На самом деле это своего рода пакетный файл, из которого вызывается несколько отдельных сценариев, но для нас сейчас это не существенно. А важно то, что положены умолчальные переменные окружения загрузчика и их значения в парном сценарию конфиге — файле /boot/defaults/loader.conf. В нем описываются и пути для поиска модулей, и имя ядра по умолчанию, и текущее дисковое устройство и корневая файловая система, и время задержки перед загрузкой — все то, что можно определить в качестве переменных окружения интерактивно. А еще в нем есть список всевозможных модулей ядра (вообще говоря, всех возможных) и указывается, следует ли их загружать автоматически при старте, или нет.
Сам по себе /boot/defaults/loader.conf для редактирования не предназначен, а лишь показывает все возможные параметры загрузки и фиксирует их значения по умолчанию. И потому собственно целям настройки loader'а служит не он, а файл /boot/loader.conf.
Правда, сразу после установки системы мы такого файла в системе не увидим. Его нужно создать самому, перенести в него нужные опции из файла /boot/defaults/loader.conf и должным образом изменить их значения.
В настройке любой системы обычно проще показать, как она делается, чем рассказать об этом. И потому приведу в качестве примера свой /boot/loader.conf с некоторыми комментариями. Я человек простой, к излишествам не склонный, и потому файл этот у меня очень маленький.
autoboot_delay="5" # Время ожидания перед автозагрузкойbeastie_disable="YES" # Отмена вывода меню загрузчика
vesa_load="YES" # Включение поддержки режима VESA
zfs_load="YES" # Включение поддержки файловой системы ZFS
snd_pcm_load="YES" # Загрузка модуля поддержки звука snd_ich_load="YES" # Загрузка модуля звукового устройства snd_hda_load="YES" # Загрузка модуля High Definition Audio # В примере — чипсетное аудио от Intel ICH#
Дополнительно здесь можно включить загрузку модуля хранителей экрана вообще и, вслед за тем, конкретного модуля (соответствующие файлы расположены в каталоге /modules и имеют вид *_saver.ko):
screensave_load="YES" screensave_name="fire_saver"
А можно также загрузить и собственную splash-картинку (созданием коей, в формате *.bmp или *.pcx, и ее размещением в каталоге /boot следует озаботиться заблаговременно):
splash_bmp_load="YES" bitmap_load="YES" bitmap_name="filename.bmp"
Обратим внимание на строку vesa_load="YES": подгружая модуль поддержки одноименного режима, она обеспечивает режим так называемой Raster Mode (или графической консоли) -- аналога режима FrameBuffer в Linux. Это необходимо для некоторых, графических, скринсейверов (например, приведенного в примере "пламени") и, конечно же, splash-картинок. Но и сам по себе графический режим в консоли — штука полезная, в чем мы убедимся в соответствующей главе.
Приведенный пример не исчерпывает всех возможностей по реконфигурации загрузчика — с иными из них можно ознакомиться при просмотре файла /boot/defaults/loader.conf. Нужно только иметь ввиду, что какие-то функции, обеспечиваемые подгружаемыми модулями, могут быть уже вкомпилированными в ядро — умолчальное или собственноручно собранное, — и дублировать их не нужно. То есть перед редактированием /boot/loader.rc неплохо свериться с текущей конфигурацией ядра. Для свежеустановленной системы она описана в файле
/usr/src/sys/i386/conf/GENERIC, а для собственноручно собранного... впрочем, если вы уже собирали ядро, то лучше меня знаете, как называется файл его конфигурации, и что в нем вписано.
Скажу только пару слов о модулях поддержки файловых систем. Очевидно, что встраивать в ядро поддержку тех из них, что используются лишь эпизодически (типа msdos), нет никакого смысла: в этом случае для всех из них (включая и ext2fs) при компиляции ядра будут по умолчанию собраны и загружаемые модули. Однако и в загрузке этих модулей при старте необходимости нет (хотя соответствующие строки в файле /boot/defaults и имеются). При обращении к устройству с чуждой файловой системой необходимый модуль подгрузится автоматически. Это же касается и модулей поддержки таких устройств, как диски в оперативной памяти (md — Memory Disk), если, конечно, не предполагается старта системы именно с них.
А вот со звуковыми устройствами этого не происходит. И потому, если лениво каждый раз перед прослушиванием музыки загружать соответствующие модули (забегая вперед, замечу, что это делается командой kldload имя_модуля), то лучше предписать их автоматическую загрузку при старте системы, как это сделано в примере.
Отыскать нужные модули легко — они содержат в своем имени компонент snd. То есть можно прибегнуть к команде типа
$ ls /modules | grep snd
и из списка вывода выбрать соответствующий реалиями. При этом для многих некогда распространенных звуковых карт на шине PCI достаточно модуля snd_pcm.
В приведенном примере отменен вывод меню loader'а -- на отлаженной системе в нём необходимости не возникает почти никогда. Разве что -- при неудачно собранном новом ядре. Но тут можно воспользоваться возможностью интерактивного вмешательства на стадии boot2, во-первых, или запомнить номер пункта для выхода в командную строку loader'а -- во-вторых. Да и значение в 10 секунд задержки перед автоматической загрузкой умолчального варианта видится излишним, для чего и дана строка
autoboot_delay="3"
Трёх секунд, мне кажется, вполне хватит для того, чтобы при необходимости успеть нажать Spacebar или клавишу с цифрой 6.
Если, тем не менее, потребность в выводе меню загрузчика все-таки возникает -- следует знать, что оно описывается в файле /boot/beastie.4th, использование коего предписано в файле /boot/loader.rc строкой
include /boot/beastie.4th
Разумеется, это не обязательно. Можно, напротив, переделать /boot/beastie.4th так, чтобы отдельные пункты меню отвечали собственным вариантам загрузки — например, с различными наборами подгружаемых модулей, для чего придется создать несколько альтернативных конфигурационных файлов для loader'а. Или — образов ядра, собранного с различными опциями.
А в самом меню, генерируемом из /boot/beastie.4th, можно легко заменить политкорректный, но скучный логотип FreeBSD на традиционного деймона с вилами. Для этого в /boot/loader.conf достаточно внести строку
loader_logo="beastiebw"
если же вы еще и вышивать умеете (пардон, рисовать ASCII-символами), то и деймона можно заменить на что-то свое.