I’m hitting the same issue as you on a Debian 12.6 incus host:
kim@debian:~$ incus launch images:rockylinux/9/cloud r9c
kim@debian:~$ incus exec r9c -- cloud-init status -l
status: error
extended_status: error
boot_status_code: enabled-by-generator
last_update: Mon, 01 Jul 2024 02:56:03 +0000
detail:
DataSourceNoCloud [seed=/var/lib/cloud/seed/nocloud-net][dsmode=net]
errors:
- ('set_hostname', SetHostnameError("Failed to set the hostname to r9c (r9c): Unexpected error while running command.\nCommand: ['hostnamectl', 'set-hostname', 'r9c']\nExit code: 1\nReason: -\nStdout: \nStderr: Could not set pretty hostname: Could not activate remote peer."))
recoverable_errors:
WARNING:
- Failed to set the hostname to r9c (r9c)
- Unable to get zpool status of default: Unexpected error while running command. Command: ['zpool', 'status', 'default'] Exit code: - Reason: [Errno 2] No such file or directory: b'zpool' Stdout: - Stderr: -
- Failed to set the hostname to r9c (r9c)
- Running module set_hostname (<module 'cloudinit.config.cc_set_hostname' from '/usr/lib/python3.9/site-packages/cloudinit/config/cc_set_hostname.py'>) failed
- Failed to set the hostname to r9c (r9c)
A rockylinux/8/cloud instance also has the same error but a debian/12/cloud instance works fine.
Yet on another system, a Ubuntu 22.04 incus host it works fine.
kim@ubuntu:~$ incus launch images:rockylinux/9/cloud r9c
kim@ubuntu:~$ incus exec r2 -- cloud-init status -l
status: done
extended_status: done
boot_status_code: enabled-by-generator
last_update: Mon, 01 Jul 2024 03:10:08 +0000
detail:
DataSourceNoCloud [seed=/var/lib/cloud/seed/nocloud-net][dsmode=net]
errors: []
recoverable_errors: {}
Also working on another Debian 12.5 WSL system:
kim@deb2:~$ incus launch images:rockylinux/9/cloud r3
Launching r3
kim@deb2:~$ incus exec r3 -- cloud-init status -l
status: done
extended_status: done
boot_status_code: enabled-by-generator
last_update: Mon, 01 Jul 2024 03:21:26 +0000
detail:
DataSourceNoCloud [seed=/var/lib/cloud/seed/nocloud-net][dsmode=net]
errors: []
recoverable_errors: {}
On yet another Debian 12 system it’s not working but I found it does work after the instance is restarted:
kim@cube:~$ incus launch images:rockylinux/9/cloud r9c
Launching r9c
kim@cube:~$ incus exec r9c -- cloud-init status -l
status: error
extended_status: error
boot_status_code: enabled-by-generator
last_update: Mon, 01 Jul 2024 04:49:54 +0000
detail:
DataSourceNoCloud [seed=/var/lib/cloud/seed/nocloud-net][dsmode=net]
errors:
- ('set_hostname', SetHostnameError("Failed to set the hostname to r9c (r9c): Unexpected error while running command.\nCommand: ['hostnamectl', 'set-hostname', 'r9c']\nExit code: 1\nReason: -\nStdout: \nStderr: Could not set pretty hostname: Could not activate remote peer."))
recoverable_errors:
WARNING:
- Failed to set the hostname to r9c (r9c)
- Failed to set the hostname to r9c (r9c)
- Running module set_hostname (<module 'cloudinit.config.cc_set_hostname' from '/usr/lib/python3.9/site-packages/cloudinit/config/cc_set_hostname.py'>) failed
- Failed to set the hostname to r9c (r9c)
kim@cube:~$ incus restart r9c
kim@cube:~$ incus exec r9c -- cloud-init status -l
status: running
extended_status: degraded running
boot_status_code: enabled-by-generator
last_update: Mon, 01 Jul 2024 04:50:15 +0000
detail:
Running in stage: init
errors: []
recoverable_errors:
WARNING:
- Failed to set the hostname to r9c (r9c)
In my use case I wait for cloud-init status to be done before running further automated tests. So on the debian and cube hosts this is broken, but it works on the debian wsl host (deb2).
Disabling apparmor before starting the instance seems to work:
kim@cube:~$ incus init images:rockylinux/9/cloud r9
Creating r9
kim@cube:~$ incus config set r9 raw.lxc lxc.apparmor.profile=unconfined
kim@cube:~$ incus start r9
kim@cube:~$ incus exec r9 -- cloud-init status -l
status: done
extended_status: done
boot_status_code: enabled-by-generator
last_update: Mon, 01 Jul 2024 05:57:10 +0000
detail:
DataSourceNoCloud [seed=/var/lib/cloud/seed/nocloud-net][dsmode=net]
errors: []
recoverable_errors: {}
So does that mean something in the apparmor profile is blocking hostnamectl with the debian kernel (6.1.0-22-amd64) but not with the WSL2 kernel (5.15.153.1-microsoft-standard-WSL2) or the ubuntu kernel (6.2.0-39-generic)?