Что происходит при загрузке Linux

Классический «разогревочный» вопрос, по ответу на который интервьюер сразу понимает глубину вашего понимания системы.

Вопрос: «Что происходит с момента, когда вы нажали кнопку питания сервера, и до момента, когда вы видите приглашение login:?»

Что на самом деле проверяет интервьюер

Никого не интересует, помните ли вы адрес нулевого сектора диска. Проверяют три вещи: умеете ли вы структурировать длинный процесс на этапы, понимаете ли, что сервер — это не «чёрный ящик», и знаете ли, куда смотреть, когда машина не загрузилась. Ответ «включается и работает» закрывает вакансию джуна на месте. Хороший ответ — это 5–6 названных этапов, у каждого из которых есть свой способ диагностики.

Развёрнутый ответ: пять этапов

1. Прошивка: BIOS или UEFI

Прошивка материнской платы проверяет железо (POST) и ищет, откуда грузиться. Старый BIOS читает первые 512 байт диска — MBR. Современный UEFI читает файл .efi из специального раздела /boot/efi и порядок загрузки хранит в собственной энергонезависимой памяти (NVRAM). Практическое следствие: если сервер после переустановки «не видит систему», в 90% случаев дело в записи UEFI, а не в убитом диске.

2. Загрузчик: GRUB

Загрузчик умеет одно: найти на диске ядро и передать ему управление вместе со списком параметров. Именно здесь вы правите строку ядра, когда нужно попасть в систему со сломанным паролем root или отключить проблемный драйвер.

# посмотреть, с какими параметрами загружено текущее ядро
cat /proc/cmdline

# типичный вывод
# BOOT_IMAGE=/vmlinuz-6.1.0-18-amd64 root=UUID=1a2b-3c4d ro quiet

3. Ядро и initramfs

Ядро распаковывается в память, поднимает драйверы и обнаруживает железо. Но корневая файловая система может лежать на LVM, RAID или зашифрованном разделе — драйверов для этого в ядре нет. Поэтому GRUB подсовывает ядру initramfs: крошечный временный корень в оперативной памяти с набором модулей. Он собирает LVM/RAID, при необходимости спрашивает пароль от LUKS, монтирует настоящий корень и делает switch_root.

4. PID 1: systemd

Ядро запускает первый пользовательский процесс — /sbin/init, который сегодня почти всегда symlink на systemd. Он получает PID 1 и становится предком всех процессов в системе. systemd читает юниты (описания сервисов, монтирований, сокетов), строит по ним граф зависимостей и запускает всё, что можно, параллельно.

# какая цель загрузки активна
systemctl get-default        # multi-user.target на сервере

# что тормозит загрузку
systemd-analyze
systemd-analyze blame | head -5

# сервисы, упавшие при старте
systemctl --failed

5. Сервисы и getty

systemd поднимает сеть, sshd, ваше приложение и запускает getty на консоли — тот самый процесс, который печатает login:. С этого момента система считается загруженной.

Второй вопрос: чем systemd лучше SysV init

Логичное продолжение, которое задают почти всегда. Суть в четырёх пунктах:

Параллельность. SysV выполнял шелл-скрипты строго по порядку номеров. systemd запускает независимые сервисы одновременно — загрузка ускоряется в разы.
Зависимости декларативны. Вместо «запусти меня 20-м» пишем After=network-online.target, и порядок вычисляется сам.
Надёжный учёт процессов. Каждый сервис живёт в своей cgroup, поэтому systemd видит все его дочерние процессы и умеет корректно их останавливать. Скрипты SysV полагались на PID-файлы, которые постоянно врали.
Единый журнал и автоперезапуск. journalctl -u myapp и Restart=on-failure вместо самописных обвязок.

[Unit]
Description=My API
After=network-online.target

[Service]
ExecStart=/usr/local/bin/myapi --port 8080
Restart=on-failure
RestartSec=5
User=myapi

[Install]
WantedBy=multi-user.target

Файл кладут в /etc/systemd/system/myapi.service, затем systemctl daemon-reload && systemctl enable --now myapi. Про daemon-reload спрашивают отдельно: без него systemd продолжит работать со старой версией юнита.

Типичные ошибки кандидатов

Пропускают initramfs — и потом не могут объяснить, как система монтирует корень, лежащий на LVM.
Путают systemctl enable (автозапуск после перезагрузки) и systemctl start (запуск здесь и сейчас). На собеседовании это ловят вопросом «сервис работает, но после ребута пропал — почему?».
Говорят «systemd — это просто init», не упоминая cgroups и journald, хотя именно они и дали ему победу.
Не могут назвать ни одной команды диагностики загрузки — а это половина ценности ответа.

Как ответить кратко (20–30 секунд)

«Прошивка UEFI проходит POST и передаёт управление загрузчику GRUB. GRUB загружает в память ядро и initramfs. Ядро поднимает драйверы, initramfs собирает LVM или RAID, монтирует настоящий корень и делает switch_root. Ядро запускает PID 1 — systemd, тот по графу зависимостей параллельно поднимает юниты до multi-user.target, включая sshd и getty, который и печатает login. Если что-то пошло не так, смотрю systemd-analyze blame и systemctl --failed.»