Bug 1623781

Created attachment 1479715 [details]
journal of a failed boot

Yes, I can confirm. Knowing about this issue at Kamil's computer, I did this:

- sudo dnf update
- sudo dnf install dbus-broker
- sudo systemctl enable dbus-broker.service
- reboot

I have not experienced any problem when booting. Seems that the missing dependency really is at heart of this bug.

How did you get dbus-1:1.12.10-2 installed? It has a dependency on system-release-30-0.2, which should not be available on F29. Can you tell me your version of the `fedora-release` package?

A simple workaround is to run `systemctl enable dbus-daemon`. You should only use `systemctl enable dbus-broker`, if you want dbus-broker over dbus-daemon.

The new dbus package requires an updated `fedora-release` package, which provides the required systemd presets. With those presets available, install 'dbus' will automatically enable 'dbus-daemon.service' (which causes the missing symlink from 'dbus.service' to point to it). Hence, my question which version of fedora-release you have installed?

You seem to be right about the dependency:

$ sudo dnf repoquery --requires dbus-common-1:1.12.10-2.fc29
/bin/sh
/usr/sbin/useradd
system-release >= 30-0.2

But it seems to have no effect:

$ sudo dnf whatprovides system-release
fedora-release-29-0.13.noarch : Fedora release files
Repo        : @System
Matched from:
Provide    : system-release

fedora-release-29-0.13.noarch : Fedora release files
Repo        : fedora
Matched from:
Provide    : system-release

generic-release-29-0.2.fc29.noarch : Generic release files
Repo        : fedora
Matched from:
Provide    : system-release

$ rpm -q fedora-release
fedora-release-29-0.13.noarch

$ sudo dnf update dbus\*
Dependencies resolved.
======================================================================================================================
 Package                   Arch                 Version                           Repository                     Size
======================================================================================================================
Upgrading:
 dbus                      x86_64               1:1.12.10-2.fc29                  updates-testing                10 k
 dbus-common               noarch               1:1.12.10-2.fc29                  updates-testing                16 k
 dbus-daemon               x86_64               1:1.12.10-2.fc29                  updates-testing               196 k
 dbus-libs                 x86_64               1:1.12.10-2.fc29                  updates-testing               145 k
 dbus-tools                x86_64               1:1.12.10-2.fc29                  updates-testing                50 k
 dbus-x11                  x86_64               1:1.12.10-2.fc29                  updates-testing                27 k

Transaction Summary
======================================================================================================================
Upgrade  6 Packages

Total download size: 443 k
Is this ok [y/N]: n
Operation aborted.
# No error, would update just fine.


So, the dependency doesn't apply for some reason. Also, if this is expected to work only on F30, why is it in F29 updates-testing?
https://bodhi.fedoraproject.org/updates/FEDORA-2018-825a2eed3d

