Fix remove machine-id

> 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.

> 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?

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, 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.

> 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

> 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.

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

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).

> 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.

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

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

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

This bug is believed to be fixed in cloud-init in version 23.1. If this is still a problem for you, please make a comment and set the state back to New

Thank you.

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