Using raspbian lite (2017-04-10) I've noticed that my /etc/machine-id file changes on each boot. This causes me problems with journald.

I've found the log line where this happens:

Apr 24 19:05:59 raspberrypi systemd[1]: Installed transient /etc/machine-id file.

And tracked down the line of code where this happens. But I can't figure out how to stop it. I've tried writing an empty file to /etc/machine-id, changing permissions, but no luck.

Has anyone experienced this? A work around is to manually write a /etc/machine-id file with a UUID in it, but this becomes quite laborious when setting up a number of pis.

I can reproduce this with a fresh raspbian lite 2017-04-10 image, on a pi 2 and a pi zero w.

  • I thought it was meant to be set once. Have you changed anything to cause this behaviour? If not it sounds like a bug in Raspbian Lite (or possibly Raspbian).
    – joan
    Apr 27, 2017 at 8:32
  • I have added to my base image but nothing that should impact this. I will try and reproduce with the vanilla lite image.
    – Andy Smith
    Apr 27, 2017 at 8:35
  • My Raspbian (full) system seems to preserve the machine_id.
    – joan
    Apr 27, 2017 at 8:40
  • Is your Pi shutting down properly? It might think it boots up for the first time again and again.
    – mystery
    Apr 27, 2017 at 9:28
  • @mystery I'm seeing this when doing a sudo reboot
    – Andy Smith
    Apr 27, 2017 at 12:20

2 Answers 2


Same behaviour on a fresh Raspbian Lite install, only change is root on F2FS, but /etc/machine-id is definitely on persistent storage and filesystem is writeable.

However, on the actual filesystem it is empty. Bizarrely, this is in my mtab:

tmpfs on /etc/machine-id type tmpfs (ro,mode=755)

... with a ctime of 1970, so merely appears to have contents - but being tmpfs it is entirely transient. I didn't even know you could mount a single file. This fixed it to be persistent by actually populating the file in the root filesystem with a new machine-id by first unmounting the temp file:

root@raspberrypi:~# umount /etc/machine-id
root@raspberrypi:~# echo $(dd if=/dev/random bs=32 count=1 | sha1sum | cut -b1-32) > /etc/machine-id
0+1 records in
0+1 records out
13 bytes (13 B) copied, 0.0115326 s, 1.1 kB/s
root@raspberrypi:~# cat /etc/machine-id
root@raspberrypi:~# systemctl reboot
...wait a bit
pi@raspberrypi:~ $ cat /etc/machine-id

You could try to capture the existing id instead, but I went for a brand new one.

  • Yes - that's what I see as well. That tmpfs mount is done my systemd in the code I linked to. You're right that I can populate this myself but as I mentioned I don't want to do this, because I want to write many pi images and I want them all to have unique machine-ids. Sounds like this may be a bug in raspbian - thanks for verifying!
    – Andy Smith
    Apr 27, 2017 at 21:08
  • The process above generates a unique machine-id on each invocation, so will be unique across devices. You could bind mount the /etc dir (mkdir /tmp/midtest; mount --bind /etc/tmp/midtest) and test the underlying file in the mounted directory, copying over the temporary id in /etc/machine-id to /tmp/midtest/machine-id to make it permanent, or generate a fresh one as above. Use rc.local to run on every boot for every device, part of tyhe standard image. Apr 29, 2017 at 18:34
  • I appreciate I can write a script that runs on startup to write the machine id but I'm keen to establish whether this is a bug or not.
    – Andy Smith
    May 1, 2017 at 10:21
  • @Andy It depends on how you define "bug". This is by design for systemd as /etc was read-only, so not a bug there, and may be by design for Raspbian?. In fact despite my lengthy commands here you can simply run systemd-machine-id-setup--commit to make it permanent, so this is handled by systemd itself. You can try reporting it as a bug, but Debian's system is not exactly user-friendly. I can think of a few use cases where this default makes sense for an embedded device, and reversing this is problematic. May 1, 2017 at 12:25

A more complete solution to capture the machine-id without interrupting the current session, or generate a new one if it is run before systemd has a chance to do it for you (beware race conditions though):

mkdir /tmp/midchange; mount --bind /etc /tmp/midchange
if [ ! -s /tmp/midchange/machine-id ]; then # The persistent file is empty
  if [ -s /etc/machine-id ]; then           # systemd has generated a machine-id already
    cat /etc/machine-id > /tmp/midchange/machine-id
  else                                      # We need to generate a new machine-id
    dd if=/dev/random bs=32 count=1 | sha1sum | cut -b1-32 > /tmp/midchange/machine-id
umount /tmp/midchange; rmdir /tmp/midchange
  • the --bind mount places a copy of the filesystem somewhere else, but without anything mounted on itself or child files/folders, letting us see the underlying file/folder and also very useful for backups.
  • Put this in /etc/rc.local so that it can run on a each reboot. Once the machine-id is stored, you can take it out, but it's very low-impact and can stay, especially if you have a large number of devices. In that instance, include this in the base image.
  • The test -s returns true if the file has contents.
  • bs=32 count=1on the dd command lets us get random without blocking (ie waiting for random data, which isn't always full). Switch these around if you want more uniqueness and are happy for systemd to catch up and generate a different id that will be discarded on the next reboot.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.