Bug 1658739 - dbus-daemon is enabled (but fails to start) after live install
Summary: dbus-daemon is enabled (but fails to start) after live install
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: fedora-release
Version: rawhide
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Mohan Boddu
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa AcceptedBlocker
: 1671737 1672056 (view as bug list)
Depends On:
Blocks: F30FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2018-12-12 18:53 UTC by Adam Williamson
Modified: 2019-02-26 10:07 UTC (History)
32 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-25 18:38:30 UTC


Attachments (Terms of Use)

Description Adam Williamson 2018-12-12 18:53:40 UTC
anaconda, at present, requires dbus-daemon, because it runs its own dbus instance and does this with dbus-daemon (not broker).

This means we have to include the dbus-daemon package in the live images, or else anaconda won't work. However, because it's included in the *live image* itself, it is also included in *the installed system* (that's how live images work), and on boot, it tries to start up, but fails.

This is a violation of the Final release criteria: https://fedoraproject.org/wiki/Fedora_30_Final_Release_Criteria#System_services - "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."

There are obviously a few different ways this could be resolved (not having dbus-daemon service enabled when the package is installed, porting anaconda to dbus-broker, etc...), but it needs to be resolved somehow.

Comment 1 Adam Williamson 2018-12-12 18:54:04 UTC
CCing mkolman for anaconda side of this.

Comment 2 Adam Williamson 2018-12-12 18:56:47 UTC
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.

Comment 3 Vendula Poncova 2018-12-13 17:59:47 UTC
Porting anaconda to dbus-broker is a reasonable solution. We will implement it.

Comment 4 Geoffrey Marr 2018-12-17 20:04:26 UTC
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

Comment 5 Adam Williamson 2019-01-15 16:13:34 UTC
For the record, still valid with 20190115.n.0.

Comment 6 Jiri Konecny 2019-01-29 13:36:27 UTC
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.

Comment 7 David Bauer 2019-02-01 16:59:13 UTC
*** Bug 1671737 has been marked as a duplicate of this bug. ***

Comment 8 David Bauer 2019-02-04 13:46:37 UTC
*** Bug 1672056 has been marked as a duplicate of this bug. ***

Comment 9 Jiri Konecny 2019-02-15 16:08:52 UTC
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?

Comment 10 David King 2019-02-15 16:42:18 UTC
(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

Comment 11 Adam Williamson 2019-02-15 17:05:02 UTC
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.

Comment 12 Jiri Konecny 2019-02-18 09:22:13 UTC
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.

Comment 13 Adam Williamson 2019-02-19 19:07:36 UTC
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

Comment 14 Adam Williamson 2019-02-25 18:38:30 UTC
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.

Comment 15 Jiri Konecny 2019-02-26 10:07:17 UTC
Thanks for testing this Adam. I'm glad we have found the way.


Note You need to log in before you can comment on or make changes to this bug.