cloud-init starts as hostname ubuntu with dhcp before setting the real hostname

[Jens Glathe]

Hi there, noticed a thing when setting up a Raspberry Pi 4 (CM4) with an ubuntu 22.04.1 server image, but I suspect it might affect more.

I used this how-to:

https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#1-overview

and it worked the second time. :) Sort of.

The module is a Raspberry Pi Compute Module 4 Rev 1.1, CM4002016, no WLAN, 2GB RAM, 16GB eMMC drive. Omitting the WLAN settings when writing the image with the Pi Imager helped, otherwise the module won't be reachable by network, even if there is a cable on eth0 or via USB eth adapter. That as an aside.

Now to the real issue: Giving all the data includes hostname, user / pass, ssh key. They will be set up correctly. However, when the module boots up the first time with the new image and cloud-init does its thing, it announces itself as hostname "ubuntu" to the DHCP server. Okay, why not, but why? Later on (20 minutes later, after completing sudo apt-get update and sudo apt-get dist-upgrade, and restarting of affected services) it correctly announces and registers with the desired hostname.

2022-10-16T14:48:56.765932496Z DHCPDISCOVER from e4:5f:01:b7:98:68 via ovs_eth0
2022-10-16T14:48:57.766149505Z DHCPOFFER on 192.168.0.157 to e4:5f:01:b7:98:68 (ubuntu) via ovs_eth0
2022-10-16T14:48:57.838722880Z DHCPREQUEST for 192.168.0.157 (192.168.0.14) from e4:5f:01:b7:98:68 (ubuntu) via ovs_eth0
2022-10-16T14:48:57.854729080Z DHCPACK on 192.168.0.157 to e4:5f:01:b7:98:68 (ubuntu) via ovs_eth0
2022-10-16T14:48:58.008077549Z Added new forward map from ubuntu.haus.lokal to 192.168.0.157
2022-10-16T14:48:58.150293327Z Added reverse map from 157.0.168.192.in-addr.arpa. to ubuntu.haus.lokal
2022-10-16T15:09:31.369843970Z DHCPDISCOVER from e4:5f:01:b7:98:68 (ubuntu) via ovs_eth0
2022-10-16T15:09:32.370471525Z DHCPOFFER on 192.168.0.157 to e4:5f:01:b7:98:68 (cmfour02) via ovs_eth0
2022-10-16T15:09:32.372325758Z DHCPREQUEST for 192.168.0.157 (192.168.0.14) from e4:5f:01:b7:98:68 (cmfour02) via ovs_eth0
2022-10-16T15:09:32.428124851Z Wrote 93 leases to leases file.
2022-10-16T15:09:32.469561052Z DHCPACK on 192.168.0.157 to e4:5f:01:b7:98:68 (cmfour02) via ovs_eth0
2022-10-16T15:09:32.598233888Z Removed forward map from ubuntu.haus.lokal to 192.168.0.157
2022-10-16T15:09:32.889359255Z Removed reverse map on 157.0.168.192.in-addr.arpa.
2022-10-16T15:09:33.005177086Z Added new forward map from cmfour02.haus.lokal to 192.168.0.157
2022-10-16T15:09:33.130294611Z Added reverse map from 157.0.168.192.in-addr.arpa. to cmfour02.haus.lokal

This is a bit odd, and given that the right hostname was available, I would suspect some order of execution issue.

$ lsb_release -rd
Description: Ubuntu 22.04.1 LTS
Release: 22.04

apt-cache policy cloud-init
cloud-init:
  Installed: 22.3.4-0ubuntu1~22.04.1
  Candidate: 22.3.4-0ubuntu1~22.04.1
  Version table:
 *** 22.3.4-0ubuntu1~22.04.1 500
        500 http://ports.ubuntu.com/ubuntu-ports jammy-updates/main arm64 Packages
        100 /var/lib/dpkg/status
     22.2-0ubuntu1~22.04.3 500
        500 http://ports.ubuntu.com/ubuntu-ports jammy-security/main arm64 Packages
     22.1-14-g2e17a0d6-0ubuntu1~22.04.5 500
        500 http://ports.ubuntu.com/ubuntu-ports jammy/main arm64 Packages

with best regards

Jens Glathe

[Marc Deslauriers (mdeslaur)]

Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.

[Brett Holman (holmanb)]

Hi Jens,

Thank you for reporting! I added the server autoinstaller project (subiquity) to this bug, since it drives cloud-init configuration during installs.

> Now to the real issue: Giving all the data includes hostname, user / pass, ssh key. They will be set up correctly. However, when the module boots up the first time with the new image and cloud-init does its thing, it announces itself as hostname "ubuntu" to the DHCP server. Okay, why not, but why?

Cloud-init is typically used to get configuration data during early boot (often from a remote http server), which requires bringing up an ephemeral network connection before configuration data is known. In early boot stage, dhcp without knowing the configured hostname is a common way to accomplish this.

Can you please explain why a dhcp request with a temporary hostname is a bug?

[Launchpad Janitor (janitor)]

[Expired for subiquity because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for cloud-init because there has been no activity for 60 days.]

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/4037