/etc/machine-id and /var/lib/dbus/machine-id identical on multipass snapcraft instances

snapcraft
1

Heyho,

i hope this is the right place and someone here is managing the build process of the snapcraft images for multipass.

i had problems starting multiple instances using the same snapcraft image via multipass. i didn’t matter if this was done via snapcraft or directlty via multipass launch. all instances which use the same image get the same ip address. after watching the network traffic it was clear that the dhcp requests were carrying the same identifier via option 61.

it seems like you forgot to empty /etc/machine-id and /var/lib/dbus/machine-id before shipping the image. at least thats a way it works, ubuntu creates a new random machine id when both files are empty.

for a test i emptied both files in the qcow2 image and created new instances which were not assignes the same ip any more.

see also

best regards qoreQyaS

3 Likes
2

Hi @qoreQyaS,

Thanks for investigating and cross-posting on the multipass issue. It looks like they are following up with the Certified Public Cloud team to clear /etc/machine-id for the Multipass images.

1 Like
3

Hey @qoreQyaS Yep, I’ll just second what @mr_cal said and say that we have filed a bug against the image. You can find it here: https://bugs.launchpad.net/cloud-images/+bug/1999415

Thanks for all of the digging and finding the root cause!

2 Likes
4

I have a tangential issue, because I’ve been gone so long. Could someone compile a list of things that needs to be changed for these things, if there are more, I mean?

5

Hi @joerlend.schinstad,

i only emptied /etc/machine-id and /var/lib/dbus/machine-id in the image and this issue was gone. the id’s are regenerated during boot when the files are empty. i only repaired snapcraft:core18 here locally because mounting of qcow2 images is a bit cumbersome

these images were not working: (they all have different ids, but they all have ids in the image)

snapcraft:core18
snapcraft:core20
snapcraft:core22
snapcraft:devel

echo | sudo tee /etc/machine-id /var/lib/dbus/machine-id

thank you @townsend for filing that bug.

6

regard the bug report @launchpad IIRC both files are the problem /etc/machine-id and /var/lib/dbus/machine-id

when the former is empty it gets filled with the contents of the latter, if both are empty they are being generated

see also

and https://www.freedesktop.org/software/systemd/man/machine-id.html#

it is also possible to force an id with a kernel paramter when i was cross checking with other multipass images (IIRC core18) i saw that /etc was mountet ro and /etc/machine-id was mounted as a tmpfs.

7

it is not a tmpfs but a bind-mount into the persistent writable disk space and the file in /var is a symlink to the (originally empty) one in /etc:

$ ls -l /var/lib/dbus/machine-id 
lrwxrwxrwx 1 root root 15 Apr  1  2020 /var/lib/dbus/machine-id -> /etc/machine-id
$ mount | grep machine-id
/dev/mmcblk0p4 on /etc/machine-id type ext4 (rw,nosuid,relatime)
$

that makes dbus generate a fresh unique ID on first boot of the system.

1 Like
8

regard the bug report @launchpad IIRC both files are the problem /etc/machine-id and /var/lib/dbus/machine-id

We mounted the qcow2 images directly, ie, before first boot and /etc/machine-id is empty but /var/lib/dbus/machine-id which is the source of the problem and why I filed the bug that way. You are seeing the image after boot which is filling in /etc/machine-id with what’s contained in the other file.

Note that snapcraft:core* is not the same as the Ubuntu Core* images. The snapcraft:core* are special images used for creating snap packages.

9

i was mounting the qcow images too, and i just checked again. i deleted the image /var/snap/multipass/common/cache/multipassd/vault/images/snapcraft-core18-20201111/bionic-server-cloudimg-amd64-disk.img then i issued a multipass launch -n foo snapcraft:core18 right before the download was finished i copied the image (from /var/snap/multi…/cache/…/images…), mounted it via guestmount and checked. there is an id in /etc/machine-id and /var/lib/dbus/machine-id

$ sudo guestmount -a bionic-server-cloudimg-amd64-disk.img -m /dev/sda1 1
$ sudo cat 1/etc/machine-id 1/var/lib/dbus/machine-id
011d1d726b774e529fef48722f6b495a
011d1d726b774e529fef48722f6b495a

the non snapcraft:* images never had a problem (at least the ones i checked)

10

Hey @qoreQyaS,

Ok, I confirmed what you see on the bionic image. Some (all?) other images do not have /etc/machine-id filled out.

At any rate, the team responsible for these images understand where the problem is occurring during the image creation and the fix they will apply should fix both cases. I don’t have an ETA yet on when fixed images will be available though.

1 Like