Подробный гайд: Решение ошибки загрузки ОС из конфигурации CustomConfig0

Гайд по устранению ошибки «Не удалось выполнить загрузку ОС из конфигурации CustomConfig0»: диагностика, причины сбоя cloud-init, VirtIO, UEFI и восстановление ВМ.

2026.09.18                  


Подробный гайд: Решение ошибки загрузки ОС из конфигурации CustomConfig0Подробный гайд: Решение ошибки загрузки ОС из конфигурации CustomConfig0 Ошибка «Не удалось выполнить загрузку ОС из конфигурации CustomConfig0» (или аналогичные ошибки, связанные с CustomConfig, ConfigDrive, cloud-init) чаще всего возникает в облачных средах (Yandex Cloud, Selectel, Cloud.ru, Huawei Cloud, OpenStack-платформы) или при использовании специфических гипервизоров.

Она означает, что управляющий агент облака или загрузчик (GRUB/systemd-boot) попытался применить пользовательский конфигурационный профиль (обычно передаваемый через user-data, config-drive или metadata-сервис), но операционная система не смогла его прочитать, обработать или применить на этапе инициализации ядра.




Этап 1: Диагностика (Сбор информации)

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

  1. Откройте Serial-консоль (VNC / Web-консоль) в панели управления вашего облачного провайдера или гипервизора.

2. Проанализируйте лог загрузки:

  • Kernel Panic / VFS: Unable to mount root fs: Проблема с драйверами дисков (отсутствуют VirtIO) или повреждена файловая система.
  • cloud-init: error / yaml.scanner.ScannerError: Синтаксическая ошибка в переданном user-data (YAML-скрипте).
  • GRUB rescue> / file not found: Загрузчик не может найти ядро, указанное в CustomConfig0.
  • Timeout waiting for metadata service: ВМ не может получить доступ к 169.254.169.254 или не может смонтировать config-drive (ISO-диск с метаданными).

Этап 2: Основные причины и способы решения

Причина 1: Ошибка в синтаксисе user-data (Cloud-init)

Если при создании ВМ вы передавали скрипт инициализации (cloud-config, bash-скрипт), ошибка в YAML-разметке (например, лишние пробелы, табуляция вместо пробелов, отсутствие #cloud-config в первой строке) приведет к падению cloud-init, что некоторые платформы интерпретируют как сбой boot-конфигурации.

Решение:

  1. Попробуйте создать тестовую ВМ без передачи user-data (с чистым образом). Если она загрузится — проблема была в скрипте.
  2. Проверьте ваш YAML-скрипт через валидатор (например, cloudinit read или онлайн-валидаторы YAML).
  3. Убедитесь, что первая строка скрипта строго содержит #cloud-config без пробелов до нее.

Причина 2: Отсутствие драйверов VirtIO в Custom-образе

Если вы загружали свой собственный образ (Custom Image / qcow2 / vmdk), ядро вашей ОС может не содержать драйверов virtio-blk (для дисков) или virtio-net (для сети). Облако монтирует CustomConfig0 как виртуальный ISO/CD-ROM или диск, и ОС просто не видит его при загрузке.

Решение:

  1. Подключите диск к другой (работающей) ВМ в режиме Rescue / LiveCD.

2. Смонтируйте раздел и проверьте наличие модулей ядра:

   lsinitrd /boot/initrd.img-$(uname -r) | grep virtio

3. Если их нет, необходимо пересобрать initramfs в chroot-окружении:

   # Для Debian/Ubuntu
   echo -e "virtio_blk\nvirtio_pci\nvirtio_net" >> /etc/initramfs-tools/modules
   update-initramfs -u

   # Для RHEL/CentOS/AlmaLinux
   echo -e "virtio_blk\nvirtio_pci\nvirtio_net" >> /etc/dracut.conf.d/virtio.conf
   dracut -f

Причина 3: Несовместимость UEFI и Legacy BIOS

Платформа могла создать конфигурацию CustomConfig0 с расчетом на UEFI-загрузку, но образ поддерживает только Legacy BIOS (или наоборот).

Решение:

  • Зайдите в настройки ВМ в панели управления.
  • Найдите параметр Boot Mode (Режим загрузки).
  • Переключите с UEFI на BIOS/Legacy (или наоборот) и перезапустите ВМ.

Причина 4: Проблема с Config Drive (Метаданные)

Некоторые облака передают CustomConfig0 через подключенный виртуальный CD-ROM (config-2). Если в ОС отключен автоматический монтаж ISO-образов или отсутствует поддержка iso9660, загрузка прервется.

Решение (через Rescue-режим):

  1. Загрузите ВМ с аварийного диска (Rescue Disk / LiveCD).
  2. Смонтируйте корневой диск вашей ОС.
  3. Убедитесь, что в /etc/fstab нет жестко заданных UUID для дисков, которые могли измениться при миграции или клонировании. Замените UUID на /dev/vda1 (или используйте LABEL=root).

4. Проверьте, установлен ли пакет cloud-init:

   chroot /mnt/sysimage
   apt install cloud-init  # или yum install cloud-init
   systemctl enable cloud-init



Причина 5: "Залипший" GRUB (Ручное вмешательство)

Иногда CustomConfig0 — это просто название custom-записи в меню GRUB, созданной агентом провайдера, которая ведет на несуществующее ядро.

Решение:

  1. При включении ВМ зажмите Shift или Esc, чтобы попасть в меню GRUB.
  2. Выберите стандартную запись (обычно первая строка, без приписки CustomConfig), нажмите e для редактирования.
  3. Проверьте пути к linux и initrd.
  4. Нажмите F10 или Ctrl+X для загрузки.

5. Если ОС загрузилась, обновите GRUB:

   update-grub      # Debian/Ubuntu
   grub2-mkconfig -o /boot/grub2/grub.cfg  # RHEL/CentOS

Этап 3: Алгоритм аварийного восстановления (Step-by-Step)

Если ВМ критически важна и её нельзя пересоздать, выполните следующие шаги:

  1. Остановите ВМ через панель управления.
  2. Отключите (Detach) системный диск от ВМ.
  3. Создайте временную ВМ (Rescue VM) в той же зоне доступности и подключите к ней ваш диск как дополнительный (второй).
  4. Загрузите Rescue VM, подключитесь по SSH.

5. Смонтируйте диск:

   sudo mkdir /mnt/rescue
   sudo mount /dev/vdb1 /mnt/rescue # (уточните имя диска через lsblk)

6. Проверьте логи cloud-init (если диск смонтировался):

   cat /mnt/rescue/var/log/cloud-init.log | grep -i error
   cat /mnt/rescue/var/log/cloud-init-output.log
  1. Исправьте конфигурацию сети или fstab, если проблема в них.
  2. Отключите диск от Rescue VM, подключите обратно к вашей проблемной ВМ и запустите её.

Этап 4: Превентивные меры (Как избежать в будущем)

  1. Подготовка Custom-образов: Перед загрузкой своего qcow2 в облако всегда устанавливайте cloud-init, qemu-guest-agent и драйверы virtio. Официальные гайды облачных провайдеров имеют скрипты для "очистки" и подготовки образа.
  2. Тестирование user-data: Всегда тестируйте сложные YAML-конфигурации на дешевых/тестовых ВМ, которые не жалко удалить.
  3. Используйте Snapshot-ы: Перед применением любых кастомных конфигураций или обновлений ядра делайте снапшот диска.
  4. Избегайте хардкода MAC-адресов и UUID в сетевых настройках (/etc/netplan/, /etc/sysconfig/network-scripts/), так как при каждом пересоздании ВМ они меняются, и CustomConfig не может применить сеть.

Мы делимся этой технической информацией, чтобы помочь вам в решении задач — используйте её с пониманием. Статья носит рекомендательный характер, поэтому, пожалуйста, применяйте описанные методы осмотрительно.


Статью подготовил: Аверко Денис Сергеевич @Nymexis г. Омск (специалист по ЗИ)

Комментарии

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