Встановлення Void Linux: мінімалістична дистрибуція, яка дивно відчувається сучасною

Чому Void відчувається сучасною, незважаючи на мінімалізм

Void Linux мінімальна так, як має сенс з операційної точки зору. Ви не отримуєте клубок «фреймворк-сервісів», яких не просили.
Ви отримуєте чисту файлову систему, розумний пакетний менеджер і init-систему, яка віддає перевагу зрозумілості над амбіціями.
Останнє важливо: профіль надійності системи часто визначається завантаженням і наглядом за службами.

Void використовує runit для init та супервізії. Це не модно. Проте це вражаюче прямо:
сервіси — це каталоги з run-скриптами; увімкнення — це символічне посилання; логи можна керувати супутньою службою.
Коли щось ламається, ви зазвичай можете бачити точно, що воно намагалося виконати і чому не вийшло.

Пакетний менеджер — xbps. Він швидкий, послідовний і приємно без театру.
Немає «операної залежностей» перед кожною транзакцією. Він встановлює пакети, перевіряє цілісність і рухається далі.
Для мінімалістичної дистрибуції це правильна сучасність: фокус на механіці, що зменшує операційні тертя.

Одна цитата, яку варто надрукувати на внутрішній стороні кожної кришки ноутбука:
Перефразована ідея (Werner Vogels): все рано чи пізно ламається; проєктуйте системи так, щоб відмови були очікуваними і відновлюваними.

Сильна сторона Void у тому, що вона не прикидається, ніби відмови не стануться. Вона дає менше рухомих частин і кращу видимість.
Це не усуває помилок. Воно просто робить їх легшими для діагностики — і в цьому справжня вигода.

Цікаві факти та контекст (те, що люди забувають)

• Void незалежний: це не похідна від Debian/Ubuntu/Fedora. Така незалежність проявляється у інструментах і налаштуваннях за замовчуванням.
• Походження runit: runit походить з початку 2000-х і використовувався в промислових умовах, наприклад вбудованих системах та апаратах.
• xbps не є обгорткою: це нативна пакетна система (бінарні пакети + репозиторії), а не фронтенд для чогось іншого.
• збірки glibc і musl: Void підтримує обидва, дозволяючи вибирати сумісність (glibc) або меншу libc (musl).
• Роллінг-реліз, але кураторський: це роллінг-реліз, але пакети зазвичай досить узгоджені — менше «щоденного рулету збірок».
• Філософія інсталятора: live ISO навмисно строгий; ви не отримаєте майстра, що ховає розмітку диска за веселими анімаціями.
• Схема етапів runit: завантаження розбите на етапи, і «дерево супервізії служб» явне, а не виникає само собою.
• xbps-alternatives: Void використовує систему альтернатив для керування реалізаціями за замовчуванням (наприклад, який редактор є «vi»).
• XBPS зберігає метадані локально: ви можете перевіряти, що встановлено і чому, простими запитами, без викликів додому.

Жарт 1/2: Void названо «Void», бо воно починається порожнім; позитив — воно також починається без драми.

Рішення, які треба прийняти перед запуском інсталятора

glibc проти musl

Оберіть glibc, якщо у вас немає конкретної причини інакше. Більшість сторонніх бінарників розраховані на нього.
musl відмінний для певних навантажень (майже статичні, контейнери, менші системи), але може додати суміснісні витрати,
яких ви не хочете на щоденному робочому столі або робочій станції.

UEFI проти legacy BIOS

Якщо ваша машина з останнього десятиліття, то майже напевно вона на UEFI. Використовуйте його правильно:
GPT-розмітка, EFI System Partition (ESP) і завантажувач, що відповідає вашій моделі загроз та терпимості до налаштувань.

Вибір файлової системи (нудний розгалужувач, що важливий пізніше)

Якщо ви хочете одну файлову систему, яка поводиться передбачувано, обирайте ext4.
Якщо у вас великі файли і важлива паралельна I/O, XFS підходить (але ставтеся з повагою до зміни розмірів).
Якщо ви хочете знімки і готові навчитися дисципліні експлуатації, btrfs може бути чудовим.
Якщо ви — спеціаліст зі сховищ і хочете перевірки цілісності + send/receive у масштабі, ZFS — реальний вибір — просто не прикидайтеся, що це «встановив і забув».

Шифрування

Для ноутбуків і всього, що ви виносите з шафи, використовуйте повне шифрування диска. LUKS2 — стандартний варіант.
Два реальних питання: чи хочете окремий незашифрований /boot, і чи потрібне віддалене розблокування?
Якщо не знаєте — тримайте просто: незашифрований ESP, зашифрований root і погодьтеся вводити пароль під час завантаження.

Swap і гібернація

Якщо ви використовуєте гібернацію, swap має бути відповідного розміру і налаштований правильно.
Якщо ні — swap все одно корисний як клапан тиску. Малий swapfile або розділ — підходить.
Не слідуйте сліпо гаслу «ніколи не використовувати swap», якщо вам цікаво спостерігати, як OOM-killer вбиває компілятори.

Інсталяція: практичний покроковий посібник (UEFI + ext4 + варіант із шифруванням)

Інсталятор Void простий. Найпоширеніша причина відмови — не «інсталятор зламався».
Це «ви зробили припущення про розмітку диска, яке не перевірили».
Тому ми будемо перевіряти все по ходу і віддаватимемо перевагу командам, що показують свою роботу.

Крок 0: завантажте live ISO і підтвердіть режим прошивки

Якщо ви думаєте, що в UEFI-режимі, але насправді ні — ваш ESP буде як підписана шухляда в будинку без дверей.

