Строка Uncompressing Linux... done, booting the kernel на чёрном экране означает, что загрузчик успешно распаковал сжатый образ ядра в оперативную память и передал ему управление — если дальше ничего не происходит, проблема почти всегда находится уже на этапе инициализации ядра, а не в загрузчике. Это сообщение характерно для систем с GRUB, U-Boot и Syslinux: на настольных ПК, одноплатных компьютерах вроде Raspberry Pi, роутерах и встраиваемых устройствах.
Сама по себе эта надпись — не ошибка, а штатный этап загрузки. Ядро Linux распространяется в сжатом виде (форматы gzip, lz4, zstd и другие), и перед стартом его нужно распаковать. Слово «done» подтверждает, что распаковка завершилась успешно, поэтому зависание после неё указывает на сбой в самом ядре, его параметрах или оборудовании. Ниже разберём, как локализовать причину и что проверять в первую очередь.
Что происходит на этом этапе загрузки
Последовательность старта выглядит так: прошивка (BIOS/UEFI или загрузчик платы) находит загрузчик, тот читает сжатый образ ядра vmlinuz и файл initramfs, распаковывает ядро в память и передаёт ему управление вместе с параметрами командной строки. Далее ядро инициализирует процессор, память, драйверы устройств, монтирует корневую файловую систему и запускает первый процесс — init или systemd.
Зависание сразу после «booting the kernel» означает, что ядро либо упало на ранней инициализации, либо работает, но не выводит сообщения на экран. Второй случай встречается часто: система фактически загружается, просто консоль настроена не на тот видеовыход или последовательный порт.
Сообщение «done, booting the kernel» — признак успешной распаковки ядра. Искать причину зависания нужно в параметрах ядра, initramfs или оборудовании, а не в загрузчике.
Типичные причины зависания
Чтобы не действовать вслепую, полезно понимать, какие неисправности чаще всего проявляются именно на этом этапе:
- 🖥️ Неверные параметры консоли — ядро выводит лог на последовательный порт (
console=ttyS0) или отключённый видеоадаптер, и экран остаётся пустым. - 💾 Повреждённый или несовместимый initramfs — образ собран под другое ядро или не содержит нужных драйверов дискового контроллера.
- 🧩 Несовместимость ядра с оборудованием — новое ядро после обновления конфликтует с видеокартой, чипсетом или проприетарным модулем.
- ⚙️ Ошибки в параметрах загрузки — неверный
root=, опечатки вcmdline.txtна Raspberry Pi или в конфигурации GRUB. - 🔌 Неисправность носителя или памяти — битая SD-карта, ошибки ОЗУ, нестабильное питание платы.
Какая из причин ваша — подскажет поведение системы: полная тишина и чёрный экран чаще указывают на консоль или видеовыход, а зависание с мигающим курсором или последующей перезагрузкой — на панику ядра.
Диагностика: включаем подробный вывод ядра
Первый осмысленный шаг — заставить ядро говорить. Для этого нужно изменить параметры загрузки. В GRUB нажмите e на выбранном пункте меню, найдите строку, начинающуюся с linux, и отредактируйте её. Уберите «тихие» параметры и добавьте отладочные:
убрать: quiet splash
добавить: loglevel=7 earlyprintk=vga ignore_loglevel
После правки нажмите Ctrl+X или F10 для загрузки. Ядро начнёт выводить подробный лог, и последние строки перед зависанием укажут на проблемный драйвер или подсистему. На одноплатных компьютерах аналогичные параметры правятся в файле cmdline.txt на загрузочном разделе — его можно отредактировать с другого компьютера, вставив SD-карту в картридер.
⚠️ Внимание: правки в меню GRUB через клавишуeдействуют только на одну загрузку и не сохраняются — это безопасный способ экспериментировать. А вот постоянные изменения в/etc/default/grubтребуют последующего выполненияupdate-grub, и ошибка в синтаксисе может усложнить следующую загрузку. Перед правкой сохраните копию файла.
☑️ Базовая диагностика зависания на «booting the kernel»
Загрузка предыдущего ядра и проверка initramfs
Если зависание началось после обновления системы, самая вероятная причина — новое ядро. В меню GRUB откройте раздел Advanced options и выберите предыдущую версию ядра. Если система с ним стартует нормально, конфликт подтверждён: можно остаться на рабочей версии и дождаться исправления, либо разбираться с конкретным модулем.
Отдельная история — повреждённый initramfs. Этот образ содержит модули, необходимые ядру для доступа к диску. Пересоздать его можно из рабочей системы или из chroot-окружения с LiveUSB командой вида:
update-initramfs -u -k allТочная команда зависит от дистрибутива: в Debian и Ubuntu используется update-initramfs, в Fedora и RHEL — dracut, в Arch — mkinitcpio. Сверьтесь с документацией вашей системы, прежде чем запускать пересборку.
Особенности одноплатных компьютеров и встраиваемых систем
На Raspberry Pi, платах с U-Boot и сетевом оборудовании картина та же, но инструменты диагностики другие. Ключевой метод — подключение UART-адаптера к отладочному последовательному порту: именно туда ядро платы чаще всего выводит лог, даже когда HDMI молчит. Скорость порта и распиновка указаны в документации конкретной платы — универсальных значений нет.
Частые причины на одноплатниках: повреждённая SD-карта (проверяется записью свежего образа фирменной утилитой), недостаточный блок питания и несовместимый device tree — файл описания оборудования, который загружается вместе с ядром. Если вы обновляли систему вручную или копировали файлы ядра с другой платы, проверьте, что .dtb соответствует вашей ревизии платы.
Перед записью нового образа на SD-карту сделайте её полный дамп через dd или аналогичную утилиту — так вы сохраните данные и сможете сравнить конфигурацию до и после сбоя.
Сравнение сценариев: где искать проблему
Свести симптомы и вероятные причины помогает таблица:
| Симптом после «booting the kernel» | Вероятная причина | Первое действие |
|---|---|---|
| Полностью чёрный экран, нет реакции | Вывод консоли не на тот порт/видеоадаптер | Убрать quiet, проверить параметр console= |
| Зависание с мигающим курсором | Паника ядра без вывода на экран | Включить loglevel=7, смотреть лог |
| Началось после обновления системы | Новое ядро или initramfs | Загрузить предыдущее ядро из GRUB |
| Ошибка монтирования root / аварийная консоль | Неверный root= или битый initramfs | Проверить UUID корня, пересобрать initramfs |
| Зависание на одноплатнике, HDMI молчит | Лог уходит в UART, несовместимый DTB | Подключить UART-адаптер, проверить .dtb |
⚠️ Внимание: при подключении UART-адаптера к плате строго соблюдайте уровни напряжения (обычно 3,3 В) и не подключайте линию питания адаптера, если плата уже запитана — несоблюдение может вывести порт или плату из строя. Распиновку сверяйте с официальной документацией именно вашей модели.
Что такое device tree и почему он важен
Device tree (dtb-файл) — это описание аппаратной конфигурации платы: какие у неё контроллеры, на каких адресах, какие GPIO за что отвечают. Ядро не умеет «угадывать» оборудование на ARM-платах, как на ПК, поэтому несовместимый или устаревший dtb приводит к зависанию на раннем этапе инициализации. Файл должен соответствовать и версии ядра, и ревизии платы.
Проверка оборудования и носителей
Если программные методы не помогают, переходите к железу. На ПК имеет смысл прогнать память утилитой Memtest86+ — она доступна прямо из меню загрузки многих дистрибутивов. Ошибки ОЗУ часто маскируются под случайные зависания ядра.
Носитель тоже под подозрением: проверьте SMART диска с LiveUSB, а SD-карту — записью заведомо рабочего образа. На устройствах с импульсными блоками питания стоит попробовать другой адаптер: просадки напряжения под нагрузкой при инициализации ядра — известная причина загадочных зависаний одноплатников.
Диагностика идёт от простого к сложному: параметры загрузки → предыдущее ядро → initramfs → носитель и память → питание и периферия. Не начинайте с перепрошивки или переустановки, пока не проверены обратимые варианты.
FAQ: частые вопросы
Это сообщение — ошибка или нормальный этап загрузки?
Это штатное сообщение: оно означает, что загрузчик распаковал ядро и передал ему управление. Ошибкой является только зависание после него, а не сама строка.
Экран чёрный после «booting the kernel», но система, похоже, работает — что делать?
Вероятно, вывод консоли направлен не на ваш монитор. Попробуйте убрать quiet, проверить параметр console= и подключиться к устройству по SSH или через последовательный порт — если система отвечает, проблема только в видеовыводе.
Зависание началось сразу после обновления. Откатиться?
Сначала загрузите предыдущую версию ядра из раздела Advanced options в GRUB. Если она работает, останьтесь на ней и дождитесь исправления в новой версии — это безопаснее, чем принудительный откат пакетов.
Поможет ли переустановка системы?
Переустановка — крайняя мера. В большинстве сценариев достаточно исправить параметры загрузки, пересобрать initramfs или заменить носитель. Переустанавливать имеет смысл только при подтверждённом повреждении системных файлов.
Как посмотреть лог прошлой неудачной загрузки?
После успешного старта системы с журналом systemd выполните journalctl -b -1 -e — команда покажет лог предыдущей загрузки с конца, где обычно видно причину сбоя. Команда работает, только если журнал сохраняется на диск.