(In reply to Kamil Páral from comment #4)
> You seem to be right about the dependency:
> 
...
> 
> But it seems to have no effect:

Aha. I am confused. Do explicit versioned dependencies not work on 'Provides:'? If not, how am I supposed to depend on an explicit version of 'fedora-release'? I was told to use 'system-release', as different fedora flavors call the packet differently...

I am confused.

> So, the dependency doesn't apply for some reason. Also, if this is expected
> to work only on F30, why is it in F29 updates-testing?
> https://bodhi.fedoraproject.org/updates/FEDORA-2018-825a2eed3d

I only filed this for rawhide, so I did not expect this to hit F29. This seems to be a misunderstanding. Anyway, we would still love these dbus.spec cleanups in F29, so I don't mind them being there. The 'system-release' dependency needs to be 29-0.12 in that case, though (which you have installed).

So I can only imagine that the explicit version dependencies don't work here. Hence 'fedora-release' got updated on your machine *after* 'dbus' (which is exactly what is not supposed to happen). In this case a simple re-install of 'dbus-daemon' should fix the issue, though. Can you re-run the dbus-daemon install and see whether the dbus.service symlink is then properly installed? This works as expected on my machine.

In the meantime, I will try to find someone explain to me the version-dependency issue here..

Thanks a lot for the report!

Also: If you *did* run `systemctl enable dbus-broker` before, then please undo this via `systemctl disable dbus-broker`. You can only ever have one dbus implementation enabled. Either dbus-broker of dbus-daemon. The fedora-release package currently ships the rules to enable dbus-daemon (or at least is meant to do that).

Enabling just dbus-daemon fixed the issue for me.

[ludovic@saraan ~]$ rpm -qa |grep fedora-release
fedora-release-29-0.13.noarch
fedora-release-workstation-29-0.13.noarch
[ludovic@saraan ~]$

(In reply to Ludovic Hirlimann [:Paul-muadib] from comment #7)
> Enabling just dbus-daemon fixed the issue for me.
> 
> [ludovic@saraan ~]$ rpm -qa |grep fedora-release
> fedora-release-29-0.13.noarch
> fedora-release-workstation-29-0.13.noarch
> [ludovic@saraan ~]$

Thanks for confirming!

A simple `dnf install dbus dbus-common dbus-daemon` should as well fix the issue (make sure the packages are actually reinstalled and the post-install scripts are executed). If someone can confirm this, I will push the required change to dbus.spec.s

(In reply to David Herrmann from comment #5)
> (In reply to Kamil Páral from comment #4)
> > You seem to be right about the dependency:
> > 
> ...
> > 
> > But it seems to have no effect:
> 
> Aha. I am confused. Do explicit versioned dependencies not work on
> 'Provides:'? If not, how am I supposed to depend on an explicit version of
> 'fedora-release'? I was told to use 'system-release', as different fedora
> flavors call the packet differently...

No idea, ask in packaging mailing list or IRC channel.

> Can you re-run the
> dbus-daemon install and see whether the dbus.service symlink is then
> properly installed? This works as expected on my machine.

I upgraded to dbus-1:1.12.10-2 again, and it broke my boot again. When I tried to start dbus.service manually, the error was "no such service file" (or similar).

I then installed dbus-broker, that didn't help. Only after enabling dbus-broker and rebooting, the system booted properly.

(Then I reverted everything back to dbus-1:1.12.10-1 and uninstalled dbus-broker).

Can we please unpush the Bodhi update ASAP, before it breaks system for more users?

(In reply to Kamil Páral from comment #9)
> (In reply to David Herrmann from comment #5)
> > Can you re-run the
> > dbus-daemon install and see whether the dbus.service symlink is then
> > properly installed? This works as expected on my machine.
> 
> I upgraded to dbus-1:1.12.10-2 again, and it broke my boot again. When I
> tried to start dbus.service manually, the error was "no such service file"
> (or similar).

dbus-daemon-1:1.12.10-2 will only provide 'dbus.service' if fedora-release-29-0.12 is installed on your machine *BEFORE* you install the dbus-daemon package. A fix for this is pending [1]. Before this can be merged, I would like to know whether this actually fixes the problem. Hence my question:

When you *install* dbus-daemon-1:1.12.10-2 *after* fedora-release-29-0.12 was installed on your machine, do you still encounter this bug?

> I then installed dbus-broker, that didn't help. Only after enabling
> dbus-broker and rebooting, the system booted properly.

I don't think dbus-broker is related to anything here.

> (Then I reverted everything back to dbus-1:1.12.10-1 and uninstalled
> dbus-broker).
>
> Can we please unpush the Bodhi update ASAP, before it breaks system for more
> users?

I am not privileged to do this, I merely try to fix this bug. It is up to the dbus maintainers to do this.

Thanks
David

[1] https://src.fedoraproject.org/rpms/dbus/pull-request/6

I'm running F30 (30-0.7)

dbus didn't start (or died). Reverted to 1:1.12.10-1.fc29

Thanks for the report and your patience. The cause for this issue is that the systemd RPM macros are only triggered on initial install, not on upgrade, so the presets are not applied when the package is updated.

I saw that David King just unpushed the package from f29, and we will figure out a proper fix ASAP.

What would happen if you just run "systemctl preset" unconditionally on upgrade, that is, remove the "if [ $1 -eq 1 ] ; then" test in postinstall?

The system-release Provides: in fedora-release and generic-release are not versioned. This is I think intentional, because the versions of fedora-release and generic-release are not guaranteed to be the same.

I think if you try and do a versioned Require on a non-versioned Provide it just works like this - it's always considered to be satisfied. That is, "Provides: foo" counts as providing *absolutely any version* of 'foo', so a package that "Provides: foo" will satisfy "Requires: foo" or "Requires: foo > 1.0" or "Requires: foo < 1.0" or...anything like that. Not 100% sure, but I think that's how it works.

As well as just plain 'system-release' there's a sorta-versioned provide:

[adamw@xps13k os-autoinst-distri-fedora (master)]$ rpm -q fedora-release
fedora-release-28-2.noarch
[adamw@xps13k os-autoinst-distri-fedora (master)]$ rpm -q --provides fedora-release
...
system-release(28)

so fedora-release-28.(anything) always provides system-release(28), so does generic-release-28.(anything). fedora-release-29.(anything) will provide system-release(29), and so on. But I don't think you can do a dependency any more specific than that, using one of the 'generic' provides.

This seems like it well could also have broken Rawhide composes:

https://pagure.io/dusty/failed-composes/issue/731

I have this problem as well. Problem is I cannot download packages, as it seems that I'm offline, so this is going to be a rough day :D

If anyone has the same problem (network won't connect due to missing dbus), here's what I managed to do:

1) use a different computer to download dbus-broker from koji https://koji.fedoraproject.org/koji/buildinfo?buildID=1139903 on a USB drive

2) connect and manually mount the USB drive to affected system


    $ sudo mkdir /media/tmp
    $ sudo mount /dev/sdb1 /media/tmp/


3) install the package 

    $ sudo dnf install /media/tmp/dbus-broker-15-2.fc29.1.x86_64.rpm 

4) enable the srevice

    $ sudo systemctl enable dbus-broker.service

5) reboot

    $ sudo reboot

(In reply to Miro Hrončok from comment #17)
> If anyone has the same problem (network won't connect due to missing dbus),
> here's what I managed to do:
> 
> 1) use a different computer to download dbus-broker from koji
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1139903 on a USB drive
> 
> 2) connect and manually mount the USB drive to affected system
> 
> 
>     $ sudo mkdir /media/tmp
>     $ sudo mount /dev/sdb1 /media/tmp/
> 
> 
> 3) install the package 
> 
>     $ sudo dnf install /media/tmp/dbus-broker-15-2.fc29.1.x86_64.rpm 
> 
> 4) enable the srevice
> 
>     $ sudo systemctl enable dbus-broker.service
> 
> 5) reboot
> 
>     $ sudo reboot



