DragonFlyBSD: загрузка и загрузчик

Алексей Федорчук
2004.12.01

В этой заметке речь пойдет только о первом этапе инициализации машины под управлением DFBSD - загрузке ее ядра и модулей оного, вплоть до запуска процесса init, первого процесса любой POSIX-совместимой системы. Начиная с этого момента, в дело вступает система инициализации, о которой частично уже говорилось в одной из прошлых заметок, но к которой я надеюсь еще вернуться.

Вводные замечания

Загрузчик - это первое, что в любой ОС видит пользователь. Правда, пользователю POSIX-совместимой системы такое удовольствие выпадает много реже, чем "подоконнику". Нормальный режим эксплуатации домашней Unix-машины - это ее включение рано утром и выключение - поздно вечером. (Правда, представления о "рано" и "поздно" у всех свои). А служебная Unix-машина по хорошему выключаться вообще не должна. Ну а необходимость в рестарте системы по ходу работы в Linux или BSD возникает чрезвычайно редко. Собственно, только после пересборки и реинсталляции нового ядра (или переносе корневого раздела - но это уже вообще исключительный случай) - во всех прочих случаях реконфигурирования системы можно обойтись и без этого.

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

За несколько лет общения с FreeBSD и эпизодическим знакомством с ее сестрами (OpenBSD и даже NetBSD) у меня как-то не было повода разбираться с устройством BSD-загрузчика. Ну грузит он прекрасно родную систему - и замечательно. Грузит без напряга также и другие BSD-системы - еще лучше. А то, что еще без напряга и Linux может загрузить - так вообще здорово.

Как и пребывал бы я в счастливом незнании, если бы как-то, в связи с установкой FreeBSD на Тошибу, не пришлось покопаться немного с опциями загрузки. И тут оказалось, что BSD-загрузчик - программа с мощными интерактивными возможностями, да еще и обладающая механизмами настройки. Не сравнить с GRUB'ом, конечно, но если не экспериментировать с многочисленными ОСями на многих винчестерах, - возможностей его более чем достаточно.

Однако в данной заметке возможности BSD-загрузчика будут рассмотрены на примере DragonFlyBSD. Хотя во всех BSD-системах загрузчики очень близки между собой, и 99% сказанного ниже можно отнести к любому их них. Моменты, специфичные именно для загрузки DFBSD, будут оговорены специально.

Загрузка как она есть

Загрузка ядра осуществляется специальной программой, которая так и называется - загрузчик (loader). В BSD-системах это еще и имя собственное такой программы, именуемой просто loader (иногда - BSD loader). Она состоит из четырех частей. Точнее, это три (как ни странно, не четыре) самостоятельные программы, хотя и тесно между собой связанные, но располагающиеся в совершенно разных местах диска (даже не файловой системы).

Первая часть (т.н. boot0) записывается в загрузочный сектор (MBR - Master Boot Record) диска, с которого осуществляется загрузка машины согласно установкам BIOS. Обычно это Master на первом IDE-канале (о SCSI-дисках здесь речи не будет), но возможны варианты (например, при наличии аппаратного ATA RAID). Вторая часть (boot1) размещается в загрузочном секторе первичного раздела, несущего BSD-систему (BSD-слайса), который принципе может располагаться и на другом физическом диске. То есть и boot0, и boot1 лежат не только за пределами файловой системы, но и, фактически, вне собственно слайса BSD. Третья же часть (boot2) лежит уже внутри слайса, но частью файловой системы также не является. Ну а четвертая - это и есть наш loader, обычный исполняемый файл, помещаемый уже на файловой системе - в специальном каталоге /boot.

Для начала нужно сказать несколько слов о первых трех частях - тех, что к файловой системе BSD не относятся. Правда, в каталоге /boot можно видеть файлы с именами boot0, boot1 и boot2, но это - лишь копии соответствующего кода, расположенного (и запускающегося) вне файловой системы BSD.

Первая часть загрузчика отвечает только за чтение таблицы первичны дисковых разделов, вывод их списка (если разделов более одного), некоторого периода ожидания для выбора пользователем (по умолчанию загрузочным будет раздел, выбранный в предыдущем сеансе работы) и после такового (или по истечении фиксированного периода ожидания), передачи управления коду, записанному в загрузочном секторе выбранного (или умолчального) раздела. Выбор раздела осуществляется нажатием клавиш F1-F4), если дисков два, нажатие клавиши F5 просто передаст управление на загрузочный сектор второго - а там уж события потекут в зависимости от того, что в нем записано.

Список разделов для выбора теоретически должен включать их имена в соответствии с идентификаторами типа файловой системы, например:

F1	DOS
F2	Linux
F3	BSD
F5	Drive 1

И во всех ранее существовавших BSD-системах (Free-, Net- и OpenBSD) так оно и есть. Однако в DFBSD каждый первичный раздел, вне зависимости от типа, маркируется как BSD. Меня это весьма удивило, когда я впервые установил эту систему второй после Archlinux, и после перезагрузки увидел такую картину:

F1  BSD
F2  BSD

способа изменить которую я пока так и не нашел. Что, впрочем, не мешает загрузчику при выборе раздела с Linux передать управление на его загрузчик (у меня в данном случае - Lilo), который и благополучно отрабатывает свою программу.

В принципе наличие первой части BSD-загрузчика не является обязательным: его вполне может подменять загрузчик Linux (тот же Lilo, передающий управление на загрузочный сектор "по цепочке") или мультисистемный GRUB, который способен на то же самое, а также и большее: прочитать файловую систему DFBSD (а ею является та же UFS, что и во FreeBSD 4-й ветки) и загрузить непосредственно ее ядро. Однако сосуществование Linux и BSD-систем на одной машине - тема отдельного разговора.

Вторая и третья части загрузчика - это, в сущности, единая программа, разделенная только из-за ограничений на размер загрузочного сектора (512 байт). Так что в задачу boot1 входит только опознать слайс BSD, отыскать на нем boot2 и передать ему управление. А уж тот обязан опознать корневую файловую систему, отыскать в нем каталог /boot и запустить собственно /boot/loader.

Сам loader быстренько загружает ядро и набор умолчальных модулей, после чего выводит свое меню с логотипом проекта, на коем можно узнать стрекозу (во FreeBSD здесь по умолчанию нарисован демон с вилами). Меню содержит следующие пункты:

  1. Boot DragonFly [default] - нормальная загрузка ядра со всеми положенными (кем и где положенными - разговор впереди) модулями, монтированием файловых систем и отработкой предписанных стартовых скриптов;
  2. Boot DragonFly with ACPI disabled - то же самое, только с выключением модулей acpi, иногда может потребоваться на некоторых ноутбуках;
  3. Boot DragonFly in Safe Mode - загрузка в безопасном режиме;
  4. Boot DragonFly in single user mode - загрузка в однопользовательском режиме, при котором монтируется (да и то только для чтения) лишь корневая файловая система, а стартовые скрипты игнорируются;
  5. Boot DragonFly with verbose logging - обычная загрузка, но с выводом подробных сообщений;
  6. Escape to loader prompt - выход в командную строку загрузчика;
  7. Reboot - ну, это мы знаем, как три пальца, только еще лучше.

Если не сделать никакого выбора - через десять секунд начнет грузиться умолчальный вариант. Для предотвращения чего (и получения дополнительного времени на размышления) достаточно нажать Spacebar, отсчет времени остановится, и загрузки не будет до выбора в явном виде.

После выбора или истечения срока давности начинается довольно длительный процесс определения оборудования, в ходе которого на экран выводятся многочисленные сообщения ядра - их отличие от обычных сообщений - в ярко-белом "окрасе" символов. Сообщения эти очень интересны, но рассмотреть их нелегко. Что, впрочем, не страшно - в дальнейшем их можно просмотреть командой dmesg. После этого монтируется корневая файловая система и с нее (файлом /sbin/init) запускается процесс init, отрабатываются стартовые скрипты. В ознаменование этого ярко-белый цвет сообщений ядра сменяется на обычный сероватый - этап загрузки, интересующий нас в данный момент, закончен.

