63

I cloned a disk (SSD) and put the cloned disk into another machine. Now both systems have the same value in /etc/machine-id. Is it any problem to simply edit /etc/machine-id to change the value? Can I do this while the system is running (or do I need to boot from a Live USB)?

Is systemd-machine-id-setup a better alternative?

The naive use of systemd-machine-id-setup doesn't work. I tried these steps:

nano /etc/machine-id (to remove the existing value)
systemd-machine-id-setup
> Initializing machine ID from D-Bus machine ID.
cat /etc/machine-id

The new value is the same as the old value.

Haris
  • 103
  • 4
MountainX
  • 17,168
  • 59
  • 155
  • 264
  • 1
    Since D-Bus is not an inter-host mechanism, what difference does it make whether hosts have the same `machine-id`? – fpmurphy Nov 09 '17 at 00:01
  • 1
    @fpmurphy If you've got virtual machines managed by libvirt and created from the same base image some configuration settings are determined by libvirt by looking at the machine-id. DHCP leases and IP addresses as a result are among these things IIRC. – PowerBoss Nautilus Feb 07 '21 at 16:26

4 Answers4

62

Although systemd-machine-id-setup and systemd-firstboot are great for systems using systemd, /etc/machine-id is not a systemd file, despite the tag. It is also used on systems that do not use systemd. So as an alternative, you can use the dbus-uuidgen tool:

rm -f /etc/machine-id

and then

dbus-uuidgen --ensure=/etc/machine-id

As mentioned by Stephen Kitt, Debian systems may have both a /etc/machine-id and a /var/lib/dbus/machine-id file. If both exist as regular files, their contents should match, so there, also remove /var/lib/dbus/machine-id:

rm /var/lib/dbus/machine-id

and re-create it:

dbus-uuidgen --ensure

This last command implicitly uses /var/lib/dbus/machine-id as the file name and will copy the machine ID from the already-newly-generated /etc/machine-id.

The dbus-uuidgen invocation may or may not already be part of the regular boot sequence. If it is part of the boot sequence, then removing the file and rebooting should be enough. If you need to run dbus-uuidgen yourself, pay attention to the warning in the man page:

If you try to change an existing machine-id on a running system, it will probably result in bad things happening. Don't try to change this file. Also, don't make it the same on two different systems; it needs to be different anytime there are two different kernels running.

So after doing this, definitely don't continue using the system without rebooting. As an extra precaution, you may instead reboot first into rescue mode (or as you suggested, boot from a live USB stick), but from my experience, that is not necessary. Bad things may happen, but the bad things that do happen are fixed by the reboot anyway.

hvd
  • 1,895
  • 1
  • 14
  • 16
  • 2
    As I understood things, the D-Bus machine id was/is stored in `/var/lib/dbus/machine-id`, and `/etc/machine-id` is a systemd-ism (which is compatible with D-Bus). – Stephen Kitt Nov 07 '17 at 17:34
  • 2
    @StephenKitt I believe you're right historically but given that D-Bus accepts it `/etc` directly nowadays (no symlink needed), it may be put in there just for simplicity: there is more code out there that only checks `/etc` than that only checks `/var/lib/dbus`. – hvd Nov 07 '17 at 17:51
  • In that case you should at least ensure the two files don't contain different values. – u1686_grawity Nov 08 '17 at 15:22
  • @grawity The easiest way to do that is by not having two separate files in the first place. Do you know of distros that do have separate files (meaning, two regular files, not one regular file and one symlink)? – hvd Nov 08 '17 at 15:37
  • Whatever distro OP uses, apparently, as the original post shows `systemd-machine-id-setup` finding a copy of the original value in there. That's basically the default behavior _unless_ a distro specially creates the symlink. – u1686_grawity Nov 08 '17 at 16:26
  • @hvd Debian derivatives seem to have separate files, not symlinks. On my main system, `/var/lib/dbus/machine-id` dates back to November 2006, and `/etc/machine-id` to November 2013; the latter was created by the `systemd` package’s `postinst`. – Stephen Kitt Nov 08 '17 at 16:34
  • @StephenKitt Huh, interesting. The only Debian derivative I have installed right now is Ubuntu, which only has a single file. I'll check Debian when I can. It's possible that this only happens when upgrading older systems, that `/var/lib/dbus/machine-id` isn't supposed to be there any more but got left behind. – hvd Nov 08 '17 at 16:37
  • @hvd the configuration is managed separately by `dbus.postinst` and `systemd.postinst`, so even newer systems get two separate files if both packages are installed. – Stephen Kitt Nov 08 '17 at 16:42
  • @StephenKitt Indeed. Thanks for the note, added it into my answer. – hvd Nov 08 '17 at 23:28
  • I use Arch Linux. Deleting `/etc/machine-id` and rebooting was not sufficient for my situation. This answer ended up being the solution for me. Thanks for all the answers. – MountainX Nov 09 '17 at 03:54
  • Do you know what "bad things happening" does mean? – Lobo Jul 01 '19 at 07:11
  • Funnily enough, my Debian unstable does _not_ have `/etc/machine-id` but it _does_ have `/var/lib/dbus/machine-id`. • But, why not just write the hexdump of some random bytes over it? – mirabilos Aug 15 '19 at 20:23
  • I edited `/etc/machine-id` manually. The system seems to work fine after the reboot. Could anyone explain the consequences of that manual change? – t7e Sep 02 '20 at 18:21
37

The easiest option is to delete /etc/machine-id on the cloned disk and reboot; systemd-machine-id-setup will generate a new one for you (you’ll need to run it manually if this doesn’t happen automatically). You might also need to delete /var/lib/dbus/machine-id (if it’s not a symlink to /etc/machine-id); in that case, make sure that the new machine-id really is new, and copy the files so that /etc/machine-id and /var/lib/dbus/machine-id contain the same value.

As you found out, running systemd-machine-id-setup on a system which was booted with an /etc/machine-id file will simply restore the identifier it was booted with (from the D-Bus machine id). This is option 1 in the manpage you linked to. Deleting the file(s) and rebooting will exercise option 4.

For the benefit of readers planning on cloning a disk in this way, the recommended approach with systemd, at least on systems where systemd-firstboot is available, is to use that instead:

  1. clone the disk;
  2. mount the cloned root partition somewhere (e.g. /mnt);

  3. initialize the machine id:

    systemd-firstboot --root=/mnt --setup-machine-id

You can use systemd-firstboot to set other parameters up while you’re at it (hostname, root password etc.).

Stephen Kitt
  • 411,918
  • 54
  • 1,065
  • 1,164
  • 1
    It's worth noting that on Ubuntu 16.04 and 17.10 `/etc/machine-id` it's not automagically recreated if removed, neither `systemd-firstboot` is available. So once you remove that file, you should manually recreate it using `systemd-machine-id-setup` (and perhaps reboot, also). – gerlos Nov 08 '17 at 16:21
  • Another point: often `/var/lib/dbus/machine-id` is just a symlink to `/etc/machine-id`, so there's no need to copy contents from one file to the other. – gerlos Nov 08 '17 at 16:39
  • 1
    @gerlos yes, hence the “might need to”; but I’ve made that explicit too, thanks again. – Stephen Kitt Nov 08 '17 at 16:43
  • 2
    Why is there even a need for a unique `machine-id` for D-Bus since D-Bus is only an intra-system IPC mechanism? – fpmurphy Nov 09 '17 at 04:34
4

These steps can help:

  • remove machine id 
    rm /etc/machine-id
rm /var/lib/dbus/machine-id
init 6
  • regenerate machine id 
    dbus-uuidgen --ensure
systemd-machine-id-setup
  • verify 
    cat /etc/machine-id
hostnamectl
AdminBee
  • 21,637
  • 21
  • 47
  • 71
Rakesh Vishwakarma
  • 41
  • 1
2

I have had a similar case, in which the cloning of various disks for embedded industrial equipment has caused the machine-id to be the same on all of them, which has later caused conflicts in the local networks where they were due to maintaining similar MAC addresses on the bridge (not on ethernet devices).

The simplest solution has been to restart these machine-id on each computer, for the case it occupies and because the computers are using systemd:

rm /etc/machine-id
systemd-machine-id-setup
Fco Javier Balón
  • 1,144
  • 2
  • 11
  • 31