Initrd linux что содержит образ

Исследуем процесс загрузки Linux

(C) В.А.Костромин, 2007
(версия файла от 5.10.2007 г.)

Этап 3: Загрузчик 2 этапа операционной системы

3.2. Файл /boot/initrd и его назначение

Как было сказано в предыдущем разделе, в процессе начальной загрузки вначале монтируется временный виртуальный диск, содержащий корневую файловую систему (очевидно, тоже временную), с помощью которой осуществляется запуск на выполнение ядра операционной системы. Образ этой корневой системы хранится на загрузочном устройстве в каталоге /boot и обычно носит имя initrd-2.x.yy-zzzz (точное наименование файла смотрите в вашей системе, далее он будет именоваться просто initrd). Загрузчик переносит образ корневой файловой системы из файла initrd в оперативную пямять одновременно с образом ядра, ядро преобразует initrd в «нормальный» RAM диск, монтирует временную корневую файловую систему, извлекает из нее нужные драйверы и другие служебные файлы, с помощью которых инициализирует все необходимые устройства. После этого происходит перемонтирование корневой файловой системы, временная ФС заменяется на постоянную, размещающуюся уже на долговременном носителе и процесс загрузки системы продолжается.

После того, как будет смонтирована корневая файловая система с жесткого диска, файл initrd уже никак не используется и место, занимаемое им в памяти, тоже освобождается. А теперь давайте подробнее рассмотрим как устроен этот файл. При этом надо сразу сказать, что внутреннее устройство initrd и его применение в ядрах версий 2.6 было изменено по сравнению с ядрами версий 2.4, так что придется рассмотреть эти случаи по отдельности.

3.2.1. Внутреннее устройство initrd

Как сказано в статье [10] в дистрибутиве Fedora Core 3 (и его предшественниках) файл initrd создавался с использованием виртуального loop-устройства. В этом случае сделать содержимое файла initrd доступным для просмотра можно с помощью следующих команд (напомню, что имя вашего образа initrd может отличаться):

В таких дистрибутивах, как Fedora Core 4, SUSE 10, . файл initrd представляет собой cpio-архив, сжатый упаковщиком gzip. Чтобы просмотреть его содержимое, надо выполнить команды, приведенные в листинге 3

/tmp вы найдете каталоговую структуру, аналогичную структуре каталогов обычной Linux-системы. В ней вы обнаружите обычные для корневого каталога подкаталоги, а также файл linuxrc. Могут там оказаться и другие файлы, например, файл bootsplash (судя по названию он содержит картинку, которая отображается при запуске).

Познакомившись с внутренним содержанием файла initrd можно вернуться к рассмотрению его роли в процессе загрузки.

3.2.2. Загрузка системы в случае использования initrd (ядра версий 2.4.х)

Приводимое ниже описание последовательности операций на этапе загрузки я позаимствовал из [11,12].

1. Загрузчик загружает ядро и содержимое initrd в память (очевидно, по вполне определенным адресам . ), после чего передает управление ядру.

2. Ядро содержит в себе небольшую несжатую часть, которая вначале разархивирует само ядро. Видимо как раз на этом этапе на экране монитора отображается сообщение «Uncompressing Linux. Ok, booting the kernel.»

3. Ядро инициализирует устройства, создает файловую систему устройств /dev, разархивирует initrd и копирует его содержимое на устройство /dev/ram0, а затем освобождает память, занятую initrd.

4. Ядро монтирует устройство /dev/ram0 для чтения и записи в качестве начальной корневой файловой системы.

5. Если в начальной корневой файловой системе находится исполняемый файл /linuxrc, он исполняется с uid 0. Этот файл должен иметь разрешения на исполнение, он может быть как обычным исполняемым файлом, так и просто скриптом оболочки, но в последнем случае должен быть и интерпретатор скриптов.

6. Cкрипт /linuxrc монтирует нормальную корневую файловую систему.

7. Корневая файловая система помещается в корневую директорию. Смена корневого устройства выполняется системным вызовом pivot_root, который также доступен через утилиту pivot_root (см. pivot_root(8); pivot_root распространяется в составе util-linux версии не ниже 2.10h ). Смена корневой директории не включает её демонтирование. Следовательно, при выполнении данной процедуры можно сохранить процессы, запущенные с файловой системы initrd.

8. Если нормальная корневая файловая система имеет каталог /initrd, то устройство /dev/ram0 перемещается из / в /initrd. Иначе, если каталог /initrd не существует, устройство /dev/ram0 размонтируется.

9. На нормальной корневой файловой системе следует обычная процедура загрузки (например, вызов /sbin/init).

10. Теперь можно демонтировать /dev/ram0 и освободить память, занятую RAM диском.

3.2.3. Initramfs — новая модель инициализации (ядра версий 2.6.х)

