[Pkg-utopia-maintainers] Bug#1040790: installation-reports: ID in /etc/machine-id and /var/lib/dbus/machine-id mismatch on fresh debian 12 installation

Luca Boccassi bluca at debian.org
Tue Jul 11 14:20:32 BST 2023


On Tue, 11 Jul 2023 at 14:14, Simon McVittie <smcv at debian.org> wrote:
>
> Control: reassign -1 src:dbus 1.12.20-3
>
> On Mon, 10 Jul 2023 at 18:43:06 +0100, Luca Boccassi wrote:
> > As a wild guess, maybe the split of src:dbus into multiple packages
> > affected the order in which the postinsts run, and now systemd's runs
> > first and creates /etc/machine-id, and then dbus-daemon's runs and
> > creates /var/lib/dbus/machine-id.
>
> The ordering here is not *meant* to matter, because dbus-uuidgen is meant
> to copy /etc/machine-id if it already exists and has suitable contents,
> and systemd-machine-id-setup is meant to copy /var/lib/dbus/machine-id
> if *that* already exists and has suitable contents.
>
> >     mkdir -p "${DPKG_ROOT:-/}var/lib/dbus"
> >     dbus-uuidgen --ensure="${DPKG_ROOT:-/}var/lib/dbus/machine-id"
>
> I think the regression here is that in attempting to respect DPKG_ROOT,
> I replaced dbus-uuidgen --ensure (which copies an existing systemd
> machine ID if one exists) with dbus-uuidgen --ensure=PATH (which doesn't).
> This was at the same time as the split into dbus.deb / dbus-daemon.deb,
> but it was an orthogonal change. bullseye is unaffected, bookworm is the
> first release with this.
>
> I'm sorry that it took so long to notice this. I should have had test
> coverage that would have detected this error.

Ah that explains it, thanks

> > There is a tmpfiles.d shipped by dbus-daemon that creates
> > /var/lib/dbus/machine-id as a symlink to /etc/machine-id if it exists,
> > but this snippet runs _after_ the dbus-uuidgen so effectively it is
> > always a no-op on package install:
>
> As an upstream, this is clearly the right thing to do, but as a
> downstream, I'm intentionally not relying on it as load-bearing by
> default. There is nothing in Debian that guarantees that /etc/machine-id
> will be created, unless we happen to be booting with systemd, which
> isn't guaranteed; and if it did get created, as far as I can see, there
> is technically also nothing that guarantees that it won't subsequently
> be deleted.
>
> https://bugs.debian.org/745876 proposed creating the machine ID in
> base-files as a basic Debian feature that any package can rely on,
> but it was closed as wontfix.
>
> See also https://bugs.debian.org/783716 for more background.
>
> Of course, d-i doesn't provide a way to not install systemd-sysv, but
> a vocal minority of users and developers use non-default installation
> mechanisms to get a different init system and consider that to be
> a critically important use-case; and I'm concerned that even if these
> users got a machine ID generated during installation, they would delete
> it as a perceived systemd'ism, and then complain loudly in the form of
> RC bugs when D-Bus doesn't work because /var/lib/dbus/machine-id is now
> a dangling symlink.

Well, I don't think we should make the 99.5% of cases more fragile to
cater to an entirely hypothetical 0.5% that would actively damage
their own installation by deleting OS files for no good reason. If
someone wants to mess manually with /etc/machine-id and
/var/lib/dbus/machine-id it's fair that they are allowed to do that,
but it's also fair to tell them that they get to keep the pieces.

Kind regards,
Luca Boccassi



More information about the Pkg-utopia-maintainers mailing list