Сервер падает в самый ранний момент загрузки с сообщением о недоступном корне, паникой ядра или бесконечным ожиданием устройства - и часто источник проблемы не в самом диске, а в образе initramfs, который не смог подготовить систему к старту. Пересборка этого образа из спасательного окружения решает большинство таких случаев за полчаса. Разбираем полный workflow: диагностику источника отказа, монтирование системы из live-образа, корректный chroot со всеми служебными слоями, пересборку initramfs с нужными модулями и восстановление загрузчика в придачу.
Как понять что проблема именно в initramfs
Признаки повреждённого initramfs узнаваемы по первым строкам на экране. Первый симптом - ядро паникует с сообщением вида unable to mount root fs или device not found, хотя диск физически на месте и биография разделов выглядит нормально. Второй - загрузка уходит в emergency shell уже на ранней стадии с жалобами на отсутствующие модули. Третий - после обновления ядра система внезапно перестала грузиться, хотя до обновления работала: обновления затрагивают именно initramfs, и неудачный mkinitcpio или dracut - типичный источник.
Проверка из live-среды подтверждает диагноз за минуты: если разделы видны, файловая система монтируется и повреждений диска нет, но система отказывается стартовать - причина почти наверняка в образе, и следующий раздел описывает лечение. Список причин повреждения невелик: прерванное обновление ядра, нехватка места в /boot, кривые хуки при ручной правке, рассинхронизация версии ядра и модулей.
Подготовка live-окружения и монтирование
Грузимся с SystemRescue или установочного образа в режиме live, поднимаем сеть при необходимости и осматриваем раскладку: lsblk показывает все разделы, и задача - правильно опознать корневой и, при UEFI, раздел EFI. Монтирование выполняется в /mnt: корневой раздел монтируется первым, затем создаются подкаталоги для служебных слоёв и монтируются остальные - /boot как отдельный раздел, если он есть, и /boot/efi для EFI-раздела.
На системах с LVM перед монтированием корня активируются группы томов: vgchange -ay - и после этого /dev/mapper/имя-группы становится доступным как обычное блочное устройство. На системах с LUKS корень сначала открывается: cryptsetup open /dev/sdXn имя, и монтируется уже /dev/mapper/имя. Оба шага стандартны, и именно на них тратится большинство времени новичков, потому что без активации слоёв корень просто не виден.
Chroot со всеми слоями
Грубый chroot /mnt даёт рабочую оболочку, но часть операций - от обновления загрузчика до grub-install - требует смонтированных виртуальных файловых систем. Каноническая последовательность: mount --bind /dev /mnt/dev, mount --bind /proc /mnt/proc, mount --bind /sys /mnt/sys, и в придачу mount --bind /run /mnt/run для сред, где он нужен. После этого chroot /mnt открывает полноценное окружение, в котором работают uname, пакеты и генераторы initramfs без странностей.
Проверка окружения перед работой: cat /etc/os-release подтверждает, что мы в целевой системе; df -h показывает смонтированные разделы; ls /boot - наличие образов initramfs и ядра. Тридцать секунд осмотра предотвращают самый досадный сценарий - пересборку в неправильном дереве.
Пересборка initramfs и обновление загрузчика
Дальше всё зависит от дистрибутива, и команды стоит произносить по памяти. На Debian и Ubuntu: update-initramfs -u -k all пересобирает образы для всех установленных ядер. На RHEL-семействе: dracut --force --regenerate-all. На Arch: mkinitcpio -P. Все команды читают конфигурацию генератора - /etc/mkinitcpio.conf, /etc/dracut.conf.d, /etc/initramfs-tools - и если отказ был вызван кривой правкой конфигурации, сейчас момент её исправить.
Если нехватка места в /boot была причиной, сначала освобождаем раздел: старые ядра удаляются пакетным менеджером, а не вручную, чтобы сохранить согласованность базы пакетов. Затем пересборка, и её стоит сопровождать проверкой результата: свежий образ появился в /boot с актуальной датой, размер в разумных пределах, а файловая система раздела не заполнена под завязку.
Финальный шаг - обновление загрузчика: update-grub на Debian-семействе или grub2-mkconfig -o /boot/grub2/grub.cfg на RHEL. На UEFI-системах при подозрении на сломанную загрузочную запись grub-install повторно ставит файлы на ESP с указанием --efi-directory=/boot/efi. Выходим из chroot, отмонтируем слои в обратном порядке и перезагружаемся.
Разбор отказов по строкам загрузки
Если после пересборки система всё равно не стартует, чтение первых экранов текста указывает следующий шаг. Сообщение о неизвестном root device проверяется в конфигурации загрузчика - верен ли UUID в root=. Жалоба на отсутствующий модуль проверяется в конфигурации генератора - входит ли нужный модуль в список. Паника с упоминанием конкретной файловой системы намекает на то, что модуль fs не попал в образ: dracut добавляет его через add-drivers, mkinitcpio - через MODULES.
Отдельный случай - рассинхронизация ядра и модулей: версия ядра в /boot новее, чем каталог /lib/modules, и образ собирается под несуществующее дерево. Лечение - либо доустановка модулей пакеты ядра, либо откат на предыдущее ядро через меню GRUB, где старая запись остаётся доступной через Advanced options.
Профилактика на будущее
Три привычки предотвращают почти все инциденты с initramfs. Первая - контроль свободного места в /boot: раздел забивается незаметно, и алерты на 80% заполнения - дешёвая страховка. Вторая - сохранение предыдущего ядра: пакетные политики, удаляющие все ядра кроме одного, экономят место ценой аварийных сценариев; минимум два ядра в системе - гигиеническая норма. Третья - проверенный runbook: однажды проделанный путь записывается по шагам, и следующая авария решается по бумажке за десятую долю времени.
Памятка из восьми шагов
Итоговая последовательность: live-загрузка, осмотр через lsblk, активация LVM и LUKS при наличии, монтирование корня и /boot/efi, bind-mount виртуальных слоёв, chroot, пересборка initramfs командой своего дистрибутива, обновление загрузчика, аккуратный выход с перезагрузкой. Каждый шаг отвечает за один слой системы, и в этой прозрачности - главная ценность процедуры: даже незнакомый сервер раскрывается как понятная конструкция, которую можно починить, не угадывая.
Тонкости с LVM и LUKS в деталях
Слои хранения - самое частое место, где воспроизводимый сценарий буксует, поэтому разберём их внимательно. LVM: после загрузки live-системы vgchange -ay активирует все группы томов, и корень обычно монтируется из /dev/mapper/vg-root или подобного имени. Если группы не видны, проверяется pvscan: он покажет физические тома, и если они с именами из старой системы, активация всё равно сработает, потому что LVM ищет метаданные на самих устройствах.
LUKS: диск открывается командой cryptsetup open /dev/sdXn имя, где имя - любое удобное имя маппера, дальше монтируется /dev/mapper/имя. Для систем с двумя ключами - например root и swap оба зашифрованы - открытие выполняется для каждого. В сложных конфигурациях с LVM поверх LUKS порядок строгий: сначала cryptsetup, потом vgchange, и только затем монтирование.
RAID-массивы mdadm: если корень лежит на программном RAID, массивы собираются автоматически при наличии метаданных, но проверить стоит через cat /proc/mdstat, и при необходимости собрать вручную mdadm --assemble --scan. Ничего из этого не страшно по отдельности - страшно только пропустить слой и монтировать не то.
Когда пересборка не помогает
Если после честной пересборки и обновления загрузчика паника повторяется, дело почти всегда в одном из трёх мест. Первое - конфигурация генератора: хук или модуль, необходимый для корня, исключён из образа, и читается это прямо в конфигурационных файлах, где строки hooks или modules перечисляют состав. Второе - само ядро: обновление поставило версию, криво собранную для этого железа, и решение - загрузка в старое ядро из Advanced options с последующим откатом проблемного пакета. Третье - конфигурация загрузчика: неверный UUID корня в root=, и правка строки через grub.cfg генератором - правильный путь, а ручное редактирование только для разовой загрузки.
Диагностика упрощается доступом к консоли: экран паники содержит имя устройства, на котором ядро искало корень, и сравнение этого имени с выводом lsblk из live-системы даёт точный ответ, где именно разошлись ожидания и реальность.
Проверка после восстановления
Успешная перезагрузка - только полдела; следом выполняется короткая проверка. Вошли в систему - просмотрели journalctl -b на предмет ошибок. Проверили uname -r - загружено ожидаемое ядро. Проверили наличие свежего образа в /boot и свободного места в разделе. Прогнали systemctl --failed на предмет служб, не поднявшихся после ремонта. Эти пять минут закрывают цикл: ремонт считается завершённым не когда появился экран логина, а когда подтверждено, что все слои системы работают.
Скрипт-заготовка для повторяющихся случаев
Там, где парк однороден, имеет смысл один раз собрать скрипт rescue-repair.sh, выполняющий монтирование слоёв и chroot по одной команде, и хранить его на спасательной флешке. Скрипт на двадцать строк снимает половину шагов процедуры и убирает риск опечатки в длинных путях, а разбирается он быстрее, чем читается документация. Скрипт не заменяет понимания - но человеку, который один раз прошёл путь вручную, он ускоряет все последующие прохождения.
История из практики
Типичный сценарий: ночное обновление ядра на файловом сервере остановилось посередине из-за переполненного /boot, и утром сервер встретил дежурного паникой. Раскладка - LVM поверх обычного раздела, live-система с SystemRescue, монтирование vg, chroot, очистка старых ядер пакетным менеджером, update-initramfs -u -k all, update-grub, перезагрузка. Суммарно тридцать минут - и файловый сервер снова раздаёт шары до того, как пользователи заметили перерыв. В таких историях нет героизма - есть знание процедуры и спасательная флешка, которые в совокупности и есть готовность.
Замыкающий принцип
Вся тема initramfs держится на одном понимании: это мост между ядром и корневой системой, и чинится он точно так же, как мост, - со стороны, снизу, спокойно. Диагноз по первым экранам, монтирование слоёв, честный chroot, пересборка генератором, обновление загрузчика, проверка после старта - каждый шаг воспроизводим, документирован и отработан тысячами инженеров до вас. Чем раньше эти шаги лягут в вашу память, тем короче будет ваш следующий аварийный вечер.
И последний совет всем, кто впервые проходит этот путь: не спешите на перезагрузку. Перечитайте пять команд перед их выполнением, сверьтесь с lsblk дважды и убедитесь, что монтируете именно целевой раздел. В процедурах восстановления зрелость проявляется не в скорости, а в количестве ошибок, которых удалось избежать, - а ошибок здесь легко избежать все, если каждый шаг сверяется с реальностью.
Одна строка для памяти перед перезагрузкой
Перед самым выходом из chroot опытные инженеры выполняют контрольный из трёх проверок: свежий образ initramfs лежит в /boot, конфигурация загрузчика содержит правильный UUID корня, файловые системы размонтированы без ошибок. Тридцать секунд этих проверок - страховка от повторения всей процедуры, потому что перезагрузка в нерабочую систему означает второй заход с live-носителем и снова все слои монтирования.
С этой дисциплиной даже первая в карьере пересборка initramfs проходит без драмы - просто потому, что каждый шаг проверяем и предсказуем.
Удачной починки - и пусть ваши initramfs собираются с первого раза всегда.
Пусть эта памятка ждёт своего часа в runbook - и пусть он не наступит раньше, чем через много лет.