Simpler:  run as root

        systemctl --no-reload preset dbus-daemon.service dbus.socket 
        systemctl --no-reload preset --global dbus-daemon.service dbus.socket 

Then reboot.  Works for me.

The post-install script would do exactly that, but only on initial install and not during upgrade.

(In reply to David Herrmann from comment #10)
> When you *install* dbus-daemon-1:1.12.10-2 *after* fedora-release-29-0.12
> was installed on your machine, do you still encounter this bug?

I believe this got clarified in comment 12. I updated the package (not installed), while having fedora-release-29-0.13 already present, and the bug is still present.

I downloaded a network install image from the failed Rawhide compose (it got as far as generating some which you can find: https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180830.n.3/compose/Everything/x86_64/os/images/boot.iso for e.g.) and it fails to boot the same way. You can get to a console after the failure occurs by hitting alt-tab.

From there, if you do 'systemctl | grep dbus' it shows nothing, indicating no dbus-related services or sockets are active. Comparing to a working image - https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180823.n.0/compose/Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-Rawhide-20180823.n.0.iso for e.g. - after that boots to a working anaconda, 'systemctl | grep dbus' shows dbus.service and dbus.socket as active and running.

In the broken image, there is no /usr/lib/systemd/system/dbus.service at all. There is a /usr/lib/systemd/system/dbus-daemon.service and a /usr/lib/systemd/system/dbus.socket .

systemctl status dbus-daemon.service shows:

Loaded: loaded (/usr/lib/systemd/system/dbus-daemon.service; disabled; vendor preset: enabled)
Active: inactive (dead)

systemctl status dbus.socket shows:

Loaded: loaded (/usr/lib/systemd/system/dbus.socket; disabled; vendor preset: enabled)
Active: inactive (dead)
...
localhost systemd[1]: dbus.socket: Socket service dbus.service not loaded, refusing.
localhost systemd[1]: Failed to listen on D-Bus System Message Bus Socket.

I think this is indicating that socket and service unit names actually need to *match*; for a dbus.socket to work, there needs to be a dbus.service.

On the working image, dbus.service and dbus.socket both show as active and 'static' (rather than 'disabled' or 'enabled'). Note the preset stuff may be weird in this environment due to how anaconda uses its own systemd targets and stuff.

On the working image, 'ps aux | grep dbus' shows two dbus-daemons running, one with --system --address=systemd: and one without --system and with --print-address. I believe the former is the one run by dbus.service and the latter is a local bus run by anaconda. On the broken image, only the latter dbus-daemon is shown in ps, not a system one.

I think dbus.socket may need this line in the [Socket] section:

Service=dbus-daemon.service

Per 'man systemd.socket':

"For each socket file, a matching service file must exist, describing the service to start on incoming traffic on the socket (see systemd.service(5) for more information about .service files). The name of the .service unit is by default the same as the name of the .socket unit, but can be altered with the Service= option described below."

It doesn't absolutely definitely state that an *alias* doesn't satisfy the requirement, but the wording "matching service *file*" (emphasis added) suggests it quite strongly. So I think probably dbus-daemon.service providing dbus.service as an alias does not fulfil the requirement.

We untagged dbus-1.12.10-2.fc30 and ran a new Rawhide compose, and it worked...so it's definitely the thing that broke the previous compose.

No network service after update. Please fix ASAP.

Proposed as a Blocker for 29-beta by Fedora user raphgro using the blocker tracking app because:

 No network after update. This violates NetworkManager test cases.
https://fedoraproject.org/wiki/Category:NetworkManager_Test_Cases

Tried the suggested workaround with systemctl enable dbus-daemon. Now I get a black screen after login with sddm to lxqt-session.

Well, network is back with the suggested workaround (see comment #25) after given some more wait time to the login process.

Reproducible inside mock:

+ xvfb-run -a -d dbus-launch --exit-with-x11 nautilus -c

** (nautilus:8126): WARNING **: 09:12:32.227: Error on getting connection: Failed to load SPARQL backend: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying

(nautilus:8126): GLib-GIO-CRITICAL **: 09:12:32.239: g_dbus_connection_signal_unsubscribe: assertion 'G_IS_DBUS_CONNECTION (connection)' failed

(nautilus:8126): GLib-GObject-CRITICAL **: 09:12:32.239: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

(nautilus:8126): GLib-GObject-CRITICAL **: 09:12:32.240: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

(nautilus:8126): GLib-GObject-WARNING **: 09:12:32.240: invalid (NULL) pointer instance

(nautilus:8126): GLib-GObject-CRITICAL **: 09:12:32.240: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
GLib-GIO-Message: 09:12:32.294: Using the 'memory' GSettings backend.  Your settings will not be saved or shared with other applications.

(nautilus:8126): Gtk-CRITICAL **: 09:12:32.351: gtk_widget_show: assertion 'GTK_IS_WIDGET (widget)' failed

** (nautilus:8126): CRITICAL **: 09:12:32.352: setup_side_pane_width: assertion 'priv->sidebar != NULL' failed

(In reply to Raphael Groner from comment #25)
> Tried the suggested workaround with systemctl enable dbus-daemon. Now I get
> a black screen after login with sddm to lxqt-session.

You need to also enable dbus for user session:

  sudo systemctl --no-reload preset dbus-daemon.service dbus.socket 
  sudo systemctl --no-reload preset --global dbus-daemon.service dbus.socket

Raphael: this wasn't proposed as a blocker because it has never made it to stable, it is only in u-t. I'm gonna go ahead and unpush it from u-t as well, though, since it seems to be breaking for everyone.

@Adam IMHO it would be better to have another update to let b0rken systems get fixed. That would avoid to have to tell affected users to use a workaround like dnf downgrade.

I'm removing the blocker nomination because this has never reached stable updates.

Everyone affected will unfortunately need to fix this manually. (I booted into runlevel 3 by adding "3" to kernel command line, then "ifup <ethernet device>", and downgraded ibus*). Since the update was unpushed, it should be sufficient to do "dnf distrosync ibus\*". Everyone using updates-testing should be used to use dnf distrosync instead of dnf update anyway, exactly because of unpushed updates. If your local mirror still contains the broken -2 update, you can simply disable u-t repo: dnf distrosync --disablerepo=updates-testing.

s/ibus/dbus/

(In reply to Villy Kruse from comment #28)
> (In reply to Raphael Groner from comment #25)
> > Tried the suggested workaround with systemctl enable dbus-daemon. Now I get
> > a black screen after login with sddm to lxqt-session.
> 
> You need to also enable dbus for user session:
> 
>   sudo systemctl --no-reload preset dbus-daemon.service dbus.socket 
>   sudo systemctl --no-reload preset --global dbus-daemon.service dbus.socket

[root@builder29 ~]# systemctl --no-reload preset dbus-daemon.service dbus.socket
Failed to preset unit: Unit file dbus-daemon.service does not exist.
[root@builder29 ~]# systemctl --no-reload preset --global dbus-daemon.service dbus.socket
Failed to preset unit, unit dbus-daemon.service does not exist.

(In reply to Kamil Páral from comment #31)
> I'm removing the blocker nomination because this has never reached stable
> updates.
> 
> Everyone affected will unfortunately need to fix this manually. (I booted
> into runlevel 3 by adding "3" to kernel command line, then "ifup <ethernet
> device>", and downgraded ibus*). Since the update was unpushed, it should be
> sufficient to do "dnf distrosync ibus\*". Everyone using updates-testing
> should be used to use dnf distrosync instead of dnf update anyway, exactly
> because of unpushed updates. If your local mirror still contains the broken
> -2 update, you can simply disable u-t repo: dnf distrosync
> --disablerepo=updates-testing.

distrosync will downgrade all other packages, too. In my system, there are affected at least 10 other packages (enabled u-t) or 98 packages (disabled u-t). That's not in the sense of the user.

[root@builder29 ~]# dnf update -y
Letzte Prüfung auf abgelaufene Metadaten: vor 0:18:29 am Di 04 Sep 2018 00:05:25 CEST.
Abhängigkeiten sind aufgelöst.

 Problem 1: cannot install the best update candidate for package bubblewrap-0.3.0-2.fc29.x86_64
  - package bubblewrap-0.3.0-2.module_2123+73a9ef6f.x86_64 is disabled
 Problem 2: cannot install the best update candidate for package exempi-2.4.5-3.fc29.x86_64
  - package exempi-2.4.5-3.module_2123+73a9ef6f.x86_64 is disabled
 Problem 3: cannot install the best update candidate for package gnome-desktop3-3.29.90.1-1.fc29.x86_64
  - package gnome-desktop3-3.29.90.1-1.module_2123+73a9ef6f.x86_64 is disabled
 Problem 4: cannot install the best update candidate for package perl-DB_File-1.842-1.fc29.x86_64
  - package perl-DB_File-1.842-1.module_2073+eebc5b71.x86_64 is disabled
 Problem 5: cannot install the best update candidate for package perl-HTTP-Tiny-0.076-1.fc29.noarch
  - package perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch is disabled
 Problem 6: cannot install the best update candidate for package perl-Thread-Queue-3.13-1.fc29.noarch
  - package perl-Thread-Queue-3.13-1.module_2073+eebc5b71.noarch is disabled
Nichts zu tun.
Fertig.

(In reply to Raphael Groner from comment #33)
> distrosync will downgrade all other packages, too. 

Just use "dnf distrosync --disablerepo=updates-testing PACKAGE" (or PACKAGE* or similar).

Created attachment 1480696 [details]
Full procedure for upgrading dbus to 1:1.12.10-2.fc29.x86_64 and make it work.

From a clean Fedora 29 I installed dbus version 1:1.12.10-2.fc29.x86_64 and its dependencies from downloaded rpm files.  Then ran the "systemctl preset" commands to enable the dbus services, and after reboot, everything works normally including networking and xfce desktop.

Thanks a bunch, Kruse!

Your first systemctl preset command seemed to work.  But, why?  I didn't have this problem with dbus package 1:1.12.10-5 or -8.  So, why did this crop up with -9 all of a sudden?

(In reply to Paul DeStefano from comment #36)
> Thanks a bunch, Kruse!
> 
> Your first systemctl preset command seemed to work.  But, why?  I didn't
> have this problem with dbus package 1:1.12.10-5 or -8.  So, why did this
> crop up with -9 all of a sudden?

Probably this change:

https://src.fedoraproject.org/rpms/dbus.git

commit 83c01b25d9470bcd6fb6fd842a5b529c7039d858
Author: Tom Gundersen <teg>
Date:   Fri Aug 31 14:38:09 2018 +0000

    dbus: apply presets on update

    The systemd RPM macros only apply presets on first install, we need
    to also apply them on the initial upgrade that starts depending on
    them.

    Signed-off-by: Tom Gundersen <teg>
    Signed-off-by: David Herrmann <dh.herrmann>


I guess the issue is closable.

There is still something odd going on. Installing 1.12.10-9 breaks the network.

Nov 26 10:21:43 localhost.localdomain NetworkManager[378]: <info>  [1543256503.5295] NetworkManager (version 1.14.2-1.fc30) is starting... (for the first time)
Nov 26 10:21:43 localhost.localdomain NetworkManager[378]: <info>  [1543256503.5295] Read config: /etc/NetworkManager/NetworkManager.conf
Nov 26 10:21:43 localhost.localdomain NetworkManager[378]: <info>  [1543256503.5313] manager[0x560c7aa3f060]: monitoring kernel firmware directory '/lib/firmware'.
Nov 26 10:21:43 localhost.localdomain NetworkManager[378]: <info>  [1543256503.5315] hostname: hostname: hostnamed not used as proxy creation failed with: Could not connect: No such file or directory
Nov 26 10:21:43 localhost.localdomain NetworkManager[378]: <info>  [1543256503.5315] hostname: hostname changed from (none) to "localhost.localdomain"
Nov 26 10:21:43 localhost.localdomain NetworkManager[378]: <info>  [1543256503.5316] dns-mgr[0x560c7aa46920]: init: dns=default, rc-manager=symlink
Nov 26 10:21:43 localhost.localdomain NetworkManager[378]: <error> [1543256503.5319] dispatcher: could not get dispatcher proxy! Could not connect: No such file or directory
Nov 26 10:21:43 localhost.localdomain NetworkManager[378]: <info>  [1543256503.5323] settings: Loaded settings plugin: SettingsPluginIfcfg ("/usr/lib64/NetworkManager/1.14.2-1.fc30/libnm-settings-plug>
Nov 26 10:21:43 localhost.localdomain NetworkManager[378]: <info>  [1543256503.5323] settings: Loaded settings plugin: NMSKeyfilePlugin (internal)
Nov 26 10:21:43 localhost.localdomain NetworkManager[378]: <warn>  [1543256503.5324] ifcfg-rh: Could not read directory '/etc/sysconfig/network-scripts': Error opening directory “/etc/sysconfig/networ>
Nov 26 10:21:43 localhost.localdomain NetworkManager[378]: <info>  [1543256503.5324] manager: rfkill: WiFi enabled by radio killswitch; enabled by state file
Nov 26 10:21:43 localhost.localdomain NetworkManager[378]: <info>  [1543256503.5324] manager: rfkill: WWAN enabled by radio killswitch; enabled by state file
Nov 26 10:21:43 localhost.localdomain NetworkManager[378]: <info>  [1543256503.5324] manager: Networking is enabled by state file
Nov 26 10:21:43 localhost.localdomain NetworkManager[378]: <info>  [1543256503.5325] dhcp-init: Using DHCP client 'dhclient'
Nov 26 10:21:43 localhost.localdomain NetworkManager[378]: <info>  [1543256503.5336] Loaded device plugin: NMTeamFactory (/usr/lib64/NetworkManager/1.14.2-1.fc30/libnm-device-plugin-team.so)
Nov 26 10:21:43 localhost.localdomain NetworkManager[378]: <info>  [1543256503.5340] device (lo): carrier: link connected
Nov 26 10:21:43 localhost.localdomain NetworkManager[378]: <info>  [1543256503.5340] manager: (lo): new Generic device (/org/freedesktop/NetworkManager/Devices/1)
Nov 26 10:21:43 localhost.localdomain NetworkManager[378]: <error> [1543256503.5342] auth: could not create polkit proxy: Could not connect: No such file or directory
Nov 26 10:21:43 localhost.localdomain NetworkManager[378]: <warn>  [1543256503.5343] sleep-monitor-sd: failed to acquire D-Bus proxy: Could not connect: No such file or directory
Nov 26 10:21:43 localhost.localdomain NetworkManager[378]: <warn>  [1543256503.5343] firewall: could not connect to system D-Bus (Could not connect: No such file or directory)
Nov 26 10:21:43 localhost.localdomain NetworkManager[378]: <warn>  [1543256503.5343] ifcfg-rh: dbus: couldn't initialize system bus: Could not connect: No such file or directory
Nov 26 10:21:43 localhost.localdomain NetworkManager[378]: <info>  [1543256503.5344] manager: startup complete

Reverting to 1.12.10-8 fixes the problem, but in order to get the network back you have to run

systemctl enable dbus-broker.service
systemctl --global enable dbus-broker.service

and then reboot.

This is on today's rawhide/koji.

dbus-broker 16-7

That's https://bugzilla.redhat.com/show_bug.cgi?id=1653059 .

Hi,

I just had the same problem, today (jan 29th, 2019).

I am not sure it is the same problem, exactly, but for your information,...

I use the regular fedora desktop 29 (I mean no special release).
Linux xxxx.mylocaldomain 4.20.4-200.fc29.x86_64 #1 SMP Wed Jan 23 16:11:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

I did an update with DNF (with GUI version), and at reboot, black screen, no reaction, nothing.
In the infos (F5) during boot :
"Failed to listen on D-Bus System Message Bus Socket."

in the journal :
"janv. 29 15:30:15 localhost.localdomain systemd[1]: Failed to listen on D-Bus System Message Bus Socket."

I also saw the error :
"Unable to get DBus system bus connection: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory"

many times, in the logs when booting (F5).
and in the journal :

janv. 29 14:47:10 localhost.localdomain libvirtd[963]: 2019-01-29 13:47:10.690+0000: 1267: warning : networkStateInitialize:769 : DBus not available, disabling firewalld support in bridge_network_driver: internal error: Unable to get DBus system bus connection: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory

When I checked (with ls), the "/run/dbus" folder was not there (does not exists).

*******************************
Whith dnf history :
dnf history info 143
I get this :

    Upgraded  curl-7.61.1-6.fc29.x86_64                                       @@System
    Upgrade   dbus-1:1.12.12-1.fc29.x86_64                                    @updates
    Upgraded  dbus-1:1.12.10-1.fc29.x86_64                                    @@System
    Upgrade   dbus-common-1:1.12.12-1.fc29.noarch                             @updates
    Upgraded  dbus-common-1:1.12.10-1.fc29.noarch                             @@System
    Upgrade   dbus-daemon-1:1.12.12-1.fc29.x86_64                             @updates
    Upgraded  dbus-daemon-1:1.12.10-1.fc29.x86_64                             @@System
    Upgrade   dbus-libs-1:1.12.12-1.fc29.i686                                 @updates
    Upgraded  dbus-libs-1:1.12.10-1.fc29.i686                                 @@System
    Upgrade   dbus-libs-1:1.12.12-1.fc29.x86_64                               @updates
    Upgraded  dbus-libs-1:1.12.10-1.fc29.x86_64                               @@System
    Upgrade   dbus-tools-1:1.12.12-1.fc29.x86_64                              @updates
    Upgraded  dbus-tools-1:1.12.10-1.fc29.x86_64                              @@System
    Upgrade   dbus-x11-1:1.12.12-1.fc29.x86_64                                @updates
    Upgraded  dbus-x11-1:1.12.10-1.fc29.x86_64                                @@System
    Upgrade   file-5.34-11.fc29.x86_64                                        @updates
    Upgraded  file-5.34-7.fc29.x86_64         

Note : the upgrade is from 1.12.10-1, to 1.12.12-1
 
*********************************
Workaround that worked :

After reading this post, to repair my system, I did :
"A simple workaround is to run `systemctl enable dbus-daemon`. You should only use `systemctl enable dbus-broker`, if you want dbus-broker over dbus-daemon."

I did only the `systemctl enable dbus-daemon`.

My system booted properly.

Folder /run/dbus is there :
ll -d /run/dbus
drwxr-xr-x. 2 root root 60 29 janv. 17:51 /run/dbus

**********************************
the problem is solved,... but this is strange....

This is still a problem (April 2019).


I'm building a new virtual machine. fedora-release and @core packages are installed, similar to:

/usr/bin/dnf install --assumeyes --installroot /tmp/build_os_image-caa58dbc5a8f3c35647926e9cbedd349 --setopt=reposdir=/tmp/build_os_image-caa58dbc5a8f3c35647926e9cbedd349/etc/yum.repos.d/ --repofrompath=install-os,https://download.fedoraproject.org/pub/fedora/linux/releases/29/Everything/x86_64/os/ --releasever 29 fedora-release

On boot I get:

[FAILED] Failed to listen on D-Bus System Message Bus Socket.
See 'systemctl status dbus.socket' for details.
[DEPEND] Dependency failed for firewalld - dynamic firewall daemon.
[DEPEND] Dependency failed for Network Manager.
[DEPEND] Dependency failed for Network Manager Wait Online.
[DEPEND] Dependency failed for Login Service.

To get it working I only need to enable dbus-daemon and reboot:

systemctl enable dbus-daemon

Not reproducible on systems with F29 Cinnamon or KDE and all current updates applied. In prior, I've done an upgrade from F28. In my opinion, this bug is fixed.

(In reply to Raphael Groner from comment #42)
> Not reproducible on systems with F29 Cinnamon or KDE and all current updates
> applied. In prior, I've done an upgrade from F28. In my opinion, this bug is
> fixed.

Still a problem for me. I've just built a Fedora 29 virtual machine using the dnf --installroot method described in #41 and I am still getting the same problem. The systemd symlink for dbus-daemon is not created so it does not start on boot. `systemctl enable dbus-daemon` fixes this.

I've done the same with a Fedora 30 virtual and again D-Bus does not start on boot. `systemctl enable dbus-daemon`, however, does not fix it. I tried `systemctl enable dbus-broker` and that doesn't enable on boot either. For F30 the closest bugs I could find were:
  Bug 1647172 - dbus-daemon not enabled on live images due to package install ordering problems caused by huge dependency loops 
  Bug 1648721 - Install ordering should always prioritize scriptlet deps over runtime deps, but it seems it may not

Why are you building VMs that way, though. That's a weird way to build VMs. use something saner, like virt-builder or virt-install or something.

(In reply to Adam Williamson from comment #44)
> Why are you building VMs that way, though. That's a weird way to build VMs.
> use something saner, like virt-builder or virt-install or something.

Strangely enough it is an open source/free software project I've developed:
https://gitlab.com/astavale/install-os

It uses --installroot.

Strangely enough a Lennart Poettering, of systemd fame, had a similar idea:
https://github.com/systemd/mkosi
That project is described as 'A fancy wrapper around dnf --installroot,
debootstrap, pacstrap and zypper that may generate disk images'

Thanks for the response, but I take it that Red Hat is no longer supporting
the --installroot method? You have a Red Hat email address. Please tell me this
has nothing to do with Red Hat being bought by IBM and that it will not be policy in
future to close down creativity and innovation of non-Red Hat projects because they
use previously well established ways of doing things.

virt-builder and virt-install are things that were already built to do exactly that, though. That work in such a way they don't have issues like this. Is there a reason for not just using one of those?

"Thanks for the response, but I take it that Red Hat is no longer supporting the --installroot method?"

What do you mean by "no longer"? AFAIK it has never been a supported way of installing a Fedora system bootable in a VM. That isn't really what it's for. I do not speak for "Red Hat", as I work on Fedora. So far as I know this is not and never *has* been a supported way to deploy a Fedora system.

And no, this has nothing at all to do with IBM. You can be as creative and innovative as you like, but when doing so, you're gonna have to accept that sometimes stuff won't work. That's the tradeoff.

BTW, I suspect the reason you're having problems is that systemctl operations are no-ops in a chroot. If systemctl detects that it's running in a chroot it just refuses to do whatever you asked it to do, the code is in systemctl.c function `run()`:

        if (arg_action != ACTION_SYSTEMCTL && running_in_chroot() > 0) {
                if (!arg_quiet)
                        log_info("Running in chroot, ignoring request.");
                r = 0;
                goto finish;
        }

so I suspect that when "installing" into an installroot in this way, no service presets are being applied.

Before stuff started getting changed for dbus-broker, dbus was actually dropping a service file directly into the systemd config directories such that it was effectively doing the equivalent of 'systemctl enable dbus.service' *directly*. Neither dbus-daemon nor dbus-broker does that any more, instead relying on the preset system. So I'm guessing that's the change that affected your workflow. I haven't confirmed this, though.

(In reply to Adam Williamson from comment #46)
> virt-builder and virt-install are things that were already built to do
> exactly that, though. That work in such a way they don't have issues like
> this. Is there a reason for not just using one of those?

Because I've been working on this for over five years and I don't really want
to abandon the project. It is convenient and allows for customised VMs to
be built.

>> "Thanks for the response, but I take it that Red Hat is no longer supporting
>> the --installroot method?"
> 
> What do you mean by "no longer"? AFAIK it has never been a supported way of
> installing a Fedora system bootable in a VM. That isn't really what it's
> for.

There are a number of resolved bug reports and queries that suggest it is used
and fixed when problems come up, e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1227001

The VM part involves creating a disk image with partitions, which is then mounted.
That part has nothing to do with the --installroot method, but --installroot is then
used to install to the mounted partition. A separate stage is then used to configure
/etc/fstab and GRUB2. Again that has nothing to do with the --installroot step.
So it is being used as part of the process, not the complete process. Please don't
conflate the two. What is --installroot meant to be used for otherwise?

> BTW, I suspect the reason you're having problems is that systemctl operations
> are no-ops in a chroot. If systemctl detects that it's running in a chroot it
> just refuses to do whatever you asked it to do

It appears `systemctl enable` creates a symlink to the unit file in /use/lib/systemd.
This is currently working fine for auditd, firewalld, NetworkManager, sshd, etc.
when using the --installroot method. systemctl also has a --root option. The man page
says:
--root= When used with enable/disable/is-enabled (and related commands), use alternative root path when looking for unit files
All that is needed is the symlink to fix this.

Thanks for looking in to this.

@adamw:
Sorry, I didn't see this part before. Replying in case it's still useful:
> "For each socket file, a matching service file must exist, describing the service to start on incoming traffic on the socket (see systemd.service(5) for more information about .service files). The name of the .service unit is by default the same as the name of the .socket unit, but can be altered with the Service= option described below."

> It doesn't absolutely definitely state that an *alias* doesn't satisfy the requirement, but the wording "matching service *file*" (emphasis added) suggests it quite strongly. So I think probably dbus-daemon.service providing dbus.service as an alias does not fulfil the requirement.

I think an alias is OK. Systemd is not doing anything smart here, it just does s/.socket/.service/ on the name
and loads the resulting unit.

→ https://github.com/systemd/systemd/pull/12631/commits/dcc9287e4347b93a54ad154a514f5de03b7cf3ca

@Al:
dnf --installroot is expected to work. I don't know why it's not working for you.
Seems to DTRT here:
$ sudo dnf install --assumeyes --installroot `pwd`/os_image --releasever 29 fedora-release dbus-daemon
$ ls -l os_image/etc/systemd/system/multi-user.target.wants/dbus-daemon.service
lrwxrwxrwx. 1 root root 43 May 22 11:06 os_image/etc/systemd/system/multi-user.target.wants/dbus-daemon.service -> /usr/lib/systemd/system/dbus-daemon.service
$ sudo systemd-nspawn -D os_image -nb
...
[  OK  ] Listening on D-Bus System Message Bus Socket.
[  OK  ] Started D-Bus System Message Bus.
...
$ sudo systemd-nspawn -D os_image -n rpm -q dbus-daemon
dbus-daemon-1.12.12-1.fc29.x86_64

I'll close this bug. The original issue is fixed according to various reporters.
If something goes awry for you with --installroot, please open a new bug as it most likely
is a different issue.

Al: --installroot is definitely *used* for stuff, that's why we keep it around, but it's not generally intended as a way to deploy a full, bootable system. (Rather, for instance, mock uses it to populate the buildroot when building a package - we use it for stuff like that). I may be off on figuring on why it's going wrong, as I said, I didn't check, it's only a theory.