NoCloud: Seed not support when using http-URL from DMI

[thannaske]

Bug report

When trying to contextualise a QEMU KVM using cloud-init with the NoCloud datasource where the seed comes from the BIOS Serial, the detection of that seed works but the datasource doesn't recognise it as valid seed.

Steps to reproduce the problem

Launch QEMU virtual machine with the following XML instruction for the BIOS:

<sysinfo type='smbios'>
    <system>
      <entry name='serial'>ds=nocloud-net;s=http://<URL>/api/service/v1/cloud-init/</entry>
    </system>
</sysinfo>

Alternatively, use ds=nocloud (or a https address), this doesn't work as well, although the documentation explicitly provides it as example. Make sure that the URL is reachable for the server and returns a properly configured cloud-init config set.

Environment details

• Cloud-init version: Tested on 23.4.3 and 22.1-14, logs look identical
• Operating System Distribution: Ubuntu 22.04, Ubuntu 20.04, Ubuntu 18.04
• Cloud provider, platform or installer type: NoCloud / QEMU

cloud-init logs

2024-02-24 13:25:23,015 - util.py[DEBUG]: Cloud-init v. 22.1-14-g2e17a0d6-0ubuntu1~22.04.5 running 'init-local' at Sat, 24 Feb 2024 13:25:22 +0000. Up 12.17 seconds.
2024-02-24 13:25:23,015 - main.py[DEBUG]: No kernel command line url found.
2024-02-24 13:25:23,015 - main.py[DEBUG]: Closing stdin.
2024-02-24 13:25:23,034 - util.py[DEBUG]: Writing to /var/log/cloud-init.log - ab: [644] 0 bytes
2024-02-24 13:25:23,035 - util.py[DEBUG]: Changing the ownership of /var/log/cloud-init.log to 104:4
2024-02-24 13:25:23,035 - util.py[DEBUG]: Writing to /var/lib/cloud/data/python-version - wb: [644] 4 bytes
2024-02-24 13:25:23,035 - util.py[DEBUG]: Attempting to remove /var/lib/cloud/instance/boot-finished
2024-02-24 13:25:23,035 - util.py[DEBUG]: Attempting to remove /var/lib/cloud/data/no-net
2024-02-24 13:25:23,036 - handlers.py[DEBUG]: start: init-local/check-cache: attempting to read from cache [check]
2024-02-24 13:25:23,036 - util.py[DEBUG]: Reading from /var/lib/cloud/instance/obj.pkl (quiet=False)
2024-02-24 13:25:23,036 - stages.py[DEBUG]: no cache found
2024-02-24 13:25:23,036 - handlers.py[DEBUG]: finish: init-local/check-cache: SUCCESS: no cache found
2024-02-24 13:25:23,036 - util.py[DEBUG]: Attempting to remove /var/lib/cloud/instance
2024-02-24 13:25:23,046 - stages.py[DEBUG]: Using distro class <class 'cloudinit.distros.ubuntu.Distro'>
2024-02-24 13:25:23,046 - __init__.py[DEBUG]: Looking for data source in: ['NoCloud', 'None'], via packages ['', 'cloudinit.sources'] that matches dependencies ['FILESYSTEM']
2024-02-24 13:25:23,050 - __init__.py[DEBUG]: Searching for local data source in: ['DataSourceNoCloud']
2024-02-24 13:25:23,051 - handlers.py[DEBUG]: start: init-local/search-NoCloud: searching for local data from DataSourceNoCloud
2024-02-24 13:25:23,051 - __init__.py[DEBUG]: Seeing if we can get any data from <class 'cloudinit.sources.DataSourceNoCloud.DataSourceNoCloud'>
2024-02-24 13:25:23,051 - __init__.py[DEBUG]: Update datasource metadata and network config due to events: boot-new-instance
2024-02-24 13:25:23,051 - dmi.py[DEBUG]: querying dmi data /sys/class/dmi/id/product_serial
2024-02-24 13:25:23,051 - util.py[DEBUG]: Reading from /var/lib/cloud/seed/nocloud/user-data (quiet=False)
2024-02-24 13:25:23,051 - util.py[DEBUG]: Reading from /var/lib/cloud/seed/nocloud/meta-data (quiet=False)
2024-02-24 13:25:23,051 - util.py[DEBUG]: Reading from /var/lib/cloud/seed/nocloud/vendor-data (quiet=False)
2024-02-24 13:25:23,051 - util.py[DEBUG]: Reading from /var/lib/cloud/seed/nocloud/network-config (quiet=False)
2024-02-24 13:25:23,051 - util.py[DEBUG]: Reading from /var/lib/cloud/seed/nocloud-net/user-data (quiet=False)
2024-02-24 13:25:23,052 - util.py[DEBUG]: Reading from /var/lib/cloud/seed/nocloud-net/meta-data (quiet=False)
2024-02-24 13:25:23,052 - util.py[DEBUG]: Reading from /var/lib/cloud/seed/nocloud-net/vendor-data (quiet=False)
2024-02-24 13:25:23,052 - util.py[DEBUG]: Reading from /var/lib/cloud/seed/nocloud-net/network-config (quiet=False)
2024-02-24 13:25:23,052 - subp.py[DEBUG]: Running command ['blkid', '-tTYPE=vfat', '-odevice'] with allowed return codes [0, 2] (shell=False, capture=True)
2024-02-24 13:25:23,105 - subp.py[DEBUG]: Running command ['blkid', '-tTYPE=iso9660', '-odevice'] with allowed return codes [0, 2] (shell=False, capture=True)
2024-02-24 13:25:23,113 - subp.py[DEBUG]: Running command ['blkid', '-tLABEL=CIDATA', '-odevice'] with allowed return codes [0, 2] (shell=False, capture=True)
2024-02-24 13:25:23,121 - subp.py[DEBUG]: Running command ['blkid', '-tLABEL=cidata', '-odevice'] with allowed return codes [0, 2] (shell=False, capture=True)
2024-02-24 13:25:23,125 - subp.py[DEBUG]: Running command ['blkid', '-tLABEL_FATBOOT=cidata', '-odevice'] with allowed return codes [0, 2] (shell=False, capture=True)
2024-02-24 13:25:23,133 - DataSourceNoCloud.py[DEBUG]: Seed from https://<URL>/api/service/v1/cloud-init/ not supported by DataSourceNoCloud [seed=None][dsmode=net]
2024-02-24 13:25:23,134 - __init__.py[DEBUG]: Datasource DataSourceNoCloud [seed=None][dsmode=net] not updated for events: boot-new-instance
2024-02-24 13:25:23,134 - handlers.py[DEBUG]: finish: init-local/search-NoCloud: SUCCESS: no local data found from DataSourceNoCloud

[OnitiFR]

We've the same issue here since 23.4.3 (it was fine with 23.4.2), our smbios / DataSourceNoCloud config is not read anymore. I don't know why the issue is closed, have you found any fix?

I see in the 23.4.3 changelog that something changed about "systemctl dbus not ready" and I see a related error message in the console:

cloud-init[323]: 2024-02-26 09:01:21,561 - activators.py[WARNING]: Running ['netplan', 'apply'] resulted in stderr output: Failed to connect system bus: No such file or directory
cloud-init[323]: Falling back to a hard restart of systemd-networkd.service

Any help would be awesome, we can't use Ubuntu anymore for our VMs 😅

[thannaske]

Duplicate of #4945

We're in the same situation, Ubuntu installations are completely broken right now. I have little hope that this is fixed with the necessary urgency :/

[holmanb]

For anyone who stumbles across this issue, the fix is released in the latest Ubuntu cloud images