Интерактивное управление процессом загрузки

Возникает вопрос, может ли пользователь повлиять на процесс загрузки интерактивно? Ответ не него будет положительным. В ходе работы загрузочной системы пользователю дважды предоставляется свобода выбора: выбора загрузочного раздела на начальном этапе и выбора режима загрузки - перед конечным. И на обоих пользователь может вмешаться в процесс руками. Зачем? Это уже другой вопрос, и ответ на него, надеюсь, станет ясным из последующего изложения.

На начальном этапе можно прервать его исполнение, точнее - избежать перехода к этапу boot1/boot2. Для этого в паузе между выбором загрузки с BSD-раздела и появлением сообщений от boot1 (пауза эта маркируется появлением на экране символа _) нужно нажать любую клавишу. Ответом будет приглашение вида:

>> BSD/i386 BOOT
  Default: 0:ad(0,a)/boot/loader
  boot:

И в строке приглашения можно указать вариант загрузки, отличный от умолчального. Например, непосредственно файл образа ядра системы. Это может иметь некоторый смысл после пересборки ядра - если новое оказалось сконфигурированным недостаточно корректно для загрузки (но достаточно, чтобы скомпилироваться).

Для этого нужно сконструировать путь к старому ядру по образу и подобию умолчального варианта. То есть указать:

  • номер диска в машине в соответствие с понимаем BIOS (0 - первый из наличных, 1 - второй, и так далее, вне зависимости от порядка подключения);
  • его интерфейс - в примере ad символизирует ATA диск (для SCSI диска было бы da, для дискеты - fd; а что такое дискета?);
  • номер на IDE-канале (0 - мастер, 1 - слейв);
  • раздел в смысле, используемом BSD Label, то есть часть слайса, резервируемая под корневую файловую систему BSD (a;
  • имя файла образа старого ядра - /kernel.old.

Если на диске имеется несколько первичных разделов разных типов, то разделы не-BSD типа будут пропущены, и литера a (очевидно, что образ ядра может лежать только на корневой файловой системе) будет относиться к первому подразделу слайса с идентификатором 165 (даже если на диске он будет четвертым по счету).

При сомнении в точном имени файла (а их может быть несколько - перед инсталляцией каждого нового неосвоенного ядра рекомендуется сделать копию предыдущего, заведомо работоспособного), в строке приглашения можно ввести знак вопроса, ответом на что будет список корневого каталога (но не глубже - просмотреть содержимое подкаталогов, даже в той же файловой системе, не удастся).

Впрочем, ту же процедуру - загрузку старого ядра, - можно (и нужно, так как это намного проще) выполнять через loader, к рассмотрению интерактивных возможностей которого мы и переходим.

Меню loader'а предлагает достаточный выбор режимов для штатных ситуаций, все нештатные (на то они такие и есть) - явно не охватывает. В частности, вариант загрузки старого ядра в меню не предусмотрен. К счастью, предпоследний пункт меню решает эту проблему (и заодно многие другие).

Итак, выбрав пункт шестой меню - Escape to loader prompt, - мы оказываемся в среде командного интерпретатора loader'а. Она имеет шелл-подобный интерфейс - команды с их опциями и аргументами вводятся после приглашения, имеющего вид

OK

С точки зрения удобства интерактивной работы - далеко не GRUB, конечно: ни тебе автодополнения, ни истории команд, возможности редактирования ограничены клавишей Backspace. Но с главной своей ролью - вводом и исполнением встроенных команд, - вполне справляется.

Тем более, что команд этих довольно много: полный их список можно получить, введя знак вопроса в командной строке. Доступна и помощь - команда help выдаст краткую подсказку, help имя_команды более подробные сведения о ее использовании. Впрочем, синтаксис команд - также шеллоподобный, так что сложностей с этим быть не должно.

Встроенные команды loader'а можно разделить на три части по их назначению:

  • для получения информации;
  • для конфигурирования загрузчика;
  • собственно для управления процессом загрузки.

Из первой группы команд отметим следующие: ls, lsdev, lsmod, show, more. Первая предназначена для просмотра корневой файловой системы и ее подкаталогов, - правда, только тех, что которые не лежат на отдельных подразделах. Но поскольку все нужные для загрузки файлы лежат в подкаталогах непосредственно корня (в /boot, /dev, /modules), это ограничение не важно. Вариант команды ls -l выводит список файлов (и каталогов) с указанием их размера - без этой опции только литерой d помечаются каталоги.

Команда lsdev выводит список дисковых устройств, имеющихся в машине, их первичных разделов и подразделов (последние - только для разделов, размеченных по правилам BSD Label). Опция -v обеспечивает детализацию вывода.

Команда lsmod обеспечивает просмотр модулей, загруженных loader'ом до появления меню (или приглашения командной строки). Как и в предыдущем случае, имеется опция детализации - -v.

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

Ну а more выполняет те же функции, что и ее тезка из числа Unix-утилит. Она позволяет просмотреть содержимое текстового файла - и это, заметьте, при несмонтированных файловых системах и незагруженной операционке! То есть, находясь в командном интерпретаторе loader'а, мы можем ознакомиться с конфигами, важными для загрузки (и с любыми другими).

Команды конфигурирования позволяют определить или снять переменные загрузчика, загрузить или удалить модули ядра. Как уже говорилось, само ядро с неким предопределенным набором модулей и переменных загружается до меню loader'а и его командного интерпретатора. Так вот, с помощью соответствующих команд эти предопределенные наборы можно несколько скорректировать (или изменить полностью). Это может быть необходимо, если умолчальная конфигурация ядра по каким-либо причинам не грузится (частый случай - конфликт ноутбучных систем энергосбережения с системными модулями ACPI), в отладочных целях, или просто удовлетворения любопытства для.

Сначала рассмотрим команды управления модулями. Это - пара команд load/unload для загрузки/удаления модулей, соответственно. Первая используется с аргументом имя_модуля, каковое при необходимости можно подсмотреть (с помощью ls) в каталоге /modules - имя в аргументе дается без суффикса *.ko. Команда unload с аналогичным аргументом удалит указанный модуль, без аргументов - все модули вообще, позволяя начать конфигурирование с чистого листа.

Действие команд load и unload распространяется также на ядро в целом. Так, посредством команды

OK unload kernel

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

OK load kernel.old

загрузить ядро старое, трудоспособное.

Пара аналогичного назначения - set/unset, - существует и для переменными окружения загрузчика. Переменные эти служат для изменения текущего дискового устройства, расположения корневой файловой системы, определения путей к модулям ядра, отличным от умолчального /modules, и тому подобных вещей. Делается это командой set в соответствие с синтаксисом C-shell, например:

currdev="disk1s1a"

Определяет текущее дисковое устройство в терминах "диск#_слайс#_раздел".

Допустимо несколько значений для одной переменной - они разделяются точкой с запятой. Например,

module_path="/;/modules;mymodule_path"

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

Некоторые переменные просто разрешают или запрещают какие-то действия, и, соответственно, значения их булевы - YES или NO. Естественно, они нуждаются в детализирующих переменных, определяющих то, что ими было разрешено. Например, переменная

userconfig_script_load="YES"

только разрешает исполнение пользовательских сценариев конфигурирования, а переменная

userconfig_script_name="/boot/my.conf"

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

С помощью переменных можно определять и режимы загрузки. Например, после установки переменной

OK set boot_single

будет осуществляться в однопользовательском режиме.

Определение переменной может отменяться командой

unset имя_переменной

В некоторых случаях ее эквивалентом будет переменная с булевым значением NO или словом disable в имени.

Полный список встроенных переменных окружения загрузчика можно посмотреть на соответствующей man-странице:

$ man 8 loader

И, наконец, команды управления загрузкой. Важнейшая из них - boot, без опций и аргументов вызывающая немедленную загрузку ядра в его умолчальной или текущей (то есть с переопределенными переменными и модулями) конфигурации.

Опции команды boot конкретизируют режим загрузки. Например, команда

OK boot -s

вызовет загрузку в однопользовательском режиме. Это эквивалентно тому, как если бы выполнить ту же команду без опций, предварительно установив переменную boot_single.

Аргументы команды boot могут определять имя образа ядра, исполняемого сценария загрузки, и так далее. Тот же сакраментальный пример: команда

OK boot kernel.old

приведет к загрузке старого ядра, аналогично команде boot без опций после исполнения пары

OK unload kernel
OK load kernel.old

Впрочем, первая команда этой пары все равно не помешает - во избежание... Особенно если новое ядро собралось уж совсем криво.

Здесь было рассказано не о всех возможностях интерактивного режима BSD-загрузчика - только о тех, которые мне довелось применять. Более подробные сведения можно почерпнуть не только в man (8) loader, но и непосредственно чтением файла помощи:

$ less /boot/loader.help

И совсем не обязательно в процессе управления загрузкой - лучше заблаговременно:-).

Конфигурирование загрузчика

Пользователь, успевший проникнуться духом Unix Way (или хотя бы почувствовавший его), вправе спросить: если в процесс загрузки можно вмешаться интерактивно, нельзя ли определенные при этом руками параметры раз и навсегда зафиксировать. И ответом ему будет: ну конечно же, можно.

Интуитивно ясно, что, поскольку вмешательство пользователя возможно на первом (boot0) и последнем (loader) этапах загрузки, именно они и поддаются настройке. Так оно и оказывается.

Правда, на первом этапе загрузки можно настроить не так уж и много, а именно:

  • изменить время ожидания выбора раздела (по умолчанию оно равно странной цифре 18,2 секунды - так в документации сказано);
  • зафиксировать один из разделов в качестве загрузочного по умолчанию - без этого, как уже говорилось, умолчальным выступает раздел, выбранный при предыдущем старте машины;
  • еще кое-какие мелочи, практического значения не имеющие.

Приведенным целям служи команды boot0cfg. Стоит помнить, что ее использование связано с изменением Главной Загрузочной Записи (MBR), разрушение которой приводит к невозможности старта машины с диска. Вероятность запортить этой командой MBR чрезвычайно мала, да и страшных последствий не имеет. Однако (береженого бог бережет) - лучше держать под рукой инсталляционный диск DFBSD. Не для переустановки системы, конечно, но для восстановления загрузочной записи - это ведь большая спасательная дискета.

