yahoo-eng-team team mailing list archive

[Brett Holman <1993068@xxxxxxxxxxxxxxxxxx>]

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?

** No longer affects: cloud-init (Ubuntu)

** Changed in: cloud-init
       Status: New => Incomplete

** Changed in: subiquity
       Status: New => Incomplete

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1993068

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

Status in cloud-init:
  Incomplete
Status in subiquity:
  Incomplete

Bug description:
  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1993068/+subscriptions