cr0x@server:~$ ls /sys/firmware/efi
config_table  efivars  fw_platform_size  runtime  runtime-map  systab

Що означає вивід: Якщо /sys/firmware/efi існує і містить записи, ви завантажилися в UEFI-режимі.
Рішення: Продовжуйте з GPT + ESP. Якщо його немає — перезавантажтеся і виберіть UEFI-запис у прошивці.

Крок 1: ідентифікуйте цільовий диск (не вгадуйте)

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MODEL
NAME   SIZE TYPE FSTYPE MODEL
sda   476.9G disk        Samsung SSD 860
├─sda1  512M part vfat
└─sda2 476.4G part

Що означає вивід: Ви бачите диски та розділи з розмірами і (якщо є) типами файлової системи.
Рішення: Підтвердіть, що встановлюєте на правильний пристрій (/dev/sda тут). Якщо на сервері декілька дисків — зупиніться і позначте їх.

Крок 2: розмітка (приклад схеми)

Мінімальна UEFI-схема:
ESP (512 MiB) + кореневий розділ (решта). Якщо шифруєте — root стане контейнером LUKS.

cr0x@server:~$ sudo parted -s /dev/sda mklabel gpt
cr0x@server:~$ sudo parted -s /dev/sda mkpart ESP fat32 1MiB 513MiB
cr0x@server:~$ sudo parted -s /dev/sda set 1 esp on
cr0x@server:~$ sudo parted -s /dev/sda mkpart primary 513MiB 100%
cr0x@server:~$ sudo parted -s /dev/sda print
Model: Samsung SSD 860 (scsi)
Disk /dev/sda: 512GB
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  538MB   537MB                ESP   boot, esp
 2      538MB   512GB   511GB                primary

Що означає вивід: GPT існує, розділ 1 позначений як ESP, розділ 2 — основний.
Рішення: Якщо прапори не показують boot, esp на розділі 1 — виправте зараз. Проблеми з UEFI-завантаженням зазвичай самостворені.

Крок 3: форматування файлових систем (без шифрування)

cr0x@server:~$ sudo mkfs.vfat -F32 -n EFI /dev/sda1
mkfs.fat 4.2 (2021-01-31)
cr0x@server:~$ sudo mkfs.ext4 -L void-root /dev/sda2
mke2fs 1.46.5 (30-Dec-2021)
Creating filesystem with 124999680 4k blocks and 31250432 inodes
Filesystem UUID: 9f6b7f39-3c4a-4cb2-8f54-5c3c2f9911a2
Superblock backups stored on blocks:
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000

Що означає вивід: ESP — FAT32, корінь — ext4 з міткою та UUID.
Рішення: Якщо плануєте шифрування — не форматувати /dev/sda2 як ext4 зараз — використайте шлях шифрування нижче.

Крок 3b: шлях шифрування (LUKS2 + ext4 всередині)

cr0x@server:~$ sudo cryptsetup luksFormat /dev/sda2
WARNING: Device /dev/sda2 already contains a 'ext4' superblock signature.
Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for /dev/sda2:
Verify passphrase:
cr0x@server:~$ sudo cryptsetup open /dev/sda2 cryptroot
Enter passphrase for /dev/sda2:
cr0x@server:~$ sudo mkfs.ext4 -L void-root /dev/mapper/cryptroot
mke2fs 1.46.5 (30-Dec-2021)
Creating filesystem with 124900352 4k blocks and 31227904 inodes
Filesystem UUID: 5c1a1d6b-6a4f-4b2e-88fb-f0b4af56c0a3

Що означає вивід: Розділ тепер зашифрований контейнер, відкритий як /dev/mapper/cryptroot, і ext4 живе всередині нього.
Рішення: Запишіть LUKS UUID пізніше для crypttab/dracut. Також вирішіть, чи потрібен ключ-файл (зазвичай ні для ноутбуків).

Крок 4: монтування цільової структури

cr0x@server:~$ sudo mount /dev/mapper/cryptroot /mnt
cr0x@server:~$ sudo mkdir -p /mnt/boot/efi
cr0x@server:~$ sudo mount /dev/sda1 /mnt/boot/efi
cr0x@server:~$ mount | grep -E '(/mnt|efi)'
/dev/mapper/cryptroot on /mnt type ext4 (rw,relatime)
/dev/sda1 on /mnt/boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)

Що означає вивід: Root і ESP змонтовані там, де інсталятор розмістить систему і завантажувальні артефакти.
Рішення: Якщо ESP змонтовано в іншому місці — виправте. Потрібен один очевидний точка монтування ESP.

Крок 5: запустіть інсталятор і контролюйте його

Void надає TUI-інсталятор. Використайте його. Але перевіряйте, що він зробив: ви — інженер на виклику, а не інсталятор.

Після інсталяції зайдіть у chroot або завантажтеся в нову систему і перевірте основи: fstab, завантажувач, initramfs, мережу, час, користувачів.
Решта — це вподобання.

Крок 6: установка мислення для першого завантаження

Ваш перший завантаження — це не «чи досягає воно запиту на вхід». Ваш перший завантаження — «чи я розумію, як воно поводитиметься в найгірший день тижня».
Це означає: як стартують сервіси, куди йдуть логи, як застосовуються оновлення і як відновити систему, якщо мережа не працює.

Практичні завдання: команди, виводи та подальші рішення

Це перевірки, які я виконую на будь-якій свіжій інсталяції. Вони не церемоніальні.
Кожна з них присутня тому, що я бачив, як їх відсутність перетворювалася на тікет.

