Анатомия загрузки Linux: от питания до системного окружения

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

1. Первичная инициализация: роль прошивок BIOS и UEFI в подготовке оборудования

Первичная инициализация: роль прошивок BIOS и UEFI в подготовке оборудования

Вы нажимаете кнопку питания на сервере. В этот момент процессор получает ток, но он абсолютно «слеп». У него нет операционной системы, он не знает, где находится жесткий диск, и не умеет работать с файлами. До того как ядро Linux выведет на экран первую строчку логов, должна отработать невидимая, но критически важная цепочка инструкций, зашитая прямо в материнскую плату.

Если сервер не загружается, проблема часто кроется не в Linux, а в том, что система даже не смогла до него добраться. Давайте разберем самый первый этап жизни сервера — от подачи питания до поиска загрузчика.

Пробуждение железа: POST и Reset Vector

Как только напряжение стабилизируется, процессор обращается к жестко заданному адресу памяти — Reset Vector. По этому адресу находится точка входа в микропрограмму материнской платы (BIOS или UEFI).

Первое, что делает эта прошивка — запускает процедуру POST (Power-On Self-Test). Это базовая проверка жизнеспособности оборудования:

  • Инициализация контроллера оперативной памяти (без RAM дальнейшая работа невозможна).
  • Проверка наличия процессора и базовых шин ввода-вывода.
  • Инициализация видеокарты (именно в этот момент на мониторе появляется логотип производителя).
  • Опрос подключенных накопителей (HDD, SSD, NVMe) и USB-устройств.

    • > Если на этапе POST обнаруживается критическая аппаратная ошибка (например, сгорела планка памяти), загрузка останавливается навсегда. Вы услышите звуковые сигналы (Beep codes) или увидите код ошибки на LED-индикаторе материнской платы. До Linux дело даже не дойдет.

    Если POST пройден успешно, перед материнской платой встает главная задача: найти операционную систему на подключенных дисках и передать ей управление. Исторически сложилось два совершенно разных подхода к решению этой задачи.

    Наследие BIOS: Загрузка вслепую

    Классический BIOS (Basic Input/Output System) был создан в эпоху, когда диски измерялись мегабайтами. Его логика поиска операционной системы примитивна: BIOS ничего не знает о файловых системах, папках или файлах.

    Он работает по жесткому алгоритму:

  • BIOS опрашивает диски в порядке очереди (Boot Order).
  • Находит первый диск и считывает его самый первый физический сектор — MBR (Master Boot Record).
  • Размер этого сектора — всего 512 байт. В них нужно уместить таблицу разделов и крошечный кусочек машинного кода.
  • BIOS загружает эти 512 байт в оперативную память и слепо передает им управление.

    • Этот крошечный код из MBR должен был сам разобраться, как прочитать остальную часть диска, чтобы вытянуть полноценный загрузчик ОС. Из-за физических ограничений MBR не поддерживал диски объемом более 2 ТБ и мог содержать только 4 основных раздела. Сегодня этот подход считается устаревшим и на современных серверах используется только в режиме совместимости (Legacy/CSM).

    Эпоха UEFI: Прошивка как мини-ОС

    На смену BIOS пришел UEFI (Unified Extensible Firmware Interface). Это уже не просто набор базовых инструкций, а полноценная мини-операционная система, живущая на материнской плате.

    Главное отличие UEFI от BIOS — UEFI умеет читать файловые системы (в частности, FAT32). Ему больше не нужно вслепую запускать код из первого сектора диска. Вместо этого UEFI ищет на диске специально подготовленный раздел.

    !Сравнение загрузки BIOS и UEFI

    Этот специальный раздел называется ESP (EFI System Partition).

  • Это небольшой раздел (обычно от 100 до 500 МБ).
  • Он отформатирован в файловой системе FAT32.
  • На нем хранятся исполняемые файлы загрузчиков с расширением .efi.

    • Логика работы UEFI выглядит так:

  • UEFI считывает таблицу разделов диска (используется современный формат GPT, который поддерживает диски любого объема).
  • Находит раздел с флагом ESP.
  • Монтирует его и ищет файл загрузчика по заранее сохраненному пути (например, \EFI\ubuntu\grubx64.efi или дефолтный \EFI\BOOT\BOOTX64.EFI).
  • Загружает этот файл в оперативную память и передает ему управление.

    • !Что произойдет при удалении ESP

    Финал инициализации: Передача эстафеты

    Как только UEFI нашел файл .efi и запустил его, роль материнской платы заканчивается. Прошивка сделала свое дело: проверила железо и нашла программу, которая знает, что делать дальше.

    Этим .efi файлом в мире Linux в 99% случаев является GRUB (GRand Unified Bootloader). Именно GRUB возьмет на себя следующую задачу: показать вам меню выбора операционной системы, найти на диске сжатый образ ядра Linux и распаковать его. Но о том, как GRUB ищет ядро и какие параметры ему передает, мы поговорим в следующей главе.

    2. Загрузчик GRUB: поиск ядра, передача параметров и выбор режима загрузки

    Загрузчик GRUB: поиск ядра, передача параметров и выбор режима загрузки

    Прошивка UEFI успешно нашла на разделе ESP файл grubx64.efi и передала ему управление. На этом этапе аппаратная часть свою работу выполнила. Но загрузчик GRUB (GRand Unified Bootloader) — это еще не операционная система. Это узкоспециализированная программа-мост, чья единственная цель — найти ядро Linux, объяснить ему, как нужно работать, и навсегда уйти со сцены.

    Главная проблема этого этапа: UEFI умеет читать только простую файловую систему FAT32. Однако само ядро Linux и его компоненты лежат на системном диске, отформатированном в сложных форматах вроде ext4, xfs или btrfs. Как загрузчик до них доберется?

    Суперсила GRUB: встроенные драйверы

    В отличие от старых примитивных загрузчиков, GRUB — это мини-операционная система. В него встроены собственные драйверы файловых систем.

    Получив управление, GRUB подгружает нужные модули (например, ext2.mod или btrfs.mod), что позволяет ему «увидеть» содержимое корневого раздела Linux или специального раздела /boot.

    !GRUB как мост между ESP и корневой файловой системой

    Как только GRUB получает доступ к файловой системе, он ищет свою карту местности — конфигурационный файл /boot/grub/grub.cfg. Именно этот файл формирует то самое меню выбора операционных систем, которое вы видите на экране при включении сервера.

    Анатомия пункта меню (grub.cfg)

    Если заглянуть под капот grub.cfg, типичный пункт меню загрузки Ubuntu или CentOS выглядит примерно так:

    Разберем три ключевые строки, которые определяют судьбу сервера на ближайшие секунды:

  • set root — указывает GRUB, на каком диске и разделе лежат файлы ядра. В данном случае: первый жесткий диск (hd0), второй раздел GPT (gpt2).
  • linux — самая важная строка. Она указывает путь к сжатому файлу ядра (vmlinuz) и передает ему параметры загрузки.
  • initrd — путь к временной файловой системе (initramfs), которая понадобится ядру для загрузки драйверов. Эту концепцию мы подробно разберем через одну главу.

    • Параметры ядра: панель управления системой

    Строка linux не просто указывает путь к файлу. Все, что написано после пути к ядру — это Kernel Command Line (командная строка ядра). Это инструкции, которые ядро прочитает в первую секунду своей жизни.

    > Параметры ядра — это ваш главный инструмент диагностики на этапе загрузки. Изменив их прямо в меню GRUB, можно спасти сервер, который отказывается загружаться.

    Рассмотрим стандартные параметры:

  • root=UUID=... — указывает ядру, где находится настоящий корневой раздел с операционной системой, который нужно смонтировать.
  • ro (read-only) — приказывает ядру смонтировать корневой раздел в режиме «только чтение». Это защитная мера: пока ядро не проверит диск на ошибки, записывать на него небезопасно. Позже система сама перемонтирует его в режим чтения-записи (rw).
  • quiet — скрывает поток отладочных текстовых сообщений ядра (тот самый «бегущий текст» хакеров из кино).
  • splash — показывает красивую графическую заставку с логотипом дистрибутива вместо черного экрана.

    • Траблшутинг на лету

    Если сервер зависает при загрузке, системный администратор может нажать клавишу e в меню GRUB и временно отредактировать строку linux.

    | Проблема | Что изменить в GRUB | Результат | | :--- | :--- | :--- | | Сервер зависает на логотипе, причина неизвестна | Удалить quiet splash | На экран выведется подробный лог (dmesg). Вы увидите, на каком именно драйвере или службе споткнулось ядро. | | Черный экран после обновления драйверов видеокарты | Добавить nomodeset | Запрещает ядру загружать графические драйверы видеокарты. Система загрузится в базовом текстовом режиме, позволяя удалить сбойный драйвер. | | Забыли пароль root / система сломана | Добавить init=/bin/bash | Ядро не будет запускать систему инициализации (systemd), а сразу выдаст вам командную строку с правами суперпользователя. |

    !Симуляция редактирования параметров ядра в GRUB

    !Диагностика сбоя графики

    Передача управления

    После того как вы выбрали пункт меню (или истек таймаут по умолчанию), GRUB выполняет свою финальную задачу:

  • Читает файл vmlinuz с диска и копирует его в оперативную память.
  • Копирует в память файл initrd (временную файловую систему).
  • Сохраняет строку параметров ядра в специальный регистр процессора.
  • Выполняет инструкцию процессора JMP (jump) на стартовый адрес ядра в оперативной памяти.

    • В этот момент GRUB выгружается из памяти. Он больше не существует. Управление сервером полностью и безвозвратно переходит к ядру Linux. О том, как ядро распаковывает себя и делает первые шаги, мы поговорим на следующем этапе.