GRUB rescue: no such partition в Debian и Ubuntu — как восстановить загрузчик, UUID и initramfs

Сообщение grub rescue> no such partition в Debian и Ubuntu выглядит неприятно, но в большинстве случаев это не катастрофа, а рассинхронизация между реальной разметкой диска и тем, что ожидает загрузчик. Чаще всего проблема появляется после изменения таблицы разделов, переноса системы на другой диск, клонирования виртуальной машины, пересоздания файловой системы или ручной правки /etc/fstab.

С практической точки зрения суть проста: GRUB не может найти раздел, на котором лежат его модули, конфигурация, ядро или initramfs. Поэтому система останавливается в минимальной консоли восстановления.

Ниже разберём рабочий порядок действий: как понять, что именно сломалось, как попробовать временно загрузить систему вручную, как проверить UUID и как корректно восстановить загрузчик из live- или rescue-среды.

Статья рассчитана на Debian и Ubuntu. Шаги для UEFI и legacy BIOS похожи, но не идентичны, поэтому сначала желательно определить режим загрузки вашей системы.

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

Что означает ошибка no such partition в GRUB

GRUB должен найти каталог /boot/grub, загрузить grub.cfg, а затем передать управление ядру Linux и образу initramfs. Если нужный раздел отсутствует, переместился, сменил UUID или стал определяться иначе, появляется сообщение error: no such partition.

На практике это обычно связано с одним из следующих сценариев:

• изменился UUID после форматирования или пересоздания файловой системы;
• диск был клонирован, а конфигурация осталась со старыми идентификаторами;
• раздел /boot был удалён, перемещён или изменил номер;
• поменялся порядок дисков после миграции или изменения настроек виртуальной машины;
• на UEFI-системе недоступен EFI System Partition;
• после обновления ядра возникла проблема с grub.cfg или ранней загрузкой.

Самая частая причина — GRUB ищет систему по старым данным, а фактическая разметка диска уже изменилась.

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

Прежде чем сразу запускать переустановку загрузчика, полезно понять, видит ли GRUB нужные разделы. Если вы уже попали в консоль grub rescue>, начните с базовых встроенных команд.

Посмотреть диски и разделы, доступные GRUB

ls

Обычно в выводе будут устройства вида (hd0), (hd0,gpt1), (hd0,gpt2) или (hd0,msdos1). Затем имеет смысл посмотреть содержимое каждого кандидата:

ls (hd0,gpt1)/
ls (hd0,gpt2)/
ls (hd0,gpt3)/

Ищите раздел, на котором есть /boot, /grub, /vmlinuz, /initrd.img или обычная структура корня Linux-системы. Если такой раздел виден, это уже хороший признак: диск читается, а проблема, скорее всего, в конфигурации.

Когда разделы не видны или выглядят неправильно

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

• изменился режим загрузки BIOS или UEFI;
• повреждена таблица разделов;
• диск не определяется контроллером или гипервизором;
• используются LVM, RAID или LUKS, а необходимых модулей GRUB не хватает.

В таких случаях лучше сразу переходить к загрузке с live-образа или в rescue-среду и проверять систему уже из полноценного shell.

Как временно загрузить систему вручную

Если нужный раздел виден, иногда достаточно вручную подсказать GRUB путь к его модулям. Это полезно, когда надо один раз загрузить систему и затем спокойно починить всё уже из работающей ОС.

Пример для случая, когда каталог /boot/grub расположен на (hd0,gpt2):

set root=(hd0,gpt2)
set prefix=(hd0,gpt2)/boot/grub
insmod normal
normal

Если после этого появилось обычное меню GRUB, загрузите систему и сразу переходите к полноценной проверке конфигурации. Если insmod normal не сработал, проверьте, на том ли разделе вы находитесь и действительно ли каталог называется /boot/grub, а не /grub.

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

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

Подробнее

Проверка UUID и fstab

Когда система загрузилась или вы зашли в live/rescue, первым делом проверьте реальные UUID разделов. Именно здесь чаще всего находится корень проблемы после миграции, клонирования или ручной переразметки.

Посмотреть реальные UUID

blkid
lsblk -f

Сравните полученные значения с тем, что записано в /etc/fstab и используется для разделов /, /boot и /boot/efi.

Проверить файл fstab

cat /etc/fstab

Если в fstab остались старые UUID, система может либо не загрузиться полностью, либо перейти в emergency mode уже после старта ядра. Это не всегда выглядит как ошибка GRUB, но очень часто идёт рядом с ней.

После исправления записей выполните проверку:

mount -a

Если ошибок нет, файл как минимум синтаксически корректен, а указанные устройства доступны.

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

Полное восстановление GRUB из live-среды

Если вручную загрузить систему не удалось, используйте стандартный алгоритм: определить нужные разделы, смонтировать систему, выполнить chroot, затем переустановить GRUB и пересобрать конфигурацию.

1. Найдите корневой, boot и EFI-разделы

lsblk -f
blkid

Типовая схема может выглядеть так:

• /dev/vda2 — корневой раздел /;
• /dev/vda1 — EFI System Partition, смонтирован в /boot/efi;
• или отдельный /dev/vda3 для /boot.

2. Смонтируйте систему и войдите в chroot

Пример для UEFI-системы без отдельного /boot:

mount /dev/vda2 /mnt
mount /dev/vda1 /mnt/boot/efi
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt

Если у вас есть отдельный /boot, сначала смонтируйте его в /mnt/boot, а уже потом EFI-раздел в /mnt/boot/efi.

3. Проверьте точки монтирования

findmnt
ls /boot
ls /boot/grub
ls /boot/efi

Это важный шаг. Часто администратор заходит в chroot, но забывает подключить EFI-раздел, после чего grub-install отрабатывает не так, как ожидалось.

4. Переустановите загрузчик

Для legacy BIOS:

grub-install /dev/vda

Для UEFI:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=debian --recheck

В Ubuntu в параметре --bootloader-id часто используют ubuntu. Смысл от этого не меняется, если EFI-запись создаётся корректно.

5. Пересоберите конфигурацию меню

update-grub

Команда заново найдёт ядра, сформирует актуальный grub.cfg и подставит правильные UUID и пути.

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

Когда нужен update-initramfs

Бывает и так: меню GRUB уже появилось, ядро запускается, но дальше система попадает в busybox или не может найти корневую файловую систему. В таком случае проблема уже не только в самом GRUB, а в ранней загрузке Linux.

initramfs отвечает за начальную инициализацию устройств, модулей, LVM, RAID и поиск root filesystem. Если внутри него устаревшие данные или не хватает нужных модулей, загрузка сломается уже после выбора пункта в GRUB.

Обновить initramfs для текущего ядра

update-initramfs -u

Пересобрать initramfs для всех ядер

update-initramfs -u -k all

После этого имеет смысл ещё раз выполнить:

update-grub

Так вы синхронизируете список ядер, образы initramfs и загрузочное меню.

Отдельные случаи: перенос диска, LVM и RAID

После миграции на другой диск или сервер

При переносе системы меняются не только UUID, но и имена устройств: например, было /dev/sda, стало /dev/vda или /dev/nvme0n1. Современные Debian и Ubuntu обычно опираются на UUID, но если где-то остались жёстко прописанные пути к устройствам, загрузка ломается.

Проверьте:

• /etc/fstab;
• /etc/default/grub;
• параметры ядра в сгенерированном /boot/grub/grub.cfg;
• конфигурацию mdadm, LVM и содержимое initramfs.

Если используется LVM

В rescue-среде перед монтированием может понадобиться активировать группы томов:

vgchange -ay
lsblk -f

После этого уже можно монтировать логический том, например /dev/mapper/vg0-root.

Если используется RAID

На программном RAID важно, чтобы массив был собран до входа в chroot, а в initramfs присутствовала поддержка mdadm. Иначе GRUB может стартовать, но ядро не увидит корневой том.

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

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

Подробнее

Как быстро понять, что именно сломано

Чтобы не чинить всё подряд, удобно разделять симптомы по этапам загрузки:

• если сразу видите grub rescue> и no such partition, проблема обычно на уровне GRUB, разметки или поиска раздела;
• если меню GRUB появляется, но ядро не запускается, проверьте содержимое /boot и корректность путей;
• если ядро стартует, но root filesystem не находится, смотрите UUID, параметры ядра и initramfs;
• если загрузка доходит до emergency mode, часто виноват неверный /etc/fstab.

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

Минимальный runbook восстановления

1. Загрузитесь в live или rescue.
2. Найдите разделы через lsblk -f и blkid.
3. Сверьте UUID с /etc/fstab.
4. Смонтируйте /, при необходимости /boot и /boot/efi.
5. Подключите /dev, /proc, /sys и выполните chroot.
6. Запустите grub-install для вашей схемы загрузки.
7. Выполните update-grub.
8. При необходимости выполните update-initramfs -u -k all.
9. Проверьте содержимое /boot и наличие EFI-записи.
10. Перезагрузите систему и проверьте обычный старт.

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

• установка GRUB не на диск, а на раздел в BIOS-режиме;
• забытый EFI-раздел перед запуском grub-install;
• исправление загрузчика без пересборки initramfs;
• правка fstab без проверки реальных UUID через blkid;
• восстановление из live-образа в другом режиме загрузки;
• игнорирование старых EFI-записей после миграции.

На виртуальных серверах есть ещё одна ловушка: в rescue-среде диск может называться иначе, чем в основной системе. Поэтому ориентироваться только на /dev/vda или /dev/sda опасно — всегда сверяйте UUID и содержимое разделов.

Как снизить риск повторения проблемы

• сохраняйте вывод lsblk -f, blkid и efibootmgr -v в документации;
• после операций с разделами перепроверяйте /etc/fstab;
• после изменений в /boot выполняйте update-grub и при необходимости update-initramfs -u;
• перед миграцией делайте резервную копию /boot, /etc/fstab и EFI-раздела;
• держите под рукой rescue ISO и доступ к консоли провайдера.

Если вы регулярно переносите проекты между серверами, имеет смысл стандартизировать схему разделов и хранить базовый runbook восстановления рядом с документацией окружения. Это экономит массу времени при аварии.

Итоги

Ошибка grub rescue с сообщением no such partition почти всегда упирается в одну из трёх причин: изменившийся UUID, потерянную привязку GRUB к разделам или проблемы на этапе ранней загрузки через initramfs. На практике лечение обычно однотипное: найти реальные разделы, проверить UUID, смонтировать систему, переустановить GRUB, выполнить update-grub и при необходимости пересобрать initramfs.

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