cloud-init unable to run on Debian 11 cloud image

Bash:
boot: c
bootdisk: scsi0
cipassword: $5$5RQ5VuBW$ub0BIkZd1CDcpC3GSu.x/cF5LSW8Ewkn9NC6Qa7CjS2
ciuser: testuser
cores: 2
ide2: vm-hdd01:vm-101-cloudinit,media=cdrom,size=4M
ipconfig0: ip=10.1.1.88/20,gw=10.1.0.1
machine: q35
memory: 4096
meta: creation-qemu=7.2.0,ctime=1686953694
name: debian-test
net0: virtio=62:BC:FD:50:B1:E1,bridge=vmbr0
numa: 1
scsi0: vm-hdd01:vm-101-disk-0,size=2G
scsihw: virtio-scsi-pci
smbios1: uuid=9409adb7-6f74-46ac-a220-6b2015362fcd
tags: cloud-init
vga: virtio
vmgenid: 1048b160-4ea6-435b-996a-cbfd6da643fc

Since this is one I specially created for testing I don’t redact the password hash
@oscar13sd
 
Bash:
boot: c
bootdisk: scsi0
cipassword: $5$5RQ5VuBW$ub0BIkZd1CDcpC3GSu.x/cF5LSW8Ewkn9NC6Qa7CjS2
ciuser: testuser
cores: 2
ide2: vm-hdd01:vm-101-cloudinit,media=cdrom,size=4M
ipconfig0: ip=10.1.1.88/20,gw=10.1.0.1
machine: q35
memory: 4096
meta: creation-qemu=7.2.0,ctime=1686953694
name: debian-test
net0: virtio=62:BC:FD:50:B1:E1,bridge=vmbr0
numa: 1
scsi0: vm-hdd01:vm-101-disk-0,size=2G
scsihw: virtio-scsi-pci
smbios1: uuid=9409adb7-6f74-46ac-a220-6b2015362fcd
tags: cloud-init
vga: virtio
vmgenid: 1048b160-4ea6-435b-996a-cbfd6da643fc

Since this is one I specially created for testing I don’t redact the password hash
@oscar13sd

No idea if this will make a difference for you, but when I spun up a new instance with machine: q35, cloud-init did not complete successfully. I tried this multiple times between q35 and i440fx, and every time was consistent. Maybe try a new instance with i440fx?
 
No idea if this will make a difference for you, but when I spun up a new instance with machine: q35, cloud-init did not complete successfully. I tried this multiple times between q35 and i440fx, and every time was consistent. Maybe try a new instance with i440fx?
Never think of this kind of problem, I’ll try that
 
No idea if this will make a difference for you, but when I spun up a new instance with machine: q35, cloud-init did not complete successfully. I tried this multiple times between q35 and i440fx, and every time was consistent. Maybe try a new instance with i440fx?
So now I tried to create both password login and ssh key login with i440fx machine type, and both with success. I would consider this as bug. Maybe because protomox use debian as it’s base system.
 
  • Like
Reactions: oscar13sd
I'd just like to let others know that I was experiencing the same issue with Debian 12 which came out quite recently, and I found that the cloud-init script would not run on the downloaded "genericcloud" image (https://cloud.debian.org/images/cloud/bookworm/latest/debian-12-genericcloud-amd64.qcow2), but would run on the "generic" image (https://cloud.debian.org/images/cloud/bookworm/latest/debian-12-generic-amd64.qcow2).
Maybe I am misunderstanding, but I am able to get cloud-init to run on the debian-12-genericcloud-amd64.qcow2 image. Are you getting some kind of error? Are you running cloud-init through the proxmox web interface (I am running it via custom yml files).
 
Maybe I am misunderstanding, but I am able to get cloud-init to run on the debian-12-genericcloud-amd64.qcow2 image. Are you getting some kind of error? Are you running cloud-init through the proxmox web interface (I am running it via custom yml files).
You are understanding correctly, but I will confess that I am doing this "raw" through virt on KVM, rather than proxmox, using manual config files. Perhaps there is something proxmox differently even though it is still KVM based, that allows cloud-init to run, but not for me, when using the genericcloud image.

For reference, below is an example cloud-init.cfg file that would set up a user called "kim" and password "possible":

YAML:
#cloud-config
hostname: template-debian-12
manage_etc_hosts: false
ssh_pwauth: false
disable_root: true
users:
- name: kim
hashed_passwd: $6$rounds=4096$thisIsASaltStrin$3o4L.8EKhHkNHEjD89SLF3..OfgVrqJ02Kp/7zZetSR/jDQzkyuwJ7RzB4Km9hYjTICak9RAUMo0/3PENZFwM0
sudo: ALL=(ALL) NOPASSWD:ALL
shell: /bin/bash
lock-passwd: false
ssh_authorized_keys:
- ssh-rsa AAAAB3NzaC1ycREDACTED=
stuart@stuart-r7-1700

...and this is the virt-install command I use to perform the addition of the new guest to KVM:

Bash:
sudo virt-install \
  --name $VM_NAME \
  --memory 1024 \
  --disk template-debian-12-replacement.qcow2,device=disk,bus=virtio \
  --disk /home/stuart/kvm/templates/template-debian-12-replacement/cloud-init.iso,device=cdrom \
  --os-type linux \
  --os-variant debian10 \
  --virt-type kvm \
  --graphics none \
  --network network=default,model=virtio \
  --import

Perhaps there is something in the way I am doing things, that requires one or more of the hardward drives provided in the generic, but not in the genericcloud image? I ran the exact same set of steps on the generic, and it worked fine.

The physical hardware of the KVM hypervisor is Debian 10 with a AMD Ryzen 5 3500X 6-Core processor.
 
Last edited:
You are understanding correctly, but I will confess that I am doing this "raw" through virt on KVM, rather than proxmox, using manual config files. Perhaps there is something proxmox differently even though it is still KVM based, that allows cloud-init to run, but not for me, when using the genericcloud image.

For reference, below is an example cloud-init.cfg file that would set up a user called "kim" and password "possible":

YAML:
#cloud-config
hostname: template-debian-12
manage_etc_hosts: false
ssh_pwauth: false
disable_root: true
users:
- name: kim
hashed_passwd: $6$rounds=4096$thisIsASaltStrin$3o4L.8EKhHkNHEjD89SLF3..OfgVrqJ02Kp/7zZetSR/jDQzkyuwJ7RzB4Km9hYjTICak9RAUMo0/3PENZFwM0
sudo: ALL=(ALL) NOPASSWD:ALL
shell: /bin/bash
lock-passwd: false
ssh_authorized_keys:
- ssh-rsa AAAAB3NzaC1ycREDACTED=
stuart@stuart-r7-1700

...and this is the virt-install command I use to perform the addition of the new guest to KVM:

Bash:
sudo virt-install \
  --name $VM_NAME \
  --memory 1024 \
  --disk template-debian-12-replacement.qcow2,device=disk,bus=virtio \
  --disk /home/stuart/kvm/templates/template-debian-12-replacement/cloud-init.iso,device=cdrom \
  --os-type linux \
  --os-variant debian10 \
  --virt-type kvm \
  --graphics none \
  --network network=default,model=virtio \
  --import

Perhaps there is something in the way I am doing things, that requires one or more of the hardward drives provided in the generic, but not in the genericcloud image? I ran the exact same set of steps on the generic, and it worked fine.

The physical hardware of the KVM hypervisor is Debian 10 with a AMD Ryzen 5 3500X 6-Core processor.

I don't know virt-install, but my qm create arguments are fairly similar.

"the cloud-init script would not run"
Do you mean that when you run it with the genericcloud image, you can't log in because the user/password is not created? The only issue I had with the debian 12 genericcloud image was that I had to create a network.yml file to get an ip. While debian 11 genericcloud automatically configured it with only a user.yml.
 
I don't know virt-install, but my qm create arguments are fairly similar.

"the cloud-init script would not run"
Do you mean that when you run it with the genericcloud image, you can't log in because the user/password is not created? The only issue I had with the debian 12 genericcloud image was that I had to create a network.yml file to get an ip. While debian 11 genericcloud automatically configured it with only a user.yml.
When I say the cloud init script would not run, I *assumed* this based on the fact that I can usually recognize parts of it it as its output flies past on boot. It generally has some ascii table art type stuff etc. I also didnt have my user login configured, which it sets up for me, which worked from the exact same config/commands I ran for genericcloud. I need to look into how to find all of the startup output text, in order to read through it for an error message. No doubt I will be able to see it from a journalctl command or a log file.
 
When I say the cloud init script would not run, I *assumed* this based on the fact that I can usually recognize parts of it it as its output flies past on boot. It generally has some ascii table art type stuff etc. I also didnt have my user login configured, which it sets up for me, which worked from the exact same config/commands I ran for genericcloud. I need to look into how to find all of the startup output text, in order to read through it for an error message. No doubt I will be able to see it from a journalctl command or a log file.

The cloud-init logs are (at least on debian 12 genericcloud):

/var/log/cloud-init-output.log
/var/log/cloud-init.log
 
@Programster Your experience with virt-install could be translated as:
Two people having a conversation about a problem they are having with a Ferrari and special custom module, and you joined saying that your car is also not working, except your built both the car and module out of parts in your garage.

Just to highlight a few actual technical issues with your situation:
- You do not show how you build the ISO. In PVE this process is automated and completely masked from user. In your case - its critical that this is done properly.
- You mention "cloud-init.cfg" file, but thats an incorrect naming for a properly built ISO. The only valid files are: user-data, meta-data, vendor-data, network-data). Its critical that they are properly formatted and located in correct place on ISO.
- Unless you lost formating due to forum copy/paste - your YAML is incorrect. The easiest way to illustrate it - is to plug your yaml here: https://onlineyamltools.com/convert-yaml-to-json
A somewhat correct format should be:
Code:
---
hostname: template-debian-12
manage_etc_hosts: false
ssh_pwauth: false
disable_root: true
users:
  - name: kim
    hashed_passwd: $6$rounds=4096$thisIsASaltStrin$3o4L.8EKhHkNHEjD89SLF3..OfgVrqJ02Kp/7zZetSR/jDQzkyuwJ7RzB4Km9hYjTICak9RAUMo0/3PENZFwM0
    sudo: ALL=(ALL) NOPASSWD:ALL
    shell: /bin/bash
    lock-passwd: false
    ssh_authorized_keys:
      - ssh-rsa AAAAB3NzaC1ycREDACTED=

Finally, if you are set on creating things manually - later versions of virt-install include a special option that lets you specify files directly:
Code:
 --cloud-init
       Pass  cloud-init  metadata  to  the  VM.  A  cloud-init NoCloud ISO file is generated, and
       attached to the VM as a CDROM device. The device is only attached for the first boot. This
       option is particularly useful for distro cloud images, which have locked login accounts by
       default; --cloud-init provides the means to initialize those login accounts, like  setting
       a root password.

Good luck


Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
  • Like
Reactions: oscar13sd
Maybe I am misunderstanding, but I am able to get cloud-init to run on the
debian-12-genericcloud-amd64.qcow2
image. Are you getting some kind of error? Are you running cloud-init through the proxmox web interface (I am running it via custom yml files).
similar troubles using the ProxMox 7.4 GUI interface with the debian-12-genericcloud-amd64.qcow2
 
Using PVE built-in cloud-init:
Code:
root@pve7opt6nvme-1:~# STORAGE=local-lvm VMID=501 ./vm_create.sh
importing disk '/mnt/pve/bbnas/template/iso/debian-12-genericcloud-amd64.qcow2' to VM 501 ...
transferred 0.0 B of 2.0 GiB (0.00%)
..
Successfully imported disk as 'unused0:local-lvm:vm-501-disk-0'
update VM 501: -scsi0 local-lvm:vm-501-disk-0 -scsihw virtio-scsi-pci
update VM 501: -net0 virtio,bridge=vmbr0,firewall=1
update VM 501: -ide2 local-lvm:cloudinit
ide2: successfully created disk 'local-lvm:vm-501-cloudinit,media=cdrom'
generating cloud-init ISO
update VM 501: -serial0 socket -vga serial0
update VM 501: -boot c -bootdisk scsi0
update VM 501: -ipconfig0 ip=dhcp
update VM 501: -sshkeys ssh-rsa%20AAAA..
root@pve7opt6nvme-1:~# qm start 501
generating cloud-init ISO
root@pve7opt6nvme-1:~# ssh debian@172.16.150.35

Linux vm501 6.1.0-9-cloud-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
debian@vm501:~$

from "qm terminal 501"
Code:
[   11.009610] cloud-init[273]: Cloud-init v. 22.4.2 running 'init-local' at Fri, 14 Jul 2023 00:12:59 +0000. Up 10.94 seconds.
[  OK  ] Finished apparmor.service - Load AppArmor profiles.
[   11.636971] virtio_net virtio2 eth0: renamed from ens18
[  OK  ] Finished cloud-init-local.…l cloud-init job (pre-networking).
[  OK  ] Reached target network-pre…get - Preparation for Network.
         Starting systemd-networkd.…ice - Network Configuration...
[  OK  ] Started systemd-networkd.service - Network Configuration.
[  OK  ] Reached target network.target - Network.
         Starting systemd-networkd-…it for Network to be Configured...
[  OK  ] Finished systemd-networkd-…Wait for Network to be Configured.
         Starting cloud-init.servic… job (metadata service crawler)...

P.S. identical results with debian-12-generic-amd64.qcow2 and debian-12-genericcloud-amd64.qcow2


Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
Last edited:
are you using scsi and UEFI by any chance?
i have a similar issue where if i set cloudinit to use IDE any cloudimage wont load up the cloud-init drive
BUT
change the cloudinit drive to isci and it works a treat!
i made an script here to setup a template for ubuntu 22.04 - https://gist.github.com/si458/98aa940837784e9ef9bff9e24a7a8bfd
 
Last edited:
What does that mean? You can't log in? You can't ssh into it? No video?
that, when you look at the replied posts, using the PVE 7.4 GUI, to configure the CloudInit for Debian 12 cloudinit images, it doesn't configure the needed and the vm doesn't boot right
 
that, when you look at the replied posts, using the PVE 7.4 GUI, to configure the CloudInit for Debian 12 cloudinit images, it doesn't configure the needed and the vm doesn't boot right
"it doesn't configure the needed"

Ok, that makes more sense...

FYI, this post has been hijacked multiple times. If you want to be vague, good luck.
 
are you using scsi and UEFI by any chance?
i have a similar issue where if i set cloudinit to use IDE any cloudimage wont load up the cloud-init drive
BUT
change the cloudinit drive to isci and it works a treat!
i made an script here to setup a template for ubuntu 22.04 - https://gist.github.com/si458/98aa940837784e9ef9bff9e24a7a8bfd
This was my problem with setting up debian cloud image as I am using UEFI
After changing from ide to scsi everything works as expected
Thank you
 
  • Like
Reactions: fdcastel
@Programster Your experience with virt-install could be translated as:
Two people having a conversation about a problem they are having with a Ferrari and special custom module, and you joined saying that your car is also not working, except your built both the car and module out of parts in your garage.

Just to highlight a few actual technical issues with your situation:
- You do not show how you build the ISO. In PVE this process is automated and completely masked from user. In your case - its critical that this is done properly.
- You mention "cloud-init.cfg" file, but thats an incorrect naming for a properly built ISO. The only valid files are: user-data, meta-data, vendor-data, network-data). Its critical that they are properly formatted and located in correct place on ISO.
- Unless you lost formating due to forum copy/paste - your YAML is incorrect. The easiest way to illustrate it - is to plug your yaml here: https://onlineyamltools.com/convert-yaml-to-json
A somewhat correct format should be:
Code:
---
hostname: template-debian-12
manage_etc_hosts: false
ssh_pwauth: false
disable_root: true
users:
  - name: kim
    hashed_passwd: $6$rounds=4096$thisIsASaltStrin$3o4L.8EKhHkNHEjD89SLF3..OfgVrqJ02Kp/7zZetSR/jDQzkyuwJ7RzB4Km9hYjTICak9RAUMo0/3PENZFwM0
    sudo: ALL=(ALL) NOPASSWD:ALL
    shell: /bin/bash
    lock-passwd: false
    ssh_authorized_keys:
      - ssh-rsa AAAAB3NzaC1ycREDACTED=

Finally, if you are set on creating things manually - later versions of virt-install include a special option that lets you specify files directly:
Code:
 --cloud-init
       Pass  cloud-init  metadata  to  the  VM.  A  cloud-init NoCloud ISO file is generated, and
       attached to the VM as a CDROM device. The device is only attached for the first boot. This
       option is particularly useful for distro cloud images, which have locked login accounts by
       default; --cloud-init provides the means to initialize those login accounts, like  setting
       a root password.

Good luck


Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox



I created my cloud-init.iso file from my cloud-init.cfg file by running the following command:

Code:
sudo cloud-localds \
  cloud-init.iso \
  cloud-init.cfg
(for this you need to have the cloud-utils package installed).


I know the YAML for my cloud-init config is okay locally, but i messed up the formatting when redacting the multi-line public SSH key and pasting it here. if one simply takes out the last line that had the wrapped end of the public key, then it is valid YAML. YAML can be formatted in a lot of different ways and certain things such as the `---` are not actually required.

Selection_215.png


I appreciate that me using KVM with virt/virfsh may be quite different because I'm not using the qm commands and proxmox. However what I'm trying to get at is that I believe there is actually with the genericcloud image provided as I was able to get it to work with the generic image withthe same cloud-init configuration. For now I have put it down to the issue with growpart as outlined here: [https://bugs.debian.org/cgi-bin/bug...debian.org/cgi-bin/bugreport.cgi?bug=1065875)
 
Last edited:

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!