Разбираемся с установкой и загрузкой Linux на примере ArchLinux

Сначала мы установим Archlinux и превратим его в загрузочный сервер. Прямо оттуда подготовим новую компактную систему, в которую добавим минимальное графическое окружение и самый необходимый функционал (на примере Firefox). Научим нашу систему загружаться по сети даже на компьютерах с UEFI. Затем полностью переведём её в режим «только для чтения» (сделаем «живой»), что позволит нам использовать систему одновременно хоть на пол сотне разномастных компьютеров с одним единственным загрузочным сервером. Это всё будет работать даже внутри дешёвой 100-Мб сети, которую мы дополнительно «разгоним» в пару раз.

Никакие закладки в жестких дисках будут вам не страшны, потому что дисков у нас не будет. Никакие очумелые ручки пользователей ничего не сломают, т. к. после перезагрузки система вернется в первозданное лично вами состояние. Конечно же, вы научитесь и сможете самостоятельно изменять загружаемую систему таким образом, чтобы в ней содержался только нужный вам функционал и ничего лишнего. Между делом мы выясним, как и в каком порядке загружается Linux, а также из чего он состоит. Знания, как известно, — бесценны, поэтому я делюсь ими даром.

Постараюсь без долгих рассуждений пояснять происходящее, иногда забегая немного вперёд, но впоследствии обязательно раскладывая всё по полочкам. Чтобы у вас вообще не возникало проблем с пониманием, предполагаю, что вы уже работали с каким-нибудь готовым дистрибутивом Linux, пробовали писать простые скрипты с помощью nano или другого текстового редактора. Если вы новичок в ArchLinux, то узнаете много нового, а если «старичок», то узнаете поменьше, но, надеюсь, что в любом случае вы ещё сильнее полюбите Linux.

Информации оказалось очень много. И по устоявшейся голливудской традиции впереди вас ждёт сериал в нескольких частях.

Сейчас мы установим Archlinux в VirtualBox, который можно будет клонировать и запускать практически на любом компьютере с legacy BIOS без каких-либо дополнительных настроек. Между делом мы познакомимся с основными приёмами работы с systemd, а также узнаем как его использовать для запуска произвольных служб и программ во время загрузки. Ещё мы увидим, какие этапы проходит Linux при загрузке, и напишем собственный обработчик (hook), который поместим в initramfs. Не знаете что такое initramfs? Тогда заходите под кат.

Есть много причин, по которым выбор пал именно на Archlinux. Первая причина: он мой давний изворотливый приятель и верный помощник. Gentoo, как пишут на просторах Интернета, ещё более изворотлив, но собирать систему из исходников не хочется. Вторая причина: в готовых сборках всегда содержится много лишнего, а перекачивание больших объемов данных может критично сказаться на производительности сети, да и ничего не видно за широкой спиной «автоматического инсталлятора» — это третья причина. Четвертая: systemd постепенно проникает во все дистрибутивы и даже в Debian, так что мы сможем хорошенько покопаться в грядущем готовых дистрибутивов на примере Archlinux. При всём при этом, систему, которую мы позднее подготовим, можно будет загружать по сети не только сервера, работающего в виртуальной машине, но и с обычного компьютера, например, с Raspberry Pi, и даже с Western Digital My Cloud (проверено), который работает под Debian.

Подготовительные работы

Скачиваем свежий образ по ссылке с официального сайта. В Москве с серверов Яндекса, например, загрузка происходит очень быстро, и если у вас процесс затянулся — просто попробуйте качать в другом месте. Рекомендую запомнить в каком, т. к. эта информация нам ещё пригодится.

В VirtualBox создаем новую виртуальную машину (например, с 1 Гб оперативной памяти и 8 Гб накопителем). В настройках сети необходимо выбрать тип подключения «сетевой мост» и подходящий сетевой адаптер с доступом к сети Интернет. Подключаем скаченный образ к CD-ROM'у. Если не терпится начать работать с железом, то берите флешку и записывайте образ с помощью Win32 Disk Imager (если работаете под Windows), а потом загружайте будущий сервер прямо с неё.

