On Tue, 13 Aug 2019 12:01:13 +0100, Simon McVittie <s...@debian.org> wrote: >(systemd cannot create a mount point that doesn't exist yet on a read-only >file system, which is why a zero-byte file is preferred.
but you can bind-mount over a file? I wasn't aware of that. >If you use systemd as init, install dbus, delete or empty /etc/machine-id, >delete /var/lib/dbus/machine-id and reboot, then systemd will recreate >/etc/machine-id very early in the boot process. Less early but still early >in the boot process (before units with DefaultDependencies=yes, analogous >to rcS in sysvinit), systemd-tmpfiles will make /var/lib/dbus/machine-id >a symlink as directed by /usr/lib/tmpfiles.d/dbus.conf. By the time >ordinary system services start, it is already a symlink. Might this be >what happened on your test systems? Probably, yes. >> >Maybe /etc/machine-id should be part of the "API" of a Debian system in >> >general (systemd or not)? >> >> please elaborate on that. > >There are some properties that we guarantee every Debian system will have, >even though they cannot be guaranteed on every GNU or Linux system. For >example, Policy guarantees that /var/run is always a symlink to /run on >Debian systems (even though they are distinct directories on e.g. >Slackware[1], and as a result upstream projects like dbus can't rely on >/var/run being equivalent to /run). Similarly, we guarantee that all >Debian systems will have the base-passwd users and groups, with their >canonical numeric values. So /etc/machine-id should be in Policy? Greetings Marc -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
