Чёрный экран, зависание на строке Loading initial ramdisk или сообщение no bootable device после перезагрузки сервера — типичные симптомы, при которых Proxmox VE не стартует и гипервизор недоступен ни через веб-интерфейс, ни по SSH. Первое действие в такой ситуации — не переустановка системы, а подключение монитора (или KVM/IPMI-консоли) и фиксация точного текста ошибки: от него зависит весь дальнейший сценарий восстановления.
Проблемы с запуском Proxmox чаще всего связаны с загрузчиком GRUB, состоянием корневой файловой системы (особенно ZFS), сбоями дисков или некорректным обновлением ядра. Ниже разберём диагностику по шагам — от простых проверок к восстановлению загрузчика и пула хранения.
Первичная диагностика: на каком этапе останавливается загрузка
Поведение сервера при включении сразу сужает круг причин. Если машина вообще не проходит POST и не выводит изображение, проблема аппаратная — и она не относится к Proxmox. Если POST проходит, но дальше чёрный экран или приглашение grub rescue>, повреждён загрузчик или его конфигурация. Если ядро начинает грузиться, но процесс останавливается с ошибками монтирования — подозрение падает на файловую систему и диски.
Обратите внимание на характерные стадии сбоя:
- 🔌 Нет изображения вообще — проверяйте питание, планки памяти, видеовыход и настройки BIOS/UEFI.
- 💾 «No bootable device» или возврат в BIOS — слетел порядок загрузки, отвалился диск или повреждён EFI-раздел.
- ⚙️ Меню GRUB есть, но загрузка зависает — вероятна проблема с ядром, initramfs или корневым пулом.
- 🆘 Приглашение initramfs/busybox — система не смогла смонтировать корневой раздел, часто из-за ZFS или сбойного диска.
⚠️ Внимание: не запускайте fsck или команды восстановления вслепую, если сервер использует ZFS. Утилиты для ext4 неприменимы к пулам ZFS и могут усугубить ситуацию. Сначала точно определите тип корневой файловой системы — он был выбран при установке Proxmox.
Проверка BIOS/UEFI и порядка загрузки
После сбоя питания или обновления прошивки настройки BIOS иногда сбрасываются, и сервер перестаёт видеть загрузочный диск. Зайдите в BIOS/UEFI и убедитесь, что диск с Proxmox присутствует в списке устройств и выбран первым в порядке загрузки. Заодно проверьте, не изменился ли режим загрузки: система, установленная в режиме UEFI, не стартует, если переключиться на Legacy/CSM, и наоборот.
Если диск не определяется даже в BIOS, откройте корпус (при выключенном питании) и проверьте SATA/SAS-кабели и разъёмы питания. Для NVMe-накопителей помогает переустановка модуля в слоте. Диск, который не виден на уровне контроллера, невозможно «оживить» программными средствами Proxmox — сначала решайте аппаратный вопрос.
Перед любыми действиями с дисками сфотографируйте текущие настройки BIOS и схему подключения накопителей. Это сэкономит время, если потребуется откатиться к исходному состоянию.
Восстановление загрузчика GRUB
Если диск виден, но загрузка обрывается на этапе GRUB, загрузчик нужно переустановить. Для этого понадобится загрузочный носитель — подойдёт ISO с Proxmox VE (в нём есть режим отладки) или любой Live-дистрибутив Linux. Загрузившись с него, можно подключиться к установленной системе через chroot и переустановить GRUB.
Общая последовательность для системы на ext4/LVM выглядит так: монтируете корневой раздел, привязываете служебные каталоги, входите в chroot и переустанавливаете загрузчик:
mount /dev/pve/root /mnt
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt
grub-install /dev/sda
update-grub
Для систем с UEFI дополнительно монтируется EFI-раздел (обычно небольшой раздел с FAT32) в /boot/efi перед выполнением grub-install. Точные имена устройств зависят от вашей разметки — проверить их можно командой lsblk. Для ZFS-систем процедура отличается: сначала импортируется пул rpool, и только потом выполняется chroot.
☑️ Восстановление GRUB — порядок действий
Проблемы с ZFS: пул rpool не импортируется
Значительная часть случаев «Proxmox не стартует» на серверах с ZFS связана с тем, что корневой пул rpool не импортируется при загрузке. Причины разные: отвалившийся диск в зеркале, повреждение метаданных после аварийного отключения питания, конфликт после замены накопителя. Симптом — падение в initramfs с сообщениями о невозможности смонтировать корень.
Из среды initramfs или Live-системы состояние пула проверяется командой:
zpool import
zpool status rpool
Первая команда показывает доступные для импорта пулы, вторая (после импорта) — состояние виртуальных устройств и наличие ошибок. Если диск в зеркале отказал, пул обычно продолжает работать в деградированном режиме (DEGRADED), и систему можно загрузить, после чего заменить накопитель. Если же видны ошибки UNAVAIL по всем устройствам или повреждение метаданных, потребуется более аккуратное восстановление, а в тяжёлых случаях — развёртывание из резервных копий.
⚠️ Внимание: не используйте zpool import -f и тем более деструктивные флаги восстановления, не убедившись, что пул не используется другой системой и что вы понимаете последствия. Принудительные операции с повреждённым пулом способны окончательно разрушить данные.
Сбой после обновления ядра
Иногда Proxmox перестаёт стартовать сразу после обновления: новое ядро не загружается из-за несовместимости модулей (часто — сторонних драйверов ZFS или сетевых карт, собранных через DKMS) или из-за нехватки места в разделе /boot, из-за чего initramfs записался неполностью. Это один из самых благоприятных сценариев, потому что откат делается штатно.
В меню GRUB откройте раздел Advanced options for Proxmox VE и выберите предыдущую версию ядра из списка. Если система загрузилась, можно удалить проблемное ядро, пересобрать initramfs командой update-initramfs -u -k all и проверить свободное место на загрузочном разделе через df -h /boot. Переполнение /boot старыми ядрами — частая скрытая причина, поэтому периодически очищайте неиспользуемые версии штатным пакетным менеджером.
Если сбой начался сразу после обновления — сначала загрузитесь с предыдущим ядром через меню GRUB. Это самый быстрый и безопасный способ вернуть работоспособность без восстановления загрузчика.
Аппаратные причины: диски, память, питание
Не всякая остановка загрузки — программная. Деградация SSD/HDD, ошибки оперативной памяти и нестабильный блок питания проявляются именно как внезапные отказы при старте системы. Характерные признаки: ошибки ввода-вывода в логах ядра, случайные зависания на разных этапах, повреждение файлов после каждой перезагрузки.
Что стоит проверить в первую очередь:
- 🩺 S.M.A.R.T. дисков — после загрузки с Live-носителя посмотрите атрибуты через
smartctl -a /dev/sdX; рост Reallocated Sector Count или Pending Sectors — тревожный сигнал. - 🧠 Оперативная память — прогон memtest86 с загрузочной флешки выявляет сбойные модули, особенно на серверах без ECC.
- 🔋 Блок питания и UPS — просадки напряжения приводят к повреждению файловых систем при аварийных отключениях.
- 🌡️ Перегрев — забитые пылью радиаторы и остановившиеся вентиляторы вызывают троттлинг и внезапные выключения.
Как посмотреть логи прошлой загрузки
Если система всё же иногда загружается, журнал предыдущей сессии доступен командой journalctl -b -1 -e. Ошибки диска ищите по строкам с I/O error, ata и blk_update_request. На ZFS дополнительно смотрите вывод zpool status -v — он показывает файлы, затронутые ошибками.
Сравнение типичных сценариев сбоя
Сводная таблица поможет быстро сопоставить симптом с вероятной причиной и первым действием:
| Симптом | Вероятная причина | Первое действие |
|---|---|---|
| No bootable device | Порядок загрузки, отвалившийся диск | Проверить BIOS и видимость диска |
| grub rescue> | Повреждён загрузчик | Live-носитель, chroot, grub-install |
| Зависание после обновления | Несовместимое ядро | Загрузка предыдущего ядра из GRUB |
| Падение в initramfs | Пул rpool не импортируется | zpool import, zpool status |
| Случайные зависания | Память, диск, питание | memtest86, smartctl, проверка БП |
Эта таблица — ориентир, а не диагноз: один и тот же симптом может иметь несколько причин, поэтому всегда подтверждайте предположение конкретной проверкой, прежде чем переходить к восстановительным операциям.
Профилактика: как не повторить ситуацию
Большинство отказов загрузки Proxmox предотвратимы. Настройте регулярные резервные копии виртуальных машин и контейнеров штатным планировщиком vzdump на отдельное хранилище, а конфигурацию кластера и каталог /etc/pve копируйте дополнительно — именно там лежат настройки ВМ и кворума. Используйте источник бесперебойного питания с корректным выключением сервера по сигналу: аварийные отключения — главный враг файловых систем.
Обновления устанавливайте осмысленно: перед мажорными переходами читайте официальные заметки о выпуске и проверяйте свободное место на /boot. Держите под рукой загрузочную флешку с актуальным ISO Proxmox — она превращает большинство аварий из катастрофы в рабочую задачу на час.
Золотое правило администрирования Proxmox: резервные копии ВМ + копия /etc/pve + загрузочная флешка с ISO = восстановление даже после полного отказа системы без потери данных.
Часто задаваемые вопросы
Proxmox загружается, но веб-интерфейс недоступен — это та же проблема?
Нет, это другой класс проблем. Если система стартует и отвечает на ping, проверяйте сетевые настройки (/etc/network/interfaces), статус службы pveproxy и не переполнен ли диск — при заполненном корневом разделе веб-интерфейс перестаёт отвечать.
Можно ли переустановить Proxmox без потери виртуальных машин?
Если ВМ хранятся на отдельном диске или пуле, отличном от системного, — да: систему переустанавливают, хранилище подключают заново, а конфигурации ВМ восстанавливают из резервных копий /etc/pve. Без бэкапов процесс заметно сложнее и не гарантирует результат.
Что делать, если zpool status показывает состояние DEGRADED?
Пул работает в деградированном режиме — один из дисков отказал, но данные доступны. Как можно скорее сделайте резервные копии важных ВМ, затем замените сбойный диск и выполните zpool replace с последующим resilver. Работа в деградированном состоянии без резерва рискованна.
Почему после сбоя питания Proxmox не стартует, хотя раньше всё работало?
Аварийное отключение прерывает запись на диск в произвольный момент, что повреждает файловую систему или метаданные ZFS. ZFS устойчивее к таким сбоям благодаря copy-on-write, но не неуязвим. Решение на будущее — источник бесперебойного питания с настроенным корректным завершением работы.
Где искать официальную информацию по восстановлению загрузки?
Официальная документация Proxmox VE и вики проекта содержат разделы по восстановлению загрузчика и работе с ZFS. Процедуры зависят от версии Proxmox и типа разметки, поэтому сверяйте шаги с документацией именно вашей версии перед выполнением команд.