Bug#1040790: installation-reports: ID in /etc/machine-id and /var/lib/dbus/machine-id mismatch on fresh debian 12 installation
Hi I created a Debian 12 VM template for our systems and saw that the id's did not match (I checked them because I have to recreate them if the template gets copied). So I have not seen any "user-visible symptoms" it was simply luck that I checked the files. At first I thought there was a change and the id's need to be different in Debian 12, so I read the docs and found nothing. Then I asked in IRC and then I created the bug entry. Regards, yogg Am 13.07.23 um 20:22 schrieb Simon McVittie: On Mon, 10 Jul 2023 at 17:27:50 +0200, yogg wrote: After installation was finished and the system has been restarted the files "/etc/machine-id" and "/var/lib/dbus/machine-id" are not linked in any way (no soft or hardlink) and the ID inside the files differ from each other. This was a regression in bookworm, thank you for reporting it. A fix is in unstable, and on its way into testing and a future bookworm stable update (hopefully as soon as 12.1, which is due in just over a week). What user-visible symptoms, if any, did this cause for you? The machine ID can be used by almost anything (in the same way that almost anything can use the hostname), so it's difficult to get a clear picture of how bad this is, or how much risk it would be acceptable to take when fixing this up on existing systems. Workaround: rm /etc/machine-id /var/lib/dbus/machine-id && dbus-uuidgen --ensure=/etc/machine-id && dbus-uuidgen --ensure "rm /var/lib/dbus/machine-id && dbus-uuidgen --ensure" would be enough, in fact. smcv
Bug#1040790: installation-reports: ID in /etc/machine-id and /var/lib/dbus/machine-id mismatch on fresh debian 12 installation
On Mon, 10 Jul 2023 at 17:27:50 +0200, yogg wrote: > After installation was finished and the system has been restarted the > files "/etc/machine-id" and "/var/lib/dbus/machine-id" are not linked > in any way (no soft or hardlink) and the ID inside the files differ from > each other. This was a regression in bookworm, thank you for reporting it. A fix is in unstable, and on its way into testing and a future bookworm stable update (hopefully as soon as 12.1, which is due in just over a week). What user-visible symptoms, if any, did this cause for you? The machine ID can be used by almost anything (in the same way that almost anything can use the hostname), so it's difficult to get a clear picture of how bad this is, or how much risk it would be acceptable to take when fixing this up on existing systems. > Workaround: > rm /etc/machine-id /var/lib/dbus/machine-id && dbus-uuidgen > --ensure=/etc/machine-id && dbus-uuidgen --ensure "rm /var/lib/dbus/machine-id && dbus-uuidgen --ensure" would be enough, in fact. smcv
Bug#1040790: installation-reports: ID in /etc/machine-id and /var/lib/dbus/machine-id mismatch on fresh debian 12 installation
On Tue, Jul 11, 2023 at 02:20:32PM +0100, Luca Boccassi wrote: >On Tue, 11 Jul 2023 at 14:14, Simon McVittie wrote: >> >> 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. Agreed, 100%. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say." -- Edward Snowden
Bug#1040790: installation-reports: ID in /etc/machine-id and /var/lib/dbus/machine-id mismatch on fresh debian 12 installation
On Tue, 11 Jul 2023 at 14:14, Simon McVittie 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
Processed: Re: Bug#1040790: installation-reports: ID in /etc/machine-id and /var/lib/dbus/machine-id mismatch on fresh debian 12 installation
Processing control commands: > reassign -1 src:dbus 1.12.20-3 Bug #1040790 [installation-reports] installation-reports: ID in /etc/machine-id and /var/lib/dbus/machine-id mismatch on fresh debian 12 installation Bug reassigned from package 'installation-reports' to 'src:dbus'. Ignoring request to alter found versions of bug #1040790 to the same values previously set Ignoring request to alter fixed versions of bug #1040790 to the same values previously set Bug #1040790 [src:dbus] installation-reports: ID in /etc/machine-id and /var/lib/dbus/machine-id mismatch on fresh debian 12 installation Marked as found in versions dbus/1.12.20-3. -- 1040790: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040790 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1040790: installation-reports: ID in /etc/machine-id and /var/lib/dbus/machine-id mismatch on fresh debian 12 installation
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.
> 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.
smcv
Bug#1040790: installation-reports: ID in /etc/machine-id and /var/lib/dbus/machine-id mismatch on fresh debian 12 installation
On Mon, 10 Jul 2023 17:14:48 +0100 Steve McIntyre
wrote:
> Hi, and thanks for your bug report!
>
> On Mon, Jul 10, 2023 at 05:27:50PM +0200, yogg wrote:
> >Package: installation-reports
> >Severity: serious
> >Tags: d-i
> >Justification: https://wiki.debian.org/MachineId
> >
>
> ...
>
> >After installation was finished and the system has been restarted
the
> >files "/etc/machine-id" and "/var/lib/dbus/machine-id" are not
linked
> >in any way (no soft or hardlink) and the ID inside the files differ
> >from each other.
>
> I've confirmed this bug just now, doing a clean installation from the
> 12.0.0 amd64 netinst.
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.
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:
$ cat /var/lib/dpkg/info/dbus-daemon.postinst
#!/bin/sh
set -e
if [ "$1" = configure ]; then
# This is idempotent, so it's OK to do every time. The system bus' init
# script does this anyway, but you also have to do this before a session
# bus will work on non-systemd systems, so we do this here for the
# benefit of people starting a temporary session bus in a chroot.
mkdir -p "${DPKG_ROOT:-/}var/lib/dbus"
dbus-uuidgen --ensure="${DPKG_ROOT:-/}var/lib/dbus/machine-id"
fi
# Automatically added by dh_installtmpfiles/13.11.4
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
if [ -x "$(command -v systemd-tmpfiles)" ]; then
systemd-tmpfiles ${DPKG_ROOT:+--root="$DPKG_ROOT"} --create
dbus.conf >/dev/null || true
fi
fi
# End automatically added section
It seems to me a safe way to fix this and do the right thing is to swap
the #DEBHELPER# token and the manual dbus-uuidgen block in dbus-
daemon's postinst. Then on systemd systems the tmpfiles will win and on
other systems dbus-uuidgen will do its job.
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
Bug#1040790: installation-reports: ID in /etc/machine-id and /var/lib/dbus/machine-id mismatch on fresh debian 12 installation
Hi, and thanks for your bug report! On Mon, Jul 10, 2023 at 05:27:50PM +0200, yogg wrote: >Package: installation-reports >Severity: serious >Tags: d-i >Justification: https://wiki.debian.org/MachineId > ... >After installation was finished and the system has been restarted the >files "/etc/machine-id" and "/var/lib/dbus/machine-id" are not linked >in any way (no soft or hardlink) and the ID inside the files differ >from each other. I've confirmed this bug just now, doing a clean installation from the 12.0.0 amd64 netinst. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Managing a volunteer open source project is a lot like herding kittens, except the kittens randomly appear and disappear because they have day jobs." -- Matt Mackall
Bug#1040790: installation-reports: ID in /etc/machine-id and /var/lib/dbus/machine-id mismatch on fresh debian 12 installation
Package: installation-reports Severity: serious Tags: d-i Justification: https://wiki.debian.org/MachineId (Please provide enough information to help the Debian maintainers evaluate the report efficiently - e.g., by filling in the sections below.) Boot method: CD/network Image version: http://ftp.debian.org/debian/dists/bookworm/main/installer-amd64/ Date: 2023-07-10 Machine: Virtual-Maschine Partitions: Disk /dev/vda: 10 GiB, 10737418240 bytes, 20971520 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0xcf0c07c3 Device Boot Start End Sectors Size Id Type /dev/vda1 2048 2000895 1998848 976M 82 Linux swap / Solaris /dev/vda2 *2000896 20969471 189685769G 83 Linux Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect media: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O]? Comments/Problems: After installation was finished and the system has been restarted the files "/etc/machine-id" and "/var/lib/dbus/machine-id" are not linked in any way (no soft or hardlink) and the ID inside the files differ from each other. Expected: "cat /etc/machine-id /var/lib/dbus/machine-id" should return the same ID two times Workaround: rm /etc/machine-id /var/lib/dbus/machine-id && dbus-uuidgen --ensure=/etc/machine-id && dbus-uuidgen --ensure -- Package-specific info: == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="12 (bookworm) - installer build 20230607" X_INSTALLATION_MEDIUM=netboot == Installer hardware-summary: == uname -a: Linux debian-test 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC [Natoma] [8086:1237] (rev 02) lspci -knn: Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100] lspci -knn: 00:01.0 ISA bridge [0601]: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] [8086:7000] lspci -knn: Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100] lspci -knn: 00:01.1 IDE interface [0101]: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] [8086:7010] lspci -knn: Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100] lspci -knn: Kernel driver in use: ata_piix lspci -knn: Kernel modules: ata_piix, ata_generic lspci -knn: 00:01.3 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ACPI [8086:7113] (rev 03) lspci -knn: Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100] lspci -knn: 00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8] lspci -knn: Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100] lspci -knn: Kernel driver in use: cirrus lspci -knn: Kernel modules: cirrus lspci -knn: 00:03.0 Ethernet controller [0200]: Red Hat, Inc. Virtio network device [1af4:1000] lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:0001] lspci -knn: Kernel driver in use: virtio-pci lspci -knn: Kernel modules: virtio_pci lspci -knn: 00:04.0 Communication controller [0780]: Red Hat, Inc. Virtio console [1af4:1003] lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:0003] lspci -knn: Kernel driver in use: virtio-pci lspci -knn: Kernel modules: virtio_pci lspci -knn: 00:05.0 SCSI storage controller [0100]: Red Hat, Inc. Virtio block device [1af4:1001] lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:0002] lspci -knn: Kernel driver in use: virtio-pci lspci -knn: Kernel modules: virtio_pci lspci -knn: 00:06.0 Unclassified device [00ff]: Red Hat, Inc. Virtio memory balloon [1af4:1002] lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:0005] lspci -knn: Kernel driver in use: virtio-pci lspci -knn: Kernel modules: virtio_pci lspci -knn: 00:07.0 Unclassified device [00ff]: Red Hat, Inc. Virtio RNG [1af4:1005] lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:0004] lspci -knn: Kernel driver in use: virtio-pci lspci -knn: Kernel modules: virtio_pci lsmod: Module Size Used by lsmod: fuse 176128 0 lsmod: battery28672 0 lsmod: dm_mod184320 0 lsmod: md_mod192512 0 lsmod: xfs 1945600 0 lsmod: jfs 221184 0 lsmod: btrfs1777664 0 lsmod: xor24576 1 btrfs lsmod:
