Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)
On Tue, 13 Aug 2019 12:01:13 +0100, Simon McVittie <smcv@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
Reply to: