Bug 218750
| Summary: | devel/dbus: X11 fails to start because /etc/machine-id missing under 10.3 RELEASE 2017Q2 | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | MMacD <scratch65535> |
| Component: | Individual Port(s) | Assignee: | freebsd-desktop (Team) <desktop> |
| Status: | Closed Overcome By Events | ||
| Severity: | Affects Only Me | CC: | arichardson, desktop, grahamperrin, tatsuki_makino, tcberner, tijl, w.schwarzenfeld |
| Priority: | --- | Flags: | tcberner:
maintainer-feedback+
|
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
| URL: | https://reviews.freebsd.org/D37722 | ||
| See Also: | https://reviews.freebsd.org/D37723 | ||
|
Description
MMacD
2017-04-19 10:07:37 UTC
We use /var/lib/dbus/machine-id. Applications normally check both that and /etc/machine-id. The file is created at boot if you have dbus_enable="YES" in /etc/rc.conf. Ideally it would be created when you install the dbus package. The problem is that it should stay the same across package updates and because update is currently implemented as delete+install that means the file cannot be removed during package delete. Our package testing framework then complains that the file isn't removed properly. No reply! Is this solved with dbus_enable="YES"? So please, close the PR. It looks like there is a lot of software that hardcodes /etc/machine-id (https://codesearch.debian.net/search?q=%2Fetc%2Fmachine-id&literal=1) and I'm not sure if all of them have a fallback to /var/lib/dbus/machine-id. According to https://www.freedesktop.org/software/systemd/man/machine-id.html machine-id does not necessarily have to be the same as /var/lib/dbus/machine-id, but as a simple solution, would a symlink from /etc to /var/lib/dbus work? This would be similar to /etc/os-release? Or maybe it makes more sense to generate this file with a firstboot script? Debian codesearch packages that reference the string /etc/machine-id: ``` kopanocore golang-github-containers-toolbox bolt apparmor cadvisor distrobox quassel qtsystems-opensource-src python-diskimage-builder spectre-meltdown-checker debian-edu-fai libjcat network-manager facterdb mono golang-github-coreos-go-systemd golang-github-crowdsecurity-machineid godot golang-github-smallstep-cli guestfs-tools olive-editor ruby-dbus glib2.0 cruft-ng open-infrastructure-system-tools gnome-software ironic cinnamon-settings-daemon systemd libconfig-model-systemd-perl kubernetes flatpak bubblewrap dracut keyman tuned charliecloud slic3r-prusa facter cadical piuparts ltsp ukui-panel freedom-maker qt6-base ruby-train obus openqa open-infrastructure-compute-tools sicherboot dbus-broker dbus libfirefox-marionette-perl mmdebstrap game-data-packager qt6-webengine packer torbrowser-launcher xpra golang-github-go-debos-fakemachine guix python-werkzeug lvm2 e17 plasma-discover libvirt fever fai pcp manpages-l10n qtbase-opensource-src-gles fcitx5 public-inbox snapd debian-lan-config logdata-anomaly-miner golang-github-jouyouyun-hardware sosreport live-build deja-dup vagrant-libvirt rust-zbus s390-tools golang-github-rs-xid gnunet debci installation-birthday gobject-introspection calamares ohai icingadb python-systemd onioncircuits cockpit linux ibus fwupd ricochet-im qutebrowser libigloo rdiff-backup kiwi crowdsec ansible-core sdbus-cpp docker-systemctl-replacement fusioninventory-agent kdevelop magnum mkosi salt debootstrap waagent qtwebengine-opensource-src remmina ostree rust-libsystemd apt aide kstars avahi gnome-tweaks debuerreotype nova calamares-settings-debian qtbase-opensource-src wsdd2 elogind lynis golang-dbus iortcw chromium ``` Just for context: I noticed this because I was trying to build GLib from source and it looks for machine-id in the following two locations: const gchar *var_lib_path = LOCALSTATEDIR "/lib/dbus/machine-id"; const gchar *etc_path = "/etc/machine-id"; And when installing to a local prefix, that means the machine-id is not found since lOCALSTATEDIR will be <prefix>/var (In reply to Alex Richardson from comment #4) Maybe we can add something like https://people.freebsd.org/~tcberner/patches/machine-id as /etc/rc.d/machine-id mfg Tobias (In reply to Alex Richardson from comment #4) When building from source it is always interesting to look at what the port does, e.g. devel/glib20/Makefile adds -Dlocalstatedir=/var to MESON_ARGS. I usually create a copy of the port, e.g. devel/glib20-git, and set WRKSRC in the Makefile to the location of the git checkout. Then you can build and install using that port. (In reply to Tijl Coosemans from comment #6) Add support in base: https://reviews.freebsd.org/D37722 Add support for older releases: https://reviews.freebsd.org/D37723 Where does this consider the hard-coded value to be the highest priority?
In the case of dbus-1.14.4, it appears to be hard-coded in the following.
File: dbus-1.14.4/dbus/dbus-sysdeps-unix.c
Function:
dbus_bool_t
_dbus_read_local_machine_uuid (DBusGUID *machine_id,
dbus_bool_t create_if_not_found,
DBusError *error)
DBUS_MACHINE_UUID_FILE is set by configure to the following value.
-DDBUS_MACHINE_UUID_FILE=\""$(localstatedir)/lib/dbus/machine-id"\"
These were found in a trace of dbus-uuidgen --ensure running in ${LOCALBASE}/etc/rc.d/dbus.
I don't like /var/lib either, but if the talk of moving it to /var/db is adopted, will all these be patched or a symlink-maze :) created?
Moin moin /etc/machine-id is now provided by the base system, so this should no longer be an issue. Please re-open if that is not the case :) mfg Tobias |
