It is a policy configuration issue obviously. I am not sure what version of reference policy Yocto is using in that environment but you might want to see if it is old. SELinux policy is very dynamic. Frankly, according to my security policy systemd-machine-id-setup is selinux aware like many systemd components and so it should address labeling programmatically (if it is allowed to by the policy selinux enforces) Can you produce this issue with selinux in permissive mode? If it works in permissive mode but not in enforcing mode then selinux is blocking systemd-machine-id-setup and that might cause the labeling issue. By the way I would argue that both init_runtime_t and etc_runtime_t are not suitable for this and that it should probably have a private machineid_t type since AFAIK this /etc/machine-id is only ever created by systemd-machine-id-setup. "Sebert, Holger.ext" <Holger.Sebert.ext@xxxxxxxxxxxxx> writes: > Hi! > > I am having issues with systemd's machine-id: On first boot it is > created, i.e. the file /etc/machine-id changes from “unintialized” to a > hash value; but it has the wrong SELinux file context, namely > “init_runtime_t”. > > Furthermore, I am getting the following error message: > > localhost systemd[1]: systemd-machine-id-commit.service: Main process exited, code=exited, status=1/FAILURE > localhost systemd-machine-id-setup[424]: Failed to unmount transient /etc/machine-id file: No such file or directory. > localhost systemd-machine-id-setup[424]: We keep that mount until next reboot. > localhost systemd[1]: systemd-machine-id-commit.service: Failed with result 'exit-code'. > > On the next boot, /etc/machine-id has the correct SELinux file context, > namely, “etc_runtime_t”, but the ID has changed! On subsequent boots, > it remains unchanged, however. > > I think this could be related to this old bug: > > https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1411140 > > And, indeed, we are also using OverlayFS (in a Yocto/Poky (mickledore) > environment). > > Do you have an idea how to work around this problem? > > Best, > Holger -- gpg --locate-keys dominick.grift@xxxxxxxxxxx (wkd) Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 Dominick Grift Mastodon: @kcinimod@xxxxxxxxxxx