Fix remove machine-id

Bug #1999680 reported by l33tname
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
cloud-init
Fix Committed
Medium
Unassigned

Bug Description

Right now --machine-id removes the /etc/machine-id file.
But apparently that's not the thing that should happen it should
only be truncated.

https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1508766

Either fix it here or provide the systemd-firstboot with ubuntu.

Revision history for this message
Brett Holman (holmanb) wrote :

> apparently that's not the thing that should happen it should only be truncated

I don't agree that that's not a thing that should happen. That is the stated purpose of this (new) flag.

Please provide more details explaining how this behavior is incorrect for upstream cloud-init.

Changed in cloud-init:
status: New → Incomplete
Revision history for this message
Brett Holman (holmanb) wrote :

> Either fix it here or provide the systemd-firstboot with ubuntu.

Based on this comment it sounds like maybe you hit a bug in an Ubuntu image and didn't know where to file it? If so, upstream cloud-init is likely not the right place, but if you share some details about your issue, we can try point you to the right project.

Are you experiencing something similar to that bug you linked?

Revision history for this message
l33tname (sirl33tname) wrote :

Yes if you delete /etc/machine-id from a ubuntu the image is broken.
And the issue i linked states that this is on purpose and a wontfix.
> Sorry for the misunderstanding/false information: Indeed /etc/machine-id must at least exist (empty is okay) in order to regenerate it
So this makes that a bug in cloud-init.

I personally care more about that it works and less if it is fixed in ubunut or cloud-init.

Problem is that if you remove /etc/machine-id your ubuntu system is broken.

l33tname (sirl33tname)
Changed in cloud-init:
status: Incomplete → New
Revision history for this message
James Falcon (falcojr) wrote :

l33tname, can you explain what you're trying to accomplish? `cloud-init clean --machine-id` needs to be called by something in order for this to affect anything. Are you calling that command to create a golden image, and your golden image isn't working? Are you launching a cloud image on a cloud that isn't booting correctly? Are you installing Ubuntu using an installer and it resulted in no machine id?

We need to understand the use case to know if this particular flag is a problem, or if we need to redirect your problem to another project.

Revision history for this message
l33tname (sirl33tname) wrote :

> l33tname, can you explain what you're trying to accomplish? `cloud-init clean --machine-id` needs to be called by something in order for this to affect anything.

I call it as part of my packer setup for my golden image.

> Are you calling that command to create a golden image, and your golden image isn't working?
Correct.

> Are you launching a cloud image on a cloud that isn't booting correctly?
It will boot but without `/etc/machine-id` which leads to weird errors for example that network interfaces can not be configured.

> Are you installing Ubuntu using an installer and it resulted in no machine id?
No I using the the ova image from here https://cloud-images.ubuntu.com/ running packer to prepare my golden image and i run cloud-init clean --seed --logs --machine-id at the end, and then when i want to use the golden image they don't regenerate /etc/machine-id which is correct behavior according to the ubuntu issue i linked https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1508766

Revision history for this message
Brett Holman (holmanb) wrote (last edit ):

> I using the the ova image from here https://cloud-images.ubuntu.com/

Which release of Ubuntu did you use?

> It will boot but without `/etc/machine-id` which leads to weird errors for example that network interfaces can not be configured.

Can you please attach the logs containing the errors you are seeing?

> Problem is that if you remove /etc/machine-id your ubuntu system is broken.

I don't think this statement is true. See the snippet from machine-id(5) below.

> they don't regenerate /etc/machine-id which is correct behavior

I don't think this is true. See this snippet from machine-id(5):

FIRST BOOT SEMANTICS
       /etc/machine-id is used to decide whether a boot is the first one. The rules are as follows:

        1. If /etc/machine-id does not exist, this is a first boot. During early boot, systemd will write
           "uninitialized\n" to this file and overmount a temporary file which contains the actual machine ID.
           Later (after first-boot-complete.target has been reached), the real machine ID will be written to disk.

Revision history for this message
Brett Holman (holmanb) wrote (last edit ):

Also note that it works as expected on Jammy.

$ lxc shell me
root@me:~# cat /etc/machine-id
b097463e683b4dcbaa2ed214b417a846
root@me:~# cloud-init clean --seed --logs --machine-id
root@me:~# reboot -h now
root@me:~#
Session terminated, killing shell...
 ...killed.
$ lxc shell me
root@me:~# cloud-init status
status: done
root@me:~# cat /etc/machine-id
d213eac39735457e8c5bac0630078967
root@me:~# lsb_release -r
Release: 22.04

Changed in cloud-init:
status: New → Incomplete
Revision history for this message
Brett Holman (holmanb) wrote :

Looks like the issue you're hitting relates to older Ubuntu releases.

bionic machine-id(5):

       For operating system images which are created once and used on multiple machines, for example for containers
       or in the cloud, /etc/machine-id should be an empty file in the generic file system image.

There is a problem, however, with simply making this file an empty file in all cases, since this would change first boot determination on newer systems:

jammy machine-id(5):
        3. If /etc/machine-id exists and is empty, a boot is not considered
           the first boot. systemd will still bind-mount a file containing
           the actual machine-id over it and later try to commit it to disk
           (if /etc/ is writable).

Revision history for this message
l33tname (sirl33tname) wrote :

> Which release of Ubuntu did you use?
The latest 22.04.Maybe it is ova image specific
but try the same thing but with the https://cloud-images.ubuntu.com/releases/22.04/release/ubuntu-22.04-server-cloudimg-amd64.ova and virtual box for example.

> Can you please attach the logs containing the errors you are seeing?
I dont have the full logs anymore but the issue i saw is:
systemd-networkd[1345]: enp3s0: DHCP4 CLIENT: Failed to set IAID+DUID: No such file or directory
and if I check ls -la /etc/machine-id it does not exist

> I don't think this is true. See this snippet from machine-id(5)
Yes but is also states that `systemd-firstboot` will do that
  systemd-firstboot(1) may be used to initialize /etc/machine-id on mounted (but not booted) system images.

And at least in the image I use:
$ systemctl status systemd-firstboot.service
Unit systemd-firstboot.service could not be found.

Revision history for this message
l33tname (sirl33tname) wrote :

I just checked and interestingly enough the lxd container also does not have systemd-firstboot but seems to work as you pointed out. machine-id is properly regenerated

Revision history for this message
Brett Holman (holmanb) wrote :

For now, you should be able to use one of the following sequences as a workaround:

cloud-init clean --seed --logs --machine-id
touch /etc/machine-id

or alternatively

cloud-init clean --seed --logs
truncate -s 0 /etc/machine-id

Revision history for this message
Chad Smith (chad.smith) wrote :

Pull request up for discussion of this bug https://github.com/canonical/cloud-init/pull/1953

James Falcon (falcojr)
Changed in cloud-init:
status: Incomplete → Triaged
importance: Undecided → Medium
Chad Smith (chad.smith)
Changed in cloud-init:
status: Triaged → Fix Committed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.