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

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

Мета

Сервер після оновлення ядра не піднявся, на консолі emergency mode, і треба зрозуміти, до якої ланки дійшло завантаження. Ланцюг від прошивки до multi-user.target описано в модулі 5. У цій роботі ви зберете його руками: розмітите диск, поставите ядро, initramfs і завантажувач, напишете юніт. Потім тричі зламаєте завантаження й полагодите його з аварійної консолі.

Після цієї роботи ви зможете:

• розмітити диск під UEFI і пояснити, за чим прошивка впізнає ESP;
• показати двома завантаженнями, навіщо initramfs у системі, де драйвер диска вбудований у ядро;
• написати .service, який залежить від мережі й перезапускається після збою, і знайти в journalctl -u, чому він упав;
• прочитати systemd-analyze critical-chain і сказати, що затримало завантаження;
• відрізнити систему, яка завантажилась як слід, від тієї, що пускає по ssh, але має зламані юніти.

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

Завдання

Результат роботи: встановлена вручну система у віртуальній машині з UEFI, яка завантажується з GPT через ESP, монтує корінь за UUID і запускає ваш юніт, а також звіт про три сценарії поломки.

Що зробити:

1. Розмітити диск GPT: ESP на 512 МіБ з типом EFI System і FAT32, решта під корінь.
2. Поставити базову систему покроковим способом: debootstrap для Debian чи Ubuntu, pacstrap для Arch.
3. Записати fstab за UUID.
4. Поставити ядро, зібрати initramfs, встановити systemd-boot або GRUB у режимі UEFI. Двома завантаженнями, з root=UUID= і з root=/dev/…, з’ясувати, для чого тут initramfs.
5. Одразу після першого завантаження зняти systemd-analyze і systemd-analyze critical-chain.
6. Написати .service, який запускає скрипт, залежить від мережі й перезапускається після збою. Один раз дати скрипту змінну середовища, якої в юніта немає, побачити падіння і виправити.
7. Зламати й полагодити завантаження у трьох сценаріях, зі знімком ВМ перед кожним: зіпсований UUID кореня у fstab, видалений initramfs поточного ядра, юніт, який блокує multi-user.target.

Чого робити не треба. Графічний інсталятор не підходить: він зробить розмітку, fstab і завантажувач за вас, і ланцюга ви не побачите. Secure Boot і шифрування кореня лишаються на «Далі, якщо цікаво», а кілька дисків, LVM і RAID належать роботі B5.

Обмеження. Лише UEFI і GPT, без BIOS-режиму і MBR. fstab тільки за UUID. Перед кожним сценарієм поломки обов’язковий знімок ВМ.

Що записати у звіт:

• вивід sgdisk -p з GUID типу ESP і findmnt -o SOURCE,TARGET,UUID /;
• результат двох завантажень без initramfs, з root=UUID= і з root=/dev/…, і ваше пояснення, чому вони відрізняються;
• systemd-analyze і critical-chain після першого завантаження і що в ланцюзі виявилось найдовшим;
• як упав юніт без змінної середовища: рядок із journalctl -u і що ви виправили;
• для кожного з трьох сценаріїв: як система себе повела, що показала аварійна консоль, якими командами ви знайшли причину і як полагодили.

Готово, коли:

• кожне з восьми тверджень у таблиці «Що треба вміти підтвердити» ви доводите однією командою на своїй системі;
• systemctl is-system-running після всіх трьох ремонтів каже running;
• у звіті є п’ять пунктів вище.

Перед початком

• Прочитайте в модулі 5 розділи «Ланцюг», «systemd» і «Як це насправді в Linux». Чому контейнер не має власного завантажувача, пояснює модуль 17, розділ «З чого зроблено контейнер».
• Потрібна віртуальна машина з увімкненим UEFI, порожнім диском і можливістю робити знімки. WSL2 не підходить: завантаженням там керує Windows. На хмарній машині потрібна можливість додати диск (огляд).
• Знадобляться sgdisk (пакет gdisk), mkfs.fat (dosfstools), debootstrap або pacstrap, lsinitramfs і systemd-analyze.
• В архіві курсу для цієї роботи файлів немає: ні заготовок, ні check.sh. Перевіркою є таблиця тверджень і звіт.

Потрібна віртуальна машина

Контейнер тут не підійде: він не має власного завантажувача й не бачить /sys/firmware/efi (модуль 17). Потрібна віртуальна машина з увімкненим UEFI.

До речі, з тринадцяти робіт курсу в контейнері не виконуються чотири: ця, A6 через /dev/fuse, B5 через блокові пристрої і B6 через лічильники продуктивності.

Етапи

1. Розмітка GPT.

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

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

2. Базова система.

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

3. fstab за UUID.

   Імена на кшталт /dev/sda2 не підходять: вони залежать від порядку виявлення й міняються, коли ви додасте диск у B5.

4. Ядро, initramfs і завантажувач.

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

   Далі з’ясуйте, навіщо тут initramfs. Спершу подивіться, чи драйвер вашого контролера взагалі є окремим модулем:

   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).

   Навіщо initramfs, якщо драйвери вбудовані

   У віртуальній машині драйвери 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 краще за будь-який опис.

5. Перше завантаження.

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

6. Власний юніт.

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

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

7. Зламати й полагодити.

   Три сценарії, кожен окремо, зі знімком ВМ перед кожним:

   • зіпсувати UUID кореня у fstab;
   • видалити initramfs поточного ядра;
   • зробити юніт, який блокує multi-user.target.

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

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

Скільки це триває

Для звірки, заміри на ВМ із двома ядрами й диском на SSD, Ubuntu 26.04: debootstrap займає 3 хвилини й 431 МБ, уся система після ядра й завантажувача важить 2.6 ГБ, initramfs має 74 МБ і майже дві тисячі файлів усередині. Завантаження встановленої системи триває близько 8 секунд, із них 2.7 припадає на ядро.

Найбільше часу в роботі забирає сьомий етап.

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

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

Твердження	Чим доводиться
Система завантажилась через 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.