Ответ
Процесс загрузки Linux — это цепочка этапов, которые я часто анализирую при диагностике проблем с виртуальными машинами или bare-metal серверами.
Основные этапы:
- BIOS/UEFI: Прошивка материнской платы выполняет самотестирование (POST), инициализирует оборудование и загружает код загрузчика с загрузочного носителя.
- Загрузчик (Bootloader): Его задача — найти и загрузить ядро Linux и образ initramfs в оперативную память. Популярные загрузчики:
- GRUB2 — самый распространенный, поддерживает UEFI и BIOS, имеет интерактивное меню.
- systemd-boot — легковесный загрузчик для UEFI, интегрированный со systemd.
- Ядро (Kernel): Ядро распаковывается из сжатого образа, инициализирует процессор, память и драйверы устройств, а затем монтирует корневую файловую систему (
/), используя параметрroot=. - Initramfs: Это временная корневая ФС в памяти. Она содержит драйверы и утилиты, необходимые для монтирования настоящей корневой ФС, особенно если она на LVM, RAID или зашифрована (LUKS). После монтирования
/управление передается процессуinit. - Init / Systemd: Первый пользовательский процесс (PID 1). В современных дистрибутивах это systemd. Он монтирует файловые системы из
/etc/fstab, запускает таргеты (default.target) и все системные сервисы.
Пример из практики: При автоматизации развертывания (например, с Packer) мы явно настраиваем GRUB, чтобы ядро загружалось с правильными параметрами, например, для AWS EC2:
# В скрипте provisioning добавляем параметр для правильного определения сетевого интерфейса
sudo sed -i 's/GRUB_CMDLINE_LINUX=".*"/GRUB_CMDLINE_LINUX="console=ttyS0 nvme_core.io_timeout=4294967295"/' /etc/default/grub
sudo update-grubОтвет 18+ 🔞
А, блядь, ну вот, опять про эту магию загрузки Linux! Сидишь, бывает, ночью, а тебе пишут: «Сервер не грузится, просто чёрный экран». И ты такой: «Ну ёпта, сейчас начнётся…» И понимаешь, что придётся вспоминать всю эту цепочку, от самого низа до systemd, которая, как хитрая жопа, может сломаться на любом этапе. Слушай, давай по косточкам разберём, чтобы ты не охуел, когда такое увидишь.
Этап первый: BIOS/UEFI — стартовая суета. Это прошивка на мамке, которая орёт «ВСТАТЬ, РАЗОЙДИСЬ!» всему железу. Она делает POST (самотестирование), пиликает, если что не так, и потом начинает искать, с чего бы загрузиться. Главная её задача — найти загрузочный сектор и передать ему управление. Если тут проблемы — волнение ебать, потому что это уже почти железо. Может, диск отвалился, а может, в настройках BIOS/UEFI какой-то пидарас шерстяной порядок загрузки сломал.
Этап второй: Загрузчик — главный распорядитель.
Вот тут уже начинается интересное. Этот чувак (чаще всего GRUB2) должен найти ядро и initramfs на диске и запихнуть их в оперативку. GRUB — это такой монстр с интерактивным меню, поддержкой и BIOS, и UEFI. А есть ещё systemd-boot — попроще, для UEFI, но зато тесно с systemd дружит. Если загрузчик сломался или его конфиг кривой — ты увидишь либо grub rescue>, либо просто тёмный экран вечности. Доверия ебать ноль к этому этапу, потому что обновление ядра или кривой grub-install могут его убить.
Этап третий: Ядро — сердце системы.
Ядро, которое обычно лежит в /boot/vmlinuz-xxx, распаковывается и начинает хозяйничать. Инициализирует процессор, память, подгружает драйверы. Ключевой момент — оно должно смонтировать корневую файловую систему (/), путь к которой мы передаём в параметре root=. Если ядро не видит диск или драйвер не подгрузился — всё, приехали. Система встаёт и говорит: «А хули мне монтировать-то? Диска нет!» И уходит в панику.
Этап четвёртый: Initramfs — временная заглушка.
Вот это, блядь, часто источник всех бед! Initramfs — это такой временный корень в оперативке, архив с драйверами и утилитами. Он нужен, когда настоящий корень на чём-то сложном: LVM, RAID, или, того хуже, зашифрован через LUKS. Его задача — подготовить всё, чтобы смонтировать настоящий /. Если в initramfs нет нужного драйвера (например, для NVMe-диска) или скрипты в нём кривые — система зависнет, тыкаясь в чёрный экран. Приходится лезть в live-окружение и пересобирать этот initramfs командой mkinitcpio или update-initramfs. Терпения ноль ебать, когда копаешься в этом.
Этап пятый: Init / Systemd — начало пользовательской вакханалии.
Как только корень смонтирован, управление передаётся первому процессу с PID 1. В старину это был init, а сейчас почти везде — systemd. Он читает /etc/fstab, монтирует оттуда все файловые системы, и если там ошибка (например, UUID диска поменялся) — может упереться и не загрузиться дальше. Потом он запускает таргеты (обычно default.target, который тянет за собой multi-user.target и graphical.target) и все системные сервисы. Если сломался критичный сервис или завис при старте — опять проблемы.
Пример из жизни, когда всё пошло по пизде: Вот, допустим, автоматизируешь развёртывание образа в облаке (допустим, на AWS EC2 через Packer). Там, сука, свои заморочки: нужно, чтобы ядро правильно общалось с железом, особенно с сетевыми интерфейсами. Если этого не сделать, то после загрузки в облаке у инстанса не будет сети. Поэтому в скрипте provisioning часто приходится лезть в GRUB и настраивать параметры ядра. Вот реальный кусок кода, который я использовал:
# Лезем в конфиг GRUB и добавляем параметры для работы на специфичном железе AWS
# console=ttyS0 — чтобы вывод шёл на последовательный порт (это важно для AWS Console)
# nvme_core.io_timeout — костыль для некоторых NVMe дисков, чтобы не отваливались по таймауту
sudo sed -i 's/GRUB_CMDLINE_LINUX=".*"/GRUB_CMDLINE_LINUX="console=ttyS0 nvme_core.io_timeout=4294967295"/' /etc/default/grub
sudo update-grubБез этого, блядь, собранный образ может загрузиться в облаке и тут же накрыться медным тазом, потому что ядро не поймёт, как работать с железом. А потом сидишь и думаешь: «Ну ядрёна вошь, почему нет связи?» А причина — в одном забытом параметре ядра на этапе загрузчика.
Короче, процесс загрузки — это как домино. Упала одна костяшка — и всё, пиздец. Но если понимаешь, на каком именно этапе система встала колом, то уже половина дела сделана. Осталось только не сойти с ума, пока копаешься в этих конфигах.