Re: Bug: machine id is never generated

[Henning Schild <henning.schild@siemens.com>]

Am Thu, 21 Jul 2022 17:41:07 +0200
schrieb "Moessbauer, Felix (T CED SES-DE)"
<felix.moessbauer@siemens.com>:

> Hi,
> 
> when booting plain ISAR images (with Debian11), the "/etc/machine-id"
> is never generated. This breaks a couple of services that depend on
> having the id. An example is the systemd-networkd with DHCP, leading
> to error messages like this one (and breaking networking):
> 
> systemd-networkd[277]: enp8s0: DHCP6 CLIENT: Failed to set
> identifier: No such file or directory

Yes that would just be one of many possible problems. It also plays
into the whole "first boot" functionality which never was really
usable with isar.

I think before the last patch to remove the file we never had a first
boot, now every boot it the first it seems.

As a workaround for systemd networkd you can likely use the MAC as
identifier for dhcp instead of the duid, but not nice.

> The error can manually be fixed by running
> "systemd-machine-id-setup", but this obviously does not work in
> embedded scenarios.
> 
> The root cause could be that /etc is read-only mounted when the
> first-boot-complete.target is reached. At least the logs indicate
> this:
> 
> journalctl --grep machine --no-pager
> -- Journal begins at Thu 2022-07-21 15:07:21 UTC, ends at Thu
> 2022-07-21 15:35:20 UTC. -- Jul 21 15:07:21 test-image systemd[1]:
> System cannot boot: Missing /etc/machine-id and /etc is mounted
> read-only. Jul 21 15:07:21 test-image systemd[1]: 1) /etc/machine-id
> exists and is populated. Jul 21 15:07:21 test-image systemd[1]: 2)
> /etc/machine-id exists and is empty. Jul 21 15:07:21 test-image
> systemd[1]: 3) /etc/machine-id is missing and /etc is writable. Jul
> 21 15:07:24 test-image systemd[1]: Condition check resulted in Commit
> a transient machine-id on disk being skipped.
> 
> Maybe Quirin knows more, as he implemented the postproc removal in
> 8b5e3f9. IIRC Jan also mentioned something that "rw" has to be added
> to the kernel cmdline, but this looks like a workaround as well. For
> the sake of completeness:
> 
> cat /proc/cmdline
> initrd=\initrd.img-5.10.0-16-amd64 LABEL=Boot
> root=PARTUUID=9ad286e9-8df8-42c2-ac7d-0f2d7387d03d rootwait
> console=tty0 console=ttyS0,115200

We should find out what that is, maybe even a systemd bug. Not many
systems actually do the first boot on the literal first boot.
In debian the first boot is when systemd gets installed.

But "ro" on the kernel cmdline should be the normal case, where the
initrd or systemd at some points makes it writable. "rw" on the cmdline
sounds like a hack.
 
> IMO this is a pretty critical bug as it affects a ton of images.

Yes maybe. Could also collect which distros are affected and whether it
was caused by quirins patch replacing the empty file with "no file".

Henning

> Best regards,
> Felix
> 
> --
> Siemens AG, Linux Expert Center
> Otto-Hahn-Ring 6, 81739 München, Germany
>