Is it OK to change /etc/machine-id?

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.

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

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.

Method 2

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

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0