Re: Bug: machine id is never generated

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

Am Thu, 21 Jul 2022 19:08:14 +0200
schrieb "Schmidl, Tobias (T CED SES-DE)" <tobiasschmidl@siemens.com>:

> Hi Felix,
> 
> Am Donnerstag, dem 21.07.2022 um 15:41 +0000 schrieb Moessbauer,
> Felix (T CED SES-DE):
> > 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
> > 
> > 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:
> >   
> 
> I've examined the same thing, for expand-on-first-boot, which would
> also profit from a `ConditionFirstBoot=yes` in its service file. I've
> seen the same pattern.

Hooking into systemds understanding of "first boot" would be good for
expand-on-first-boot and sshd-regen-keys when just talking plain isar.
Both recipes use a weird trick to only run once. A nasty pattern that
might have spread into layer recipes.

It would be really nice if isar generated images could make use of
`ConditionFirstBoot=yes` in any recipe that has such needs. I think we
should try to get there with isar. The only problem is that debian
assumes the "first boot" to be the install-time so we might break
assumptions. But if we do i am sure debian will try to cater once there
is any kind of problem and we explain the case.

regards,
Henning

> 
> What I don't understand is that with a normal Debian the regeneration
> of /etc/machine-id works without any problems. Somehow we have to
> differ here.
> 
> Kind regards,
> 
> Tobias
>