Sysroot linux что это

Обновлено: 04.07.2024

Понимание процедуры загрузки в Linux RHEL7/CentOS

Следующие шаги суммируют, как процедура загрузки происходит в Linux.

1. Выполнение POST: машина включена. Из системного ПО, которым может быть UEFI или классический BIOS, выполняется самотестирование при включении питания (POST) и аппаратное обеспечение, необходимое для запуска инициализации системы.

2. Выбор загрузочного устройства: В загрузочной прошивке UEFI или в основной загрузочной записи находится загрузочное устройство.

3. Загрузка загрузчика: с загрузочного устройства находится загрузчик. На Red Hat/CentOS это обычно GRUB 2.

4. Загрузка ядра: Загрузчик может представить пользователю меню загрузки или может быть настроен на автоматический запуск Linux по умолчанию. Для загрузки Linux ядро загружается вместе с initramfs . Initramfs содержит модули ядра для всего оборудования, которое требуется для загрузки, а также начальные сценарии, необходимые для перехода к следующему этапу загрузки. На RHEL 7/CentOS initramfs содержит полную операционную систему (которая может использоваться для устранения неполадок).

5. Запуск /sbin/init: Как только ядро загружено в память, загружается первый из всех процессов, но все еще из initramfs . Это процесс /sbin/init , который связан с systemd . Демон udev также загружается для дальнейшей инициализации оборудования. Все это все еще происходит из образа initramfs .

6. Обработка initrd.target: процесс systemd выполняет все юниты из initrd.target , который подготавливает минимальную операционную среду, в которой корневая файловая система на диске монтируется в каталог /sysroot . На данный момент загружено достаточно, чтобы перейти к установке системы, которая была записана на жесткий диск.

7. Переключение на корневую файловую систему: система переключается на корневую файловую систему, которая находится на диске, и в этот момент может также загрузить процесс systemd с диска.

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

Передача аргементов в GRUB 2 ядру во время загрузки

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

Когда сервер загружается, вы кратко видите меню GRUB 2. Смотри быстро, потому что это будет длиться всего несколько секунд. В этом загрузочном меню вы можете ввести e, чтобы войти в режим, в котором вы можете редактировать команды, или c, чтобы ввести полную командную строку GRUB.

После передачи e в загрузочное меню GRUB вы увидите интерфейс, показанный на скриншоте ниже. В этом интерфейсе прокрутите вниз, чтобы найти раздел, начинающийся с linux16 /vmlinuz , за которым следует множество аргументов. Это строка, которая сообщает GRUB, как запустить ядро, и по умолчанию это выглядит так:

После ввода параметров загрузки, которые вы хотите использовать, нажмите Ctrl + X, чтобы запустить ядро с этими параметрами. Обратите внимание, что эти параметры используются только один раз и не являются постоянными. Чтобы сделать их постоянными, вы должны изменить содержимое файла конфигурации /etc/default/grub и использовать grub2-mkconfig -o /boot/grub2/grub.cfg , чтобы применить изменение.

Когда у вас возникли проблемы, у вас есть несколько вариантов (целей), которые вы можете ввести в приглашении загрузки GRUB:

■ rd.break Это останавливает процедуру загрузки, пока она еще находится в стадии initramfs .
Эта опция полезна, если у вас нет пароля root.

■ init=/bin/sh или init=/bin/bash Указывает, что оболочка должна быть запущена сразу после загрузки ядра и initrd . Это полезный вариант, но не лучший, потому что в некоторых случаях вы потеряете консольный доступ или пропустите другие функции.

■ systemd.unit=rescue.target Команда запускает еще несколько системных юнитов, чтобы привести вас в более полный рабочий режим. Требуется пароль root.
Чтобы увидеть, что загружено только очень ограниченное количество юнит-файлов, вы можете ввести команду systemctl list-units .

Запуск целей(targets) устранения неполадок в Linux

1. (Пере)загружаем Linux. Когда отобразиться меню GRUB, нажимаем e ;

2. Находим строку, которая начинается на linux16 /vmlinuz. В конце строки вводим systemd.unit=rescue.target и удаляем rhgb quit ;

3. Жмем Ctrl+X, чтобы начать загрузку с этими параметрами. Вводим пароль от root;

4. Вводим systemctl list-units и смотрим. Будут показаны все юнит-файлы, которые загружены в данный момент и соответственно загружена базовая системная среда;

5. Вводим systemctl show-environment . Видим переменные окружения в режиме rescue.target;

6. Перезагружаемся reboot ;

7. Когда отобразится меню GRUB, нажимаем e . Находим строку, которая начинается на linux16 /vmlinuz. В конце строки вводим systemd.unit=emergency.target и удаляем rhgb quit ;

