Debian/Ubuntu: как исправить cloud-init status: error после first boot на VDS

cloud-init status: error на Debian или Ubuntu после первого запуска виртуальной машины — ситуация неприятная, но очень типовая. Особенно часто она встречается на новых VDS, cloud-образах, golden image и после клонирования уже настроенной системы.

Снаружи всё может выглядеть почти нормально: сервер загружается, SSH отвечает, сеть частично работает, но cloud-init сообщает об ошибке, а часть начальной конфигурации не применена. Из-за этого легко получить неверный hostname, старые ключи, не ту сетевую схему или пропущенные команды из user-data.

Хорошая новость в том, что в большинстве случаев ничего переустанавливать не нужно. Если понять, что именно сломалось — datasource, instance-id, кэш в /var/lib/cloud или отдельный модуль cloud-init, — проблема устраняется довольно быстро.

Разберём, как cloud-init определяет first boot, где хранит состояние, что делать на cloned VDS, когда достаточно cloud-init clean, а когда нужна ручная очистка.

Что означает cloud-init status: error

Команда cloud-init status показывает не просто факт запуска службы, а итог состояния всей цепочки инициализации. Статус error означает, что хотя бы один этап завершился неуспешно.

Это не всегда означает, что система неработоспособна. Иногда падает только один модуль, а сервер в целом уже доступен. Например, сеть поднялась, но не применился hostname. Или пользователь создан, но не отработал финальный скрипт.

Поэтому первый шаг всегда один и тот же: смотреть реальные логи, а не ориентироваться только на короткий статус.

cloud-init status --long
cloud-init analyze show
journalctl -u cloud-init -u cloud-config -u cloud-final -b
tail -n 100 /var/log/cloud-init.log
tail -n 100 /var/log/cloud-init-output.log

Самая частая ошибка при разборе cloud-init — сразу чистить состояние, не посмотрев лог. Обычно причина там видна явно: datasource, модуль, traceback или конкретная команда.

Как cloud-init понимает, что это первый запуск

cloud-init должен отличать новый экземпляр от уже знакомого. Для этого он использует данные от источника метаданных и своё локальное состояние. Ключевые элементы — instance-id и содержимое каталога /var/lib/cloud.

Логика простая: cloud-init получает метаданные, сравнивает текущий instance-id с ранее сохранённым и решает, нужно ли выполнять одноразовые действия. Если экземпляр новый, запускается сценарий first boot. Если система считает инстанс прежним, часть шагов повторно не выполняется.

Именно тут чаще всего ломаются клоны. Вы копируете уже инициализированную машину, а вместе с ней переносите и старое состояние cloud-init. Новая VM фактически уже несёт память о чужом первом запуске.

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

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

Подробнее

Если вы регулярно собираете образы под развёртывание, полезно заранее продумать процесс подготовки шаблонов. В этом контексте может пригодиться материал про сборку golden image с cloud-init — он помогает убрать первопричину ещё на этапе шаблона.

Где хранится состояние cloud-init

Основной каталог состояния — /var/lib/cloud. Там cloud-init хранит сведения об обнаруженном datasource, текущем экземпляре, уже выполненных модулях и промежуточных данных между перезагрузками.

Обычно внутри встречаются такие пути:

• /var/lib/cloud/instance — данные текущего инстанса;
• /var/lib/cloud/instances — состояние по отдельным instance-id;
• /var/lib/cloud/data — служебные файлы и маркеры этапов;
• /var/lib/cloud/seed — локальные seed-данные, если они используются.

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

Проверить состояние можно так:

find /var/lib/cloud -maxdepth 3 -type f | sort
cat /var/lib/cloud/data/instance-id
readlink -f /var/lib/cloud/instance

Типичные причины ошибки на Debian и Ubuntu

Datasource не найден или определён неверно

Datasource — это источник метаданных, откуда cloud-init получает сведения о сети, ключах, hostname и параметрах инициализации. Если cloud-init ждёт один источник, а доступен другой, часть стадий может завершиться ошибкой.

Быстрая проверка:

