Hi
On Sun, Nov 25, 2018 at 10:53 PM Tomasz Kłoczko
<kloczko.tomasz(a)gmail.com> wrote:
On Sun, 25 Nov 2018 at 11:35, Tomasz Kłoczko <kloczko.tomasz(a)gmail.com> wrote:
[..]
> I’m talking about F30 recent change in which has been implemented switch to
dubs-broker.
> Ps. If this change has been propagated to F29 (hopefully not) more things will be
screwed.
Seems I found what caused the issue.
I've been doing upgrade (only) dbus packages using rpm and for some
reason after all old dbus-daemon has been killed and deactivated and
at the same time dbus-broker has not been started.
Instant effect was very strange. For example I was unable to unpack
any archives with files owned by group/user not present in my system
because NSS seems now depends on dbus as well. After next few minutes
Gnome GUI crashed,
if [ $1 -eq 1 ] ; then
systemctl --no-reload disable dbus-daemon.service
systemctl --no-reload --global disable dbus-daemon.service
systemctl --no-reload enable dbus-broker.service
systemctl --no-reload --global enable dbus-broker.service
fi
This dbus-broker %post scriplet seems is only swapping started
services but does not stops dbus-daemon and starts dbus-broker if
dbus-daemon is already runimg.
You cannot stop dbus-daemon on a running system. This would tear down
everything. The package upgrade needs a reboot.
At the same time because in spec file is missing uninstall
dbus-daemon
by missing "Obsoletes: dbus-daemon" below
Uninstalling dbus-daemon would break a running system, because it
would stop the system bus. Furthermore, other packages still depend on
tools provided by the old dbus-package. Can you elaborate why it is
harmful to keep dbus-daemon around? We made sure you can manually
remove it, unless other packages explicitly depend on the dbus-daemon
binary for private buses.
%triggerpostun -- dbus-daemon
systemctl --no-reload preset dbus-broker.service
systemctl --no-reload --global preset dbus-broker.service
has not been activated as well. IMO implementing whole transition with
leaving both old and new packages installed seems is wrong.
Solution: login after all in single mode and execute "systemctl enable
dbus-broker" than reboot.
This surprises me. You are saying a simple reboot did not solve your
issues? The `enable` line is executed during upgrade, but you are
saying on your system dbus-broker was not enabled after the upgrade?
Other problem is that dnf and rpm are executing batch of packages
scriplets not the same order with other operations. Breaking rpm
semantics by dnf is kind of asking for troubles.
Thanks a lot for the report. We tested this upgrade with several
different setups (both dbus-daemon and broker installed/not installed
before the upgrade, etc.), and we didn't see this behavior. We are
aware that this update needs a reboot to fully work, but we made sure
it somewhat works even if you don't reboot. For rawhide, there is
sadly no way to mark updates as "needs reboot".
Thanks
David