Завдання 1: підтвердіть, що ви завантажені з ядра, яке думаєте, що встановили

cr0x@server:~$ uname -a
Linux voidbox 6.6.15_1 #1 SMP PREEMPT_DYNAMIC Thu Jan 18 10:22:01 UTC 2024 x86_64 GNU/Linux

Що означає вивід: Версія ядра і архітектура.
Рішення: Якщо ядро старіше очікуваного — ви, ймовірно, завантажилися не з того запису або не встановили потрібний мета-пакунок ядра.

Завдання 2: перевірте UUID і мітки дисків перед записом fstab

cr0x@server:~$ blkid
/dev/sda1: LABEL_FATBOOT="EFI" LABEL="EFI" UUID="7C2A-1B3D" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="ESP" PARTUUID="e2b7c5a1-6d8d-4e5c-a2b3-7f3a0d4b9b0c"
/dev/sda2: UUID="f1b2c3d4-1111-2222-3333-abcdefabcdef" TYPE="crypto_LUKS" PARTUUID="7a9c8d6e-aaaa-bbbb-cccc-1234567890ab"
/dev/mapper/cryptroot: LABEL="void-root" UUID="5c1a1d6b-6a4f-4b2e-88fb-f0b4af56c0a3" BLOCK_SIZE="4096" TYPE="ext4"

Що означає вивід: Стабільні ідентифікатори для монтувань і зашифрованих карт.
Рішення: Використовуйте UUID у /etc/fstab і (якщо зашифровано) у командному рядку dracut/налаштуваннях шифрування; уникайте сирих /dev/sdaX.

Завдання 3: перевірте опції монтування і доступний простір

cr0x@server:~$ df -hT
Filesystem              Type   Size  Used Avail Use% Mounted on
/dev/mapper/cryptroot   ext4   468G  2.6G  441G   1% /
/dev/sda1               vfat   511M   12M  500M   3% /boot/efi
tmpfs                   tmpfs  3.1G     0  3.1G   0% /run

Що означає вивід: Типи ФС, розміри і точки монтування.
Рішення: Переконайтеся, що /boot/efi не знаходиться на кореневій ФС. Якщо так — UEFI-завантажувальні артефакти можуть бути непостійними.

Завдання 4: перевірте, що init — дійсно runit

cr0x@server:~$ ps -p 1 -o pid,comm,args
  PID COMMAND         COMMAND
    1 runit           runit

Що означає вивід: PID 1 — runit.
Рішення: Якщо PID 1 не runit — ви не на Void, як очікували, або ви в контейнері/chroot.

Завдання 5: перелік увімкнених сервісів (що стартуватиме при завантаженні)

cr0x@server:~$ ls -l /var/service
total 0
lrwxrwxrwx 1 root root  16 Jan 20 09:10 dhcpcd -> /etc/sv/dhcpcd
lrwxrwxrwx 1 root root  14 Jan 20 09:10 sshd -> /etc/sv/sshd
lrwxrwxrwx 1 root root  15 Jan 20 09:10 socklog-unix -> /etc/sv/socklog-unix
lrwxrwxrwx 1 root root  13 Jan 20 09:10 nanoklogd -> /etc/sv/nanoklogd

Що означає вивід: Кожне символічне посилання — увімкнена служба під наглядом runit.
Рішення: Якщо чогось критичного немає (мережа, логування, ssh для віддалених систем) — увімкніть це зараз, а не виявляйте під час інциденту.

Завдання 6: перевірте стан служби відповідально (не за відчуттями)

cr0x@server:~$ sudo sv status sshd
run: sshd: (pid 842) 37s

Що означає вивід: Служба працює, з PID і часом роботи.
Рішення: Якщо вона down або fail, перегляньте run-скрипт і логи перед тим, як міняти випадкові налаштування.

Завдання 7: перевірте, що логи існують і збираються

cr0x@server:~$ sudo sv status socklog-unix
run: socklog-unix: (pid 520) 5m12s
cr0x@server:~$ sudo ls -lah /var/log/socklog
total 16K
drwx------  4 root root 4.0K Jan 20 09:11 .
drwxr-xr-x 11 root root 4.0K Jan 20 09:11 ..
drwx------  2 root root 4.0K Jan 20 09:11 kernel
drwx------  2 root root 4.0K Jan 20 09:11 sshd

Що означає вивід: socklog працює і пише логи по сервісах.
Рішення: Якщо логи відсутні — виправте логування перед «тюнінгом продуктивності». Ви не можете оптимізувати те, чого не спостерігаєте.

Завдання 8: перевірте конфігурацію репозиторіїв і виконайте безпечну синхронізацію

cr0x@server:~$ xbps-query -L
 997 https://repo-default.voidlinux.org/current (RSA signed)
