Приветствую! Меня зовут Валерий, я инженер операционных систем в секторе клиентской и мобильной ОС.
Сегодня хочу затронуть фундаментальные вопросы:
— процесс загрузки операционной системы в автоматизированное рабочее место (АРМ),
— распаковку начального образа оперативной памяти,
— подробный разбор initrd, что это такое и с чем его едят.
Этот материал поможет понять как природу загрузки ОС Astra Linux Special Edition в частности, так и загрузку GNU/Linux в целом.
1. Что такое initrd?
Начальный RAM-диск для загрузки Linux (initrd) — это блочное устройство, в операционной системе представленное образом, который монтируется в процессе загрузки системы в оперативную память для поддержки 2-уровневой модели загрузки. Initrd состоит из различных исполняемых файлов и драйверов, которые позволяют смонтировать настоящую корневую файловую систему, после чего initrd размонтируется и освободится память.
Определим, как загружается initrd в систему. Для этого выполним команду:
sudo dmesg | grep -i 'initramfs' [0.322851] Trying to unpack rootfs image as initramfs... [0.651110] Freeing initrd memory: 75824K [2.320381] systemd[1]: systemd-fsck-root.service - File System Check on Root Device was skipped because of an unmet condition check (ConditionPathExists=!/run/initramfs/fsck-root).Из первой строки сообщений видно, что на этапе загрузки системы ядро пытается распаковать образ корневой файловой системы, такой как initramfs, для начальной инициализации файловой системы.
Второе сообщение говорит об освобождаемой памяти, занятой initrd. Также оно явно указывает, что начальная загрузка использовала initrd, который после завершения своей задачи высвобождает занятые ранее аппаратные ресурсы.
Третье сообщение подтверждает, что используется все-таки initramfs, а systemd сообщает о пропущенной проверке файловой системы systemd-fsck-root.service из-за того, что не существует пути /run/initramfs/fsck-root.
Логика этой проверки такова: проверить файловую систему, если /run/initramfs/fsck-root не существует.
А поскольку проверка была пропущена, то данный путь существует в момент запуска операционной системы, ведь других сообщений касательно initramfs не появлялось.
1.1. Как initrd загружается в память?
Когда мы нажали кнопку включения компьютера или сервера, начался процесс загрузки BIOS/UEFI. Сначала он определяет устройство для загрузки с помощью проверки таблиц разделов устройств MBR или GPT.
Затем, используя информацию о разделах и загрузочных данных, загружается начальная часть загрузчика (например, GRUB), которая отвечает за загрузку второй стадии grub, отвечающей за загрузку ядра операционной системы и переход на её выполнение.
Когда ядро загрузилось в оперативную память, GRUB передает ему управление через прямой переход (например, через функции jmp или call на x86_64 архитектуре):
jmp [адрес начала ядра]После чего ядро начинает настройку таблиц страниц в оперативной памяти, кеширование и настройку других системных структур.
Так как в загрузчике указан initrd, ядро будет искать и загружать образ в оперативную память. GRUB в этом случае передает ядру путь к initrd через параметры командной строки. Ядро использует свои встроенные драйверы для разархивации и монтирования initrd. В зависимости от типа сжатия используется соответствующий декомпрессор (в ОС Astra Linux SE используется метод сжатия gzip). Initrd распаковывается в область оперативной памяти согласно параметрам, передаваемым от GRUB, через структуру boot_params. Она описана в заголовках ядра Linux и содержит такие поля, как:
__u32 ext_ramdisk_image;/* 0x0c0 */ __u32 ext_ramdisk_size;/* 0x0c4 */ __u32 ext_cmd_line_ptr;/* 0x0c8 */Данная информация содержится по пути:
/usr/src/linux-headers-$(uname -r)/arch/x86/include/uapi/asm/bootparam.h Это происходит на ранних стадиях инициализации, еще до запуска init-процесса.
Но поскольку мы изучаем initrd в данной статье, давайте рассмотрим структуру каталогов и файлов, распаковав initrd в операционной системе:
mkdir initrd_content && cp /boot/initrd.img-6.1.90-1-generic ~/initrd_content/initrd.img-6.1.90-1-generic.xz cd ~/initrd_content/ unzstd initrd.img-6.1.90-1-generic.xz && cpio -id < ./initrd.img-6.1.90-1-generic rm initrd.img-6.1.90-1-generic*Так выглядит распакованный образ initrd.
administrator@astra-02841:~/initrd_content$ ls -la итого 48 drwxr-xr-x 9 administrator administrator 4096 сен 3 17:43 . drwxr-x---+ 20 administrator administrator 4096 сен 3 17:43 .. lrwxrwxrwx 1 administrator administrator 7 сен 3 17:43 bin -> usr/bin drwxr-xr-x 3 administrator administrator 4096 сен 3 17:43 conf drwxr-xr-x 2 administrator administrator 4096 сен 3 17:43 cryptroot drwxr-xr-x 11 administrator administrator 4096 сен 3 17:43 etc -rwxr-xr-x 1 administrator administrator 6556 сен 3 17:43 init lrwxrwxrwx 1 administrator administrator 7 сен 3 17:43 lib -> usr/lib lrwxrwxrwx 1 administrator administrator 9 сен 3 17:43 lib64 -> usr/lib64 drwxr-xr-x 2 administrator administrator 4096 сен 3 17:43 run lrwxrwxrwx 1 administrator administrator 8 сен 3 17:43 sbin -> usr/sbin drwxr-xr-x 10 administrator administrator 4096 сен 3 17:43 scripts drwxr-xr-x 9 administrator administrator 4096 сен 3 17:43 usr drwxr-xr-x 3 administrator administrator 4096 сен 3 17:43 varВ Astra Linux многие действия и механизмы защиты содержатся в директории скриптов.
1.2. Вперед, изучать скрипты! Скрипт init
Посмотрим в содержимое каталога scripts:
administrator@astra-02841:~/initrd_content/scripts$ ls -lah итого 64K drwxr-xr-x 10 administrator administrator 4,0K сен 3 17:43 . drwxr-xr-x 9 administrator administrator 4,0K сен 3 17:43 .. -rw-r--r-- 1 administrator administrator 12K сен 3 17:43 functions drwxr-xr-x 2 administrator administrator 4,0K сен 3 17:43 init-bottom drwxr-xr-x 2 administrator administrator 4,0K сен 3 17:43 init-premount drwxr-xr-x 2 administrator administrator 4,0K сен 3 17:43 init-top -rw-r--r-- 1 administrator administrator 5,2K сен 3 17:43 local drwxr-xr-x 2 administrator administrator 4,0K сен 3 17:43 local-block drwxr-xr-x 2 administrator administrator 4,0K сен 3 17:43 local-bottom drwxr-xr-x 2 administrator administrator 4,0K сен 3 17:43 local-premount drwxr-xr-x 2 administrator administrator 4,0K сен 3 17:43 local-top -rw-r--r-- 1 administrator administrator 3,1K сен 3 17:43 nfs drwxr-xr-x 2 administrator administrator 4,0K сен 3 17:43 panicМы наблюдаем скрипты разных уровней, которые загружаются в определенной последовательности. Так какой же скрипт загружается первым?
Самым «шустрым» оказался скрипт ./init, расположенный в корне inird:
Что он делает?
Как работает скрипт init, начальная отработка
Для начала он настраивает окружение:
export PATH=/sbin:/usr/sbin:/bin:/usr/binПотом скрипт монтирует директории /dev /root /sys /proc /tmp. Далее монтирует файловые системы sysfs и proc, которые предоставляют информацию о системе и процессах.
[ -d /dev ] || mkdir -m 0755 /dev [ -d /root ] || mkdir -m 0700 /root [ -d /sys ] || mkdir /sys [ -d /proc ] || mkdir /proc [ -d /tmp ] || mkdir /tmp mount -t sysfs -o nodev,noexec,nosuid sysfs /sys mount -t proc -o nodev,noexec,nosuid proc /procЧуть не забыли о создании каталога:
mkdir -p /var/lock Он создает lock-директорию для хранения файлов блокировок. В основном каталог предназначен для предотвращения гонок и коллизий, для обеспечения ресурсной синхронизации и для управления доступом к ресурсам уже в пользовательском режиме.
Дальше идет обработка параметров командой строки, которые задаются в меню GRUB.
for x in $(cat /proc/cmdline); do case $x in initramfs.clear) clear ;; quiet) quiet=y ;; esac doneЭтот кусочек скрипта не так важен, он просто реагирует на параметр quiet и выводит на экран надпись Loading, please wait…:
if [ "$quiet" != "y" ]; then quiet=n echo "Loading, please wait..." fi export quietа после этого скрипт:
mount -t devtmpfs -o nosuid,mode=0755 udev /devмонтирует виртуальную файловую систему devtmpfs, которая позволяет автоматизировать создание файлов устройств (потому что в Linux все есть файл!).
Смысл параметров заключается в доступе root на чтение, запись и выполнение, остальным пользователям на чтение и выполнение, в том числе атрибут nosuid запрещает выполнение файлов с setuid и setgid битами, чтобы повысить безопасность. Это еще не корневая ФС, если не будут использованы udev-скрипты, о чем говорит комментарий:
# Note that this only becomes /dev on the real filesystem if udev's scripts # are used; which they will be, but it's worth pointing outСкрипты udev потом выполняют действия для окончательного переноса файлов устройств на корневую файловую систему.
Это уточнение важно для понимания того, как файловая система и каталоги устройства интегрируются на разных этапах загрузки системы. Временная файловая система используется на ранних этапах загрузки, а затем передаёт контроль основной файловой системе, где и происходит окончательная настройка и управление устройствами через udev. Но об этом как-нибудь позже.
А вот и потоки ввода-вывода:
# Prepare the /dev directory [ ! -h /dev/fd ] && ln -s /proc/self/fd /dev/fd [ ! -h /dev/stdin ] && ln -s /proc/self/fd/0 /dev/stdin [ ! -h /dev/stdout ] && ln -s /proc/self/fd/1 /dev/stdout [ ! -h /dev/stderr ] && ln -s /proc/self/fd/2 /dev/stderrЧетыре строчки обеспечивают возможность ввода-вывода через потоки!
Первая часть каждой строчки проверяет, есть ли файл. Если его не существует или он не является символической ссылкой (симлинком), возвращает true, после чего линкуется с соответствующим файлом в /dev. Каждый линуксоид когда-нибудь делал что-то вроде такого:
somecommand 2>> error.logИменно про это и сделаны скрипты для создания потоков ввода-вывода.
Переходим к терминалам. Вернее, к псевдотерминалам!
mkdir /dev/pts mount -t devpts -o noexec,nosuid,gid=5,mode=0620 devpts /dev/pts || trueЭтими командами initrd создает каталог для псевдотерминалов, а теперь к параметрам его монтирования!
noexec запрещает выполнение файлов в этой ФС.
nosuid, как и в /dev, запрещает выполнение файлов с setuid и setgid битами, устанавливает доступ для группы c gid 5 на запись. В любом linux стандартно это группа tty (tty:x:5:).
Root имеет в данном случае право на чтение и запись, devpts — стандартное имя файловой системы псевдотерминалов, а /dev/pts || true — точка монтирования и интересные пайплайны, которые обеспечат продолжение работы скрипта, если монтирование будет неуспешным.
Экспортирование переменных
После монтирования устройств идёт экспортирование переменных:
# Export the dpkg architecture export DPKG_ARCH= . /conf/arch.confПервый экспорт архитектуры DPKG берет свое значение из /conf/arch.conf и равен для x86_64 архитектур amd64. Думаю, здесь ничего непонятного нет, не так ли?
# Set modprobe env export MODPROBE_OPTIONS="-qb"Опции для команды modprobe, говорящие ей: «Не выводи сообщения о статусе и игнорируй ошибки».
# Export relevant variables export ROOT= export ROOTDELAY= export ROOTFLAGS= export ROOTFSTYPE= export IP= export DEVICE= export BOOT= export BOOTIF= export UBIMTD= export break= export init=/sbin/init export readonly=y export rootmnt=/root export debug= export panic= export blacklist= export resume= export resume_offset= export noresume= export drop_caps= export fastboot=n export forcefsck=n export fsckfix=Теперь пройдемся по определенным переменным окружения:
init=/sbin/init — указывает, какой иницилизационный процесс следует запустить после загрузки. Стандартно это, конечно же, init, который запускает с 0 PID и вызывает systemd.
readonly=y: — указывает, что корневая файловая система должна монтироваться только для чтения. Установлено значение «Да».
rootmnt=/root — указывает на то, что мы определили корневой монтированный каталог.
В результате выполнения экспорта настроены переменные окружения для дальнейшей работы initrd.
Но об этом я расскажу в следующей части.
В качестве промежуточного анонса могу добавить, что дальше остановимся на конфигурационном файле initramfs.conf, а также доразберем init-скрипт. Продолжение следует.
ссылка на оригинал статьи https://habr.com/ru/articles/851056/
Добавить комментарий