Во-первых, виртуальный диск, как и все блочные устройства, требует драйвер файловой системы для интерпретации данных во время выполнения. Этот драйвер приходилось включать в ядро.

Во-вторых, неэфективно используется оперативная память, так как размер виртуального диска фиксирован и не может изменяться во время работы без его переформатирования (даже если диск не заполнен, невозможно отдать эту память под другие нужды).

В третьих, в Linux осуществляется кэширование всех файлов и записей каталогов, прочитанных или записанных на блочное устройство. Виртуальный диск тоже кешируется, как и обычные диски, то есть часть данных будет храниться не только на RAM диске, но и в страничном кэше «page cache» (для файловых данных) и в кэше для записей каталогов «dentry cache», что еще больше снижает эффективность использования памяти.

Для устраненеия этих недостатков Линус Торвальдс предложил монтировать кэш ядра Линукс как особую файловую систему, работающую полностью в кэше ядра. При этом нет лишнего дублирования информации между блочным устройством и кэшем, так как блочного устройства попросту нет. Файловая система, реализующая эти идеи, была разработана и получила название initramfs. Ее использование имеет следующие преимущества:

• Система, использующая initramfs в качестве корневой файловой системы, более не нуждается в соответствующем драйвере файловой системы, встроенном в ядро, так как нет блочных устройств для интерпретации файловых систем.
• Размер этой файловой системы автоматически изменяется в соответствии с обьёмом данных, которые она содержит. При добавлении новых файлов (как и при расширении существующих) автоматически выделяется память, при удалении или уменьшении файла происходит высвобождение памяти.
• Достоинством initramfs является также то, что это не новый код, а новое применение уже существующего кода кэширования ядра Линукс, что практически не влечёт увеличение размера ядра, выполнение будет очень простым и основано на чрезвычайно хорошо протестированной инфраструктуре.
• Исчезают некоторые проблемы загрузки с SATA-дисков.
• Initramfs загружается немного быстрее, чем initrd.

Формат initramfs используется по умолчанию для всех ядер, начиная с версии 2.6.15.

В каталоге /boot такая файловая система хранится, по-прежнему, в файле в виде сжатого cpio-архива. Только имя включаемого в этот архив скрипта изменилось с linuxrc на init. Например, в системе ASP Linux 11 после разархивирования файла initrd-2.6.14-1.1653.1asp.img по приведенному в листинге 3 алгоритму я увидел скрипт init и следующую структуру каталогов:

В подкаталоге /bin обнаружилось всего 4 исполняемых файла и две ссылки, в подкаталоге /dev — 8 файлов устройств, в /etc — конфигурационный файл udev/udev.conf, в каталоге lib — два файла: ext3.ko и jbd.ko. Остальные подкаталоги — пустые. Файл init оказался скриптом оболочки следующего вида:

Листинг 4. Содержимое файла init в дистрибутиве ASP Linux версии 11. Обратите внимание на первую строку этого файла: это скрипт для оболочки nash, которая является сильно урезанной версией командного процессора и тоже включена в состав initramfs. Другие, более мощные оболочки на этом этапе еще недоступны.

Как видно из листинга 4, скрипт init монтирует файловые системы /sys и /dev, инициализирует несколько устройств, загружает модули из подкаталога /lib и монтирует корневую файловую систему. Сколько я ни вглядывался в экран при перезагрузках системы, я не увидел сообщений, которые вроде бы должны выдаваться командами echo, включенными в этот скрипт.

Образ виртуальной файловой системы initramfs хранится на диске по-прежнему в файле /boot/initrd-version и создается такой файл как и ранее командой mkinitrd. Прочитать о том, как создать такой файл, можно в статье [10]. Перечень модулей (иначе говоря, драйверов), которые будут включены в эту файловую систему, приведен в переменой INITRD_MODULES в файле /etc/sysconfig/kernel. Если вам требуется включить в /boot/initrd-version какие-то дополнительные модули (например, в случае изменения состава оборудования), вы можете скорректировать соответствующим образом список модулей в файле /etc/sysconfig/kernel, после чего заново создать файл /boot/initrd-version.

Источник

Initrd linux что содержит образ

Для использования /dev/initrd с поддержкой «диска в RAM» и «начального диска в RAM» ядро Linux должно быть собрано с параметрами CONFIG_BLK_DEV_RAM=y и CONFIG_BLK_DEV_INITRD=y. При использовании /dev/initrd драйвер диска в RAM не может загружаться как модуль.

ОПИСАНИЕ

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

Выполнение загрузки

Параметры

Смена нормальной корневой файловой системы