Итак, изменить время ожидания можно с помощью опции -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 свежеинсталлированной системы, но - для страховки не повредит.

Обратим внимание на опцию noupdate в итоговом выводе команды: именно она фиксирует один из слайсов в качестве загружаемого по умолчанию. Если такое положение по каким-либо причинам не понравится - это легко изменить, повторив команду в такой форме:

$ $ boot0cfg -o update ad0

Ну а смысл прочих опций (и другие способы применения команды) можно уточнить у тети Мани: man (8) boot0cfg.

Вот мы и добрались до настройки собственно loader'а. Я как-то раньше обмолвился, до появления меню и возможности перехода в интерактивный режим, уже успевает загрузиться ядро с неким положенным набором параметров, и обещал рассказать, где и кем эти параметры положены. Пора исполнить свое обещание.

Так вот, параметры загрузки ядра положены сценарием инициализации загрузчика - /boot/loader.rc. На самом деле это своего рода пакетный файл, из которого вызывается несколько отдельных сценариев, но для нас сейчас это не существенно. А важно то, что положены умолчальные параметры загрузки в парном конфиге - файле /boot/defaults/loader.conf. В нем описываются и пути для поиска модулей, и имя ядра по умолчанию, и текущее дисковое устройство и корневая файловая система, и время задержки перед загрузкой - все то, что можно определить в качестве переменных окружения интерактивно. А еще в нем есть список всевозможных модулей ядра (вообще говоря, всех возможных) и указывается, следует ли их загружать автоматически при старте, или нет.

