Что сервер успевает сделать между подачей питания и появлением GRUB

MAATRIX

Вы подключаетесь по KVM-консоли к только что перезагруженному серверу и видите чёрный экран с бегущими строками ещё до того, как появляется знакомое меню GRUB с вариантами ядер. Кажется, что это пустая формальность — доля секунды между «включили» и «загружается ОС». На деле там происходит отдельный, самостоятельный этап работы, у которого своя логика, свои ошибки и своя причина существовать. Разберём по шагам, что успевает сделать сервер до того, как GRUB вообще получает шанс появиться на экране.

Первый актёр — не операционная система, а прошивка платы

Когда на сервер подаётся питание, процессор не «знает», что делать: у него нет операционной системы, нет загруженного кода, вообще ничего в оперативной памяти. Первая инструкция, которую он выполняет, зашита не на диске, а в отдельной микросхеме на материнской плате — это прошивка: классический BIOS (Basic Input/Output System) или его современная замена UEFI (Unified Extensible Firmware Interface). Она физически не зависит от того, какая операционная система стоит на дисках сервера и стоит ли она вообще.

Важно сразу развести две вещи, которые в разговоре часто путают:

• Прошивка платы (BIOS/UEFI) — код, который стартует первым, проверяет железо и передаёт управление дальше. Живёт в микросхеме на материнской плате.
• Загрузчик ОС (GRUB, systemd-boot и другие) — код, который прошивка находит и запускает уже после себя. Живёт на диске, в специальном разделе или секторе.

GRUB — это не первый этап загрузки, а один из последних. Прежде чем он вообще появится на экране, прошивка успевает выполнить собственный, довольно объёмный цикл работы. Ниже — что именно.

POST: самотестирование железа

Первое, что делает прошивка после включения питания — POST (Power-On Self-Test), самотестирование оборудования. Это не проверка «работает ли Linux» — на этом этапе никакой ОС ещё не существует в памяти сервера. POST проверяет исправность самого железа на минимально необходимом уровне:

• отвечает ли процессор и в каком он режиме;
• есть ли модули оперативной памяти, инициализируются ли они, нет ли базовых ошибок чтения/записи;
• видит ли прошивка встроенные контроллеры платы — SATA/NVMe, сетевые интерфейсы, USB-контроллер;
• нет ли явных сигналов неисправности от датчиков платы.

Если POST находит критическую проблему — например, ни одного модуля памяти, — сервер обычно не идёт дальше: раздаётся серия коротких сигналов через системный динамик (если он физически распаян на плате) или прошивка останавливается с кодом ошибки на экране/в логе IPMI. Конкретные коды сигналов различаются между производителями плат (AMI, Award, Phoenix, серверные вендоры вроде Dell/Supermicro/HPE со своими схемами), поэтому для точной расшифровки нужно смотреть документацию именно на вашу материнскую плату или BMC-контроллер, а не полагаться на общую таблицу из интернета.

На арендованном выделенном сервере вы обычно не слышите эти сигналы физически — зато их часто видно в логе management-контроллера (IPMI/iDRAC/iLO), если POST застрял или завершился с ошибкой. Про то, как этим пользоваться, когда SSH ещё недоступен, отдельно рассказано в статье про IPMI и удалённое управление железом.

Если POST прошёл успешно, прошивка переходит к следующему шагу — инициализации железа, которое понадобится для дальнейшей загрузки.

Инициализация: что прошивка включает, а что — нет

После самотестирования прошивка не поднимает *всё* железо сервера сразу — это работа операционной системы и её драйверов. Задача прошивки на этом этапе куда более узкая: подготовить минимальный набор устройств, без которых саму загрузку не начать.

Как правило, речь идёт о:

• контроллере оперативной памяти — таймингах, объёме, режиме работы;
• базовой инициализации процессора — количестве ядер, частоте, включении нужных режимов работы;
• дисковых контроллерах (SATA/SAS/NVMe/RAID-контроллер) в объёме, достаточном, чтобы прошивка могла прочитать данные с диска;
• видеовыходе или последовательном порте — чтобы вообще было куда выводить сообщения (при удалённой аренде это часто виртуальный экран, который транслируется через IPMI/KVM-over-IP);
• клавиатуре/USB — на случай, если понадобится войти в меню настроек прошивки.

Полноценную инициализацию сетевых карт, GPU, дополнительных PCIe-устройств, файловых систем и всего остального берёт на себя уже операционная система после запуска — прошивке это не нужно, если только вы не грузитесь по сети (PXE) или карта не участвует в самом процессе поиска загрузочного устройства.

Именно поэтому на серверах с RAID-контроллером или большим количеством NVMe-дисков инициализация иногда занимает заметно больше времени, чем на простой машине с одним SSD: RAID-контроллер может сканировать состояние массива и опрашивать диски ещё до передачи управления дальше.

Как прошивка находит загрузочное устройство

Когда минимальный набор железа готов, прошивка переходит к следующей задаче — понять, откуда грузиться. У неё нет «интуиции», она следует заданному порядку загрузочных устройств (boot order), который либо задан по умолчанию производителем платы, либо настроен вами вручную в меню прошивки (обычно попадают туда клавишей Del, F2, F10, F11 или F12 — конкретная клавиша зависит от производителя платы).

Boot order — это просто список: диск 1, диск 2, USB, сеть (PXE) — в том порядке, в котором прошивка будет пробовать их опросить. Она идёт по списку и на каждом устройстве проверяет: есть ли на нём загрузочный код, распознаваемый прошивкой.

• В режиме Legacy BIOS — прошивка ищет на устройстве стандартную сигнатуру загрузочного сектора (два байта 0x55AA в конце первых 512 байт диска). Если сигнатура есть — устройство считается загрузочным, прошивка передаёт управление коду из этого сектора. Если сигнатуры нет — переходит к следующему устройству в списке.
• В режиме UEFI — прошивка ищет не сектор, а файл: она умеет читать файловую систему FAT на специальном служебном разделе ESP (EFI System Partition) и ищет там исполняемый EFI-файл загрузчика по определённому пути (например, \EFI\BOOT\BOOTX64.EFI для загрузки по умолчанию или конкретную запись из своего собственного списка загрузочных пунктов NVRAM).

На арендованном сервере или VPS порядок загрузки чаще всего управляется через панель хостинга или консоль IPMI, а не физическим входом в BIOS с клавиатурой — это удобно, когда нужно временно поставить загрузку с ISO-образа для переустановки системы, а потом вернуть обратно на диск.

Legacy BIOS: MBR и загрузочный сектор без посредников

Классическая схема BIOS работает по разметке диска MBR (Master Boot Record). Идея простая и старая, ей несколько десятилетий:

• В первых 512 байтах диска лежит MBR: таблица разделов (до 4 первичных разделов) плюс небольшой кусочек исполняемого кода — тот самый загрузочный сектор.
• BIOS не разбирается в файловых системах вообще. Он просто загружает эти 512 байт в память и передаёт им управление, ничего не понимая про содержимое диска дальше.
• Дальше уже сам этот маленький код (обычно это первая стадия загрузчика, например GRUB в режиме BIOS-совместимости) знает, как найти следующую стадию — например, прочитать более крупный загрузочный образ из зарезервированного пространства между MBR и первым разделом или напрямую обратиться к разделу /boot.

Ограничения этой схемы известны и вполне реальны: MBR поддерживает не более 4 первичных разделов (обходится через расширенные разделы, что усложняет схему), а адресация диска в классическом MBR ограничена 2 ТиБ. Именно поэтому Legacy BIOS плохо совместим с современными большими дисками и постепенно уходит со сцены — но на массе существующих серверов, особенно с уже установленными системами, он всё ещё встречается и прекрасно работает.

UEFI: умнее, потому что понимает файловые системы

UEFI устроен принципиально иначе — и именно это его главное отличие от BIOS, а не просто «более новый графический интерфейс настроек», как иногда думают.

Ключевая разница: UEFI умеет самостоятельно читать файловую систему (обычно FAT32 на разделе ESP) и находить там конкретный исполняемый файл загрузчика — а не просто выполнять код из первого попавшегося сектора вслепую. Из этого вытекает всё остальное:

• Разметка диска — GPT (GUID Partition Table) вместо MBR: нет практического ограничения на количество разделов, снят лимит в 2 ТиБ, у каждого раздела есть уникальный идентификатор и явно помеченный тип.
• Загрузчиков может быть несколько одновременно — прошивка хранит список записей в собственной энергонезависимой памяти (NVRAM) и позволяет выбирать, какую запускать. Отсюда, например, возможность иметь на одном диске загрузку и Linux, и Windows, аккуратно разведённых по записям в этом списке.
• Поддерживается Secure Boot — проверка цифровой подписи загрузчика и ядра ещё до того, как им передано управление. Если подпись не совпадает с доверенным сертификатом, прошивка вправе отказаться запускать такой код. Подробно, когда это действительно нужно, а когда только мешает, разобрано в статье про UEFI и Secure Boot.
• UEFI умеет работать с сетевой загрузкой (PXE), некоторыми базовыми драйверами устройств ещё на этапе прошивки и предоставляет загрузчику более богатое окружение, чем голый BIOS-прерывания старого стиля.

На практике для администратора сервера это означает: UEFI попросту "видит" диск не как безликую последовательность байт, а как размеченное пространство с файлами — что и позволяет ему находить нужный загрузчик надёжнее и гибче, без хрупкой зависимости от одного 512-байтного сектора.

Проверить, в каком режиме реально загрузилась текущая система, можно на живом Linux-сервере командой:

ls /sys/firmware/efi

Если каталог существует и не пуст — система загружена в режиме UEFI. Если каталога нет — сервер работал через Legacy BIOS. Список текущих UEFI-записей загрузки и их порядок показывает утилита efibootmgr (устанавливается пакетом efibootmgr в большинстве дистрибутивов):

efibootmgr -v

Момент передачи управления: где заканчивается прошивка и начинается GRUB

Как только прошивка нашла подходящее загрузочное устройство и загрузочный код на нём (загрузочный сектор в случае BIOS или EFI-файл в случае UEFI), она делает последнее, что от неё требуется: передаёт управление процессором этому коду и, по сути, отходит в сторону. С этого момента прошивка больше не участвует в процессе — вся дальнейшая логика на совести загрузчика.

Именно тут в дело вступает GRUB (GRand Unified Bootloader) — самый распространённый загрузчик в мире Linux-серверов. Он читает свой конфиг (обычно /boot/grub/grub.cfg, сгенерированный автоматически из /etc/default/grub и скриптов в /etc/grub.d/), строит то самое знакомое меню выбора ядра и параметров загрузки, и уже после выбора (или по таймауту) загружает ядро Linux и передаёт управление ему.

С точки зрения времени это разделение на два независимых этапа объясняет разброс в ощущениях "долго грузится сервер": если завис POST или инициализация RAID-контроллера — вы вообще не увидите GRUB, проблема ещё до него. Если же GRUB появляется быстро, а дальше система долго стартует — вопрос уже не к прошивке, а к тому, что происходит после передачи управления ядру и systemd. Этот следующий этап — отдельная большая тема, разобранная в статье как работает systemd при загрузке.

На выделенном арендованном сервере увидеть весь этот процесс — от POST до появления GRUB — можно только через консоль вне операционной системы: обычный SSH здесь бессилен, поскольку до старта ОС никакого SSH-сервера физически ещё не существует. Именно для этого на серверах и предусмотрен KVM-доступ или IPMI: подробнее о том, как им пользоваться, — в статье KVM-доступ к серверу: зачем и как.

Частые вопросы