Bug#851445: /etc/machine-id is not guaranteed to exist, makes test-suite failures non-fatal

Michael Biebl biebl at debian.org
Sun Jan 15 00:43:10 GMT 2017


Source: systemd
Version: 232-10
Severity: important

While investigating #851412, I noticed that we have a couple of buildds,
where the test-suite fails but we ignore the error, because
/etc/machine-id does not exist.
In case of mips64el this did hide a real bug.

As init is no longer essential, the assumption that /etc/machine-id is
always available and the absence means an old sysv chroot where we can
ignore test suite failures is no longer correct:
https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=bb42ca5806768929f4b31db04ad651cedcbf421c

We have three options
a/ Add a Build-Depends: systemd <!nocheck>
   This ensures /etc/machine-id exists while still making the package
   bootstrappable by using "nocheck". The only downside afaics is that
   we ignore test suite failures during the initial bootstrap.

b/ Restore
   https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=e27b77c90e48f37495f7792318f9394b41f41420
   Upstream is pretty clear that such a patch won't be merged, so the
   obbvious downside is that we will basically have to carry that
   forever downstream including the ongoing maintainance effort.
   To prove that point, the original patch by Martin no longer applies
   cleanly and would need to be forward ported.

c/ Get /etc/machine-id in a different, essential package so we can
   depend on it existing always.
   We tried that in #745876 but the base-files maintainer did not take
   that patch.

d/ Use an LD_PRELOAD hack, which overrides sd_id128_get_machine. An
   example that was mentioned in IRC by waldi was
   thin-provisioning-tools.

a/ strikes me as the most simple solution, which always has a certain
appeal. I'd appreciate more feedback why we should not pick that obvious
solution and go a different way. Maybe there is a different way I forgot
to think about.


The status quo of ignoring test suite failures is bad. I suspect this to
regress once more build chroots are rebuilt where init is not essential.

Michael

-- Package-specific info:

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd is related to:
pn  dracut           <none>
ii  initramfs-tools  0.126
ii  udev             232-10

-- no debconf information



More information about the Pkg-systemd-maintainers mailing list