Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)
On Tue, 13 Aug 2019 at 14:22:31 +0200, Marc Haber wrote:
> 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.
Yes, you can bind-mount a directory over another directory, or a
non-directory non-symlink over another non-directory non-symlink.
(Symlinks get dereferenced before they're used as the source or
destination of a bind-mount.)
bubblewrap and other container-runners often use this when setting
up containers - for example if you have a Flatpak app installed, try
something like
flatpak run --command=mount org.gnome.Recipes
and you'll see that the container's /etc is a mixture of read-only
bind-mounts from the host system and read-only bind-mounts from the
runtime, some of which are individual files.
> >> >Maybe /etc/machine-id should be part of the "API" of a Debian system in
> >> >general (systemd or not)?
>
> So /etc/machine-id should be in Policy?
Probably yes, if that proposal has consensus, although a prerequisite
for it being in Policy would be to have an implementation of making it
exist even on systems with neither systemd nor dbus installed (Policy
is meant to document what's true, not what we hope will become true).
smcv
Reply to: