Trusty instances get same machine-id

Bug #1731279 reported by Andreas Hasenack on 2017-11-09
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
cloud-images
Undecided
Unassigned

Bug Description

I'm using MAAS for testing, but somebody else tested with plain kvm locally, and in their openstack STSstack cloud, and the same happens there.

tl;dr

deploy trusty
$ cat /var/lib/dbus/machine-id
21ccdbe57cf13cba71862c6459fa3211

All your trusty instances will have that machine-id in /var/lib/dbus/machine-id

In xenial it's different in each instance:
ubuntu@56-40:~$ cat /var/lib/dbus/machine-id
6d26080b84e94965abc40a3d65e79ce7

ubuntu@87-69:~$ cat /var/lib/dbus/machine-id
d9ebc0cb4d6f48489011fc625ef98a5c

The reason I'm bringing this up is because when one installs livepatch on trusty, that pulls in systemd, which in turns generates a /etc/machine-id based on several sources, the first one being that /var/lib/dbus/machine-id file. It then essentially copies that to /etc/machine-id.

Livepatch uses /etc/machine-id to uniquely identify each client, and on trusty that now means 21ccdbe57cf13cba71862c6459fa3211 is already taken, and all trusty VMs will get an error. Livepatch has a workaround in that it tells the user which commands to use to regenerate that machine-id when it encounters this situation.

Here is the livepatch bug about it: https://bugs.launchpad.net/canonical-livepatch-client/+bug/1680611

Currently we are seeing that only on trusty VMs.

Here is some inconclusive brainstorming:

Xenial also has that value in /etc/machine-id, whereas trusty doesn't have that file. Probably because xenial ships systemd.

A quick grep in /etc/init.d shows that the dbus service creates it on trusty:
ubuntu@10-e2:~$ grep machine-id /etc/init.d/*
/etc/init.d/dbus: # Create machine-id file

But because there is no dbus-daemon executable, the file doesn't get created:
ubuntu@10-e2:~$ sudo sh -x /etc/init.d/dbus start
+ set -e
+ DAEMON=/usr/bin/dbus-daemon
+ UUIDGEN=/usr/bin/dbus-uuidgen
+ UUIDGEN_OPTS=--ensure
+ NAME=dbus
+ DAEMONUSER=messagebus
+ PIDDIR=/var/run/dbus
+ PIDFILE=/var/run/dbus/pid
+ DESC=system message bus
+ test -x /usr/bin/dbus-daemon
+ exit 0

It's actually in /bin:
ubuntu@10-e2:~$ which dbus-daemon
/bin/dbus-daemon

But there is a dbus-daemon process running, so something else probably started it, outside of that initscript:
root@10-e2:/proc/831# ps fxaw|grep dbus-daemon|grep -v grep
  831 ? Ss 0:00 dbus-daemon --system --fork
root@10-e2:/proc/831# ll /proc/831/exe
lrwxrwxrwx 1 root root 0 Nov 9 14:24 /proc/831/exe -> /bin/dbus-daemon*
root@10-e2:/proc/831#

I don't know what in xenial regenerates the machine-id in /var/lib/dbus.

Steve Langasek (vorlon) wrote :

Installation of the dbus package in trusty generates /var/lib/dbus/machine-id. The cloud image build scripts need to wipe this file as part of the image creation.

Steve Langasek (vorlon) wrote :

(The command in the postinst that creates this file is 'dbus-uuidgen --ensure'.)

tags: added: sts
Dan Watkins (oddbloke) wrote :

The latest trusty daily should have this fixed; can someone confirm?

Changed in cloud-images:
status: New → Fix Committed
Chris Newcomer (cnewcomer) wrote :

Dan,

Sorry for the late response, I was able to load to trusty machines with the same MAAS image and they both yield different machine-ids. Thanks for fixing it!

ubuntu@test2:/home/ubuntu$ cat /var/lib/dbus/machine-id
5a03eeec2ce9f6a6638bbc2f5a380add

ubuntu@test3:~$ cat /var/lib/dbus/machine-id
959c9918e0485262b496c8155a380d1e

Dan Watkins (oddbloke) wrote :

Thanks for the confirmation, Chris!

Changed in cloud-images:
status: Fix Committed → Fix Released
tags: added: id-5a0a1be37dcf65bc1d676cbc
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers