
Это мой первый пост здесь, так что, пожалуйста, наберитесь терпения :)
Я пытаюсь собрать образ Ubuntu 20.04.5 с помощью Packer(1.8.4) на Proxmox(7.2-11). Все, кажется, работает нормально (получает IP, считывает конфигурацию cloud-init через HTTP, запускает установку, устанавливает ядро) до установки qemu-guest-agent с помощью subiquity. Он не может запустить команду установки, генерирует отчет о сбое и просит нажать Enter, чтобы получить терминал. Для образа ISO 20.04.4 все работает нормально с той же самой конфигурацией в Packer.
Конфигурация cloud-init:
#cloud-config
autoinstall:
version: 1
locale: en_US
keyboard:
layout: en
network:
version: 2
ethernets:
ens18:
dhcp4: true
ssh:
install-server: true
allow-pw: false
disable_root: true
ssh_quiet_keygen: true
allow_public_ssh_keys: true
packages:
- qemu-guest-agent
- sudo
storage:
swap:
size: 0
config:
- {ptable: gpt, path: /dev/vda, preserve: false, name: '', grub_device: true, type: disk, id: disk-vda}
- {type: partition, number: 1, device: disk-vda, flag: bios_grub, size: 1M, id: vda-grub}
- {type: partition, number: 2, device: disk-vda, flag: boot, size: 1G, id: vda-boot}
- {type: partition, number: 3, device: disk-vda, size: -1, id: vda-lvm}
- {type: lvm_volgroup, name: vg-ubuntu, devices: [vda-lvm], id: vg-ubuntu}
- {type: lvm_partition, volgroup: vg-ubuntu, id: lv-root, name: lv-root, size: -1}
- {type: format, fstype: ext4, volume: vda-boot, id: vda-boot-fs}
- {type: format, fstype: xfs, volume: lv-root, id: lv-root-fs}
- {type: mount, path: /, id: m-root, device: lv-root-fs}
- {type: mount, path: /boot, id: m-boot, device: vda-boot-fs}
user-data:
package_upgrade: true
timezone: Europe/Bucharest
users:
- name: devops
groups: [adm, sudo]
lock-passwd: false
sudo: ALL=(ALL) NOPASSWD:ALL
shell: /bin/bash
# passwd: your-password
ssh_authorized_keys:
- MyPublicKey
Я понятия не имею, связано ли это с новым iso-образом Ubuntu или с Packer, но поскольку та же конфигурация работает и в 20.04.4, я думаю, что это связано с чем-то новым, что было включено в последний релиз.
Есть ли у кого-нибудь идеи или опыт подобного?
Заранее спасибо за ваши ответы!
решение1
Судя по всему, я нашел временное решение вашей проблемы...
Я не уверен, подойдет ли это вам, или у нас могут возникнуть те же проблемы с qemu-guest-agent
возвратом Error 100
.
Вот мое обходное решение:
Я просто добавил late-commands
директиву в свой user-data
файл, которая будет запускаться apt-get update
и устанавливаться qemu-guest-agent
после срабатывания.
вот фрагмент user-data
:
#cloud-config
autoinstall:
...
late-commands:
- curtin in-target -- apt-get update
- curtin in-target -- apt-get install qemu-guest-agent
...
Я глубже изучил проблему, чтобы понять, почему это не удалось. По-видимому, удаление qemu-guest-agent
в списке пакетов заставляет все работать нормально. Когда я пытаюсь запустить предполагаемую команду внутри оболочки ошибки, она упоминает, что " qemu-guest-agent
не найден" при попытке установить этот пакет. Вот почему я пришел к этому решению, перечитывая документацию по автоматизированной установке сервера в Ubuntu. СогласнодокументацияЧто касается запуска команд на целевой машине, там написано, что вы должны добавлять curtin in-target --target=/target --
перед любой командой, чтобы она запускалась внутри целевой системы. В этом случае я хочу обновить исходники и установить qemu-guest-agent
, и это сработало, как и предполагалось. Я действительно чувствую, что может быть лучшее решение для этого, например, настройка директивы apt
и т. п. Надеюсь, этот обходной путь сработает в вашем случае...
решение2
Я увидел очень похожую проблему в своей среде и понял, что проблема была в том, что мне нужно было настроить корпоративный прокси-сервер так, чтобы разрешить apt/snapd выходить в Интернет.
В соответствии сСсылка на автоустановкуМне нужно было добавить следующее в файл пользовательских данных:
autoinstall:
...
proxy: http://<proxy.url>:<port-number>
...