B1. Встановлення системи

базовийспирається на модуль 5

Мета

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

Етапи

Розмітка GPT.

Два розділи: ESP на 512 МіБ з типом EFI System і файловою системою FAT32, решта під корінь.

Подивіться на таблицю через sgdisk -p і знайдіть у ній GUID типу розділу — саме за ним прошивка впізнає ESP, а не за іменем чи розміром.
Базова система.

debootstrap для Debian чи Ubuntu, pacstrap для Arch — будь-який спосіб, аби він був покроковим, а не графічним інсталятором.
fstab за UUID.

Не за /dev/sda2: імена пристроїв залежать від порядку виявлення й міняються, коли ви додасте диск у B5.
Ядро, initramfs і завантажувач.

Поставте ядро, зберіть initramfs, встановіть systemd-boot або GRUB у режимі UEFI.

Далі з’ясуйте, навіщо тут initramfs. Спершу подивіться, чи драйвер вашого контролера взагалі є окремим модулем:
Terminal window
```
grep -E '^CONFIG_(SCSI_VIRTIO|VIRTIO_BLK|BLK_DEV_NVME)=' /boot/config-$(uname -r)
lsinitramfs /boot/initrd.img | grep -c 'kernel/drivers'
```
Якщо у відповіді =y, драйвер вбудований у саме ядро, і шукати його серед модулів initramfs марно (модуль 5).

У віртуальній машині драйвери virtio зазвичай зібрані в ядро (CONFIG_SCSI_VIRTIO=y), тож пояснення «без initramfs ядро не побачить диска» тут не працює: диск воно бачить.
Потрібен він для іншого. Рядок root=UUID=… розбирає не ядро, а програма з initramfs: щоб зіставити UUID із пристроєм, треба прочитати заголовки файлових систем, а це вже робота для простору користувача. Приберіть initramfs — і отримаєте Kernel panic: VFS: Unable to mount root fs on unknown-block(0,0). Замініть у тому ж завантаженні root=UUID=… на root=/dev/sda2 — і те саме ядро без initramfs підніметься без жодної скарги.
Це варто зробити руками: два завантаження, які відрізняються одним параметром, пояснюють роль initramfs краще за будь-який опис.
Перше завантаження.

systemd-analyze і systemd-analyze critical-chain одразу після входу — щоб було з чим порівнювати далі.
Власний юніт.

Напишіть .service, який запускає простий скрипт, залежить від мережі й перезапускається після збою. Перевірте systemctl status, journalctl -u.

Обов’язково зробіть так, щоб скрипт покладався на змінну середовища, якої в юніта немає. Подивіться, як він упаде, і виправте — це найчастіша реальна проблема (модуль 5).
Зламати й полагодити.

Три сценарії, кожен окремо, зі знімком ВМ перед кожним:
- зіпсувати UUID кореня у fstab;
- видалити initramfs поточного ядра;
- зробити юніт, який блокує multi-user.target.
Для кожного: як система себе поводить, що показує аварійна консоль, якими командами ви це знайшли, як полагодили.

Не чекайте, що всі три дадуть чорний екран. Тільки один із них узагалі не дасть системі завантажитись, а два інші зроблять гірше: машина підніметься, пустить вас по ssh і виглядатиме справною. Ваше завдання — навчитися бачити різницю між «працює» і «завантажилось як слід», а systemctl is-system-running тут корисніший за будь-який зовнішній моніторинг.

Що треба вміти підтвердити

Робота зарахована, якщо ви можете однією командою довести кожне з тверджень на своїй системі:

Твердження	Чим доводиться
Система завантажилась через UEFI, не BIOS	`[ -d /sys/firmware/efi ] && echo UEFI`
Таблиця розділів — GPT, є ESP	`sgdisk -p /dev/…` або `lsblk -o NAME,PARTTYPENAME`
Корінь підключений за UUID	`findmnt -o SOURCE,TARGET,UUID /`
Завантажувач знає про ядро	`cat /proc/cmdline`
Ви знаєте, навіщо тут initramfs	два завантаження: з `root=UUID=` і з `root=/dev/…`
Ваш юніт активний і перезапускається	`systemctl status ім'я.service`
Ви знаєте, що заповільнило завантаження	`systemd-analyze critical-chain`
Після всіх ремонтів система справді ціла	`systemctl is-system-running` каже `running`, не `degraded`

Часті помилки

ESP відформатовано не у FAT32. Прошивка його просто не побачить.

GRUB встановлено в режимі BIOS на UEFI-машині. Класика жанру: команда виконалася без жодної помилки, а система не завантажилась.

fstab за іменем пристрою. Працюватиме рівно до першого нового диска.

Юніт без After=. Служба стартує раніше за мережу й падає, а в журналі це виглядає як помилка застосунку.

Ремонт без знімка. Після третьої спроби ви вже не пам’ятаєте, що зламали самі, а що було зламане до вас. Знімок перед кожним сценарієм обов’язковий.

mount -o remount,rw / не рятує зіпсований fstab. Команда сама читає fstab, щоб дізнатися, який пристрій монтувати в /, і спотикається об той самий хибний UUID: can't find UUID=…. Назвіть пристрій явно — mount -o remount,rw /dev/sda2 / — і тоді файл можна буде виправити.

Завантажувач ставили не на тій машині. Якщо ви зібрали систему на одному комп’ютері, а диск переставили в інший, grub-install міг записати образ, якому бракує драйвера файлової системи кореня. Прошивка запустить GRUB, а той не знайде власного конфіга й викине вас у grub> з error: file '/boot/' not found. Підйом із цього стану робиться на місці:

grub> insmod ext2
grub> search --fs-uuid --set=root <UUID кореня>
grub> set prefix=($root)/boot/grub
grub> insmod normal
grub> normal

А постійне лікування — повторити grub-install уже із завантаженої системи, на її власній машині.

Далі, якщо цікаво

Увімкнути Secure Boot і підписати власне ядро. Або зашифрувати корінь через LUKS і подивитися, як змінюється роль initramfs.