Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix remove machine-id #4056

Closed
ubuntu-server-builder opened this issue May 12, 2023 · 13 comments
Closed

Fix remove machine-id #4056

ubuntu-server-builder opened this issue May 12, 2023 · 13 comments
Labels
launchpad Migrated from Launchpad

Comments

@ubuntu-server-builder
Copy link
Collaborator

This bug was originally filed in Launchpad as LP: #1999680

Launchpad details
affected_projects = []
assignee = None
assignee_name = None
date_closed = 2023-02-22T16:52:38.069619+00:00
date_created = 2022-12-14T17:43:32.169271+00:00
date_fix_committed = 2023-01-18T02:34:52.856593+00:00
date_fix_released = 2023-02-22T16:52:38.069619+00:00
id = 1999680
importance = medium
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/1999680
milestone = None
owner = sirl33tname
owner_name = l33tname
private = False
status = fix_released
submitter = sirl33tname
submitter_name = l33tname
tags = []
duplicates = [2002784]

Launchpad user l33tname(sirl33tname) wrote on 2022-12-14T17:43:32.169271+00:00

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.

@ubuntu-server-builder ubuntu-server-builder added the launchpad Migrated from Launchpad label May 12, 2023
@ubuntu-server-builder
Copy link
Collaborator Author

Launchpad user Brett Holman(holmanb) wrote on 2022-12-15T16:30:18.820463+00:00

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.

@ubuntu-server-builder
Copy link
Collaborator Author

Launchpad user Brett Holman(holmanb) wrote on 2022-12-15T16:36:42.920363+00:00

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?

@ubuntu-server-builder
Copy link
Collaborator Author

Launchpad user l33tname(sirl33tname) wrote on 2022-12-19T19:20:36.271005+00:00

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.

@ubuntu-server-builder
Copy link
Collaborator Author

Launchpad user James Falcon(falcojr) wrote on 2023-01-03T15:57:07.070194+00:00

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.

@ubuntu-server-builder
Copy link
Collaborator Author

Launchpad user l33tname(sirl33tname) wrote on 2023-01-06T15:40:03.181047+00:00

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

@ubuntu-server-builder
Copy link
Collaborator Author

Launchpad user Brett Holman(holmanb) wrote on 2023-01-06T17:28:39.966315+00:00

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.

@ubuntu-server-builder
Copy link
Collaborator Author

Launchpad user Brett Holman(holmanb) wrote on 2023-01-06T17:29:02.663537+00:00

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

@ubuntu-server-builder
Copy link
Collaborator Author

Launchpad user Brett Holman(holmanb) wrote on 2023-01-06T18:59:22.078435+00:00

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

@ubuntu-server-builder
Copy link
Collaborator Author

Launchpad user l33tname(sirl33tname) wrote on 2023-01-07T11:19:02.879931+00:00

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.

@ubuntu-server-builder
Copy link
Collaborator Author

Launchpad user l33tname(sirl33tname) wrote on 2023-01-07T12:36:30.243025+00:00

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

@ubuntu-server-builder
Copy link
Collaborator Author

Launchpad user Brett Holman(holmanb) wrote on 2023-01-10T16:52:23.291658+00:00

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

@ubuntu-server-builder
Copy link
Collaborator Author

Launchpad user Chad Smith(chad.smith) wrote on 2023-01-12T05:46:41.824045+00:00

Pull request up for discussion of this bug #1953

@ubuntu-server-builder
Copy link
Collaborator Author

Launchpad user Alberto Contreras(aciba) wrote on 2023-02-22T16:52:38.781332+00:00

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
launchpad Migrated from Launchpad
Projects
None yet
Development

No branches or pull requests

1 participant