Включаем машину, дожидаемся появления командной строки и устанавливаем пароль, без которого SSH работать не будет:

passwd

Запускаем сервер SSH командой:

systemctl start sshd

Остается узнать IP адрес машины, изучив вывод команды:

ip addr | grep "scope global"

Адрес будет указан сразу после «inet».

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

Базовая установка

Дальше максимально коротко опишу стандартную установку Archlinux. Если появятся вопросы, то ответы на них вы, вероятно, найдете в Подробном описании установки для новичков. Wiki просто замечательная, а англоязычная wiki даже актуальная, так что старайтесь пользоваться именно ей.

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

cfdisk /dev/sda

Форматируем в ext4 и устанавливаем метку, например HABR:

mkfs.ext4 /dev/sda1 -L "HABR"

Будущий корневой раздел монтируем в /mnt:

export root=/mnt
mount /dev/sda1 $root

Archlinux обычно устанавливается через интернет, поэтому сразу после установки у вас будет самая новая и актуальная версия. Список репозиториев находится в файле /etc/pacman.d/mirrorlist. Постарайтесь вспомнить, откуда скачивали дистрибутив и перенесите эти серверы в самое начало списка — так вы серьезно сэкономите время на следующем шаге. Обычно это серверы, географически расположенные там же, где вы сейчас находитесь.

nano /etc/pacman.d/mirrorlist

Устанавливаем базовый набор пакетов и набор для разработчиков:

pacstrap -i $root base base-devel

Теперь воспользуемся командой arch-chroot, которая позволяет временно подменить корневой каталог на любой другой, в котором есть структура корневой файловой системы Linux. При этом программы, которые мы оттуда запустим, не будут знать о том, что снаружи ещё что-то существует. Мы практически окажемся в нашей новой системе с правами администратора:

arch-chroot $root

Обратите внимание, как поменялось приглашение командной строки.

Выбираем языки, которые планируем использовать. Предлагаю оставить en_US.UTF-8 UTF-8 и ru_RU.UTF-8 UTF-8. В текстовом редакторе нужно просто снять комментарии напротив них:

nano /etc/locale.gen

Теперь генерируем выбранные локализации:

locale-gen

Если всё прошло хорошо, то вы увидите примерно такой текст:

Generating locales...
  en_US.UTF-8... done
  ru_RU.UTF-8... done
Generation complete.

Устанавливаем язык, который будет использоваться по-умолчанию:

echo LANG=ru_RU.UTF-8 > /etc/locale.conf

А также раскладку и шрифт в консоли:

echo -e "KEYMAP=runFONT=cyr-sun16nFONT_MAP=" > /etc/vconsole.conf

Указываем часовой пояс (я использую московское время):

ln -s /usr/share/zoneinfo/Europe/Moscow /etc/localtime

Придумываем название для нашего будущего сервера:

echo "HabraBoot" > /etc/hostname

Теперь установим пароль администратора. Делаем мы это в первую очередь из-за того, что SSH не позволит нам подключиться к системе без пароля. Тему неразумности использования системы, незащищенной паролем, здесь мы развивать не будем.

passwd

Дважды вводим пароль и убеждаемся, что password updated successfully.

Добавим нового пользователя с именем username (можете выбрать любое), наделим его правами администратора и зададим ему пароль из тех же соображений, а ещё и из-за того, что под root в текущей версии Arch мы не сможем собирать пакеты из AUR (Arch User Repository — это репозиторий от сообщества пользователей Arch Linux с программами, которые не вошли в основной репозиторий):

useradd -m username

Редактируем файл настроек /etc/sudoers с помощью nano:

EDITOR=nano visudo

Добавив в него сразу после строки «root ALL=(ALL) ALL» ещё одну строчку:

username ALL=(ALL) ALL

И задаём пароль для пользователя username:

passwd username

