Bug 1658739

CCing mkolman for anaconda side of this.

Oddly, this bug shows up in the Workstation live, but not the KDE live. I'm not 100% sure why that is, yet. Will try and dig into it a bit more. Porting anaconda to dbus-broker is the 'obvious' fix here, though.

Porting anaconda to dbus-broker is a reasonable solution. We will implement it.

Discussed during the 2018-12-17 blocker review meeting: [1]

The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criteria:

"All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present."

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-12-17/f30-blocker-review.2018-12-17-17.00.txt

For the record, still valid with 20190115.n.0.

Yes, it is still valid. We have met with the DBus broker developers to find the best way to make Anaconda transition to DBus Broker. Luckily we would implement this soon.

*** Bug 1671737 has been marked as a duplicate of this bug. ***

*** Bug 1672056 has been marked as a duplicate of this bug. ***

Hello everyone,

We were working on many ways how this is doable. See below for explanation or under separator for our proposal to fix this.

The first option we were thinking was that we will migrate to dbus broker. Unfortunately, thanks to the fact we are running our own dbus instance, and that lmc is run in a mock so we don't have systemd available all the time. Thanks to all of this it is not an easy to migrate to dbus broker. And we don't want to give that amount of work to end up with code where on RHEL-8 we have standard dbus and code on Fedora with the new dbus-broker.

Thanks to this I was also looking onto how we can enable having systemd all the time but that is even more complicated thanks to the fact that lmc is running Anaconda in koji and koji runs in a mock. The problem is that lmc can be run only in the old mock (--old-chroot) which is not suitable to run systemd and it can't be started in a new mock because you can't use loop devices here.

----------

So our proposal is to split the DBus package into `dbus` and `minimal`. The minimal package would contain all the binaries necessary to run your own dbus session, namely `dbus-daemon` binary which is called by Anaconda. Then only the `minimal` package would be contained in the Live environment (Anaconda dependency) and the `dbus-broker` started as a service. That would also mean that the Live media would run both dbus-broker system and user sessions and dbus Anaconda private session but I guess that shouldn't be a problem.

We already did something similar with the blivet-gui package and it works well.

What do you think David, Adam? Is that doable from your point of view?

(In reply to Jiri Konecny from comment #9)

> So our proposal is to split the DBus package into `dbus` and `minimal`. The
> minimal package would contain all the binaries necessary to run your own
> dbus session, namely `dbus-daemon` binary which is called by Anaconda. Then
> only the `minimal` package would be contained in the Live environment
> (Anaconda dependency) and the `dbus-broker` started as a service. That would
> also mean that the Live media would run both dbus-broker system and user
> sessions and dbus Anaconda private session but I guess that shouldn't be a
> problem.

The minimal package exists as of today, and is called "dbus-daemon". You do not mention what would be in the "dbus" package that you propose, so it is difficult to know if there need to be any changes to dbus packaging, but it seems not. The fix for this would seem to be making dbus-broker enabled in the Fedora presets, and ensuring dbus-daemon is disabled. There is a pull request for fedora-presets to do exactly that, which looks set to be merged soon:

https://src.fedoraproject.org/rpms/fedora-release/pull-request/37

The point of the 'minimal' package would be to include the dbus-daemon *binary* but not the *service*. This idea was based on the assumption that the dbus maintainers still wanted dbus-daemon enabled by default if it was installed. If that's not actually the case, and it will be switched to disabled by default, then I think indeed that should actually solve the problem here.

Yes exactly as Adam said.

So it is even easier fix than I thought with no changes in the packaging. Thanks David for this info and link.

Adam, I'll leave this bug open in case that the solution won't work as expected. Please close the bug if everything will work fine.

The PR has been merged and a new fedora-release build was done yesterday; hopefully with the next Rawhide compose, this should be fixed.

https://koji.fedoraproject.org/koji/buildinfo?buildID=1211957

We don't have a Rawhide compose yet, still, but we *did* get a Branched compose (which should contain the same change, as that build has both f30 and f31 tags), and indeed the issue appears fixed. Both live images passed most tests, including the 'base_services_start' test which was failing due to this issue.

Thanks for testing this Adam. I'm glad we have found the way.