Trusty instances get same machine-id

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

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.


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

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

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

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:

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

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*

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 :


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

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

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