8. Снова вводим пароль от root;

9. Система загрузилась в режиме emergency.target;

10. Вводим systemctl list-units и видим, что загрузился самый минимум из юнит-файлов.

Устранение неполадок с помощью загрузочного диска Linux

Еще один способ восстановления работоспособности Linux использовать образ операционки.

Если вам повезет меньше, вы увидите мигающий курсор в системе, которая вообще не загружается. Если это произойдет, вам нужен аварийный диск. Образ восстановления по умолчанию для Linux находится на установочном диске. При загрузке с установочного диска вы увидите пункт меню "Troubleshooting". Выберите этот пункт, чтобы получить доступ к параметрам, необходимым для ремонта машины.

Install CentOS 7 in Basic Graphics Mode: эта опция переустанавливает систему. Не используйте её, если не хотите устранить неполадки в ситуации, когда обычная установка не работает и вам необходим базовый графический режим. Как правило, вам никогда не нужно использовать эту опцию для устранения неисправностей при установке.
Rescue a CentOS System: это самая гибкая система спасения. Это должен быть первый вариант выбора при использовании аварийного диска.
Run a Memory Test: если вы столкнулись с ошибками памяти, это позволяет пометить плохие микросхемы памяти, чтобы ваша машина могла нормально загружаться.
Boot from local drive: здесь я думаю всё понятно.

Пример использования "Rescue a CentOS System"

1. Перезагружаем сервер с установочным диском Centos 7. Загружаемся и выбираем "Troubleshooting".

2. В меню траблшутинга выбираем "Rescue a CentOS System" и загружаемся.

3. Система восстановления теперь предлагает вам найти установленную систему Linux и смонтировать ее в /mnt/sysimage . Выберите номер 1, чтобы продолжить:
4. Если была найдена правильная установка CentOS, вам будет предложено, чтобы система была смонтирована в /mnt/sysimage . В этот момент вы можете дважды нажать Enter, чтобы получить доступ к оболочке восстановления.

5. Ваша система Linux на данный момент доступна через каталог /mnt/sysimage . Введите chroot /mnt/sysimage . На этом этапе у вас есть доступ к корневой файловой системе, и вы можете получить доступ ко всем инструментам, которые необходимы для восстановления доступа к вашей системе.

Переустановка GRUB с помощью аварийного диска

Одна из распространенных причин, по которой вам нужно запустить аварийный диск, заключается в том, что загрузчик GRUB 2 не работает. Если это произойдет, вам может понадобиться установить его снова. После того, как вы восстановили доступ к своему серверу с помощью аварийного диска, переустановить GRUB 2 несложно, и он состоит из двух этапов:

Убедитесь, что вы поместили содержимое каталога /mnt/sysimage в текущую рабочую среду.
Используйте команду grub2-install , а затем имя устройства, на котором вы хотите переустановить GRUB 2. Если это виртуальная машина KVM используйте команду grub2-install /dev/vda и на физическом сервере или виртуальная машина VMware, HyperV или Virtual Box, это grub2-install /dev/sda .

Повторное создание Initramfs с помощью аварийного диска

Иногда initramfs также может быть поврежден. Если это произойдет, вы не сможете загрузить свой сервер в нормальном рабочем режиме. Чтобы восстановить образ initramfs после загрузки в среду восстановления, вы можете использовать команду dracut . Если используется без аргументов, эта команда создает новый initramfs для загруженного в данный момент ядра.
Кроме того, вы можете использовать команду dracut с несколькими опциями для создания initramfs для конкретных сред ядра. Существует также файл конфигурации с именем /etc/dracut.conf , который можно использовать для включения определенных параметров при повторном создании initramfs .

