Debian/Ubuntu: Kernel panic not syncing: VFS: Unable to mount root fs on unknown-block

Сообщение Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(...) означает, что ядро Linux уже стартовало, но не смогло подключить корневую файловую систему. Для администратора это одна из самых неприятных загрузочных ошибок: сервер не поднимается, SSH недоступен, а причина может скрываться как в неверном UUID, так и в сломанном initramfs, обновлении ядра, драйверах контроллера диска или повреждении самой файловой системы.

На Debian и Ubuntu сценарии обычно повторяются: после обновления ядра система перестаёт загружаться, после клонирования диска меняются UUID, после ручного редактирования /etc/fstab и параметров GRUB корень становится недоступен, а после аварийного выключения внезапно выясняется, что проблема уже не в загрузчике, а в файловой системе.

Хорошая новость в том, что ошибка почти всегда поддаётся системной диагностике. Плохая — лечить её наугад опасно. Если бездумно пересобирать пакеты ядра, править конфиги и запускать fsck не на том разделе, можно только ухудшить ситуацию.

Важно понимать этапы загрузки. BIOS или UEFI передаёт управление grub, затем загружается ядро и образ initramfs. После этого ядро должно увидеть устройство с корневой файловой системой, распознать драйвер контроллера, найти нужный раздел по UUID или имени устройства и смонтировать его как /. Если на любом из этих шагов доступ к корню теряется, вы и видите unable to mount root fs.

Числа внутри unknown-block(x,y) тоже иногда полезны. Например, unknown-block(0,0) нередко указывает, что ядро вообще не смогло сопоставить указанный root с блочным устройством. Значения вроде unknown-block(8,1) часто означают, что тип устройства найден, но конкретный раздел или файловая система недоступны.

Что обычно ломается

На практике причины можно сгруппировать в несколько типовых блоков. Если идти по ним последовательно, шанс быстро найти проблему намного выше, чем при хаотичном переборе.

• Неверный параметр root= в строке загрузки ядра.
• Изменившийся или ошибочный UUID в /etc/fstab или в конфигурации grub.
• Повреждённый или неполный initramfs, в котором нет нужных модулей.
• Отсутствие драйверов для контроллера диска, RAID, LVM, NVMe или VirtIO.
• Повреждение файловой системы после сбоя питания или проблем с диском.
• Ошибки в конфигурации LVM, mdadm или LUKS.
• Смена имён устройств: было /dev/sda, стало /dev/vda или /dev/nvme0n1p2.

С чего начать диагностику

Первое правило: не переустанавливайте систему сразу. Даже если это виртуальная машина, в большинстве случаев восстановление занимает меньше времени, чем повторная сборка окружения и возврат сервисов.

Если у вас есть консоль провайдера, IPMI, VNC или rescue-режим — используйте их. При такой ошибке обычный SSH уже не поможет. Самый удобный путь — загрузиться в rescue или live-среду той же архитектуры и близкого дистрибутива.

Дальше нужно ответить на четыре вопроса:

1. Видит ли система диски и разделы?
2. Какой раздел реально является root?
3. Совпадает ли его UUID с тем, что ожидают fstab и grub?
4. Есть ли в initramfs всё необходимое для доступа к этому устройству?

Если ошибка появилась сразу после обновления ядра, сначала подозревайте initramfs и модули. Если после миграции, клонирования или изменения разметки — чаще всего проблема в UUID, fstab или параметре root=.

Для продакшн-серверов на VDS особенно важно иметь доступ к rescue-консоли: без неё разбирать такие падения намного сложнее.

Шаг 1. Найдите корневой раздел и его UUID

Загрузитесь в rescue-среду и посмотрите список устройств. Не полагайтесь на память: имена дисков могли измениться.

lsblk -f
blkid
fdisk -l

Ищите раздел с вашей корневой файловой системой. Обычно это ext4 или XFS, иногда LVM-том. Если используется LVM, дополнительно проверьте:

vgchange -ay
lvscan
pvs
vgs
lvs

Если root находится внутри RAID, активируйте массивы:

cat /proc/mdstat
mdadm --assemble --scan

Если используется шифрование LUKS, сначала откройте контейнер:

cryptsetup luksOpen /dev/sdXn cryptroot
lsblk -f

Когда вы нашли реальный root-раздел, запишите его UUID. Он понадобится для сверки с конфигами.

Шаг 2. Проверьте /etc/fstab

Смонтируйте корневой раздел во временную директорию и проверьте содержимое /etc/fstab. Очень частая причина — старый UUID после клонирования диска, восстановления из снапшота или пересоздания разделов.

mount /dev/sdXn /mnt
cat /mnt/etc/fstab