cr0x@server:~$ sudo xbps-install -S
[*] Updating repository `https://repo-default.voidlinux.org/current/x86_64-repodata' ...
x86_64-repodata: 1824KB [avg rate: 410KB/s]

Що означає вивід: Репозиторії налаштовані і метадані оновлюються чисто.
Рішення: Якщо перевірка підписів не вдається — зупиніться. Виправте синхронізацію часу, URL репозиторіїв або ключі перед встановленням будь-чого.

Завдання 9: проаудитуйте, що утримує вашу базову систему

cr0x@server:~$ xbps-query -m | head
base-system-0.114_1
linux6.6-6.6.15_1
linux-firmware-20240115_1
runit-2.1.2_12
xbps-0.59.2_2

Що означає вивід: Мета-пакунки забезпечують базовий набір «це виглядає як система».
Рішення: Тримайте base-system, якщо у вас немає добре задокументованої причини відходити від нього.

Завдання 10: перевірте розв’язання DNS (бо «мережа вгору» ≠ «корисна»)

cr0x@server:~$ getent hosts repo-default.voidlinux.org
2a04:4e42:600::644  repo-default.voidlinux.org
2a04:4e42::644       repo-default.voidlinux.org

Що означає вивід: Іменування через NSS працює, повертаючи IP-адреси.
Рішення: Якщо це не вдається, але ви можете пінгувати IP — проблема в DNS-конфігурації, зазвичай власність /etc/resolv.conf або поведінка DHCP-клієнта.

Завдання 11: підтвердіть синхронізацію часу (TLS і підписи пакетів цього потребують)

cr0x@server:~$ date -u
Sat Jan 20 09:18:44 UTC 2024

Що означає вивід: Поточний час UTC.
Рішення: Якщо він неправильний на хвилини/години — виправте NTP (наприклад, chrony) перш ніж звинувачувати «зламаний SSL» для завантажень пакетів.

Завдання 12: перевірте, чи існують записи завантаження (UEFI-практика)

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001
Boot0001* UEFI: Built-in EFI Shell	RC
Boot0003* VoidLinux	HD(1,GPT,e2b7c5a1-6d8d-4e5c-a2b3-7f3a0d4b9b0c,0x800,0x100000)/File(\EFI\void\grubx64.efi)

Що означає вивід: Прошивка бачить запис VoidLinux, що вказує на EFI-бінарник на ESP.
Рішення: Якщо запису немає — ви будете завантажуватися випадково. Виправте встановлення завантажувача перед перезавантаженням у стан плутанини.

Завдання 13: перевірте генерацію initramfs (особливо для шифрування)

cr0x@server:~$ ls -lh /boot | head
total 88M
-rw-r--r-- 1 root root  32M Jan 20 09:05 initramfs-6.6.15_1.img
-rw-r--r-- 1 root root  12M Jan 20 09:05 vmlinuz-6.6.15_1
drwxr-xr-x 3 root root 4.0K Jan 20 09:05 grub

Що означає вивід: Ядро і initramfs існують і мають правдоподібні розміри.
Рішення: Якщо initramfs відсутній — завантаження може не вдатися після оновлень ядра. Переконайтеся, що dracut-хуки встановлені й налаштовані.

Завдання 14: підтвердіть стан TRIM на SSD (гігієна сховища)

cr0x@server:~$ lsblk -D
NAME          DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                  0      512B       2G         0
├─sda1               0      512B       2G         0
└─sda2               0      512B       2G         0

Що означає вивід: Відображається гранулярність та максимальний розмір discard.
Рішення: Увімкніть періодичний fstrim (або монтуйте з discard, якщо приймаєте компроміси). Якщо значення нуль — пристрій може не підтримувати TRIM.

Завдання 15: перевірте базові показники пам’яті (не відправляйте коробку, що вмирає на збірці)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       1.1Gi       5.6Gi       120Mi       1.0Gi       6.3Gi
Swap:          2.0Gi          0B       2.0Gi

Що означає вивід: У вас є swap і розумна доступна пам’ять.
Рішення: Якщо swap відсутній на ноутбуці — додайте його. Якщо swap величезний на малому SSD — перегляньте це рішення; знос реальний, але стабільність також важлива.

runit: управління сервісами, яке вас не буде вводити в оману

r u n i t — це не спосіб життя. Це супервізор. Він запускає сервіси, перезапускає їх при падінні
і надає послідовний інтерфейс для перевірки стану та управління.
Ментальна модель: «служба — це каталог з виконуваним run-скриптом».

Увімкнення та вимкнення сервісів

Увімкнення — це символічне посилання в /var/service. Вимкнення видаляє це посилання.
Це настільки очевидно, що здається підозріло надто простим. Але так — воно працює.

cr0x@server:~$ sudo ln -s /etc/sv/sshd /var/service
cr0x@server:~$ sudo sv status sshd
run: sshd: (pid 1123) 4s

Що означає вивід: Як тільки посилання існує, runit негайно супервізує службу.
Рішення: Якщо служба стартує несподівано при увімкненні — це не дивина; це контракт. Плануйте зміни відповідно.

Де зберігається конфігурація

Run-скрипти сервісів знаходяться в /etc/sv/<service>/run. Багато служб також мають /etc/sv/<service>/conf.
Якщо хочете змінити, як стартує служба — робіть це там, а не сподіваючись, що генератор юнітів відчує ваш настрій.

Логування — первинна турбота (якщо ви цього хочете)

Звична схема — окрема директорія log під службою, оброблювана svlogd.
Це дає передбачувані локальні логи без припущень про systemd-journal.
Якщо ви централізуєте логи (і так робити варто для важливих систем) — все одно зберігайте локальні логи.
Вони — чорний ящик, коли мережа в вогні.

Вибір сховища: ext4, XFS, btrfs, ZFS (і що б я обрав)

Сховище — це місце, де мінімалістичні дистрибуції або сяють, або ламаються. Void дає варіанти, не нав’язуючи жодного.
Це добре. Але це також означає, що можна створити крихку «сніжинку».

ext4: за замовчуванням, за який не треба вибачатися

ext4 — нудна в кращому сенсі. Засоби відновлення зрілі, продуктивність послідовна, і більшість режимів відмов знайомі.
Якщо ваша ціль — «робоча станція, що завжди завантажується» або «сервер, що ніколи не дивує» — ext4 — сильна база.

XFS: швидкий, стабільний, але поважайте межі

XFS любить паралельну I/O і великі файлові системи. Він також очікує, що ви ретельно підходите до нарощування і процедур ремонту.
Якщо звикли випадково змінювати розміри розділів у випадковому порядку — спочатку вивчіть правильну послідовність.

btrfs: функції з операційними зобов’язаннями

Знімки, субтоми, send/receive — btrfs може спростити відкат і бекапи.
Але btrfs — не «безкоштовна надійність». Це «інструменти для профі». Потрібен моніторинг, розклад scrub-ів і план щодо впливу знімків на використання диска.

ZFS: чудово, якщо ставитись до нього як до системи зберігання, а не лише як ФС

ZFS чудовий у цілісності даних (контрольні суми) і робочих процесах реплікації (send/receive).
Це також інша екосистема: питання модулів ядра, очікування щодо пам’яті і операційна модель, що винагороджує дисципліну.
Якщо ви встановлюєте Void на ноутбук, ZFS root можливий, але рекомендував би його лише якщо вже знаєте, навіщо потрібен.

Жарт 2/2: Кожного разу, коли ви кажете «я просто використаю ZFS для знімків», майбутній ви планує додаткову нічні чергування.

Мережа: Wi‑Fi, DHCP, DNS і нудні деталі

Мережа не є складною. Вона просто алергічна до припущень.
Void не ховає мережу за монолітним менеджером, якщо ви його не встановите. Ви можете зберегти простоту.

DHCP з dhcpcd

dhcpcd часто використовується в Void. Увімкніть його, перевірте, що він працює, і підтвердіть, що він дійсно налаштував маршрути й DNS.

cr0x@server:~$ sudo sv status dhcpcd
run: dhcpcd: (pid 610) 8m44s
cr0x@server:~$ ip route
default via 192.168.1.1 dev enp3s0 proto dhcp src 192.168.1.50 metric 100
192.168.1.0/24 dev enp3s0 proto kernel scope link src 192.168.1.50 metric 100

Що означає вивід: Існує маршрут за замовчуванням і він вказує на шлюз на очікуваному інтерфейсі.
Рішення: Якщо маршрут за замовчуванням відсутній — це не «проблема DNS». У вас немає шляху до інтернету. Виправте DHCP або статичну конфігурацію спочатку.

Wi‑Fi з wpa_supplicant (практично і явно)

Якщо віддаєте перевагу NetworkManager — встановіть його. Якщо віддаєте перевагу прозорим конфігам — wpa_supplicant підходить.
Головна вимога: збережіть конфігурації з правильними правами і переконайтеся, що служба стартує під час завантаження.

cr0x@server:~$ sudo install -d -m 0700 /etc/wpa_supplicant
cr0x@server:~$ sudo wpa_passphrase "CorpWiFi" "correct horse battery staple" | sudo tee /etc/wpa_supplicant/wpa_supplicant-wlp2s0.conf >/dev/null
cr0x@server:~$ sudo chmod 600 /etc/wpa_supplicant/wpa_supplicant-wlp2s0.conf
cr0x@server:~$ sudo ln -s /etc/sv/wpa_supplicant /var/service
cr0x@server:~$ sudo sv status wpa_supplicant
run: wpa_supplicant: (pid 1337) 2s

Що означає вивід: Конфіг створено, захищено, і служба працює.
Рішення: Якщо вона працює, але не асоціюється — перевірте назви інтерфейсів і регуляторну зону; не поспішайте звинувачувати «драйвери».

DNS: війна за власність resolv.conf

Помилки DNS часто виникають через те, що resolv.conf перезаписується (або ні) різними компонентами.
Вирішіть, хто ним керує: dhcpcd, resolvconf, NetworkManager або ваш статичний файл. І зробіть це правдою.

cr0x@server:~$ ls -l /etc/resolv.conf
-rw-r--r-- 1 root root 46 Jan 20 09:12 /etc/resolv.conf
cr0x@server:~$ cat /etc/resolv.conf
nameserver 192.168.1.1
search lan

Що означає вивід: Простіший файл з локальним резольвером і пошуковим доменом.
Рішення: Якщо він постійно змінюється несподівано — знайдіть, хто його перезаписує, і або налаштуйте це, або вимкніть зайвий компонент.

Оновлення та мислення про відкат з xbps

Void — роллінг-реліз. Це прийнятно в продакшні, якщо ви ставитесь до оновлень як до контрольованої діяльності, а не як до хобі.
Вам потрібні: передбачувані вікна оновлень, журнали змін і план відновлення після невдалого завантаження.

Робочий процес оновлень: синхронізуйте, за потреби симулюйте, потім застосуйте

cr0x@server:~$ sudo xbps-install -S
[*] Updating repository `https://repo-default.voidlinux.org/current/x86_64-repodata' ...
x86_64-repodata: 1824KB [avg rate: 390KB/s]
cr0x@server:~$ sudo xbps-install -u
[*] Updating package `openssl-3.2.0_1' ...
[*] Updating package `curl-8.5.0_1' ...
[*] Updating package `linux6.6-6.6.16_1' ...

Що означає вивід: Репозиторії синхронізовані; пакети оновлені, включно з ядром.
Рішення: Оновлення ядра означає, що ви маєте перевіряти завантажувальні артефакти і перезавантажуватися у свій запланований час, а не коли цього вимагає додаток.

Перевірте, що змінилося і чому

cr0x@server:~$ xbps-query -R linux6.6 | head -n 10
pkgver: linux6.6-6.6.16_1
repository: https://repo-default.voidlinux.org/current
short_desc: Linux kernel and modules (6.6 series)
maintainer: Void Linux team
license: GPL-2.0-only
architecture: x86_64

Що означає вивід: Метадані пакета і джерело репозиторію.
Рішення: Якщо пакет прийшов з неочікуваного репозиторію — можливо, ви змішали репозиторії. Саме так будують систему, що оновлюється як «будинок з привидами».

Тримайте завантажувальний запасний ядро

На будь-якій важливій системі зберігайте принаймні одне відомо-робоче ядро.
Це не параноя; це дешева страховка.
Переконайтеся, що завантажувач його перераховує і що для нього є initramfs.

План швидкої діагностики

Коли Void «гальмує» або «не завантажується» або «мережа дивна», вам не потрібна філософська сесія.
Потрібен порядок операцій, що швидко знаходить вузьке місце і уникає метушні.

Перше: визначте домен відмови

• Домен завантаження/прошивки: не бачите запиту на вхід, падає в emergency shell або петля на завантажувачі.
• Домен сховища: очікування вводу/виводу, ФС в режимі лише для читання, служби таймаутяться, дивні зависання.
• Мережевий домен: пінгується шлюз, але немає резолюції DNS, або резолюція є, але немає доступу до віддалених ресурсів.
• Домен служб: система завантажується, але додаток/служба знижена, флапає або зависла.

Друге: перевірте найпростіші спостережувані речі з великою інформаційною цінністю

Ці перевірки швидкі і не вимагають віри ні в що.

Перевірка ланцюга завантаження

cr0x@server:~$ mount | grep -E ' /boot|/boot/efi '
/dev/sda1 on /boot/efi type vfat (rw,relatime)

Рішення: Якщо ESP не змонтовано — оновлення ядра/initramfs можуть не оновлювати реальний носій завантаження.

Огляд супервізії служб

cr0x@server:~$ sudo sv status /var/service/*
run: dhcpcd: (pid 610) 12m33s
run: nanoklogd: (pid 505) 12m34s
run: socklog-unix: (pid 520) 12m34s
run: sshd: (pid 842) 12m32s

Рішення: Якщо критична служба down — це ваша негайна сфера. Не налагоджуйте додаток, поки стан супервізора нестабільний.

Узгодження CPU та I/O

cr0x@server:~$ uptime
 09:34:10 up 25 min,  1 user,  load average: 3.12, 2.40, 1.80
cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3  0      0 5852400 112340 812400    0    0    12    35  412  780 12  4 82  2  0
 2  1      0 5849800 112340 812900    0    0  2400   120  520  900  8  3 61 28  0

Що означає: Якщо wa (I/O wait) високий — ви обмежені сховищем. Якщо домінує us/sy — ви обмежені CPU.
Рішення: Не «піднастройуйте sysctl», поки не з’ясуєте, чи чекаєте на диск.

Третє: ізолюйте винуватця цілеспрямованими перевірками

Після того, як ви визначили домен проблеми, зробіть глибшу перевірку за напрямком: стан диска, помилки ФС, логи драйверів, таблиці маршрутів, run-скрипти служб.
Уникайте широких змін. Зробіть одну зміну, спостерігайте, потім рухайтеся далі.

Поширені помилки: симптом → корінь → виправлення

1) Симптом: система завантажується в прошивку або «немає завантажувального пристрою»

Корінь: ESP не створено правильно, не позначено або відсутній запис завантаження; іноді встановлено в legacy-режимі.

Виправлення: Завантажте live ISO в UEFI-режимі, змонтуйте ESP як /boot/efi, перевстановіть завантажувач і підтвердіть з efibootmgr -v.

2) Симптом: після оновлень система падає в initramfs shell (не знайдено зашифрований root)

Корінь: initramfs не містить крипто-модулів або cmdline ядра не вказує LUKS-пристрій.

Виправлення: Переконайтеся, що dracut включає підтримку crypt, перевірте правильний UUID, перебудуйте initramfs і перевірте командний рядок завантажувача.

3) Симптом: мережа «працює», але xbps не може завантажити або TLS відмовляє

Корінь: некоректний системний час або зламана резолюція DNS.

Виправлення: виправте NTP/chrony; перевірте getent hosts; перевірте власність /etc/resolv.conf і поведінку DHCP-клієнта.

4) Симптом: служба постійно перезапускається кожні кілька секунд

Корінь: run-скрипт виходить негайно (поганий конфіг, відсутній бінар, неправильні права), супервізор робить свою роботу і перезапускає.

Виправлення: перегляньте /etc/sv/<service>/run, перевірте шляхи до виконуваних файлів і прочитайте логи під /var/log/socklog.

5) Симптом: диск несподівано заповнюється на «мінімальній» системі

Корінь: логи ростуть без ротації або знімки/субтоми (btrfs/ZFS) не очищуються.

Виправлення: реалізуйте ротацію логів (або утримання svlogd), заплануйте очищення знімків і моніторте df -h та приріст по каталогах.

6) Симптом: підвіс/відновлення ноутбука працює нестабільно

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

Виправлення: встановіть відповідні пакети прошивки/мікрокоду, перевірте параметри ядра і уникайте одночасного використання кількох «енергетичних» інструментів, що конфліктують.

7) Симптом: не вдається розв’язати імена після встановлення NetworkManager

Корінь: два компоненти керують /etc/resolv.conf (наприклад, dhcpcd + NetworkManager) і перезаписують один одного.

Виправлення: оберіть один мережевий стек; вимкніть інший; переконайтесь, що /etc/resolv.conf стабільний через перезавантаження.

8) Симптом: оновлення пакетів скаржаться на підписи або метадані репозиторію

Корінь: неправильний системний час, пошкоджений кеш або змішані репозиторії.

Виправлення: виправте час, очистіть кеш при потребі, перевірте список репозиторіїв з xbps-query -L і видаліть несподівані записи.

Три корпоративні міні-історії з практики

Міні-історія 1: інцидент через неправильне припущення

Середня компанія мала невеликий парк агентів збірки. Вони не були «продакшн», що зазвичай швидко знижує стандарти.
Агенти часто перевстановлювали, і хтось запропонував Void, бо він швидко завантажується і не заважає.
Хороше рішення. Розгортання пройшло швидко, і перший тиждень був тихий.

Потім у понеділок збірки почали періодично падати. Не всі. Не послідовно.
Помилки мали мережевий характер: таймаути, зависання завантаження пакетів, випадкові помилки TLS.
Початкова діагностика — типовий корпоративний рефлекс: «команда фаєрволу щось змінила».
Створилися тікети. Запланувалися наради. Інженер на чергуванні постарів на рік.

Справжня проблема — неправильне припущення: що системний час буде «достатньо близький» без служби синхронізації часу.
Деякі агенти завантажувалися з дрейфом годинників, достатнім, щоб спричиняти помилки валідації TLS проти певних кінцевих точок.
Це не було детермінованим, бо годинники прошивки дрейфували з різною швидкістю і образи збиралися в різний час.

Виправлення було неприємно простим: встановити й увімкнути демона синхронізації часу і додати перевірку перед стартом у скрипт запуску агента,
який відмовлявся запускати робітника збірки, якщо час сильно відрізнявся. Все стабілізувалося миттєво.
Нікому не довелося змінювати фаєрвол. Наради все одно відбулися, бо наради — окремий підсистема.

Міні-історія 2: оптимізація, яка відгукнулася бумерангом

Інша організація керувала набором внутрішніх робочих станцій розробників, що одночасно були тестовими стендами. Хтось помітив, що на певній моделі апаратури завантаження «повільне»
і вирішив оптимізувати. План — агресивно обрізати сервіси і видалити «непотрібні» пакети з базової інсталяції, щоб зменшити роботу під час старту.

Оптимізація спрацювала — на папері. Завантаження стало швидшим на кілька секунд. Потім почалися тонкі збої.
Розробники повідомляли, що після оновлення ядра системи іноді не завантажуються, і відновлення вимагало USB-носія.
Збої концентрувалися на машинах, які були «оптимізовані» найагресивніше.

Причина відкату — видалення на перший погляд опціональних інструментів навколо генерації initramfs і завантаження прошивки.
Машини все ще завантажувалися під поточним ядром, тож зміна здавалася безпечною.
Але коли прийшло наступне ядро — система не перебудувала initramfs коректно, і оновлене ядро не могло знайти зашифрований root на деяких пристроях.
Це не проблема продуктивності; це проблема життєвого циклу.

Ремедіація не була «припиніть оптимізувати». Це було «оптимізуйте з обмеженнями».
Вони відновили інструменти роботи з ядром і initramfs як захищену базу, задокументували, які пакети не підлягають зміні, і знову виміряли час завантаження.
Завантаження стало трохи повільнішим за «оптимізовану» версію, але значно швидшим за «завантаження з USB, щоб полагодити вашу робочу станцію».

Міні-історія 3: нудна, але правильна практика, що врятувала день

Команда запускала кілька невеликих сервісів на Void VM у лабораторному середовищі. Нічого гламурного: внутрішній API, шлюз метрик, кілька запланованих завдань.
У них була одна звичка, що виглядала смішно консервативно: перед будь-яким вікном оновлень вони робили снапшот на рівні гіпервізора
і експортували текстову копію невеликого «звіту стану системи» (ядро, список пакетів, увімкнені служби, ключові конфіги).

Одне оновлення внесло регрес у мережі, специфічний для версії драйвера віртуального NIC. VM завантажувалися, але інтерфейс так і не піднімався.
Це могло перерости в інцидент на весь день, бо сервіси були залежностями для пайплайнів тестування інших команд.
Натомість інженер на чергуванні дотримався рукопису: перевірив стан dhcpcd, стан лінку, порівняв зі звітом стану системи й відкотився.

Відкат — не була поразка; це був контрольований крок.
Вони відновили сервіс за хвилини, потім відтворили проблему на одній пожертвуваній VM.
З базовим звітом вони могли точно побачити, що змінилося. Це звело простір проблем з «всього інтернету» до «кількох пакетів».

Остаточне виправлення — зафіксувати одну пакунку тимчасово і запланувати оновлення після вирішення регресу у вихідному коді.
Нудна практика — снапшоти плюс звіти стану — була різницею між коротким збійом і днем хаосу.
Це не було хитро; це було правильно.

Чеклісти / покроковий план

План інсталяції (UEFI ноутбук/робоча станція, розумні налаштування)

1. Завантажте live ISO в UEFI-режимі; підтвердьте командою ls /sys/firmware/efi.
2. Ідентифікуйте цільовий диск за допомогою lsblk; відключіть зайві диски, якщо можете.
3. Створіть GPT, ESP (512 MiB) і кореневий розділ за допомогою parted.
4. Форматуйте ESP як FAT32; створіть LUKS2 на root, якщо шифруєте; форматніть ext4 всередині.
5. Змонтйте root в /mnt, ESP в /mnt/boot/efi.
6. Запустіть інсталятор; встановіть hostname, локаль, часовий пояс; створіть користувача.
7. При першому завантаженні: перевірте, що fstab використовує UUID; перевірте наявність записів завантаження.
8. Увімкніть логування (socklog) і синхронізацію часу; перевірте мережу і DNS.
9. Запустіть xbps-install -S, потім xbps-install -u у контрольованому вікні.
10. Перезавантажтеся після оновлень ядра; підтвердіть наявність запасного ядра.

Операційний базовий чекліст (пакет «майбутній я»)

• Віддалений доступ: sshd увімкнено і підтверджено; ключі встановлені; політика автентифікації визначена.
• Логи: локальні логи присутні і обмежені; рішення по централізації прийняте.
• Час: синхронізація часу увімкнена; годинник правильний при запуску.
• Оновлення: визначено частоту оновлень; є план перезавантаження ядра.
• Резервні копії: принаймні один метод знімків/образів системи; перевірка відновлення виконана один раз.
• Гігієна сховища: періодичний fstrim для SSD; моніторинг зростання використання диска.
• Власність мережі: один інструмент керує DHCP/DNS; ніяких конфліктних менеджерів.

Кроки жорсткого захисту, які варті зусиль (і ті, які можна пропустити)

Варто зробити:
сувора конфігурація SSH, мінімум встановлених пакетів, регулярні оновлення, шифрування диска на мобільних пристроях,
і базові правила файрволу відповідно до ролі (робоча станція vs сервер).

Пропускайте, якщо немає причини:
складні «пакети безпеки», одночасне встановлення трьох менеджерів живлення, екзотичні набори параметрів ядра, скопійовані з чужих інтернетів.
Безпека — це зменшення поверхні атаки і підтримка патч-хігієни, а не збір ручок.

FAQ

Чи підходить Void Linux для виробничих серверів?

Так, якщо ваша команда комфортно з роллінг-релізом і у вас є процес оновлення.
Операційна модель (runit + xbps) чиста. Ризик — не в дистрибуції, а в невпорядкованих оновленнях і недокументованих змінах.

Чи варто обирати musl для робочої станції?

Зазвичай — ні. glibc збереже вам сумісність зі сторонніми бінарними файлами та інструментами розробки.
Обирайте musl, коли точно знаєте, навіщо він потрібен (і готові відлагоджувати наслідки).

Як увімкнути службу у Void?

Створіть символічне посилання з /etc/sv/<service> до /var/service/<service>.
Потім перевірте стан з sv status <service>.

Де зберігаються логи?

Це залежить від того, що ви встановили і увімкнули. Звична конфігурація використовує socklog і зберігає логи під /var/log/socklog.
Визначте заздалегідь, як ви хочете обробляти логи; не лишайте це неоднозначним.

Яка найпростіша настільна конфігурація?

Якщо хочете мінімального тертя — використайте легкий віконний менеджер або знайому вам популярну оболонку.
Встановлюйте лише необхідне і не перетворюйте «мінімалізм» на змагання.

Як безпечно обробляти оновлення ядра?

Оновлюйте у вікні, переконайтеся, що initramfs існує для нового ядра, тримайте хоча б одне запасне ядро,
і перезавантажуйтеся у свій розклад. Перевіряйте записи завантажувача з efibootmgr -v.

Чи можна зробити повне шифрування диска з незашифрованим ESP?

Так. Це стандартний підхід UEFI: ESP незашифрований, root зашифрований (LUKS2).
Модель загроз вирішує, чи потрібен вам Secure Boot, інтеграція з TPM або віддалене розблокування.

Чому мій DNS постійно змінюється?

Бо кілька компонентів намагаються керувати /etc/resolv.conf.
Оберіть один: dhcpcd (+ resolvconf, якщо ви його використовуєте), NetworkManager або статичну конфігурацію. Потім вимкніть інші.

Чи складніше Void, ніж Arch?

Інший тип складності. Arch має широку спільноту й усталені шаблони; Void має менше шарів і меншої церемонії.
Void може відчуватися легшим, коли ви освоїте runit і xbps, бо залишається менше «магії», яку треба відучуватися.

Яка найкраща файловa система для Void?

ext4 — якщо хочете передбачуваності. btrfs — якщо хочете знімків і готові керувати ними.
ZFS — якщо ви свідомо ведете систему зберігання і приймаєте її операційну модель.
Якщо не можете чітко сформулювати компроміс — оберіть ext4 і живіть далі.

Висновок: наступні кроки, які допоможуть уникнути проблем

Void Linux мінімальна в тому, що важливо: менше абстракцій між вами і поведінкою системи.
Це робить її чудовою платформою для тих, хто любить розуміти свої машини, а не вести з ними переговори.
Але мінімалізм не виправдовує операційну лінь. Він просто робить лінь більш видимою.

Наступні кроки, які я дійсно зробив би, в порядку:

1. Увімкніть логування і синхронізацію часу; перевірте, що вони переживають перезавантаження.
2. Забезпечте SSH (або видаліть його, якщо не потрібен) і підтвердіть можливість відновлення доступу.
3. Визначте графік оновлень і протестуйте оновлення ядра + перезавантаження, коли ви не під тиском.
4. Оберіть політику зберігання: ext4 як база, або знімки з btrfs/ZFS — з моніторингом і очищенням.
5. Напишіть односторінковий локальний рукопис: розмітка диска, UUID шифрування, увімкнені служби і як завантажити запасне ядро.

Мета не побудувати наймінімальнішу систему в інтернеті. Мета — побудувати систему, якою можна керувати спокійно, коли вона поводиться неправильно.
Void дає інструменти. Використайте їх так, ніби саме вас можуть покликати о 3-й ночі — бо так може статися.