Сам по себе /boot/defaults/loader.conf для редактирования не предназначен, а лишь показывает все возможные параметры загрузки и фиксирует их значения по умолчанию. И потому собственно целям настройки loader'а служит не он, а файл /boot/loader.conf.

Правда, сразу после установки DFBSD мы такого файла в системе не увидим. Его нужно создать самому, перенести в него нужные опции из файла /boot/defaults/loader.conf и должным образом изменить их значения.

В настройке любой системы обычно проще показать, как она делается, чем рассказать об этом. И потому приведу в качестве примера свой /boot/loader.conf с некоторыми комментариями. Я человек простой, к излишествам не склонный, и потому файл этот у меня очень маленький.

autoboot_delay="5"
# Время ожидания перед автозагрузкой
beastie_disable="YES"
# Отмена вывода меню загрузчика

screensave_load="YES"
# Разрешение загрузки модуля хранителей экрана
screensave_name="fire_saver"
# Загрузка модуля хранителя экрана

snd_pcm_load="YES"
# Загрузка модуля поддержки звука
snd_ich_load="YES"
# Загрузка модуля моего звукового устройства
# В примере - чипсетное аудио от Intel ICH#

В приведенном примере отменен вывод меню loader'а. Меню это описывается в файле /boot/beastie.4th, использование коего предписано в файле /boot/loader.rc строкой

include /boot/beastie.4th

Разумеется, это не обязательно. Можно, напротив, переделать /boot/beastie.4th так, чтобы пункты меню отвечали собственным вариантам загрузки (если это, конечно, нужно, в чем я лично сильно сомневаюсь). А если вы еще и рисовать умеете (ASCII-символами), то можно заменить украшающую меню стрекозу (или демона во FreeBSD) на что-то свое.

Приведенный пример не исчерпывает возможности по реконфигурации загрузчика - иные возможности можно почерпнуть из просмотра файла /boot/defaults/loader.conf. Нужно только иметь ввиду, что какие-то функции, обеспечиваемые подгружаемыми модулями, могут быть уже вкомпилированными в ядро - умолчальное или собственноручно собранное, - и дублировать их не нужно. То есть перед редактированием /boot/loader.rc неплохо свериться с текущей конфигурацией ядра. Для свежеустановленной системы она описана в файле /usr/src/sys/i386/conf/GENERIC, а для собственноручно собранного... впрочем, если вы уже собирали ядро, то лучше меня знаете, как называется файл его конфигурации, и что в нем вписано.

Скажу только пару слов о модулях поддержки файловых систем. Очевидно, что встраивать в ядро поддержку тех из них, что используются лишь эпизодически (типа msdos), нет никакого смысла: в этом случае для всех из них (включая и ext2fs) при компиляции ядра будут по умолчанию собраны и загружаемые модули. Однако и в загрузке этих модулей при старте необходимости нет. При обращении к устройству с чуждой файловой системой необходимый модуль подгрузится автоматически.

А вот со звуковыми устройствами этого не происходит. И потому, если лениво каждый раз перед прослушиванием музыки загружать соответствующие модули (забегая вперед, замечу, что это делается командой kldload имя_модуля), то лучше предписать их автоматическую загрузку при старте системы, как это сделано в примере.

Отыскать нужные модули легко - они содержат в своем имени компонент snd. То есть можно прибегнуть к команде типа

$ ls /modules | grep snd

и из списка вывода выбрать соответствующий реалиями. При этом для многих некогда распространенных звуковых карт на шине PCI достаточно модуля snd_pcm.

С модулями скрипсейверов - аналогичный случай. Дается команда

$ ls /modules | grep saver

и выбирается нужный из появившегося списка. Следует только учесть, что некоторые модули требуют поддержки ядром режима графической консоли (т.н. PIXEL_MODE - разговор о ней впереди), отсутствующей в ядре GENERIC, и в чисто текстовой консоли работать не будут.

Обновлено: 12.03.2015