Также сменить нормальное корневое устройство можно из /linuxrc. Для этого должен быть смонтирован каталог /proc. После монтирования /proc, сменить нормальное корневое устройство из /linuxrc можно записав настройки в proc-файлы /proc/sys/kernel/real-root-dev, /proc/sys/kernel/nfs-root-name и /proc/sys/kernel/nfs-root-addrs. Для смены физического корневого устройства из /linuxrc нужно записать номер нового устройства корневой файловой системы в /proc/sys/kernel/real-root-dev. Для смены корневой файловой системы NFS из /linuxrc нужно записать настройки NFS в файлы /proc/sys/kernel/nfs-root-name и /proc/sys/kernel/nfs-root-addrs, а затем записать 0xff (номер псевдо-NFS-устройства) в файл /proc/sys/kernel/real-root-dev. Так, например, следующие команды изменят нормальное корневое устройство на /dev/hdb1:

В качестве примера c NFS, следующие команды изменят нормальное корневое устройство на каталог NFS /var/nfsroot на NFS-сервере локальной сети с IP-адресом 193.8.232.7 для системы с IP-адресом 193.8.232.2 и именем ‘idefix’:

Замечание: Файл /proc/sys/kernel/real-root-dev для смены корневой файловой системы больше не применяется. Современный метод смены корневой файловой системы описан в файле Documentation/initrd.txt из исходного кода ядра Linux, а также в pivot_root(2) и pivot_root(8).

Использование

Возможный сценарий установки системы:

1. Программа-загрузчик стартует с дискеты или другого носителя с минимальным ядром (например, включающим поддержку /dev/ram, /dev/initrd и файловой системы ext2) и загружает в /dev/initrd начальную файловую систему, сжатую программой gzip. 2. Исполняемый файл /linuxrc определяет: (1) что необходимо, чтобы смонтировать нормальную корневую файловую систему (т.е., тип устройства, драйверы, файловую систему) и (2) носитель распространения (например, CD-ROM, сеть, лента, …). Для этого может быть задан вопрос пользователю, запущена автоматического определения или использован гибридный подход. 3. Исполняемый файл /linuxrc загружает необходимые модули из начальной корневой файловой системы. 4. Исполняемый файл /linuxrc создаёт и заполняет корневую файловую систему (на этой стадии нормальная корневая файловая система ещё не является законченной системой). 5. Исполняемый файл /linuxrc устанавливает /proc/sys/kernel/real-root-dev, размонтирует /proc, нормальную корневую файловую систему и все другие файловые системы, которые он монтировал, а затем завершает работу. 6. Затем ядро монтирует нормальную корневую файловую систему. 7. Теперь, поскольку файловая система доступна и полноценна, может быть установлен системный загрузчик. 8. Системный загрузчик настраивается так, чтобы загружать в /dev/initrd файловую систему с набором модулей, которые были использованы для запуска системы в первый раз (например, устройство /dev/ram0 может быть изменено, затем размонтировано и, наконец, образ записывается из /dev/ram0 в файл). 9. Система теперь может загружаться, и можно выполнять дополнительные действия по установке.

Ключевая роль /dev/initrd в вышеописанном механизме — в повторном использовании данных настройки во время нормальных действий системы без необходимости начального выбора ядра, загрузки ядра большего размера или пересборки ядра.

Второй вариант, где пригодится initrd — установка Linux на системы с различными наборами оборудования в одной обслуживаемой сети. В таких случаях может быть желательно использовать лишь небольшой набор ядер (в идеале — одно) и поддерживать как можно меньше по объему специфических изменений под конкретные системы. В этом случае создайте общий файл со всеми необходимыми модулями. После этого будет разным только файл /linuxrc или файл, запускаемый /linuxrc.

Третий вариант — более удобные диски восстановления системы. Поскольку информация, например расположение раздела корневой файловой системы, не нужна во время начальной загрузки, загруженная с /dev/initrd система может использовать диалоговый режим и/или автоматическое определение с последующей, возможно, проверкой правильности.

И наконец, дистрибутивы Linux на CD-ROM могут использовать initrd для упрощения установки с CD-ROM. Дистрибутив может использовать LOADLIN для непосредственной загрузки /dev/initrd с CD-ROM без необходимости в дискетах. Дистрибутив также может использовать загрузочную дискету LILO и затем запускаться с помощью /dev/initrd с большего RAM-диска, находящегося на CD-ROM.

Источник

Сказание о Линуксе: загрузчик, initrd и Sys V

Linux постепенно заполнял память. Загрузчик извлекал все новые и новые килобайты кода. Ни одной мысли, ни одной эмоции. Да и каких эмоций, по правде говоря, можно ждать от загрузчика. Бит за битом, байт за байтом входили в память обрывки кода, сотворенные в результате долгих лет и общих усилий множества мудрых народов. Они душа Системы. Сейчас код загружается, кусок за куском, до последнего бита. Загрузчик бросает взгляд на своё чадо: «Скоро вновь настанет твоё время. Жди», — говорит он и начинает загружать образ initrd. Как и прежде, он трудится не покладая рук. Когда наконец загружены все основные сведения, он передает свои полномочия ядру, отступая в тень. Ядро оживает. Без промедления, без жалоб. Оно внезапно приходит в движение, выглядя так, как будто проработало уже много часов. А затем. наступает тьма. Сумасшедший программист с невменяемой улыбкой нажал кнопку «Reset»: «Все работает, как запланировано. Но. что же будет дальше. «, — подумал он. У программиста поехала крыша, но, если не принимать это во внимание, он был гением. Он не набрасывал план перед работой, просто садился и писал код. И сейчас у него было на выбор по меньшей мере три возможности. По меньшей мере.

Глава 1. Начало: загрузчик.

Как выглядит загрузка операционной системы? Этот вопрос редко приходит в голову обычному пользователю ПК. Он просто нажимает кнопку «Power» и идет на кухню сделать себе кофе, а когда возвращается, тут уже для него подготовлено поле, в которое можно ввести пароль. Однако иногда в голове несколько более увлеченного компьютерами энтузиаста рождается вопрос: «А как же это на самом деле работает?» В чём мы все можем быть твердо уверены, так это в том, что чёрная магия в этом процессе не задействована. Так как же это происходит? На самом деле, все просто: компьютер выполняет серию команд, организованных по определенной логике, по шаблону. Но┘ откуда он «знает», какие команды и когда выполнять? В конце концов, Система — это не один большой исполняемый файл. Их десятки, если не сотни. Так как же она с ними справляется?

Ну прежде всего следует произвести некоторые действия, характер которых не зависит от типа программ, которые мы хотим запустить в системе и от того, каким образом мы хотим запустить их. Мы уже установили, что питание включено, кофе остывает и с «железом» всё в порядке. Первое приложение, которому выпадает честь выполнить заготовленные команды — это загрузчик (также известный как менеджер загрузки). На этом уровне мы пока еще не можем говорить об операционной системе. У нас есть только программа загрузки, которая, будучи единожды запущенной, ответственна за то, чтобы «поднять» ядро системы из указанного местоположения, записанного в файле конфигурации, и загрузить его в память. Не правда ли, все довольно просто? Но у загрузчика есть ещё одно задание: он должен загрузить образ initrd. Теперь о том, что это за зверь.

Глава 2. Initrd.

Название «initrd» — это аббревиатура для «Initial RAM disk» («диск в оперативной памяти для начальной инициализации»). Это файл, который заключает в себе образ файловой системы. Идея заключается в следующем: электронный диск (RAM disk, то есть тщательно выбранный участок памяти, который остальные видят просто как еще одно устройство для хранения информации; он может быть описан как виртуальный жесткий диск) создается в памяти компьютера. Его содержимое хранится в файле initrd. Сам собой напрашивается вопрос: почему все происходит именно так? Почему мы не можем просто напрямую использовать жесткий диск? Ну, мы могли бы, конечно, но виртуальный диск обладает неоспоримыми преимуществами. В первую очередь, его использование даёт нам гарантию, что у нас будет дееспособная файловая система в независимости от того, удастся нам подключить какой-либо невиртуальный диск или нет. Более того, давайте представим, что мы являемся счастливыми обладателями нового сверхсовременного «Ultra-SAS-SATA X»-устройства (такие будут в широком употреблении через 55 лет, но у нам уже предоставили для тестирования предварительную версию, и не спрашивайте, как нам удалось достать ее). В настоящий момент ядро Linux не имеет ни малейшего представления о том, как монтировать такой диск. Помните и о том, что монолитные ядра, такие, как Linux, всецело ответственны за управление оборудованием. Если же ядро «само по себе» не знает, как управлять некоторым оборудованием, оно, как нетрудно догадаться, имеет модуль для работы с ним. А где находится этот модуль? Конечно же, на жестком диске. И здесь замыкается порочный круг, потому что этот диск и является тем оборудованием, к которому мы хотели получить доступ. Неужели все так плохо? Не совсем. Мы можем загрузить модуль благодаря «патенту» initrd. Встроенная в образ initrd файловая система имеет модуль как раз для этого жесткого диска, так что все должно работать. Великолепно. Теперь Вы, вероятно, собираетесь спросить что-нибудь вроде: «Почему это ядро не может получить доступ к этому гребаному модулю, а менеджер загрузки — без проблем?». Менеджер загрузки и операционная система — это два разных мира. Когда работает менеджер загрузки, операционная система неактивна, и наоборот. Так что не следует их сравнивать. Помимо того, где это я сказал, что менеджер загрузки должен брать образ ядра с того же самого диска, на котором находится целевая файловая система? Несколько лет назад у меня был компьютер, оборудованный диском SATA с установленной ОС Red Hat 8.0. Корневой каталог («/») был расположен на диске SATA, который ядро «не видело». Чтобы устранить это «небольшое недоразумение», само ядро вместе со специально подготовленным образом initrd было расположено на «обычном» старом IDE-диске. Есть, конечно, и ряд других примеров. Ветераны могут припомнить, как они ставили Slackware в старые добрые времена. Им приходилось создавать два образа дискет: один для загрузчика и образа и один для образа initrd (называемый rootdisk). Ключевым резидентом последнего была установочная программа, которая инсталлировала старую добрую Slackware. Но давайте временно прекратим теоретические измышления и вместо этого проведем следующий эксперимент.