Теперь нужно установить загрузчик на внутренний накопитель, чтобы система смогла самостоятельно с него загрузиться. В качестве загрузчика предлагаю использовать GRUB, потому что позже он нам снова пригодится. Устанавливаем пакеты с помощью стандартного для Archlinux менеджера пакетов pacman:

pacman -S grub

Записываем загрузчик в MBR (Master Boot Record) нашего внутреннего накопителя.

grub-install --target=i386-pc --force --recheck /dev/sda

Если всё прошло нормально, то вы увидите Installation finished. No error reported.

Выходим из chroot:

exit

И замечаем, как поменялось приглашение командной строки.

Мы будем использовать метки дисков, подробное объяснение этого утверждения последует позже.

Снимите комментарий со строки GRUB_DISABLE_LINUX_UUID=true, чтобы не использовались UUID накопителей:

nano $root/etc/default/grub

Генерируем файл конфигурации загрузчика, снова используя arch-chroot. Будет произведён вход, выполнение одной единственной команды, и последует автоматический выход:

arch-chroot $root grub-mkconfig --output=/boot/grub/grub.cfg

Нам нужно заменить все упоминания /dev/sda1 на LABEL=HABR в файле конфигурации:

mv $root/boot/grub/grub.cfg $root/boot/grub/grub.cfg.autoconf &&  cat $root/boot/grub/grub.cfg.autoconf | sed 's/(root=)/dev/sda1/1LABEL=HABR/g' > $root/boot/grub/grub.cfg

Если поменять в этом же файле строку set lang=en_US на set lang=ru_RU, то загрузчик будет общаться с нами на великом и могучем.

Генерируем файл fstab с ключом -L, который заставит генератор использовать метки дисков:

genfstab -p -L $root > $root/etc/fstab

На этом базовая установка ArchLinux закончена. Система будет загружаться самостоятельно и встретит вас приветливым русскоязычным интерфейсом командной строки. Если после этого мы введем команду dhcpcd, то скорее всего даже Интернет заработает. Но мы пока не будем торопиться с перезагрузкой.

Запуск при загрузке с помощью systemd на примере NTP и SSH

Поскольку наша система будет общаться с другими компьютерами, нам потребуется синхронизировать время. Если время на сервере и клиенте будет отличаться, то существует большая вероятность того, что они вообще не смогут соединиться друг с другом. В свою очередь sudo может начать просить пароль после каждого действия, думая, что таймаут авторизации давно истёк. И кто знает, с чем нам ещё предстоит столкнуться? Перестрахуемся.

Чтобы синхронизировать время с серверами через Интернет по протоколу NTP, нам нужно установить недостающие пакеты. Можно воспользоваться arch-root, но но мы обойдёмся ключами, которые сообщат новое место для установки менеджеру пакетов:

pacman --root $root --dbpath $root/var/lib/pacman -S ntp

Настроим получение точного времени с российских серверов:

mv $root/etc/ntp.conf $root/etc/ntp.conf.old && cat $root/etc/ntp.conf.old | sed 's/([0-9]).*(.pool.ntp.org)/1.ru2/g' | tee $root/etc/ntp.conf

Нам достаточно синхронизировать время один раз при загрузке. Раньше мы бы записали запуск службы точного времени в файл rc.local, но сейчас появился менеджер системы и служб systemd, который старается запускать службы (в оригинале они называются unit) параллельно для уменьшения времени загрузки системы. Естественно, что работоспособность одной службы может зависеть от функционирования другой. Например, нам бесполезно пытаться синхронизировать время через Интернет до того, как у нас на компьютере заработает сеть. Чтобы описать все эти взаимосвязи, уже недостаточно простого указания имени исполняемого файла, поэтому запуск посредством systemd стал весьма нетривиальным занятием. Для этой цели были созданы специальные файлы с расширением ".service". В них указаны зависимости, имена исполняемых файлов и другие параметры, которые нужно учитывать для успешного запуска. В частности, для управления этапами загрузки в systemd используются цели (target), которые по возлагаемым на них задачам схожи с уровнями запуска (runlevel). Подробности читайте в вики.

К радости новичков, вместе с пакетом ntp поставляется уже готовый ntpdate.service. Все файлы, описывающие запуск служб, находятся в папке $root/usr/lib/systemd/system/, и их можно открыть в любом текстовом редакторе или посмотреть обычным образом. Вот, например, $root/usr/lib/systemd/system/ntpdate.service:

[Unit]
Description=One-Shot Network Time Service
After=network.target nss-lookup.target
Before=ntpd.service

[Service]
Type=oneshot
PrivateTmp=true
ExecStart=/usr/bin/ntpd -q -n -g -u ntp:ntp

[Install]
WantedBy=multi-user.target

В блоке [Unit] в строке Description указывается краткое описание службы, и при каких условиях она должна быть запущена (в данном случае, после запуска сети, но до перед запуском сервера NTP, который мы вообще не планируем запускать). Запрос точного времени происходит единственный раз во время загрузки, и за это отвечает строка Type=oneshot из блока [Service]. В этом же блоке в строке ExecStart указаны действия, которые необходимо выполнить для запуска сервиса. В блоке [Install] в нашем случае указано, что запуск нашей службы необходим для достижения цели multi-user.target. Рекомендуется использовать такое же содержание блока [Install] для запуска самодельных служб.

В качестве первого практического примера мы немного расширим функциональность ntpdate.service, попросив его дополнительно исправлять время на аппаратных часах. Если после этого, на этом же самом компьютере вы загрузите Windows, то увидите время по Гринвичу, так что не пугайтесь.

Изменение стандартного поведения любой службы systemd производится следующим образом: сначала в папке /etc/systemd/system/ создается новый каталог с полным именем службы и расширением ".d", куда добавляется файл с произвольным именем и расширением ".conf", и уже там производятся нужные модификации. Приступим:

mkdir -p $root/etc/systemd/system/ntpdate.service.d && echo -e '[Service]nExecStart=/usr/bin/hwclock -w' > $root/etc/systemd/system/ntpdate.service.d/hwclock.conf

Здесь просто говорится о том, что во сразу после запуска службы выполнить команду "/usr/bin/hwclock -w", которая переведёт аппаратные часы.

Добавляем службу ntpdate в автозагрузку (синтаксис стандартен для всех служб):

arch-chroot $root systemctl enable ntpdate
Created symlink from /etc/systemd/system/multi-user.target.wants/ntpdate.service to /usr/lib/systemd/system/ntpdate.service.

Как видите, в каталоге multi-user.target.wants создалась обыкновенная символическая ссылка на файл ntpdate.service, а упоминание о цели multi-user.target мы видели в блоке [Install] этого самого файла. Получается для того, чтобы система достигла цели multi-user.target, должны быть запущены все службы из каталога multi-user.target.wants.

Теперь устанавливаем пакет SSH аналогичным способом (в ArchLinux он называется openssh):

pacman --root $root --dbpath $root/var/lib/pacman -S openssh

Но на этот раз для автозапуска мы будем использовать сокет, чтобы сервер SSH стартовал только после поступления запроса на подключение, а не висел мёртвым грузом в оперативной памяти:

arch-chroot $root systemctl enable sshd.socket

Мы не поменяли стандартный 22-й порт и не включили принудительное использование Protocol 2 — пусть это останется на моей совести.

Забегая вперед или знакомимся с обработчиками (hooks)

Чтобы мы могли не глядя подключиться к нашему будущему серверу, нам нужно знать его IP адрес. Будет намного проще, если этот адрес — статический. Обычные способы, о которых говорится в вики, нам не подходят. Проблема в том, что сетевые адаптеры в современном мире именуются согласно своему физическому расположению на материнской плате. Например, имя устройства enp0s3 означает, что это сетевой адаптер ethernet, который расположен на нулевой шине PCI в третьем слоте (подробности здесь). Сделано так для того, чтобы при замене одного адаптера другим, имя устройства в системе не поменялось. Такое поведение нам не желательно, т. к. на разных моделях материнских плат положение сетевой карты может быть разным, и когда мы попытаемся перенести наш загрузочный сервер из VirtualBox на реальное железо, нам скорее всего придётся загружаться с клавиатурой и монитором, чтобы правильно настроить сеть. Нам нужно, чтобы имя сетевого адаптера стало более предсказуемым, например, eth0 (это место зарезервировано смайликом).

