Установка Arch Linux на виртуальную машину VirtualBox

Для определенности – устанавливать будем образ от 1 декабря 2024 года в VirtualBox 7.0.22 (хотя, оказывается, уже есть 7.1, но пока не буду обновляться), хост внезапно Windows 10 (но это наверное совсем ни на что не влияет), локалка за роутером.

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

https://mirror.yandex.ru/archlinux/iso/latest/archlinux-x86_64.iso

Виртуальная машина

Создадим ее. Я предпочитаю "экспертный" режим. Если вести название Arch Linux, то автоматически подставится нужный тип и версия операционной системы. Мы не будем пользоваться услугами автоматической установки, поэтому образ ISO пока не "подкидываем".

Оборудование оставим по умолчанию (гиг ОЗУ и 1 ядро) за исключением флага EFI – я хочу продемонстрировать именно этот способ, он же и проще наверное.

Размер диска тоже можно оставить по умолчанию (8 гигабайт).

Пока не запускаем – хочу немного "полирнуть" настройки.

Система – Материнская плата. Я по традиции меняю чипсет на ICH9. По умолчанию установился как бы правильный манипулятор курсора – "USB планшет", но поскольку графика нам не потребуется, предлагаю сбросить до "PS/2 мышь". Также хочу обратить внимание на взведенный флаг аппаратных часов по UTC и отключенный Secure Boot (это правильные настройки).

Аудио – отключаем.

Сеть – Адаптер 1. Предлагаю воспользоваться сетевым мостом, как наиболее простым вариантом в настройке.

USB – опять же предлагаю отключить совсем.

На этом создание виртуальной машины окончено.

Установка

Загрузка

Запускаем виртуальную машину, подключаем образ, ожидаем окончания загрузки. Даже под root система входит автоматически. Предлагаю пропустить первые несколько пунктов из официальной инструкции и сразу же вывести сведения о сети – ip addr. Видим, что роутер назначил виртуальной машине IP 192.168.1.105.

Все консольные команды будут выполняться под root, поэтому со всякими решетками и долларами не заморачиваюсь. А теперь делаем финт ушами…

Доступ по SSH

Заходим по этому IP через SSH. В Windows это, традиционно, PuTTY. Точнее пока не заходим, а разрешаем вход root по паролю:

nano /etc/ssh/sshd_config

PermitRootLogin Yes

Устанавливаем этот самый пароль:

passwd

Перезапускаем сервис:

systemctl restart sshd

И вот теперь входим.

Для чего это нужно? Скорее всего вы не сможете пользоваться буфером обмена, а он нам потребуется ближе к окончанию установки для указания UUID корневой файловой системы в загрузчике. Если, конечно, вы не хотите вводить длиннющую команду, включающую этот самый UUID, "врукопашную". В консоли SSH же все прекрасно копируется и вставляется.

Разметка диска

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

Смотрим, какие есть – fdisk -l – чтобы определить нужный. В моем случае это /dev/sda (на 8 гигов).

root@archiso ~ # fdisk -l
Disk /dev/sda: 8 GiB, 8589934592 bytes, 16777216 sectors
Disk model: VBOX HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop0: 813.39 MiB, 852901888 bytes, 1665824 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Размечаем: тип GPT, разделы: EFI System (предлагается гигабайт), swap (тоже сделаю гиг в соответствии с объемом выделенной памяти), ну и все остальное под корневую систему. Конечно слегка расточительно для первых двух, как по мне, но рисковать и делать впритык по 512 не буду.

fdisk /dev/sda

Вообще можно было воспользоваться и gpart, и cfdisk в некоторых инструкциях фигурирует, но раз уж начали с fdisk, то в нем и продолжим.

По порядку команды:

• g – создать таблицу GPT
• n – новый раздел:
  • номер 1 (по умолчанию)
  • начальный сектор 2048 (по умолчанию)
  • конечный сектор +1G (именно с плюсом)
• t – изменить тип раздела
  • uefi – EFI system
• n – новый раздел:
  • номер 2 (по умолчанию)
  • начальный сектор 2099200 (по умолчанию)
  • конечный сектор аналогично +1G
• t – изменить тип раздела
  • номер раздела 2 (по умолчанию)
  • swap – раздел подкачки
• n – новый раздел со всеми значениями по умолчанию
• t – изменить тип раздела
  • номер раздела 3 (по умолчанию)
  • L – для контроля вывести список типов (q – выход из просмотра)
  • 23 (или актуальный, если вдруг поменялся) – раздел Linux root (x86-64)
• p – вывести таблицу разделов
• если все в порядке, то w – записать таблицу разделов и выйти.

Для контроля – вот что получилось у меня:

Command (m for help): p
Disk /dev/sda: 8 GiB, 8589934592 bytes, 16777216 sectors
Disk model: VBOX HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: DDB67C4E-6956-456C-BF5D-25D22F612385

Device       Start      End  Sectors Size Type
/dev/sda1     2048  2099199  2097152   1G EFI System
/dev/sda2  2099200  4196351  2097152   1G Linux swap
/dev/sda3  4196352 16775167 12578816   6G Linux root (x86-64)