Эксперимент 1: Как легче всего использовать некоторые из дистрибутивов на LiveCD. Давайте возьмём, к примеру, SLAX 6.0 и сделаем следующее:

1. Запустите систему с CD.
2. Создайте директорию /initr d.
3. Найдите файл /mnt/live/mnt/hdc/boot/initrd.gz и распакуйте его содержимое в только что созданную директорию /initrd. Для этой цели мы можем воспользоваться Ark, который доступен в контекстовом меню файла в KDE, или же по старинке сделать все при помощи командной строки.
4. Создайте новую директорию: /initrd/mount.
5. Выполните:
6. В /initrd/mount мы теперь видим «загадочный» образ initrd. Мне бы хотелось обратить ваше внимание на сценарии, которые подробно описал в недавней статье «SLAX». как он работает?» («SLAX». how does it work?»)
7. Конец эксперимента.

Оборвем дискуссию об initrd, с ней или без нее, но мы обладаем полнофункциональной операционной системой. Здесь я основываюсь на том определении, что ОС — это ядро, а все остальное — это приложения. У нас также есть готовая файловая система. Говоря «готовая» я подразумеваю «готовая к использованию», а не обязательно «смонтированная»! Наше ядро требует только того, чтобы была готовая к использованию виртуальная файловая система. Может существовать лишь один пустой корневой каталог, и этого будет достаточно. Монтирование дисков — это совсем другая история. Теперь пришло время запустить систему. Лучше, чтобы процедура эта была полностью автоматической. Нам бы хотелось иметь дееспособную систему, готовую к работе, со всеми традиционными составляющими, как то: графическая оболочка, звук, мышь, сетевое подключение, веб-сервер, программы для общего доступа к файлам в локальной сети и т.д. И здесь начинаются настоящие проблемы, потому что теория и практика во многих случаях — это не одно и то же. Совсем не одно и то же.

Глава 3. Уровни загрузки системы (runlevels).

Linux — это многозадачная система. Пусть это утверждение будет нашей точкой отсчета. Ее многозадачность — настолько очевидное любому пользователю свойство, что он едва ли когда задумывается о нем. С точки зрения машины здесь все просто: она просто должна исполнять несколько задач одновременно. На самом деле, важно осознавать, что машина особенно не беспокоится о том, тонирует ли она изображения, обрабатывает ли веб-страницы или считает количество слов в документе. Все это логико-арифметические операции, которые превращаются в итоге в двоичные, достигая процессора. Наборы офисных программ, сетевые приложения и игры отличаем друг от друга только мы, люди (ну, возможно, еще инопланетяне, но о них мы поговорим позже). С этой точки зрения многозадачность — не такая простая и очевидная вещь. Что же это значит на самом деле?

• То, что пользователи могут запускать несколько приложений?
• То, что несколько пользователей могут войти в систему на одном ПК?
• То, что несколько пользователей могут запускать по несколько приложений?

Если мы думаем о многозадачности в таком ключе, мы на самом деле говорим о приложениях, которые, будучи запущены единовременно, являются показателем функциональности системы. Я хотел бы недвусмысленно заявить: Linux — это не Трансформер. Однажды запущенный, он работает так, как скомпилирован. Все остальное производится приложениями, запущенными поверх него. Если мы запускаем на нашей машине некий гипотетический минимальный набор приложений, у нас, конечно, будет возможность запустить множество программ, но только в текстовом режиме и только в том случае, если мы физически находимся в непосредственной близости от машины. Дополнительные предложения включают поддержку наличия нескольких пользователей, другие — поддержку сетевых подключений, третьи позволяют пользователям входить в систему через эти соединения. Небольшое приложение под названием «sshd» позволяет удаленно управлять нашими компьютерами, используя протокол SSH. Другие приложения «организуют» графический интерфейс, звук и т.д. и т.п. Эти наборы приложений, имеющих определенные функции, объединены в так называемые уровни загрузки (runlevels). Установлено, что у нас их восемь, они обозначены цифрами от нуля до шести, и есть еще уровень «S» (или «s»). Также предложена следующая интерпретация этих уровней:

