Rawhide composes have been failing the last few days, due to the Cloud base image failing. https://koji.fedoraproject.org/koji/taskinfo?taskID=30189358 and looking at the screenshot... Traceback (most recent call last): File "/sbin/anaconda", line 543, in <module> keyboard_activate_keyboard(localization_proxy) ... gi.repository.Glib.Error: g-io-error-quark: Could not connect: No such file or directory This may well be some other component changing under anaconda, but I am not sure what it is. Please move to that component if it's obvious...
Automatic F30 blocker, as it completely prevents the compose from happening.
So, looking at everything that changed on the day when this started, it looks like it might be caused by dbus. I untagged dbus-1.12.10-3 and the Cloud base image composed. (Although the entire rawhide compose failed for another reason) I'm still not sure _why_ the dbus update caused this. It adds: +%triggerpostun common -- dbus-common < 1:1.12.10-4 +systemctl --no-reload preset dbus.socket &>/dev/null || : +systemctl --no-reload --global preset dbus.socket &>/dev/null || : + +%triggerpostun daemon -- dbus-daemon < 1:1.12.10-4 +systemctl --no-reload preset dbus-daemon.service &>/dev/null || : +systemctl --no-reload --global preset dbus-daemon.service &>/dev/null || :
Does that have the effect of actually implementing the dbus -> dbus-broker switch, and anaconda turns out not to work with dbus-broker? ...or something?
No, the intent of that change was to make sure upgraded users get the new units enabled for the broker. I am not sure how preset calls might mess up an install. ;( Adding zbyszek for any systemd thoughts...
dbus.socket, dbus-daemon.service are enabled in presets. So if those 'systemctl presets' commands were executed, both units should be (still) enabled afterwards. That said, during a compose, I don't think *anything* should be ever uninstalled, so those %triggerpost*un* lines should never fire. So the error must be somewhere different I think.
The problem is that dbus-common which contains the unit files in question has no dependency on systemd (see https://fedoraproject.org/wiki/Packaging:Scriptlets#Scriptlets for how this should look). Hence, during the initial installation, dbus-daemon is installed before systemd, and the preset call done from the dbus-daemon scriptlet fails silently. The right solution is either to add '%{?systemd_requires}' or '%{?systemd_ordering}' to the dbus-daemon. Note that in F30, the unit files have been moved to dbus-common, so those macros should be added to that package instead.
Oh, and btw, this is fairly easy to test: $ koji download-build -a noarch -a x86_64 1140329 $ sudo dnf -y --setopt=install_weak_deps=False --releasever=29 --installroot=/tmp/f29test2 --disablerepo='*' --enablerepo=fedora --enablerepo=updates install dnf fedora-release dbus-common-1.12.10-2.fc29.noarch.rpm dbus-libs-1.12.10-2.fc29.x86_64.rpm dbus-daemon-1.12.10-2.fc29.x86_64.rpm dbus-1.12.10-2.fc29.x86_64.rpm dbus-tools-1.12.10-2.fc29.x86_64.rpm $ sudo systemd-nspawn -D /tmp/f29test2 # systemctl is-enabled dbus.socket
https://src.fedoraproject.org/rpms/dbus/pull-request/8 has a fix for this (and another bif of fallout from the dbus-broker changes).
dbus-1.12.10-4.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-1eff1712c2
dbus-1.12.10-4.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-1eff1712c2
dbus-1.12.10-5.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-a232773e25