Systemd fails to start with missing /etc/machine-id

Embedded Linux Discussions
1

I use omap-image-builder to create custom images for our board and recent builds since this commit have caused failure of systemd and associated logging with the following output:

[   12.719949] systemd[1]: System cannot boot: Missing /etc/machine-id and /etc is mounted read-only.
[   12.729247] systemd[1]: Booting up is supported only when:
[   12.734885] systemd[1]: 1) /etc/machine-id exists and is populated.
[   12.741232] systemd[1]: 2) /etc/machine-id exists and is empty.
[   12.747218] systemd[1]: 3) /etc/machine-id is missing and /etc is writable.
[   13.936330] systemd-journald[1854]: Failed to open runtime journal: No such file or directory
[FAILED] Failed to start Journal Service.
See 'systemctl status systemd-journald.service' for details.
[DEPEND] Dependency failed for Flush Journal to Persistent Storage.
[  OK  ] Started Load Kernel Modules.
[  OK  ] Started Restore / save the current clock.
[  OK  ] Mounted /sys/kernel/debug.
[  OK  ] Stopped Journal Service.
         Starting Journal Service...
[  OK  ] Started File System Check Daemon to report status.
         Starting Apply Kernel Variables...
         Mounting FUSE Control File System...
[   14.412345] systemd-journald[1869]: Failed to open runtime journal: No such file or directory
         Mounting Configuration File System...
         Starting Create Static Device Nodes in /dev...
         Starting Remount Root and Kernel File Systems...
[  OK  ] Mounted Configuration File System.
[  OK  ] Mounted FUSE Control File System.
[FAILED] Failed to start Journal Service.

What is the expected behavior here after the change to delete /etc/machine-id ?

Thanks,
Ryan

2

Hi @ryannss systemd, should regenerate after first the boot… The idea behind the commit was to automatically make every new install unique for security purposes…

PS, add this to your *.conf:

keep_ssh_keys="enable"

and it’ll bypass the whole ssh removal/etc…

Regards,

3

Thanks @RobertCNelson I’ll try the conf setting. I am seeing that systemd starts up properly on the second boot after flash; the issue is that the first boot after flash exhibits this behavior and we expect the first boot to result in extended system uptime. Is that what you mean by “systemd should regenerate after the first boot” ? I do see systemd executing our services but one main issue is that /var/log/syslog only contains kernel events and none of our service output is logged.

4

So with our default configuration, the image is shipped with no host keys, or a machine-id… On first bootup, these are generated, it can take anywhere from 30-45 seconds for this. This helps make sure each device that is flashed from a ‘single’ image has a unique ID and host keys… Otherwise, all flashed devices would have the exact same ID/etc…

Regards,

5

That makes sense, and I’m familiar with the host key generation. The removal of machine-id in the recent commit and the subsequent systemd failure to start & failure to log service output to /var/log/syslog is the part I’m confused about. Should I expect that after this host key and machine-id generation on first boot is complete that systemd begins emitting to /var/log/syslog? I am observing that is not the case and our system stays in a degraded state until we reboot, i.e. the second boot after flash.

Thanks,
Ryan

6

We were trying to fix another race condition, detailed here…

I’m actually starting to think about blowing that all out… Instead just writing a script that the end user would run on their own, which would regenerate everything…

Regards,