Уровень	Выполняется.
S	. в процессе загрузки системы. Теоретически, результатом этого уровня должна явиться базовая система с одним пользователем.
0	. в процессе выключения.
1	. режим одного пользователя. Используется для администрирования системы с правами root’а. Запущен минимальный набор приложений. Нет сетевых подключений, отсутствует графический интерфейс.
2	. многопользовательская среда, тестовый режим, подключение либо отсутствует либо обладает ограниченным набором функций.
3	. полностью многопользовательский режим. Все еще в текстовом режиме, но с поддержкой сети, звука и разных прочих приятностей.
4	. личные настройки. Обычно то же самое, что в режиме 3.
5	. то же, что в режиме 3, но с графической оболочкой. Так называемая «полная фукнциональность».
6	. во время перезагрузки ситемы.

Таблица 1. Уровни загрузки ОС.

Slackware, уровень загрузки 3

Как я уже писал прежде, «так бывает», и именно так это выглядит, например, в Red Hat или Fedora, но нетрудно понять, что из этого «правила» существует целая кипа исключений. Например:

Debian — режим по умолчанию — 2, многопользовательский режим, где работает сеть, графическая оболочка, звук и множество других технических приятностей. Уровни 3-5 ничего не значат или, можно сказать, являются тем же самым вторым уровнем.

Ubuntu — то же самое. Конечно, он основан на Debian.

Slackware — режимы 2 и 4 не используются, но устроены как уровень 3. Еще более «забавным» является то, какой уровень является уровнем по умолчанию в определенном дистрибутиве. Это:

• Debian / Ubuntu — уровень 2,
• Slackware — уровень 3, (который, заметьте, менее функционален, чем чем уровень 2 Debian),,
• Gentoo — уровень 3,,
• Red Hat / Fedora — уровень 3 или 5,,
• SUSE / openSUSE — уровень 5,

Slackware, уровень загрузки S

А теперь отбросим прочь монотонность и занудство. Но на самом деле я бы хотел, чтобы всё было гораздо более занудно и монотонно. Текущий уровень загрузки системы можно выяснить, набрав в консоли:

если вы вошли как root. А если как простой смертный, то:

И мы возвращаемся к вопросу о загрузке системы.

Глава 4. Init.

Первой исполняемой программой в готовом к работе окружении является обычно программа init. Эта программа расположена в директории /sbin, ее файлом конфигурации является /etc/inittab. В Linux программа init является ключевой. Почему? Это «родоначальник всех процессов» (выписано из руководства). Более подробно об этом процессе мы расскажем во второй части «Сказания». Сейчас же достаточно будет написать, что в файле конфигурации этой программы есть крайне важная для загрузки строчка. Ее пример (из Debian):

Указанный файл будет исполнен в процессе загрузки. Этот файл устанавливает, какие приложения будут работать во время загрузки, то есть на уровне S. Это довольно важно, потому что впоследствии уровни могут меняться. Скажем, root запускает команду init 1 (в командной строке), чтобы придать себе функции администратора. Он исполняет функции администратора, а затем выполняет init 5, и тут в дело вновь вступаем мы, простые пользователи. Во время переключения уровней загрузки исполняются определенные сценарии, которые должным образом настраивают окружение. Но существуют программы, запускать которые требуется всего лишь один раз. Например, swap partition выполняется при загрузке компьютера и работает дальше, несмотря на то, какой уровень загрузки мы установили, разве не так? Было бы абсолютно неразумно подключать и отключать разделы каждый раз, когда мы меняем уровень загрузки. В этом просто нет смысла. И вновь возвращаясь к программе init: /etc/inittab содержит также еще одну интересную строку:

Это уровень загрузки системы по умолчанию. Если для Вашей, к примеру, Slackware установлен третий уровень, мы можем, изменяя эту строку, установить по умолчанию «графическую» загрузку. Но, конечно же, Вы должны знать, что в Slackware многопользовательским уровнем с графической оболочкой является 4-й, а не, например, 5-й, как в Red Hat. Строка, приведённая в качестве примера, была взята из Debian, а в Debian 2 означает «полный набор функций». На самом деле, /etc/inittab содержит только интересные строки: что система должна делать после нажатия ctrl+alt+del, после перебоя в питании, сколько может быть доступно виртуальных консолей.

Глава 5. Необычайно короткая глава о том, какие программы запускаются.

Программы, обеспечивающие функционирование системы обычно запускаются не «ни с того ни с сего», а благодаря соответствующим сценариям. Эти сценарии расположены по большей части в директории etc/init.d. вот их примеры:

• alsa — запускает программы, позволяющие слушать музыку,
• apache2 — запускает веб-сервер,
• gdm — включает графический менеджер входа в систему,
• samba — предоставляет возможность сделать доступным содержимое локальной сети,
• urandom — сценарий, который (если выполнять его во время загрузки и перезагрузки системы и выключения компьютера) «запоминает» данные.

