☰

qemu-guest-agent schlägt bei der automatischen Installation fehl

tag-icon • tag-icon kvm-virtualization
qemu-guest-agent schlägt bei der automatischen Installation fehl

Dies ist mein erster Beitrag hier, also haben Sie bitte Geduld :)

Ich versuche, ein Ubuntu 20.04.5-Image mit Packer (1.8.4) auf Proxmox (7.2-11) zu erstellen. Alles scheint gut zu funktionieren (IP abrufen, Cloud-Init-Konfiguration über HTTP lesen, Installation starten, Kernel installieren), bis zur Installation von qemu-guest-agent mit Subiquity. Der Installationsbefehl kann nicht ausgeführt werden, es wird ein Absturzbericht generiert und Sie werden aufgefordert, die Eingabetaste zu drücken, um ein Terminal zu erhalten. Beim 20.04.4 ISO-Image funktioniert alles mit genau derselben Konfiguration in Packer einwandfrei.

Cloud-Init-Konfiguration:

#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

Ich habe keine Ahnung, ob dies vom neuen ISO oder Packer von Ubuntu stammt, aber da die gleiche Konfiguration für 20.04.4 funktioniert, denke ich, dass es von etwas Neuem stammt, das in der letzten Version enthalten war.

Hat jemand eine Idee oder gleiche Erfahrungen gemacht?

Vielen Dank im Voraus für Ihre Antworten!

Antwort1

Offenbar habe ich für Ihr Problem eine Notlösung gefunden ...

qemu-guest-agentIch bin nicht sicher, ob es für Sie funktionieren würde oder ob bei der Rücksendung möglicherweise dasselbe Problem auftritt Error 100.

Dies ist meine Workaround-Lösung:

Ich habe late-commandsmeiner Datei einfach eine Anweisung hinzugefügt, mit der es nachträglich user-dataausgeführt apt-get updateund installiert wird.qemu-guest-agent

hier ist ein Ausschnitt davon user-data:

#cloud-config
autoinstall:
...
  late-commands:
    - curtin in-target -- apt-get update
    - curtin in-target -- apt-get install qemu-guest-agent
...

Ich habe mir das Problem genauer angesehen, warum es fehlgeschlagen ist. Anscheinend qemu-guest-agentfunktioniert alles einwandfrei, wenn ich es aus der Liste der Pakete entferne. Wenn ich versuche, den angeblichen Befehl in der Fehler-Shell auszuführen, wird qemu-guest-agentbeim Versuch, dieses Paket zu installieren, angezeigt, dass „nicht gefunden“ wurde. Aus diesem Grund bin ich auf diese Lösung gekommen, als ich die Dokumentation zur automatisierten Serverinstallation in Ubuntu erneut gelesen habe. Laut derDokumentationIn Bezug auf das Ausführen von Befehlen auf dem Zielcomputer steht dort, dass Sie curtin in-target --target=/target --vor jedem Befehl Folgendes hinzufügen sollten, damit dieser im Zielsystem ausgeführt wird. In diesem Fall möchte ich die Quellen aktualisieren und installieren qemu-guest-agent, und es hat wie vorgesehen funktioniert. Ich denke jedoch, dass es dafür eine bessere Lösung geben könnte, beispielsweise die Konfiguration der aptDirektive und dergleichen. Hoffentlich funktioniert dieser Workaround in Ihrem Fall ...

Antwort2

Ich habe in meiner Umgebung ein sehr ähnliches Problem wie Sie festgestellt und festgestellt, dass mein Problem darin bestand, dass ich meinen Unternehmensproxy so einrichten musste, dass apt/snapd auf das Internet zugreifen können.

Gemäß derAutoinstall-ReferenzIch musste meiner Benutzerdatendatei Folgendes hinzufügen:

    autoinstall:
    ...
      proxy: http://<proxy.url>:<port-number>
    ...

verwandte Informationen