Форматирование и монтирование

Создадим файловые системы на вновь созданных разделах. EFI – FAT32, подкачку как бы даже не форматируем, а инициализируем – mkswap, а вот корневую я предлагаю отформатировать в btrfs.

mkfs.fat -F 32 /dev/sda1
mkswap /dev/sda2
mkfs.btrfs /dev/sda3

Это позволит реализовать кое-какие фишки – главным образом сжатие. Или, если вдруг места станет не хватать, то элементарно добавляете диск в ВМ, а затем к ФС. Опять же, Docker может неким образом оптимизировать расходы, используя подтома/снимки. В идеале бы не монтировать "всю" btrfs в качестве корневой ФС, а создать для этого подтом (или даже в стиле OpenSUSE насоздавать подтома для основных точек монтирования), но стоит ли настолько заморачиваться в ВМ?..

Пример вывода:

root@archiso ~ # mkfs.fat -F 32 /dev/sda1
mkfs.fat 4.2 (2021-01-31)
root@archiso ~ # mkswap /dev/sda2
Setting up swapspace version 1, size = 1024 MiB (1073737728 bytes)
no label, UUID=c05af060-09a0-4a5a-8156-e0fc358b89d2
root@archiso ~ # mkfs.btrfs /dev/sda3
btrfs-progs v6.11
See https://btrfs.readthedocs.io for more information.

Performing full device TRIM /dev/sda3 (6.00GiB) ...
NOTE: several default settings have changed in version 5.15, please make sure
      this does not affect your deployments:
      – DUP for metadata (-m dup)
      – enabled no-holes (-O no-holes)
      – enabled free-space-tree (-R free-space-tree)

Label:              (null)
UUID:               53825132-fc65-4f88-bf79-6bf885712aae
Node size:          16384
Sector size:        4096        (CPU page size: 4096)
Filesystem size:    6.00GiB
Block group profiles:
  Data:             single            8.00MiB
  Metadata:         DUP             256.00MiB
  System:           DUP               8.00MiB
SSD detected:       no
Zoned device:       no
Features:           extref, skinny-metadata, no-holes, free-space-tree
Checksum:           crc32c
Number of devices:  1
Devices:
   ID        SIZE  PATH
    1     6.00GiB  /dev/sda3

Как-то сохраните UUID файловой системы BTRFS, он потребуется при настройке загрузчика. Но в принципе он потом еще будет в fstab, который можно будет вывести на экран. В моем случае, как вы можете видеть, это 53825132-fc65-4f88-bf79-6bf885712aae.

Монтируем файловые системы, при этом сразу включим сжатие:

mount -o compress=zstd /dev/sda3 /mnt
mount --mkdir /dev/sda1 /mnt/boot
swapon /dev/sda2

Хотелось бы прямо сейчас сгенерировать fstab, но пожалуй все же лучше сделать это по инструкции – после предустановки ПО, поскольку будет создана заготовка этого файла.

Предустановка ПО

Это делается с использованием утилиты pacstrap (видимо означает pacman bootstrap):

pacstrap -K /mnt base linux btrfs-progs nano efibootmgr openssh

Можно сказать, минимальный набор. Написано, что linux-firmware необязательно устанавливать в виртуальной машине – поверим на слово. Раз отформатировали корневую ФС в btrfs, я сразу же добавил установку btrfs-progs. Еще, как оказалось, надо сразу же устанавливать текстовый редактор (nano вроде как стандартный) и менеджер загрузки (efibootmgr в нашем случае). Напоследок добавил openssh – в идеале мы хотим сразу же доступаться к виртуалке этим способом.

Total Download Size: 281.26 MiB
Total Installed Size: 733.80 MiB

Ждем-с...

Настройка

Прежде всего генерируем fstab с использованием UUID:

genfstab -U /mnt >> /mnt/etc/fstab

Вот что получилось в моем случае:

root@archiso ~ # cat /mnt/etc/fstab
# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>
# /dev/sda3
UUID=53825132-fc65-4f88-bf79-6bf885712aae       /               btrfs          rw,relatime,compress=zstd:3,space_cache=v2,subvol=/      0 0

# /dev/sda1
UUID=AE74-4868          /boot           vfat            rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro  0 2

# /dev/sda2
UUID=c05af060-09a0-4a5a-8156-e0fc358b89d2       none            swap           defaults         0 0

Что-то с опциями монтирования по-моему перебор. Скорее всего можно было бы ограничиться compress=zstd для btrfs и, очень теоретически, defaults для EFI (поскольку явных опций команде mount в этом случае мы не передавали), ну да ладно. Оставлю как есть.

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

arch-chroot /mnt

Хорошо хоть для этого "макрос" сделали. "Классический" chroot выполнять довольно муторно.

Далее предлагается настроить часовой пояс, оставим UTC?

ln -sf /usr/share/zoneinfo/UTC /etc/localtime
hwclock --systohc