Но давайте не углубляться в скучные подробности: включение того или иного уровня загрузки системы — это всего лишь выполнение сценариев в определенной последовательности. Обычно из директории /etc/init. d, но необязательно.

Программист все думал и думал. Он знал общепринятые способы запуска и закрытия (да: не забудьте и о закрытии, потому что иногда нам приходится перезагружать компьютер, а иногда даже и выключать его) приложений во время переключения уровней загрузки системы. Но ни один из них не устраивал его. В стиле BSD? За этим сложно проследить. Может, в стиле SysV? Может, попробовать один из менее популярных способов? В следующий миг он понял: «Да! Ну конечно! Теперь все заработает быстрее и лучше!» — воскликнул он и немедленно приступил к работе. Если бы программисты, работающие с системами вроде Solaris, Debian или Slackware, увидели на экране код, набранный Сумасшедшим, у них бы глаза полезли на лоб от изумления, они бы позеленели от зависти. Если бы они поняли хоть часть того, что увидели.

Глава 6. В стиле BSD.

Какой способ выполнения сценариев приложений, требующихся во время работы на определенном уровне загрузки системы является наиболее простым? Это легко: Вы должны написать соответствующий скрипт. Такой метод применяется в системах семейства BSD и в некоторых дистрибутивах Linux, таких, как, например, Slackware или CRUX. В директории /etc/rc. d есть сценарии rc.S, rc.0, rc.4, rc.6 и т.д. Среди этих скриптов есть изящные сценарии, выполняющие запуск соответствующих программ, и даже сценарии автономных приложений. Что значит здесь слово «изящные»? Ну вот вам пример:

Это значит примерно следующее: «Если есть какой-либо графический GNU-менеджер входа в систему, запусти его». «Изящный» применяется по отношению к управлению или информации, если то, чего мы ждем от системы, вообще возможно. На самом деле, здесь действует простое правило: мы пишем сценарий, который ведет машину к начальному уровню загрузки («S»), а затем и к желаемому: например, 4-му, который в случае Slackware означает полный набор функций. Подобным же образом мы создаем скрипт для запуска приложений, которые предоставляют возможности уровню root, скрипт, для перезапуска системы и т.п. Можно ли сделать это по-другому?

Глава 7. В стиле SysV

Точно так же, как и раньше, когда мы приводили в качестве примера Slackware, теперь мы хотим поиздеваться над ее сильно младшим братом: дистрибутивом Debian. Это канонический (это только прилагательное, а не название производителя) пример данного стиля настройки уровня загрузки системы, который, кстати, является доминирующим в Linux. В этом случае все гораздо интереснее, а на первый взгляд — так прямо волшебство. Но давайте же приступим.

Эксперимент 2. Давайте создадим на нашем компьютере директорию. Наш эксперимент может быть успешно проведен и в Slackware: мы будем использовать стандартные команды. Давайте назовем нашу директорию «scripts».

Отлично. Теперь давайте создадим в этой директории три файла, как описано ниже:

Мы создадим остальные два файла таким же образом, только все последовательности символов «01» заменим на «02» и «03». Конечно же, Вы можете создать хоть сотню таких, если захотите. Для того, чтобы «вспомнить» последнюю команду и изменить ее, я предлагаю использовать клавишу «стрелка вверх». Следующим шагом будет придание нашим псевдосценариям свойства исполняемости:

А теперь самое интересное. Как нам уже известно, мы можем выполнить любой сценарий, например:

Вы можете также выполнить сразу несколько, например:

Пока что ничего нового. Но что, если мы хотим выполнить все сценарии, а их там не 5, а 105? Ну, или что, если другой пользователь нашего ПК, Боб Кодер, добавил еще два сценария? (Что, конечно, отнюдь не значит, что он плохой программист. Или все-таки плохой?) Так что же делать? Выписывать имена всех файлов, потом напряженно «вбивать» их в командную строку? Конечно же, нет. Система содержит определенную команду, которой мы прямо сейчас и воспользуемся:

Интересно? Не забывайте ставить точку в конце имени команды. Хотелось бы напомнить вам, что точка не означает конец предложения. Это всего лишь имя текущей директории. Подобным образом Debian проводит выполнение загрузочных сценариев. Проверьте, пожалуйста, следующие директории. Для начала — /etc/rcS.d . эти сценарии выполняются при старте системы. Пример из моего компьютера (фрагмент):

И так далее, и тому подобное. Как вы видите, имена начинаются с последовательности: «S» плюс номер. Дело в том, что программа «запуска-по-частям» («run-parts») выполняет сценарии в алфавитном порядке. Если Вы хотите, чтобы тот или иной сценарий выполнялся раньше либо позже, Вам нужно лишь сменить его номер. Например, с «S04udev» на «S76udev». (Но не делайте этого! Это всего лишь возможность, из чего не следует, что это будет хорошо для системы!) Похожую ситуацию можно наблюдать в директориях от /etc/rc0.d до /etc/rc6.d . Важно также то, что все проанализированное здесь содержимое директорий является символьными ссылками, созданными командой «ln -s». Нет ни смысла, ни необходимости в том, чтобы копировать указанные файлы. «Оригиналы» тихо-смирно сидят в директории /etc/init.d, и их именам не предшествуют никакие числа. Иными словами, директория /etc/init.d содержит всю совокупность загрузочных сценариев. Если мы хотим выполнить, например, чтобы сценарий «gdm» (запуск менеджера входа в систему, сходного с GNOME, в графической оболочке) автоматически выполнялся при старте системы, мы выполняем следующую команду:

И теперь о самом графическом менеджере входа в систему. Благодаря наличию номеров в именах сценариев Вы можете достичь эффекта, сходного с тем, что мы наблюдаем в MS Windows&copy, когда система на самом деле еще загружает требуемые приложения, но пользователь уже видит экран входа. Вам просто нужно передвинуть запуск программы gdm на несколько более раннее время. Но есть ли в этом какой-либо смысл? Решение этого вопроса я оставляю на суд читателя. Сценарий также может быть выполнен при помощи следующей команды:

Что значит: для каждого файла, расположенного в директории /etc/rcS.d/ и обладающего именем, подходящим под шаблон «S, плюс два символа, плюс еще что угодно», выполнить. Debian использует этот метод наравне с программой «запуска-по-частям». Будет ли используемый в Debian способ запуска приложений для нужд уровня загрузки системы лучше того, который используется в Slackware? Это непростой вопрос. Как я уже упоминал ранее, в Slackware Вам нужно напряженно печатать в сто втором, сто третьем, сто четвертом скрипте из тех, что Вам нужны, а в Debian все это как будто проще, но с другой стороны. Когда Вы редактируете файлы, которыми хотите воспользоваться, Вы теоретически больше осведомлены о том, что случится с вашей системой, а в сценариях Slackware вы можете писать собственные комментарии. Однако для Debian и его «семьи» существуют специальные программы: update-rc.d (запускается в консоли) или KsysV (это часть среды KDE), которые делают проще управление символьными ссылками на сценарии для определенных уровней загрузки системы.

KSysV в Debian

Конечно, можно применять различные методы.

Глава 8. GoboLinux.

GoboLinux — нечто совсем другое. Условимся, что это факт, а факты мы не оспариваем. Если он отличен от других дистрибутивов, то и запускаться и прекращать работу стандартным образом он также не может. Он в этом плане больше напоминает BSD, но со своими особенностями. В Gobo использованы сценарии, которые содержат в себе сложную процедуру загрузки и не менее сложную процедуру выхода из системы. В Slackware Вам приходилось выполнять несколько сценариев (например, два), таких, как rc.S и rc.4 для загрузки в «полном» режиме (с графической оболочкой). А в Gobo сценарий загрузки (BootUp, размещённый в директории /System/Settings/BootScripts) содержит все шаги по загрузке системы. От начала до конца. Есть также похожий сценарий Shutdown. Думаю, вы сами в силах догадаться, для чего он нужен (тоже мне — ребус!)

Около полуночи зазвонил телефон. Гуру несколько лениво убавил громкость и поднял трубку. «Это Мичук. У нас проблема», — услышал он. Через мгновение он сухо спросил: «В чем дело?» — «Keyto получил доступ к исходникам системы Сумасшедшего программиста. Он украл их, или что-то вроде того. Он пытался обработать эти сведения для своей статьи, но не выдержал сложности кода и сломался под давлением огромного количества информации», — «О чем это ты!?» — «Он не смог, Гуру», — «Он сошел с ума», — «О Боже! Ты видел этот код?» — «Конечно, нет». «И что теперь? Надо что-то предпринять», — опечалился Гуру, — «Я еще не полностью уверен, из-за психического ли это состояния Keyto, или это просто последствие серьезных проблем с пониманием кода Безумца». «Окей, хорошо, я встречусь кое с кем. Психиатр и Линус Торвальдс с Ричардом Столлманом уже в пути. «

• Во-первых: про диск «Ultra-SAS-SATA X» — это, конечно, шутка. Их выпустят не через 55, а через 57 лет.
• Во-вторых: данная статья описывает процесс загрузки UNIX-систем. Загрузка Windows-систем будет описана на соответствующем сайте, когда он наконец откроется.
• В-третьих: продолжение следует. В следующей статье этой серии я расскажу вам что-нибудь о директории /proc и о многом другом, так что не пропустите.

Подробнее узнать о процессе загрузки вы можете в статье «Исследуем процесс загрузки Linux» и других статьях раздела «Настройка процедур загрузки системы» нашей Библиотеки.

Источник