Устанавливаем пакет mkinitcpio-nfs-utils, и у нас появится обработчик (hook) под названием «net»:

pacman --root $root --dbpath $root/var/lib/pacman -S mkinitcpio-nfs-utils

По-умолчанию, все файлы обработчика попадают в /usr/lib/initcpio/. Обычно это парные файлы с одинаковым названием, один из которых окажется в подкаталоге install, а другой — в hooks. Сами файлы являются обычными скриптами. Файл из папки hooks обычно попадает внутрь файла initramfs (позже мы о нём всё узнаем) и выполняется при загрузке системы. Второй файл из пары попадает в папку install. Внутри него есть функция build(), в которой находятся сведения о том, какие действия нужно выполнить во время генерации файла initramfs, а также функция help() с описанием того, для чего предназначен данный обработчик. Если запутались, то просто читайте дальше, и всё сказанное в этом абзаце встанет на свои места.

Папка initcpio также присутствует в каталоге /etc, и в ней тоже есть подкаталоги install и hooks. При этом она имеет безусловный приоритет над /usr/lib/initcpio, т. е. если в обеих папках окажутся файлы с одинаковыми названиями, то при генерации initcpio будут использоваться файлы из /etc/initcpio, а не из /usr/lib/initcpio.

Нам нужно немного поменять функциональность обработчика net, поэтому просто скопируем файлы из /usr/lib/initcpio в /etc/initcpio:

cp $root/usr/lib/initcpio/hooks/net $root/etc/initcpio/hooks/ && cp $root/usr/lib/initcpio/install/net $root/etc/initcpio/install/

Приводим файл hooks/net к следующему виду:

cat $root/etc/initcpio/hooks/net

# vim: set ft=sh:
run_hook() {
    ipconfig "ip=192.168.1.100::192.168.1.1:255.255.255.0::eth0:none"
}

# vim: set ft=sh ts=4 sw=4 et:

Теперь откроем файл $root/etc/initcpio/install/net и увидим, что в функции help() отлично описан синтаксис команды, которую мы использовали выше, а именно:

ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>

Легко понять, что мы жёстко задали IP адрес для нашей машины 192.168.1.100, шлюз 192.168.1.1, маску подсети 255.255.255.0 и название сетевого устройства eth0. None в самом конце строки указывает, что нам не нужна автоматическая конфигурация. Здесь и далее изменяйте данные в соответствии с настройками вашей сети. Использование динамического адреса выходит за рамки данного исследования, но нет ничего невозможного.

Теперь уберём всё лишнее из файла $root/etc/initcpio/install/net. Оставляем загрузку модулей сетевых устройств, программу ipconfig, которую использовали выше, и, естественно, сам скрипт из папки hooks, выполняющий всю основную работу. Получится примерно следующее:

cat $root/etc/initcpio/install/net

#!/bin/bash

build() {
    add_checked_modules '/drivers/net/'

    add_binary "/usr/lib/initcpio/ipconfig" "/bin/ipconfig"

    add_runscript
}

help() {
    cat <<HELPEOF
This hook loads necessary modules for a network device.
Manually configures network and freezes network device name.
HELPEOF
}

# vim: set ft=sh ts=4 sw=4 et:

Когда во время загрузки менеджер устройств systemd-udevd попробует переименовать наше сетевое устройство в привычное ему predictable network interface name, например, в enp0s3, то у него ничего не получится. Почему — читайте дальше.

Как происходит загрузка системы

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

Как раз такой загрузчик мы записали в MBR нашего накопителя. Мы использовали GRUB, в настройках которого (файл grub.cfg) указали, что корневой раздел находится на диске с меткой HABR. Вот эта строка целиком:

linux   /boot/vmlinuz-linux root=LABEL=HABR rw  quiet

Здесь упомянут файл vmlinuz-linux, который является ядром системы, а указатель на корневую систему является его параметром. Мы просим искать корневую систему на устройстве с меткой HABR. Здесь также мог бы быть уникальный для каждого накопителя UUID, но в этом случае при переносе системы на другой диск нам несомненно пришлось бы его изменить. Если бы мы указали положение корневой системы привычным для линуксоидов образом: /dev/sda1, то не смогли бы загрузиться с USB накопителя, т. к. это имя USB накопитель бы получил только будучи единственным накопителем в компьютере. Маловероятно, что в компьютере окажется ещё один накопитель с меткой HABR, но не стоит об этом забывать.

В соседней строке есть упоминание файла initramfs, с которым я обещал разобраться:

initrd  /boot/initramfs-linux.img

Далее при загрузке происходит следующее: загрузчик GRUB получает файлы vmlinuz и initramfs, сообщает им, где искать корневую файловую систему и передаёт им управление дальнейшей загрузкой.

Название initramfs образовано от initial ram file system. Это на самом деле обычная корневая файловая система Linux, упакованная в архив. Она разворачивается в оперативной памяти во время загрузки и предназначена для того, чтобы найти и подготовить корневую файловую систему нашего linux, который мы пытаемся загрузить в итоге. В initramfs есть всё необходимое для этих целей, ведь это настоящий «маленький линукс», который может выполнять многие обычные команды. Его возможности расширяются с помощью обработчиков (hooks), которые помогают сформировать новую корневую файловую систему нашего linux.

После того, как программы из initramfs выполнят свою работу, управление дальнейшей загрузкой передается процессу init подготовленной корневой файловой системы. В качестве процесса init Archlinux использует systemd.

Менеджер устройств systemd-udevd является частью systemd. Он, как и его старший брат, старается обнаруживать и настраивать все устройства в системе параллельно. Он начинает свою работу одним из первых, но уже после того, как наш обработчик net инициализирует сетевую карту ещё на на этапе работы initramfs. Таким образом, systemd-udevd не может переименовать используемое устройство, и имя eth0 сохраняется за сетевой картой в течение всего времени работы.

Готовим initramfs

Для создания файла initramfs используется программа mkinitcpio, которая входит в пакет base, установленный нами в самом начале. Настройки находятся в файле $root/etc/mkinitcpio.conf, а пресеты лежат в папке /etc/mkinitcpio.d. От нас требуется сделать initramfs таким, чтобы он смог найти и подготовить корневую файловую систему, с которой впоследствии начнёт работать systemd. Нам совершенно необязательно учитывать все возможные варианты, достаточно только самого необходимого, чтобы не увеличивать размеры файла initramfs. Более подробная информация находится здесь wiki.archlinux.org/index.php/Mkinitcpio

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

Достаточный для наших целей список обработчиков включая созданный нами net выглядит следующим образом:

HOOKS="base udev net block filesystems"

вставляем эту строку в файл mkinitcpio.conf, а старую комментируем:

nano $root/etc/mkinitcpio.conf

На базе стандартного пресета linux создаем свой пресет habr:

cp $root/etc/mkinitcpio.d/linux.preset $root/etc/mkinitcpio.d/habr.preset

И приводим его к такому виду:

cat $root/etc/mkinitcpio.d/habr.preset

ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/boot/vmlinuz-linux"

PRESETS=('default' )

default_image="/boot/initramfs-linux.img"

Нам не нужна ветка 'fallback', которая удаляет из обработчиков autodetect, ведь мы его уже сами убрали, и нам не нужно дважды генерировать одинаковый файл initramfs с разными названиями.

Генерируем новый initramfs с помощью пресета habr:

arch-chroot $root mkinitcpio -p habr

Пишем службу обновления DNS для использования с systemd