Для локализации редактируем /etc/locale.gen (вот уже потребовался текстовый редактор):

nano /etc/locale.gen

Необходимо раскомментировать en_US.UTF-8 UTF-8 и, в нашем случае, ru_RU.UTF-8 UTF-8. Генерируем:

locale-gen

Создаем файл /etc/locale.conf с языком (локалью). Пусть наверное будет английский:

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

Аналогично, по желанию (archlinux по умолчанию), пропишем какое-нибудь (arch-vm) имя хоста:

echo 'arch-vm' > /etc/hostname

Установим пароль root (не путать с установкой пароля для доступа по SSH для установки):

passwd

Так, ну и осталось разобраться с загрузчиком. На этом руководство по установке обрывается, типа разбирайтесь сами, какой вам нужен. Наверное нам нужен EFI boot stub, для чего, собственно, и ставили efibootmgr. Настало время им воспользоваться – команда довольно длинная (при том что опции загрузки весьма номинальные), в ней-то и понадобится UUID btrfs.

efibootmgr --create --disk /dev/sda --part 1 --label "Arch Linux" --loader /vmlinuz-linux --unicode 'root=UUID=53825132-fc65-4f88-bf79-6bf885712aae rw initrd=\initramfs-linux.img'

Для контроля – сверьте диск (/dev/sda), загрузчик (vmlinuz-linux), UUID опять же, ну и initrd. В UEFI приняты обратные слэши для путей (подозреваю, под влиянием MS, FAT и т.д.)

Можно, например, ls /boot для проверки имен файлов:

[root@archiso /]# ls /boot
initramfs-linux-fallback.img  initramfs-linux.img  vmlinuz-linux

Поставим сервисы в "автозагрузку":

systemctl enable systemd-networkd
systemctl enable systemd-resolved
systemctl enable sshd

Добавим настройки сети:

nano /etc/systemd/network/10-wired.network

[Match]
Name=enp0s3

[Link]
RequiredForOnline=routable

[Network]
DHCP=yes

Имя адаптера можно было видеть в самом начале, когда определяли IP. Если что, скорректируйте по факту (или можно вместо конкретного имени использовать маску типа en*). Поскольку используется DHCP, в пару к systemd-networkd добавил systemd-resolved выше.

Как и до этого, включим парольный доступ по SSH (PermitRootLogin Yes в /etc/ssh/sshd_config).

На этом вроде бы все? Выходим exit, перезагружаемся reboot. Осталось убедиться, что пойдет загрузка с жесткого диска, а не оптического – что у меня и произошло. И даже по SSH сразу же зашел (если не считать предупреждения об изменившемся ключе). Чудеса!

После установки

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

df -H | grep sda

Считается, что данные по btrfs такой командой искажаются, но все же:

/dev/sda3       6.5G  863M  5.1G  15% /
/dev/sda1       1.1G   70M  1.1G   7% /boot

И зачем делали гиг для EFI?.. Хотя, предположу, в случае обновлений ядра там место будет тратиться.

Более детально по btrfs:

btrfs fi usage /

Фрагменты вывода:

Used:                        817.04MiB
Free (estimated):              4.75GiB      (min: 2.93GiB)

Data,single: Size:1.84GiB, Used:749.95MiB (39.89%)

Сжатие вроде бы работает. Без его учета, по моим прикидкам, Arch устанавливается где-то на 1,2 гига.

Чтобы далеко не ходить – команда обновления:

pacman -Syu

Вряд-ли он сразу же после установки что-то найдет… А сейчас можно установить дополнительное ПО. Собственно, Докер:

pacman -S docker docker-compose docker-buildx

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

btrfs subvolume create /var/lib/docker

Каталога /etc/docker скорее всего еще нет, поэтому вручную его создадим (mkdir /etc/docker) и добавим файл /etc/docker/daemon.json для использования драйвера хранилища btrfs:

{
  "storage-driver": "btrfs"
}

Стартуем:

systemctl enable --now docker

И, по традиции, проверяем установку – docker info и/или docker run hello-world. По идее все должно работать.

Заключение

Какой-нибудь скриптик типа setup-alpine, наверное, не повредил бы… С другой стороны, практически все настройки "вручную" править не сильно дольше, чем через гипотетический мастер. Пожалуй, наибольшую трудность представляет разбиение диска (хотя опять же, последовательность команд fdisk’а только выглядит длинной, а "прокликать" ее реально секунд за 10-20 мне кажется) и установка загрузчика, и вот тут какие-нибудь шаблоны бы не помешали. Зато можно выбирать из нескольких сетевых менеджеров и загрузчиков.

Хотя… Хотя эти рассуждения все же больше характерны для виртуалки. На реальной машине, да еще и с какой-нибудь мультизагрузкой и Wi-Fi будет веселее, да и вероятность выстрелить себе в ногу кратно повышается.

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

В целом, получаем "всегда свежую" и относительно компактную операционку с systemd (в результате общие подходы скорее всего не особо отличаются от Debian/RHEL) и стандартными библиотеками.