Ubuntu
systemd package

/etc/machine-id not created if missing

Bug #1508766 reported by Jason Gerard DeRose on 2015-10-22

14

This bug affects 3 people

Affects		Status	Importance	Assigned to	Milestone
	systemd (Ubuntu)	Won't Fix	Low	Unassigned

Bug Description

If /etc/machine-id is missing at boot, systemd does not create it.

I came across lp:1387090 in which Martin Pitt mentions that it should be created if missing, but is unsure why this doesn't work.

I'm likewise unsure why it doesn't work, but this bit from dmesg makes me think it *might* be because systemd is trying to do so while the rootfs is still mounted read-only, before it gets remounted read-write:

[ 19.240451] systemd[1]: System cannot boot: Missing /etc/machine-id and /etc is mounted read-only.
[ 19.240464] systemd[1]: Booting up is supported only when:
[ 19.240466] systemd[1]: 1) /etc/machine-id exists and is populated.
[ 19.240467] systemd[1]: 2) /etc/machine-id exists and is empty.
[ 19.240468] systemd[1]: 3) /etc/machine-id is missing and /etc is writable.

A missing /etc/machine-id file has broad consequences for the boot process. As one example, the Journal Service doesn't get started.

This problem appears to have greater impact now that on Wily (desktop) /var/lib/dbus/machine-id is a symlink to /etc/machine-id. Previously the system dbus instance would generate the machine-id with dbus-uidgen if the file was missing, but on Wily desktop it wont.

Note that on Wily server /var/lib/dbus/machine-id is a regular file, is not a symlink to /etc/machine-id. I filed lp:1508697 about this separate issue as it seems strange for this to be different between Wily desktop and server.

Thanks!

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: systemd 225-1ubuntu9
ProcVersionSignature: Ubuntu 4.2.0-16.19-generic 4.2.3
Uname: Linux 4.2.0-16-generic x86_64
ApportVersion: 2.19.1-0ubuntu3
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Oct 21 19:57:58 2015
JournalErrors:
No journal files were found.
-- No entries --
MachineType: System76, Inc. Gazelle Professional
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.2.0-16-generic root=UUID=424ed0f3-306d-4302-b58c-6b1e7adb7c74 ro quiet splash vt.handoff=7
SourcePackage: systemd
UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 05/16/2012
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 4.6.5
dmi.board.asset.tag: Tag 12345
dmi.board.name: Gazelle Professional
dmi.board.vendor: System76, Inc.
dmi.board.version: gazp7
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 9
dmi.chassis.vendor: No Enclosure
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4.6.5:bd05/16/2012:svnSystem76,Inc.:pnGazelleProfessional:pvrgazp7:rvnSystem76,Inc.:rnGazelleProfessional:rvrgazp7:cvnNoEnclosure:ct9:cvrN/A:
dmi.product.name: Gazelle Professional
dmi.product.version: gazp7
dmi.sys.vendor: System76, Inc.

See original description

Tags:

Revision history for this message

Jason Gerard DeRose (jderose) wrote on 2015-10-22:

#1

CurrentDmesg.txt Edit (79.4 KiB, text/plain; charset="utf-8")
Dependencies.txt Edit (2.7 KiB, text/plain; charset="utf-8")
Lspci.txt Edit (10.0 KiB, text/plain; charset="utf-8")
Lsusb.txt Edit (399 bytes, text/plain; charset="utf-8")
ProcCpuinfo.txt Edit (7.5 KiB, text/plain; charset="utf-8")
ProcEnviron.txt Edit (112 bytes, text/plain; charset="utf-8")
ProcInterrupts.txt Edit (4.3 KiB, text/plain; charset="utf-8")
ProcModules.txt Edit (3.9 KiB, text/plain; charset="utf-8")
SystemdDelta.txt Edit (1013 bytes, text/plain; charset="utf-8")
SystemdFailedUnits.txt Edit (2.7 KiB, text/plain; charset="utf-8")
UdevDb.txt Edit (137.3 KiB, text/plain; charset="utf-8")

Jason Gerard DeRose (jderose) on 2015-10-22

description:

updated

Revision history for this message

Simon McVittie (smcv) wrote on 2015-10-29:

#2

I'm surprised the root filesystem is read-only at the point where systemd starts. Isn't it remounted rw by the initramfs? (It is in Debian.)

From context on lp:1508697 you're using some sort of "golden image" creation process: install once, delete unique IDs and other transient state, then dd the image onto multiple machines and let the boot process re-populate those unique IDs.

If your image creation process truncated /etc/machine-id to 0 bytes instead of deleting it altogether, then systemd would be able to do tricks with bind-mounts to populate it; that's what Debian Live does. However, I'm not sure how/whether the newly generated ID gets written to the filesystem when it becomes rw.

Revision history for this message

Jason Gerard DeRose (jderose) wrote on 2015-10-29:

#3

Simon,

I've never really dug into initramfs-tools enough to know for sure, but my guess has always been that the rootfs got remounted based on what's in /etc/fstab, which as far as I know is handled by systemd. But perhaps the initramfs remounts the rootfs read-write, and then it is remounted a 3rd time based on what's in /etc/fstab? (Which could technically be read-only if the ro option was specific in fstab).

As far as our imaging system... yes, we have a golden image tarball which we unpack after we create and mount the needed partitions. But I already had work-arounds in our imaging system before I filed these bugs, needed because we started shipping Ubuntu 15.10 the day it was released :)

Thanks!

Revision history for this message

Jason Gerard DeRose (jderose) wrote on 2015-10-29:

#4

Simon,

Also, I just tested with an empty /etc/machine-id file... in this case, systemd does correctly create a write a random machine-id.

Which kinda makes me wonder if systemd is erroneously concluding the rootfs is mounted read-write when the /etc/machine-id file is missing altogether.

Revision history for this message

Martin Pitt (pitti) wrote on 2015-10-29:

#5

> I'm surprised the root filesystem is read-only at the point where systemd starts. Isn't it remounted rw by the initramfs? (It is in Debian.)

No, it shouldn't; Usually grub passes the "ro" option in which case initramfs should leave it as readonly (see /usr/share/initramfs-tools/init). rw mounting happens in systemd-remount-fs.service.

Sorry for the misunderstanding/false information: Indeed /etc/machine-id must at least exist (empty is okay) in order to regenerate it -- then systemd will create a new one in a temporary location in /run, bind-mount /etc/machine-id to it, and systemd-machine-id-commit.service will then write it to /etc/machine-id once the fs becomes read-write. So the message in the description as well as machine-id(5) ("Optionally, for stateless systems, it is generated during runtime at boot if it is found to be empty.") are quite correct.

So this is pretty much "wontfix" on the downstream side. There's probably a way to combine the above so that writing an entirely absent /etc/machine-id after the root fs becomes rw, but that should then happen upstream.

Changed in systemd (Ubuntu):
importance:	Undecided → Low
status:	New → Won't Fix

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.