Если у вас LVM или NVMe, используйте актуальное имя устройства, которое показал lsblk.

Сравните UUID в fstab с тем, что показывает blkid. Особое внимание обратите на строку для /. Ошибка даже в одном символе даёт ровно ту картину, которую вы видите при загрузке.

Если в fstab указан путь вида /dev/sda1, а после смены гипервизора или типа контроллера диск стал /dev/vda1 или /dev/nvme0n1p1, система тоже может не загрузиться. В таких случаях лучше использовать UUID или PARTUUID.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Шаг 3. Проверьте GRUB и параметр root=

Даже если fstab корректен, ядро может получать неверный параметр root= из grub. Тогда до чтения обычного fstab загрузка уже не дойдёт.

Проверьте конфигурацию по умолчанию:

cat /mnt/etc/default/grub

Затем посмотрите фактическую сгенерированную конфигурацию:

grep -R "root=" /mnt/boot/grub/grub.cfg

В нормальном случае там будет что-то вроде root=UUID=.... Этот UUID должен соответствовать настоящему корневому разделу. Если вместо UUID используется имя устройства, а схема дисков менялась, это уже серьёзное подозрение.

Если у вас отдельный /boot, не перепутайте его с корневым разделом. Это частая ошибка: администратор видит знакомый UUID, но это UUID раздела /boot, а не /.

Шаг 4. Проверьте initramfs

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

Типовые сценарии: обновили ядро, но initramfs-tools сработал некорректно; отключился autodetect модулей; используется VirtIO, NVMe, LVM или mdadm, а нужные модули не попали в образ.

Если root-раздел смонтирован в /mnt, подготовьте chroot:

mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt /bin/bash

Посмотрите, какие ядра установлены:

dpkg -l | grep linux-image
ls -lh /boot

Пересоберите initramfs для всех установленных ядер:

update-initramfs -u -k all

Затем пересоздайте конфигурацию GRUB:

update-grub

Если система виртуальная и использует VirtIO-диски, убедитесь, что модули реально доступны. При необходимости можно явно добавить модули:

printf '%s
' virtio_pci virtio_blk virtio_scsi nvme ext4 xfs ahci sd_mod megaraid_sas >> /etc/initramfs-tools/modules
update-initramfs -u -k all

Не добавляйте всё подряд без понимания, но для rescue-сценария включить драйверы реального стека хранения — нормальная практика. Если вы меняли размер раздела или диска перед появлением ошибки, может пригодиться отдельный разбор по теме расширения диска и growpart на VDS.

Шаг 5. Проверьте файловую систему

Если диск и UUID определяются, а загрузка всё равно падает, возможно, ядро не может смонтировать root из-за ошибок файловой системы. Особенно часто это бывает после аварийного выключения, аппаратной ошибки диска или нехватки места в момент обновления.

Для ext4 используйте fsck только на размонтированном разделе:

umount /mnt
fsck -f /dev/sdXn

Для XFS логика другая: обычный fsck не применяется, используется xfs_repair. Если root на XFS, действуйте особенно аккуратно и не запускайте команды по аналогии с ext4.

Если файловая система исправилась и монтируется вручную, но загрузка по-прежнему невозможна, возвращайтесь к связке initramfs и grub. Нередко это комбинированная проблема.

Шаг 6. Переустановите ядро и GRUB, если проблема появилась после обновления

Иногда пакет ядра установился не полностью, а в /boot лежат несовместимые или неполные файлы. Это часто видно по странному набору версий: есть vmlinuz, но нет свежего initrd.img, либо ссылки указывают не туда.

В chroot можно переустановить текущее ядро:

apt update
apt install --reinstall linux-image-amd64 initramfs-tools grub-pc grub-common

Для Ubuntu метапакет может отличаться:

apt install --reinstall linux-image-generic initramfs-tools grub-pc grub-common

После этого снова обновите initramfs и grub:

update-initramfs -u -k all
update-grub

При BIOS-схеме при необходимости можно заново установить GRUB в диск:

grub-install /dev/sdX
update-grub

Для UEFI сначала убедитесь, что EFI-раздел смонтирован в /boot/efi, и только потом запускайте установку. Иначе можно получить ещё одну загрузочную проблему поверх первой.

Как читать симптомы по контексту

Сама фраза kernel panic not syncing слишком общая. Реальную причину лучше угадывать по тому, что происходило перед падением.

