Ubuntu зависает при достижении цели инициализации целевого облака
Обновлено: 04.07.2024
В зависимости от того, какой модуль systemd убивает для разрешения цикла, это может привести к тому, что cloud-init никогда не завершится, что приведет к тому, что сервер subiquity будет ждать его вечно, и ничего полезного сделать нельзя (кроме перезапуска и надежды на удачу в следующий раз). ).
Поскольку subiquity сама ожидает cloud-init (и это было верно в течение длительного времени), нет необходимости, чтобы serial-getty@$ TTY.service ждал cloud-final. обслуживание.
[потенциал регрессии]
Это изменение приводит к довольно сильному перетасовыванию модулей systemd, но новое расположение было протестировано в разработке в течение нескольких месяцев и там хорошо работает. Это также намного проще, чем текущая настройка.
[тестовый пример]
Это немного сложно, так как это периодический сбой. По сути, загрузите интерактивный установщик с настроенной последовательной консолью несколько раз и (10?) убедитесь, что установщик каждый раз запускается правильно.
[original description]
Время от времени (эпизодически и очень редко - может быть, в одной-двух попытках из двадцати) сталкиваюсь с ситуацией, когда система установщика (на s390x) не загружается полностью.
Это уже случалось со мной в прошлом, но, поскольку это случалось всего один или два раза, я подумал, что это связано с нехваткой ресурсов в системе или около того.
Но так как я снова столкнулся с этим на LPAR (до того, как это было на z/VM), я сейчас открываю этот тикет.
В последнем случае я использовал ежедневное живое изображение от 20 июля с инсталлятором 20.06.1 (но так было и с предыдущими версиями).
Ситуация такая:
Загрузка установщика заканчивается здесь (LPAR):
.
"[ 128.200711] cloud-init[1375]: случайное изображение ключа:"
"[ 128.200735] cloud-init[1375]: +--[ED25519 256]--+"
"[ 128.200758] cloud-init[1375]: |о .ооо |"
"[ 128.200781] cloud-init[1375]: |.= . . . +. o. . .|"
"[ 128.200804] cloud-init[1375]: |+ * . . . * o.o. |"
"[ 128.200826] cloud-init[1375]: |.= o . = = = + |"
"[ 128.200849] cloud-init[1375]: |o + .S o + |"
"[ 128.200876] cloud-init[1375]: | + o = . . . |"
"[ 128.200900] cloud-init[1375]: | o + . |"
"[ 128.200925] cloud-init[1375]: | o.=.E |"
"[ 128.200947] cloud-init[1375]: | .+.o+o. |"
"[ 128.200977] cloud-init[1375]: +----[SHA256] -----+"
"[ 138.898906] cloud-init[2217]: Cloud-init v. 20.2-45-g5f7825e2-0ubuntu1~ 20.04."
"1 запускал модуль 'modules:config' в среду, 22 июля 2020 г., 11:27:39 +0000. Увеличение на 138,77 секунды"
.
"[ 138.898966] cloud-init[2217]: установите следующие "случайные" пароли"
"[ 138.899001] cloud-init[2217]: installer: aecmewaoicnai"
или другой пример (z/VM):
.
¬ 93.463680| cloud-init¬1282|: +--¬ED25519 256|--+
¬ 93.463713| cloud-init¬1282|: !Eo=o . !
¬ 93.463749| cloud-init¬1282|: !.Bo.o . о!
¬ 93.463782| cloud-init¬1282|: !**.*. о = !
¬ 93.463818| cloud-init¬1282|: !*=O o. о . . !
¬ 93.463849| cloud-init¬1282|: !**++ S !
¬ 93.463886| cloud-init¬1282|: !§o+.. !
¬ 93.463918| cloud-init¬1282|: !++o. !
¬ 93.463954| cloud-init¬1282|: !.o. !
¬ 93.463988| cloud-init¬1282|: !. !
¬ 93.464028| cloud-init¬1282|: +----¬SHA256|-----+
¬ 104.841438| cloud-init-2004|: Cloud-init v. 20.2-45-g5f7825e2-0ubuntu1ß20. 04.
1 запущен 'modules:config' в пн, 20 июля 2020 г., 10:46:38 +0000. До 104,63 секунды
.
¬ 104.841490| cloud-init¬2004|: Установите следующие «случайные» пароли
¬ 104.841516| cloud-init-2004|: установщик: U9NJDuvXFw6X2fx G7pP8
Но это еще не все.
Завершенная загрузка системы установщика заканчивается следующим образом:
"Можно подключиться к установщику по сети, что"
"может позволить использовать более функциональный терминал и может предлагать больше языков"
", чем может быть отображено в Linux консоль."
"Для подключения используйте SSH к installer@ ."
"Вы должны использовать пароль "ydnjdnciu" kZ4tR4vRvPxHPer CNU8g"" ."
<Р> "RSA SHA256: п + 6TJsfdCBII2PO 89GMU10mG1oFvEI FBT2v6uPN0Jz0""ECDSA SHA256: VcDS5ac8xswXxFE ghjo1ZIcue38AM6 HJg0poIxdeeec"
"ED25519 SHA256: фунт / DVVhj1obDPhf o3M8oPqeAyduvlL cPFJCC8ZaiCJY"
"Ubuntu 20.04 LTS ubuntu-сервер sclp_line0"
В такой ситуации я также не могу получить доступ к пользовательскому интерфейсу subiquity:
Информация о системе по состоянию на 22 июля 11:28:32 UTC 2020
Нагрузка на систему: 0,44 Использование памяти: 4% Процессов: 180
Использование /home: неизвестно Использование подкачки: 0% Вошедших пользователей: 0
0 обновлений можно установить сразу.
0 из этих обновлений являются обновлениями безопасности.
Программы, включенные в систему Ubuntu, являются бесплатными;
Точные условия распространения для каждой программы описаны в
отдельных файлах в /usr/share/doc/*/copyright .
Ubuntu поставляется АБСОЛЮТНО НИКАКИХ ГАРАНТИЙ, если это разрешено
применимым законодательством.
Поэтому даже сбор журналов, к сожалению, невозможен.
Связанные ветки
Дэн Бунгерт (сообщество): Утверждено 27 июля 2021 г. Основная группа разработчиков Ubuntu: Ожидается запрос 23 июля 2021 г. Различия: 88 строк (+22/-9)
debian/changelog (+10/-0)
live-build/ubuntu-server/includes.binary/overlay/etc/cloud/cloud.cfg (+1/-3)
live -build/ubuntu-server/includes.binary/overlay/usr/lib/systemd/system/getty@tty1.service (+1/-0)
live-build/ubuntu-server/includes.binary/overlay /usr/lib/systemd/system/serial-getty@.service.d/subiquity-serial.conf (+8/-1)
live-build/ubuntu-server/includes.binary/overlay/usr/ lib/systemd/system/serial-getty@sclp_line0.service.d/subiquity-serial.conf (+2/-4)
live-build/ubuntu-server/includes.binary/overlay/usr/lib/ systemd/system/snap.subiquity.subiquity-service.service.d/subiquity.conf (+0/-1)
| Изменено в системах ubuntu-z: | |
| правопреемник: | nobody → Команда Canonical Foundations (canonical-foundations) |
| резюме: | - спорадически система установки загружается не полностью + Время от времени система установки загружается не полностью (или + не запускаются все службы) |
Только что снова произошло на z/VM с использованием образа, предложенного для тестирования QA Tracker от 23 июля.
Запуск установки второй раз сработал - значит установщик загрузился до конца.
Получилось снова - и последующая загрузка системы установки сработала:
Ý 143.093052¨ cloud-initÝ1848¨: Cloud-init v. 20.2-45-g5f7825e2-0ubuntu1~ 20.04.
1 финишировал во вторник, 28 июля 2020 г., 07:39:06 +0000. Источник данных DataSourceNoCloud Ýсм.
d=/var/lib/cloud/seed/nocloud¨ Ýdsmode= net¨. Up 143,08 секунды
Ý 143.093125¨ cloud-initÝ1848¨: Добро пожаловать в установщик Ubuntu Server!
Ý 143.093195¨ cloud-initÝ1848¨: выше вы найдете ключи хоста SSH и случайный
пароль, установленный для пользователя установщика. Вы можете использовать эти учетные данные для входа по ssh и
и завершить установку. Если вы указали ключи SSH в файле данных cloud-init
rce, они также были предоставлены пользователю установщика.
Ý 143.093266¨ cloud-initÝ1848¨: Если у вас есть доступ к графической консоли,
ке терминалу TTY1 или HMC ASCII, вы также можете завершить установку там.
Ý Ý0;32m OK Ý0m¨ Готово Ý0;1;39mВыполнение пользовательских/конечных сценариев в облаке Ý0m.
Ý Ý0;32m OK Ý0m¨ Достигнута цель Ý0;1;39mCloud-init target Ý0m.
Ý Ý0;32m OK Ý0m¨ Запущен Ý0;1;39mSubiquity, установщик для сервера Ubuntu
hvc0 Ý0m.
Ý Ý0;32m OK Ý0m¨ Запущено Ý0;1;39mSubiquity, вставка для Ubuntu Server t
tysclp0 Ý0m.
installer@ 2001:67c: 1562:8123: 28:ape: febo:57
Вы должны использовать пароль "ubiewaucea85ca ewfD9Gz".
rsa sha256: 7ucaisnt + tqqagk4zuyz7q9u eryspwr5mexihlm ygl4
ECDSA SHA256: 3ermimvsugrmuqw kn1x0zyyyo8xz + cew7jlxs6r484ue
ED25519 SHA256: 2HWOLACLCLCCUNLEX GXQHOIICTXS1O + CLYDICHC0Z21M
Ubuntu 20.04.1 LTS Ubuntu-сервер ttyS0
Интересно, не заканчивается ли ОЗУ гостевой системе z/VM — у нее всего 2 ГБ ОЗУ.
Померю гостей покрупнее и посмотрю, замечу ли я разницу.
У меня возникла та же проблема, когда я пытался установить focus на гостевой z/VM с 4 ГБ ОЗУ.
Ну, это звучит забавно для отладки :( Я думаю, вы могли бы взломать оболочку default_user в /etc/cloud/cloud.cfg в installer.squashfs, чтобы она была /bin/bash, а затем ssh-ing должен работать?
| Изменено в системах ubuntu-z: | |
| важность: | Не определился → Высокий |
Вы сообщали об этой проблеме задолго до того, как она была выпущена в стабильной версии, так что я очень надеюсь, что нет.
Я столкнулся с ситуацией, когда вывод консоли был явно неполным:
Ý 152.164507¨ cloud-initÝ2084¨: ci-info: нет отпечатков авторизованных ключей SSH для
и пользовательского установщика.
Ý 152.164548¨ cloud-initÝ2084¨: Cloud-init v. 20.2-45- g5f7825e2- 0ubuntu1~ 20.04
1 завершено в понедельник, 07 декабря 2020 г., 17:56:43 +0000. Источник данных DataSourceNoCloud Ýсм.
d=/var/lib/cloud/seed/nocloud¨ Ýdsmode= net¨. Up 152,16 секунды
Ý 152.164593¨ cloud-initÝ2084¨: Добро пожаловать в установщик Ubuntu Server!
Ý 152.164631¨ cloud-initÝ2084¨: выше вы найдете ключи хоста SSH и случайный
пароль, установленный для пользователя `установщика`. Вы можете использовать эти учетные данные для входа по ssh и
и завершить установку. Если вы указали ключи SSH в файле данных cloud-init
rce, они также были предоставлены пользователю установщика.
Ý 152.164675¨ cloud-initÝ2084¨: Если вы ч.
cloud-init — это пакет Ubuntu, который обеспечивает раннюю инициализацию облачного экземпляра. Он устанавливается в официальные образы серверов Ubuntu с момента выпуска 18.04, облачные образы Ubuntu, а также в официальные образы Ubuntu, доступные на EC2.
- установка языкового стандарта по умолчанию
- настройка имени хоста
- сгенерировать закрытые ключи ssh
- добавление ключей ssh в .ssh/authorized_keys пользователя, чтобы они могли войти в систему
- настройка временных точек подключения
Поведение cloud-init можно настроить с помощью пользовательских данных. Пользовательские данные передаются в cloud-init пользователем облачному провайдеру во время запуска, обычно как параметр в интерфейсе командной строки, шаблоне или облачном портале, который используется для запуска экземпляра.
Форматы ввода пользовательских данных
- Этот список правил применяется к каждой части этого файла, состоящего из нескольких частей. Используя файл mime-multi, пользователь может указать более одного типа данных. Например, можно указать как сценарий данных пользователя, так и тип облачной конфигурации.
Это "частичный обработчик". Он будет записан в файл в /var/lib/cloud/data на основе имени файла. Это должен быть код Python, содержащий метод list_types и метод handle_type. Как только раздел будет прочитан, будет вызван метод list_types. Он должен возвращать список MIME-типов, которые обработчики этого частичного обработчика.
Метод handle_type должен быть таким:
Скрипты пользовательских данных
Как популяризировал alestic.com, скрипты пользовательских данных — это удобный способ сделать что-то при первой загрузке запущенного экземпляра. Этот входной формат принимается cloud-init и обрабатывается так, как вы ожидаете. Сценарий будет запущен в точке, подобной "rc.local", в последовательности загрузки.
После выполнения вышеуказанного вы можете ожидать, что /root/output.txt будет содержать нужный текст.
Синтаксис Cloud Config
- apt upgrade следует запускать при первой загрузке
- следует использовать другое подходящее зеркало
- необходимо добавить дополнительные подходящие источники
- необходимо импортировать определенные ключи ssh
Файл должен иметь допустимый синтаксис yaml.
Составной ввод
Единого формата пользовательских данных может быть недостаточно для достижения желаемого. Например, вы можете вставить задание выскочки, а также запустить сценарий пользовательских данных.
В каталоге bin/ cloud-utils есть инструмент под названием write-mime-multipart, который может помочь в создании MIME-контента, состоящего из нескольких частей.
Рассмотрите следующий пример:
Теперь, учитывая указанные выше файлы в текущем каталоге, вы можете сделать следующее:
- ключи smoser, импортированные пользователями ubuntu ~/.ssh/authorized_keys . Обратите внимание, что я не указал «--key» в командной строке, так как он не нужен. Вместо этого были импортированы мои ключи панели запуска.
- принадлежащий root файл в /var/lib/cloud/data/user-data.txt, содержащий сжатые gzip пользовательские данные.
- файл, принадлежащий root, в /var/lib/cloud/data/user-data.txt.i, содержащий постобработанные пользовательские данные (несжатые, с разрешенными включениями).
- файл '/var/lib/cloud/data/user-data.txt.i'
Подробнее
Примеры пользовательских данных для cloud-init можно увидеть в каталоге примеров Github.
Привет,
Я работаю над сервером на платформе Greenlow. Теперь столкнулся с проблемой: система зависает после вывода «Достигнута целевая базовая система».
Мой вопрос: какая функция ядра выдаст это сообщение? Я могу продолжить отслеживать эту проблему, если найду имя функции.
Спасибо
[ 0.000000] tsc: Ошибка быстрой калибровки TSC
ÿ[ 2.279076] i8042: Контроллер не найден
[[32m OK [0m] Started Show Plymouth Boot Screen.
[[32 минуты OK [0 минут] Достигнуты целевые пути.
[[32 минуты OK [0 минут] Достигнута целевая базовая система.
Ответы
Можно ли переключиться на другой терминал, например, нажав Alt+F2 ? Если да, попробуйте запустить
Должны отображаться сообщения журнала текущей загрузки.
Сообщение, о котором вы спрашиваете (Достигнута целевая базовая система) выводится systemd при загрузке базовой системы — за этим может последовать запуск графического интерфейса и различных системных служб. См. справочную страницу bootup(7) для получения дополнительной информации о последовательности загрузки.
Я также сталкиваюсь с той же проблемой, за которой следует тайм-аут dracut
У меня та же проблема, я не могу получить доступ к терминалу, нажав ALT+2
"Достигнута целевая базовая система" не является сообщением ядра: оно исходит от initramfs. Вы можете получить диагностическую оболочку, используя параметр rd.break=
boot.
В частности, это выглядит как параметр загрузки
предоставит вам диагностическую оболочку перед сообщением "Достигнута целевая базовая система" (= сразу после сообщения "Запущен диспетчер устройств ядра udev") и параметром загрузки
вызовет диагностическую оболочку сразу после сообщения "Достигнута целевая базовая система".
Другие виртуальные консоли в этот момент использовать нельзя, так как шаг "Запущена служба входа" еще не достигнут. Вот почему Alt+F2 не работает.
Следующим шагом после «Достигнута целевая базовая система», очевидно, является загрузка модулей контроллера хранилища, необходимых для поиска и активации корневой файловой системы.Если в этот момент система зависает, вы можете попробовать загрузить соответствующие модули вручную и посмотреть, какой модуль вызывает зависание системы при загрузке. Если этот модуль не является обязательным, вы можете попробовать добавить его в черный список с опцией загрузки
Это приводит к тому, что cloud-init останавливается на потенциально долгое время во время загрузки (я полагаю, в ожидании энтропии). Google сообщил о задержке загрузки на 75 минут.
Я отследил это до следующего импорта в templater.py, который вызывает задержку:
из jinja2 импортировать шаблон как JTemplate
Вызывается при импорте cc_update_etc_hosts.
mvo: fwiw jinja2 импортирует случайным образом и считывает 2500 символов из /dev/urandom при импорте
| Изменено в Linux (Ubuntu): | |
| важность: | Не определился → Высокий |
Для этой ошибки отсутствуют файлы журналов, которые помогут в диагностике проблемы. При запуске ядра Ubuntu (не основного или стороннего ядра) введите следующую команду в окне терминала:
а затем измените статус ошибки на "Подтверждено".
Если из-за характера проблемы, с которой вы столкнулись, вы не можете запустить эту команду, добавьте комментарий, подтверждающий этот факт, и измените статус ошибки на "Подтверждено".
Это изменение было внесено автоматическим сценарием, поддерживаемым командой ядра Ubuntu.
| Изменено в Linux (Ubuntu): | |
| статус: | Новое → Незавершенное |
| Изменено в cloud-init (Ubuntu): | |
| важность:< /td> | Не определился → Высокий |
| Изменено в Linux (Ubuntu Bionic): | |||||||||||||||||||||
| статус: | Новый → Исправление подтверждено | ||||||||||||||||||||
| важность: | Не определено → Высокий | < /tr>||||||||||||||||||||
| Изменено в cloud-init (Ubuntu Bionic): | |
| status: | Новое → Подтверждено |
| Изменено в cloud-init (Ubuntu): | |
| Новое → Подтверждено | |
Похоже, это также влияет на рабочий стол Ubuntu с включенным crng_init.
* Экземпляры EC2 — затронуты, та же проблема, что описана
* Домашний рабочий стол (Xubuntu) — затронуты, см. описание ниже
* Домашний сервер (Lubuntu, у которого по какой-то причине crng_init=0) — не затронуты< /p>
cloud-init может быть просто отвлекающим маневром, так как мой домашний рабочий стол зависал более 30 секунд на "docker.service". Когда я отключу Docker, он все равно будет зависать на 30 секунд, но «системный анализ вины» не выявит виновника.
Эта ошибка ожидает подтверждения того, что предлагаемое ядро решает проблему. Пожалуйста, протестируйте ядро и обновите эту ошибку с результатами. Если проблема решена, измените тег «verification-need-bionic» на «verification-done-bionic». Если проблема не устранена, измените тег «verification-need-bionic» на «verification-failed-bionic».
Если проверка не будет выполнена в течение 5 рабочих дней с сегодняшнего дня, это исправление будет удалено из исходного кода, и эта ошибка будет закрыта.
| Изменено в cloud-init (Ubuntu): | |
| status:< /td> | Подтверждено → Недействительно |
| Изменено в cloud-init (Ubuntu Bionic): | |
| Подтверждено → Недействительно | |
| Изменено в Linux (Ubuntu): | |
| статус: | Не завершено → Исправление зафиксировано |
Здравствуйте!
Я заметил ту же проблему в наших недавно выпущенных образах Scaleway с включенным cloud-init на Bionic под управлением 4.15.0-24.
Тестирование с ядром 4.15.0-26-generic в -proposed _ДЕЛАЕТ_ решение проблемы с задержкой в нашем образе.
Я позволю себе отметить проверенную ошибку.
| теги: | добавлено: проверка-выполнена-bionic удалено: требуется проверка-bionic |