Наша сетевая карта получает все настройки для того, чтобы работала сеть и Интернет. Но названия сайтов переводиться в IP адреса не будут, т. к. наша система не знает, какие серверы DNS следует для этого использовать. Напишем собственную службу для этих целей, которую при загрузке будет запускать systemd. А чтобы узнать что-то новое и не заскучать от однообразия, передадим информацию о названии сетевого устройства в качестве параметра, а список DNS серверов сохраним во внешнем файле.

Обновлением информации о DNS серверах занимается resolvconf. Нам идеально подходит синтакскис:

resolvconf [-m metric] [-p] -a interface <file

В импортируемом здесь файле IP адрес каждого сервера указывается в новой строке после ключевого слова nameserver. Можно указать сколько угодно серверов, но использоваться будут только первые 3 из них. В качестве примера воспользуемся серверами Яндекс. В этом случае файл, передаваемый в resolvconf, должен выглядеть вот так:

nameserver 77.88.8.8
nameserver 77.88.8.1

Нам нужно получать информацию о DNS серверах до того, как система будет уверена, что сеть полностью работает, т. е. до достижения цели network.target. Будем считать, что информацию о серверах нам достаточно обновлять один раз во время загрузки. И стандартно скажем, что нашу службу требует цель multi-user.target. Создаём файл запуска службы в каталоге со следующим содержанием:

cat $root/etc/systemd/system/update_dns@.service

[Unit]
Description=Manual resolvconf update (%i)
Before=network.target

[Service]
Type=oneshot
EnvironmentFile=/etc/default/dns@%i
ExecStart=/usr/bin/sh -c 'echo -e "nameserver ${DNS0}nnameserver ${DNS1}" | resolvconf -a %i'

[Install]
WantedBy=multi-user.target

В строке ExecStart мы выполняем команду echo, на лету генерирующую файл со списком серверов, который через конвейер передаем resolvconf. Вообще, в строке ExecStart нельзя использовать несколько команд и тем более нельзя использовать конвейеры, но мы снова всех обманули, передав эти команды в качестве параметра -c для /usr/bin/sh.

Обратите внимание, что в названии файла update_dns@.service используется символ @, после которого можно указать переменную, и она попадёт внутрь файла, заменив собой "%i". Таким образом строка EnvironmentFile=/etc/default/dns@%i превратится в EnvironmentFile=/etc/default/dns@eth0 — именно это название внешнего файла, мы будем использовать для хранения значения переменных DNS0 и DNS1. Синтаксис как в обычных скриптах: «название переменной=значение переменной». Создадим файл:

nano $root/etc/default/dns@eth0

И добавим следующие строки:

DNS0=77.88.8.8
DNS1=77.88.8.1

Теперь добавляем службу в автозагрузку не забывая указать имя сетевой карты после @:

arch-chroot $root systemctl enable update_dns@eth0.service

Только что мы написали универсальный файл, обеспечивающий запуск службы. Универсальность заключается в том что, если в нашей системе окажется несколько сетевых адаптеров, то для каждого из них мы сможем указать свои собственные DNS серверы. Нужно будет просто подготовить набор файлов со списком серверов для каждого из устройств и запускать службу для каждого адаптера в отдельности указывая его имя после @.

Перед первым запуском

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

Отключаем готовую корневую систему:

umount $root

И выключаем виртуальную машину:

poweroff

Теперь можно отключить загрузочный образ из CD-ROM или достать флешку, после этого включаем машину и убеждаемся, что всё работает.

P.S. Я хотел сразу написать всё до конца, но на вторые сутки решил остановиться, чтобы передохнуть и понять, а нужно ли вам это? Возможно, что вы не захотите читать подробности «что и как», а нужна простая инструкция «скопировать и вставить»? Если вы заинтересованы в продолжении, то, пожалуйста, оставляйте свои комментарии. Буду рад любым замечаниям и советам.

Всё, о чём я планирую рассказать дальше, проверено в работе на реальном железе: начиная с бородатого Pentium 4 на материнских платах BIOS и заканчивая позапрошлогодним Celeron J1800 на материнских платах UEFI.

Автор: Roshalsky

Источник