• После обновления ядра — проверяйте initramfs, список модулей и наличие свежего initrd.
• После клонирования VM или миграции диска — проверяйте UUID, fstab и root= в grub.
• После смены типа виртуализации или контроллера — проверяйте драйверы VirtIO, SCSI, NVMe и AHCI.
• После сбоя питания — проверяйте файловую систему и журнал, затем пересобирайте initramfs.
• После изменений в LVM, RAID или шифровании — проверяйте активацию томов и наличие нужных хуков ранней загрузки.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Если система загружается в старое ядро

Это лучший сценарий. Если через меню grub удаётся загрузиться в предыдущее ядро, не перезагружайтесь без диагностики. Сразу соберите данные: какая версия ядра рабочая, какая нет, существует ли образ initrd, есть ли ошибки генерации initramfs в логах dpkg и apt.

uname -r
ls -lh /boot
grep -i initramfs /var/log/dpkg.log
journalctl -b -p warning

Часто достаточно пересобрать образ для проблемной версии ядра и обновить grub. Если старое ядро стабильно грузится, не удаляйте его до полного восстановления.

Типичный порядок восстановления в rescue-режиме

Если свести всё к короткому runbook, получится такой порядок:

1. Загрузиться в rescue или live-среду.
2. Найти root-раздел через lsblk и blkid.
3. Проверить /etc/fstab на корректный UUID.
4. Проверить root= в grub.
5. При необходимости активировать LVM, RAID, LUKS.
6. Смонтировать систему и войти в chroot.
7. Пересобрать initramfs.
8. Пересоздать конфигурацию grub.
9. Проверить файловую систему.
10. Если нужно — переустановить пакет ядра и загрузчик.

Именно такая последовательность помогает не пропустить простой конфликт по UUID и не тратить время на глубокую отладку там, где достаточно одной правки.

Частые ошибки при восстановлении

Есть несколько типичных ловушек, из-за которых администратор делает всё вроде бы правильно, но результата нет.

• Редактирует /etc/fstab не того раздела, потому что смонтировал не тот диск.
• Забывает смонтировать /boot или /boot/efi перед пересборкой загрузчика.
• Делает chroot без bind-монта /dev, /proc и /sys.
• Путает UUID файловой системы и PARTUUID раздела.
• Запускает fsck по смонтированному разделу.
• Исправляет fstab, но забывает обновить grub, где остался старый root UUID.

Если после изменений ошибка не изменилась вообще, чаще всего причина в том, что вы правили не тот корень, не тот initramfs или не ту конфигурацию загрузчика.

Профилактика

Полностью исключить такие сбои нельзя, но их можно сильно упростить для восстановления.

• Держите минимум одно предыдущее рабочее ядро и не удаляйте его сразу после обновления.
• Не используйте имена вроде /dev/sda1 в критичных местах, если можно использовать UUID.
• После изменений в дисковой схеме проверяйте fstab, grub и наличие корректного initramfs.
• Держите доступ к rescue-консоли и проверяйте его заранее.
• Перед обновлением ядра убедитесь, что раздел /boot не переполнен.
• Если инфраструктура виртуальная, делайте снапшот перед рискованными изменениями.

Если серверов много, полезно иметь короткий внутренний документ по схеме хранения: где root, есть ли LVM, mdadm, LUKS, отдельный /boot, какой тип диска у гипервизора. В момент аварии это экономит много времени. Заодно пригодится и смежный материал о том, как уменьшать лишние записи на диск через настройку atime и relatime в Linux.

Когда проблема не в Linux, а в платформе

Иногда Debian или Ubuntu ни при чём. Например, после миграции виртуальной машины меняется тип контроллера, и старое ядро без нужных модулей уже не видит диск. Или в панели виртуализации диск подключён не к той шине. Или snapshot восстановлен неполно.

Особенно это актуально для виртуальных серверов, где переход между SCSI, VirtIO и NVMe меняет набор модулей, нужных на раннем этапе загрузки. Внешне это выглядит как типичный unknown-block, но источник ошибки находится уровнем ниже операционной системы.

Если вы только планируете развёртывание нового проекта, выбирайте площадку с нормальной консолью, rescue-режимом и предсказуемой виртуализацией. Для таких задач удобны как виртуальный хостинг для простых сайтов, так и облачные VDS для систем, где нужен полный контроль над загрузкой и дисковой схемой.

Вывод

Ошибка Kernel panic not syncing: VFS: Unable to mount root fs on unknown-block в Debian и Ubuntu почти всегда сводится к одной из четырёх вещей: неправильный UUID, сломанный initramfs, проблема в grub или недоступный либо повреждённый корневой раздел.

Поэтому лучший способ восстановления — не гадать, а последовательно проверить диск, UUID, конфиги загрузки и ранние модули ядра. Если идти по этой схеме, большинство случаев закрываются без переустановки системы.