/usr/lib/dracut/dracut.conf.d/*.conf содержит системные файлы конфигурации по умолчанию.
/etc/dracut.conf.d содержит пользовательские файлы конфигурации dracut.
/etc/dracut.conf используется в качестве основного файла конфигурации.

Исправление общих проблем

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

Переустановка GRUB 2

Код загрузчика не исчезает просто так, но иногда может случиться, что загрузочный код GRUB 2 будет поврежден. В этом случае вам лучше знать, как переустановить GRUB 2. Точный подход зависит от того, находится ли ваш сервер в загрузочном состоянии. Если это так, то довольно просто переустановить GRUB 2. Просто введите grub2-install и имя устройства, на которое вы хотите его установить. У команды есть много различных опций для точной настройки того, что именно будет установлено, но вам, вероятно, они не понадобятся, потому что по умолчанию команда устанавливает все необходимое, чтобы ваша система снова загрузилась. Становится немного сложнее, если ваш сервер не загружается.

Если это произойдет, вам сначала нужно запустить систему восстановления и восстановить доступ к вашему серверу из системы восстановления. После монтирования файловых систем вашего сервера в /mnt/sysimage и использования chroot /mnt/sysimage , чтобы сделать смонтированный образ системы вашим корневым образом: Просто запустите grub2-install , чтобы установить GRUB 2 на желаемое установочное устройство. Но если вы находитесь на виртуальной машине KVM, запустите grub2-install /dev/vda , а если вы находитесь на физическом диске, запустите grub2-install /dev/sda .

Исправление Initramfs

В редких случаях может случиться так, что initramfs будет поврежден. Если вы тщательно проанализируете процедуру загрузки, вы узнаете, что у вас есть проблема с initramfs , потому что вы никогда не увидите, как корневая файловая система монтируется в корневой каталог, и при этом вы не увидите запуска каких-либо системных модулей. Если вы подозреваете, что у вас есть проблема с initramfs , ее легко создать заново. Чтобы воссоздать его, используя все настройки по умолчанию (что в большинстве случаев нормально), вы можете просто запустить команду dracut --force . (Без --force команда откажется перезаписать ваши существующие initramfs .)
При запуске команды dracut вы можете использовать файл конфигурации /etc/dracut.conf , чтобы указать, что именно записывается в initramfs . В этом файле конфигурации вы можете увидеть такие параметры, как lvmconf = «no» , которые можно использовать для включения или выключения определенных функций. Используйте эти параметры, чтобы убедиться, что у вас есть все необходимые функции в initramfs .

Восстановление после проблем с файловой системой

На данный момент мы достигли своей службы dracut.pre-mount.service , когда наша корневая файловая система пользователя ещё не смонтирована внутри initramfs. Следующая стадия запуска systemd смонтирует эту корневую файловую систему в sysroot .

sysroot.mount

systemd принимает параметр командной строки dracut mount , который сбрасывает нас в аварийную оболочку - mount . Как вы видите на Рисунке 9-1, мы передали параметр командной строки ядра rd.break=mount .

Рисунок 9-1

Параметр командной строки ядра

Как вы можете видеть на Рисунке 9-2, sysroot была смонтирована с корневой файловой системой пользователя в режиме только для чтения.

Рисунок 9-2

Особая точка входа монтирования

Особая точка входа dracut.mount ( usr/lib/systemd/system/dracut-mount.service ) запустит надлежащий сценарий /bin/dracut-mount из initramfs, который и выполнит необходимую часть монтирования.

Как вы можете видеть, этот выполняет сценарий dracut-mount из iniramfs и к тому же экспортирует соответствующую переменную NEWROOT со значением sysroot .

В Главе 8 мы увидели как именно это сбрасывает нас в некую аварийную оболочку и все связанные функции этого. Так как мы остановили свою последовательность запуска после монтирования необходимой корневой файловой системы внутри initramfs, как вы можете обнаружить на Рисунке 9-3, наш systemd-fstab-generator уже был выполнен и уже были созданы файлы элементов -mount .

Рисунок 9-3

Поведение нашего systemd-fstab-generator

Помните, что значение названия корневой файловой системы в sysroot.mount было взято из соответствующего файла /proc/cmdline . Сам sysroot.mount чётко указывает что следует монтировать и где это надлежит монтировать.

initrd.target

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

Поиск самой корневой файловой системы пользователя.

Монтирование этой корневой файловой системы пользователя (мы достигли этого этапа запуска).

Поиск прочих необходимых файловых систем и их монтирования ( usr , var , nfs , cifs и т.п.).

Переключение на смонтированную корневую файловую систему пользователя.

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

Запуск multi-user.target или graphical.target (что выходит за рамки этой книги).

Как вы можете видеть, на данный момент мы достигли этапа 2, коим выступает монтирование необходимой корневой файловой системы пользователя. Мы знаем, что systemd имеет .targets , а .target это ни что иное, как пакет файлов элементов. Такой .target может быть успешно запущен только когда все эти файлы элементов были успешно запущены.

В установленном мире systemd имеется моножество целей, такие как basic.target , multi-user.target , graphical.target , default.target и sysinit.target , перечисляя лишь часть. Окончательная цель initramfs состоит в достижении initrd.target . После того как успешно запущен initrd.target , тогда в него переключится switch_root systemd. Итак, вначале мы взглянем на initrd.target и где она стоит с точки зрения последовательности запуска. Обращаем ваше внимание на показанную на Рисунке 9-4 блок- схему.

Рисунок 9-4

Наша последовательность запуска

Когда вы находитесь вне initramfs (то есть после switch_root ), default.target systemd будет либо multi-user.target , либо graphical.target , в то время как внутри initremfs (то есть паеред switch_root ) после basic.target default.target systemd будет initrd.target . Итак, после успешного завершения sysinit.target и basic.target , основная задача systemd состоит в достижении initrd.target . Для её достижения systemd применит этап sysroot.target для считывания тех смонтированных файлов элементов, которые созданы systemd-fstab-generator . Сама служба dracut-mount.service смонтирует необходимую корневую файловую систему в /sysroot и затем systemd исполнит соответствующую службу initrd-parse-etc.service . Она выполнит синтаксический разбор файла /sysroot/etc/fstab и создаст необходимые монтируемые файлы элементов для usr или всех прочих точек монтирования, которые обладают установкой параметра x-initrd.mount . Вот как работает initrd-parse-etc.service :

Обычно эта служба выполняет systemctl с неким переключателем daemon-reload . Это перезапускает установленную конфигурацию диспетчера systemd. Что перезапустит все генераторы, перезагрузит все файлы элементов и повторно создаст всё дерево зависимостей целиком. В то время как этот демон перезапускается, будут оставаться доступными все сокеты, в которых systemd от имени пользователя выполняет ожидание. Те генераторы, которые повторно исполняет systemd таковы:

Как вы можете видеть, это выполнит systemd-fstab-generator , который считает записи /sysroot/etc/fstab и создаст необходимые монтируемые файлы элементов для usr и для устройств, обладающих установленным параметром x-initrd.mount . Короче говоря, systemd-fstab-generator исполняется дважды.

Поэтому когда вы сваливаете себя в соответствующую оболочку монтирования ( rd.break=mount ), вы на самом деле прерываете свою последовательность запуска после соответствующей initrd.target . Эта цель запускает всего лишь такие службы:

Для понимания всего этого обращаем ваше внимание на Рисунок 9-5.

Рисунок 9-5

Общее исполнение initrd.target

Иногда новички во время установки Ubuntu сталкиваются с ошибкой Корневая файловая система не определена, В этой ошибке виновен не дистрибутив и его проблемы сборки, а пользователь, задавший неверные параметры установки системы.

Ошибка: корневая файловая система не определена при установке

Такая ошибка может возникнуть если во время установки Ubuntu вы выбираете ручную разметку диска, а потом не добавляете корневую файловую систему и пытаетесь перейти к следующему шагу установки:

Корневая файловая система, это раздел диска, на который будет устанавливаться основная часть операционной системы Linux. Без этого раздела установка невозможна, поэтому программа установки предлагает вам вернуться назад и всё таки указать нужный раздел.

Если ваш жесткий диск, на который вы собираетесь установить Linux пуст, вам следует создать новую таблицу разделов, для этого кликнте по соответствующей кнопке, но не делайте этого если на диске уже есть какие-либо данные, иначе эта операция сотрёт всё, что там было:

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

В открывшемся окне обязательно надо выбрать точку монтирования "/", а также желательно выбрать файловую систему семейства EXT в поле Использовать как, она самая стабильная и надёжная:

Именно по точке монтирования установщик определяет, что это корневая файловая система. После этого у вас появится только что созданный корневой раздел в списке разделов:

И теперь установка продолжиться успешно, так как всё что необходимо уже есть. Раньше утилита установки ещё предлагала создать раздел подкачки, но теперь в этом нет необходимости потому что подкачка размещается в виде файла на корневом разделе. Теперь вы знаете что делать если у вас возникла такая ошибка, как видите, всё очень просто.

Нет похожих записей

Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна.

Как было сказано в предыдущем разделе, в процессе начальной загрузки вначале монтируется временный виртуальный диск, содержащий корневую файловую систему (очевидно, тоже временную), с помощью которой осуществляется запуск на выполнение ядра операционной системы. Образ этой корневой системы хранится на загрузочном устройстве в каталоге /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 может отличаться):

Листинг 2. Просматриваем initrd в варианте loop-устройства (до FC3) После этого вы можете посмотреть содержимое initrd в директории /mnt/initrd. Заметьте что даже если имя вашего образа initrd не заканчивается на ".gz", это все равно сжатый файл и добавив к концу имени суффикс ".gz", вы сможете воспользоваться командой gunzip, чтобы его распаковать.

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

Листинг 3. Просматриваем initrd в варианте cpio-архива (FC3 и позже) После этого в каталоге

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

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

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

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

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

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.х)

Все сказанное выше относительно процедур загрузки и использования файла initrd справедливо для ядер версии 2.4.xx и более ранних. В ядрах версии 2.6 (а точнее, начиная с экспериментального ядра версии 2.5.46) разработчики решили реализовать иной механизм. Причиной послужили несколько недостатков ранее использовавшегося варианта реализации временной корневой файловой системы.

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

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

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

Система, использующая 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. Другие, более мощные оболочки на этом этапе еще недоступны.

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

Читайте также: