How do you use a "cloud" image that doesn't enable cloud-init?

Incus
1

I have VMs based on “Ubuntu noble amd64 (20250911_07:42)” from the linux containers repo that started fine using the cloud-init config specified in the VM’s yaml config. Now I need to use a “jammy” image so I tried “Ubuntu jammy amd64 (20250919_07:42)” which is listed as a “cloud” image. Unfortunately, it seems to completely ignore the cloud-init config (which has hostname and passwords set) and comes up with a hostname of distrobuilder-655ecd39-5dd6-4bbd-a36c-38e14f29af08, no network and no way to log in. How are you supposed to use it?

2

Yeah, I know… mount the root filesystem on the host and run “passwd”. That’s not the answer I was looking for though :slight_smile:

3

Well, apparently the image also won’t run incus-agent and is ignoring device definitions to mount host directories so it’s pretty much unusable for me.

4

To identify an image from the project’s remote, you would use a name like images:ubuntu/22.04/cloud. Those images are updated often, hence the date ID.

Are you using the images from the project’s remote or are you generating your own images using the distrobuilder?

If you are using the project’s images and you found one iteration that cloud-init is not working as it should, then you found a bug?

5

Exact steps to reproduce? The following works for me:

# incus launch images:ubuntu/22.04/cloud foobar --vm <<'EOS'
config:
  cloud-init.network-config: |
    version: 2
    ethernets:
      enp5s0:
        dhcp4: false
        accept-ra: false
        addresses:
          - 1.2.3.4/24
        routes:
          - to: default
            via: 1.2.3.1
  cloud-init.user-data: |
    #cloud-config
    password: abcd1234
EOS

(wait)
# incus list foobar
+--------+---------+------------------+------+-----------------+-----------+
|  NAME  |  STATE  |       IPV4       | IPV6 |      TYPE       | SNAPSHOTS |
+--------+---------+------------------+------+-----------------+-----------+
| foobar | RUNNING | 1.2.3.4 (enp5s0) |      | VIRTUAL-MACHINE | 0         |
+--------+---------+------------------+------+-----------------+-----------+
# incus exec foobar -- grep ubuntu /etc/shadow
ubuntu:$y$j9T$OrmUd.0CpSQ9ukczReReV0$wYRBrkmJyxtYAnvl/v/tB.QQ4BAGC8RRvUbgjnKOcn5:0:0:99999:7:::

You can use:

incus shell <instance-name>

as long as the image has the incus-agent in it (which all the supplied ones do). Edit: unless as @simon says you found one particular broken image.

This is the one that got pulled in for me:

# incus image list
+-------+--------------+--------+-------------------------------------+--------------+-----------------+-----------+----------------------+
| ALIAS | FINGERPRINT  | PUBLIC |             DESCRIPTION             | ARCHITECTURE |      TYPE       |   SIZE    |     UPLOAD DATE      |
+-------+--------------+--------+-------------------------------------+--------------+-----------------+-----------+----------------------+
|       | 9ab4ce94970d | no     | Ubuntu jammy amd64 (20250920_07:42) | x86_64       | VIRTUAL-MACHINE | 308.97MiB | 2025/09/20 15:17 UTC |
+-------+--------------+--------+-------------------------------------+--------------+-----------------+-----------+----------------------+
# incus image show 9ab4ce94970d
auto_update: true
properties:
  architecture: amd64
  description: Ubuntu jammy amd64 (20250920_07:42)
  os: Ubuntu
  release: jammy
  serial: "20250920_07:42"
  type: disk-kvm.img
  variant: cloud
public: false
expires_at: 1970-01-01T00:00:00Z
profiles:
- default

(it’s worth checking whether incus image show gives variant: cloud for the one you’re using)

6

Well, the key was “incus-agent”. The Fedora (yes I should have mentioned the host was Fedora, sorry) incus-agent package is mistakenly linking incus-agent dynamically which means it will run fine with libc version 2.39 shipped with >=noble images but fails with 2.35 which is the version shipped with jammy.

In a Ubuntu 22.04.5 VM with libc6/jammy-updates,jammy-security,now 2.35-0ubuntu3.10 amd64 
# ldd /run/incus_agent/incus-agent
/run/incus_agent/incus-agent: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_ABI_DT_RELR' not found (required by /run/incus_agent/incus-agent)
        linux-vdso.so.1 (0x00007ffe66dc7000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2c0bb05000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f2c0cf47000)

When I rebuilt incus-agent with static linking and re-created the VM, it came up perfectly.

Sorry for the noise. :slight_smile:

Oh, if you’re interested, here’s the Fedora bug for this…

1 Like