Последовательность загрузки
Linux загружается строго по цепочке: прошивка → загрузчик → ядро → initramfs → PID 1. Каждый этап передаёт управление следующему с конкретным артефактом. Знание, где обрывается цепочка, показывает как восстановить машину, которая не загружается.
Два часа ночи. Продакшн-VM не отвечает. Ты подключаешься через консоль и видишь мигающий курсор — машина не завершила загрузку. Ты знаешь, где именно в цепочке она остановилась? Без этой ментальной модели ты угадываешь. Зная её — ты читаешь позицию курсора, последнюю строку лога или меню grub и сразу понимаешь: прошивка, загрузчик, распаковка ядра, монтирование initramfs или сбой PID 1.
Последовательность загрузки Linux — не магия. Это строгая цепочка передач управления, где каждый этап делает ровно одно дело и передаёт управление следующему. Когда она ломается, она ломается на стыке.
После этого урока ты сможешь назвать каждый этап загрузки Linux, объяснить что каждый этап передаёт следующему, определить какой этап отвечает за данный симптом зависания, и использовать journalctl -b для чтения лога загрузки.
Этап 1 — Прошивка (UEFI или BIOS). При подаче питания CPU начинает выполнять код из фиксированного адреса в ROM — прошивке. На современных машинах это UEFI; на старом железе — BIOS. Прошивка проводит самотестирование при включении (POST): проверяет RAM, обнаруживает контроллеры хранилищ, перечисляет PCI-устройства. У неё пока нет понятия о Linux — только об аппаратуре.
После POST прошивка ищет загрузочное устройство. UEFI читает EFI System Partition (ESP, обычно /dev/sda1, форматированный FAT32) и находит EFI-исполняемый файл (например, grubx64.efi). BIOS читает первые 512 байт диска (Master Boot Record) и прыгает на код там.
Работа прошивки завершается, как только она передаёт управление загрузчику. Если машина останавливается здесь: нет POST-сигнала, пустой экран, или сообщение прошивки (“No boot device found”).
Этап 2 — Загрузчик (GRUB 2). Единственная цель загрузчика — загрузить ядро и передать ему образ initramfs плюс командную строку. На Debian/Ubuntu загрузчик — GRUB 2 (/boot/grub/grub.cfg). GRUB читает файл конфигурации, показывает меню (несколько секунд или сразу), затем:
- Загружает образ ядра из
/boot/vmlinuz-<версия>в память. - Загружает начальную RAM-файловую систему из
/boot/initrd.img-<версия>в память. - Передаёт командную строку ядра (из
grub.cfg— например,root=/dev/sda2 ro quiet splash). - Прыгает на точку входа ядра.
Если GRUB падает — видишь его командную оболочку или сообщения “error: no such device”. Частая причина: UUID в grub.cfg не совпадает с реальным диском (происходит после замены диска или изменения разделов).
Этап 3 — Распаковка ядра и инициализация. Образ ядра (vmlinuz) — это сжатый самораспаковывающийся бинарник. Когда GRUB прыгает на него, ядро сначала распаковывает себя. Затем инициализирует CPU (устанавливает таблицу дескрипторов прерываний, включает пейджинг), обнаруживает оборудование из дерева устройств или таблиц ACPI, инициализирует аллокатор памяти.
На этом этапе не смонтировано ни одной файловой системы — даже корневой. У ядра в памяти только образ initramfs. Сообщения ядра появляются в консоли (строки, которые мелькают: [ 0.000000] Booting Linux on physical CPU 0x0). Если ядро паникует здесь — это плохой параметр ядра, отсутствующие возможности CPU или повреждение памяти.
Этап 4 — initramfs (начальная RAM-файловая система). Ядро монтирует initramfs как временную корневую файловую систему (в памяти, не на диске). Внутри живёт минимальный userland: busybox, менеджер устройств udev, и главное — скрипты и инструменты для нахождения и монтирования настоящей корневой файловой системы. Именно здесь происходят активация LVM, расшифровка LUKS, сборка RAID и fsck — до монтирования постоянного корня.
# Посмотреть, что внутри initramfs
lsinitramfs /boot/initrd.img-$(uname -r) | head -30Как только скрипты initramfs успешно монтируют настоящий корень в /root (с точки зрения initramfs), они вызывают switch_root для переключения с RAM-корня на реальный дисковый корень. RAM initramfs освобождается. Если система останавливается здесь — например, ты видишь “Waiting for root device…” — initramfs не может найти или расшифровать диск.
Этап 5 — PID 1 и подъём системы. После монтирования настоящего корня и выполнения pivot ядро запускает /sbin/init (или /lib/systemd/systemd) как PID 1 — первый процесс userland. На современных Debian/Ubuntu это systemd. PID 1 отвечает за всё с этого момента: монтирование остальных файловых систем, запуск всех сервисов и достижение целевого состояния (например, multi-user.target).
# Посмотреть полный лог загрузки с последнего старта
journalctl -b
# Проверить, сколько времени заняли этапы загрузки
systemd-analyze blameЕсли PID 1 падает, ядро паникует с “Kernel panic — not syncing: Attempted to kill init!” — восстановление без перезагрузки невозможно.
Диагностика машины, застрявшей на “Waiting for root device /dev/sda2…”
Это сообщение печатают скрипты initramfs, когда не могут найти устройство. Самая частая причина на VM после замены диска: UUID в /etc/fstab и в grub.cfg всё ещё указывает на UUID старого диска.
Шаги восстановления с live-загрузки:
# Загружаемся с live-USB, затем:
# 1. Узнаём реальный UUID нового диска
blkid /dev/sda2
# 2. Временно монтируем настоящий корень
mount /dev/sda2 /mnt
# 3. Правим fstab с новым UUID
nano /mnt/etc/fstab
# 4. Входим в chroot и перегенерируем grub
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt update-grub
# 5. ПерезагружаемсяКлючевой вывод: initramfs передаёт управление только после успешного switch_root. Несовпадение UUID — это 100% сбой на этапе 4, а не проблема ядра или прошивки.
▸Почему это работает
На macOS и Mac с Apple Silicon цепочка загрузки контролируется Apple: iBoot (Apple Boot ROM) → ядро macOS. Нет GRUB, нет initramfs в смысле Linux, нет /sbin/init — macOS использует launchd как PID 1. Концептуальная схема (прошивка → загрузчик → ядро → init) та же, но каждый конкретный инструмент другой. Всё в этом уроке применимо к Linux на железе, в VM и в контейнерах начиная с этапа ядра.
▸Частая ошибка
Частая ошибка при chroot-восстановлении сломанной загрузки: забыть bind-монтировать /dev, /proc и /sys перед запуском update-grub или dpkg. Без этих псевдофайловых систем update-grub может молча упасть или сгенерировать неверный конфиг, потому что не может прочитать текущую топологию дисков из /sys/block. Всегда монтируй все три перед любой операцией в chroot, затрагивающей загрузчик или initramfs.
VM показывает "Waiting for root device..." и не продвигается дальше. Какой этап загрузки завершился неудачей?
Linux загружается в пять этапов: прошивка (POST, поиск устройства), загрузчик (загружает ядро + initramfs + cmdline), инициализация ядра (распаковка, обнаружение железа), initramfs (найти и смонтировать настоящий корень — здесь живут LUKS/LVM), и PID 1 (systemd запускает сервисы). Каждый этап передаёт управление следующему на чётко определённом стыке. Сбои загрузки всегда происходят на стыке: “no boot device” — прошивка/загрузчик; “Waiting for root device” — initramfs; “Attempted to kill init” — PID 1. journalctl -b и systemd-analyze blame — основные инструменты после успешной загрузки.
Практика
Начни сверху. Задачи идут от простого к сложному: вспомнить факт, применить к случаю, затем senior-уровень. Открой, попробуй, потом открой ответ.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.