cloud-init query ds
cloud-id
grep -i datasource /var/log/cloud-init.log | tail -n 50

Клонирование уже инициализированной машины

Самый частый сценарий: администратор обновил систему, поставил нужные пакеты, а потом сделал снимок или шаблон без очистки cloud-init. Следующий экземпляр стартует уже не как новый, а как копия старого.

Типичные симптомы:

• не применяются новые SSH-ключи;
• hostname остаётся от исходной машины;
• в логах всплывает старый instance-id;
• сеть ведёт себя нестабильно;
• cloud-init status сразу показывает ошибку.

Проблемы с instance-id

instance-id нужен cloud-init, чтобы понять: это новый экземпляр или уже знакомый. Если ID не меняется там, где должен меняться, одноразовые шаги могут не запуститься. Если же он меняется на каждом старте, cloud-init будет воспринимать каждый boot как первый.

Остатки сетевой конфигурации

После клонирования часто конфликтуют старые сетевые файлы, новые MAC-адреса, имена интерфейсов и логика генерации конфигурации. В результате cloud-init не может корректно завершить сетевую стадию, а следом ломаются и зависящие от сети шаги.

Ошибки в user-data

Иногда сам cloud-init работает нормально, а падает конкретный модуль: из-за неверного YAML, отсутствующего пакета, несуществующего пользователя или некорректной команды. Формально статус всё равно будет error.

Базовая схема диагностики

Если сервер уже доступен по SSH, не начинайте с удаления файлов. Сначала соберите картину: какой datasource найден, какой instance-id активен и что именно пишет лог текущей загрузки.

cloud-init status --long
cloud-init query ds
cloud-init query instance_id
cloud-id
ls -la /var/lib/cloud
readlink -f /var/lib/cloud/instance
journalctl -b | grep -i cloud-init
grep -Ei 'error|failed|traceback|datasource|instance-id' /var/log/cloud-init.log | tail -n 100

После этого ответьте на четыре вопроса:

1. Какой datasource реально определился?
2. Какой instance-id cloud-init считает текущим?
3. Похоже ли содержимое /var/lib/cloud на наследство от другой машины?
4. Ошибка глобальная или упал только один модуль?

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

Когда использовать cloud-init clean

cloud-init clean — штатный способ сбросить локальное состояние. В нормальной ситуации это лучше, чем вручную удалять содержимое /var/lib/cloud.

Эта команда уместна в трёх типовых случаях: при подготовке шаблона, сразу после неудачного клонирования и когда первый запуск прошёл некорректно и его нужно воспроизвести заново.

Базовая процедура:

sudo cloud-init clean --logs
sudo reboot

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

cloud-init status --wait
cloud-init status --long

Если вы готовите образ под массовое развёртывание, очистку лучше делать до выключения исходной машины. Тогда каждый новый экземпляр на VDS действительно увидит корректный first boot.

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

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

Подробнее

Когда нужна ручная очистка /var/lib/cloud

Иногда штатной очистки недостаточно: состояние повреждено, поведение образа нестандартное или вы разбираете старый кастомный шаблон. Тогда приходится вручную очищать каталог состояния.

Делать это стоит только после сохранения диагностики. На рабочей машине разумно сначала снять копию каталога.

sudo systemctl stop cloud-init-local.service cloud-init.service cloud-config.service cloud-final.service
sudo cp -a /var/lib/cloud /root/cloud-backup-$(date +%F-%H%M%S)
sudo rm -rf /var/lib/cloud/*
sudo reboot

На некоторых образах Ubuntu могут мешать дополнительные файлы, связанные с настройкой сети установщиком. Удалять их нужно только если вы точно понимаете, зачем это делаете.

sudo rm -f /etc/cloud/cloud.cfg.d/subiquity-disable-cloudinit-networking.cfg

Как проверить и при необходимости ограничить datasource

Если проблема не в клонировании, а в неверном определении источника метаданных, проверьте конфигурацию cloud-init в /etc/cloud/cloud.cfg и /etc/cloud/cloud.cfg.d/.

grep -R "datasource" /etc/cloud/cloud.cfg /etc/cloud/cloud.cfg.d 2>/dev/null
ls -1 /etc/cloud/cloud.cfg.d

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

datasource_list: [ NoCloud, ConfigDrive ]

Такой фрагмент обычно сохраняют в отдельный файл, например /etc/cloud/cloud.cfg.d/90-datasource.cfg. После изменения конфигурации имеет смысл очистить состояние и перезагрузить систему, иначе cloud-init может продолжить использовать старые данные из кэша.

Но ограничивать список нужно аккуратно. Ошибка здесь приведёт к обратному результату: cloud-init вообще перестанет видеть правильный datasource.

Что делать с instance-id на cloned VDS

На клонированной машине главный вопрос простой: должна ли она считаться новым экземпляром? Почти всегда да. Значит, у неё должен появиться новый instance-id, а локальное состояние старой машины нужно удалить.

Проверка:

cloud-init query instance_id
cat /var/lib/cloud/data/instance-id

Если новая VM в логах продолжает ссылаться на старый идентификатор, почти наверняка образ был клонирован без корректной очистки. Исправление обычно сводится к cloud-init clean --logs или полной очистке /var/lib/cloud с последующей перезагрузкой.

Практический сценарий восстановления

Типовая ситуация: вы подготовили Ubuntu или Debian, обновили пакеты, поставили агенты, сделали шаблон, а новый экземпляр запускается со старым hostname и ошибкой cloud-init.

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

1. Проверить, доступен ли корректный datasource.
2. Снять статус и логи текущей загрузки.
3. Посмотреть текущий instance-id.
4. Выполнить cloud-init clean --logs.
5. Если не помогло, очистить /var/lib/cloud вручную.
6. Перезагрузить сервер и дождаться завершения cloud-init.
7. Проверить hostname, сеть, ключи и финальные модули.

Если вы ещё только выбираете конфигурацию под такие задачи, полезно оценить ресурсы заранее: статья про подбор VDS по CPU и RAM помогает не промахнуться с планом для шаблонов, CI и сервисов инициализации.

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

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

cloud-init status --wait
cloud-init status --long
journalctl -u cloud-final -b
cloud-init analyze show

Если текущий статус стал done, а в журналах этой загрузки нет ошибок, значит сценарий инициализации завершился корректно.

Как не наступать на ту же проблему снова

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

• Не клонируйте рабочую машину без предварительной очистки cloud-init.
• Перед созданием шаблона выполняйте cloud-init clean --logs.
• Проверяйте, какой datasource реально используется у провайдера.
• Тестируйте минимум два независимых экземпляра из одного шаблона.
• Не смешивайте ручное управление сетью и cloud-init без чёткого понимания, кто отвечает за конфигурацию.
• Храните заметки о задействованных модулях: пользователи, SSH-ключи, сеть, пакеты, runcmd.

Короткий чек-лист

1. Проверить cloud-init status --long.
2. Посмотреть datasource через cloud-init query ds и cloud-id.
3. Проверить текущий instance-id.
4. Осмотреть /var/lib/cloud.
5. Если это клон и нужен новый первый запуск — выполнить cloud-init clean --logs.
6. Если не помогло — вручную очистить /var/lib/cloud.
7. Перезагрузить сервер и дождаться завершения cloud-init.
8. Проверить сеть, hostname, ключи и финальную стадию настройки.

Итог

cloud-init status: error после first boot почти всегда связан не с абстрактно «сломанной системой», а с конкретной причиной: неверным datasource, конфликтным instance-id, старым содержимым /var/lib/cloud или ошибкой в пользовательской конфигурации.

Если не спешить и начать с логов, проблема обычно находится быстро. А дальше всё сводится к двум сценариям: либо исправить источник метаданных, либо корректно сбросить локальное состояние cloud-init.

Для Debian и Ubuntu это как раз тот случай, где аккуратная подготовка шаблона экономит больше времени, чем любое аварийное восстановление после неудачного клонирования.