dbus-broker: dbus-broker-units has made Light Display Manager (lightdm) unable to start

Our policy is to refuse broken system software to be installed.

That’s like saying you’re not gonna have safety-belts because you refuse to be involved in an accident. You’re not in factual control of either.

The status quo is that if Joe User installs a single service w/ a malformed config, they’ll be confronted with an unusable system that they’ll have to analyze and fix offline, what is unrealistic and will drive the majority of them into bad decisions (uninformed mitigational efforts or re-installation)

The error is not critical to dbus-broker itself, so if the config is broken/malformed reject the specific service and carry on. Also most users will have some sort of notification daemon - spam them with warnings whenever it shows up on the bus.

@dvdhrm @rgudwin @sileooo @teg

I solved, and I have to say a big thank you to rgudwin.

The files /etc/dbus-1/system.d/org.freedesktop.NetworkManager.Manjaro.conf and /etc/dbus-1/system.d/gksu-polkit.conf had an improper XML formatting: I fixed them (instead of removing) and I have been able to install dbus-broker without the issue on boot.

EDIT: /etc/dbus-1/system.d/org.freedesktop.NetworkManager.Manjaro.conf is owned by manjaro-hotfixes package. /etc/dbus-1/system.d/gksu-polkit.conf is owned by gksu-polkit package. Both packages are deprecated and obsolete, so I removed both. This removal has also deleted the mentioned conf files. But dbus-broker shouldn’t break the boot process due to an improper XML formatting.

This problem happened to me, too. It is critical, as dbus is not properly started, you became with a non-tty console, without the possibility even to log in to the system. This is happening because the new dbus-broker is not resilient enough to deal with non-XML configuration files in /etc/dbus-1/system.d, probably installed by old packages, and does not start. The problem is everything else depends on dbus, even the services for tty login. The maintainers of this package should change their code to just make a warning (i.e. to ignore those non-compliant conf files) instead of aborting the start of dbus … otherwise the whole system will be blocked. It took me a whole day to discover that and fix my system. I had to boot with a live pendrive, do a chroot and just move these files with non-XML confs at the system.d folder to a different location (possibly making the packages using them non-operative). Alternatively, if you can localize these old packages with non-XML conf files, you can also uninstall them. But dbus-broker should be more resilient to that. Dbus is a too important service to just die like that because of these non-XML configuration files.

Even put in a 20 second delay or something to make sure they know something is wrong. Just bailing out completely seems like a massive overreaction.

the new dbus-broker is not resilient enough to deal with non-XML configuration files in /etc/dbus-1/system.d, probably installed by old packages, and does not start. […] I had to boot with a live pendrive, do a chroot and just move these files with non-XML confs at the system.d folder to a different location (possibly making the packages using them non-operative). Alternatively, if you can localize these old packages with non-XML conf files, you can also uninstall them. But dbus-broker should be more resilient to that. Dbus is a too important service to just die like that because of these non-XML configuration files.

My content of ls -la /etc/dbus-1/system.d/ is:

-rw-r--r-- 1 root root  329 17 set  2019 gksu-polkit.conf
-rw-r--r-- 1 root root  899  1 ott 19.13 net.launchpad.backintime.serviceHelper.conf
-rw-r--r-- 1 root root 1470  5 set  2018 org.freedesktop.NetworkManager.Manjaro.conf
-rw-r--r-- 1 root root  891  2 dic 18.28 org.manjaro.pamac.daemon.conf

pacman -Qo on each file reports “No package owns $filename”

So: which files, exactly, did you removed from /etc/dbus-1/system.d/?

In my case, it was the configuration file of an old package: panther-launcher-git … to discover what is the offending configuration file, there are many options: you might look into each of them, trying to identify a non-XML file (a XML file is a text file and needs to start with a line like that: <?xml version=“1.0” encoding=“UTF-8”?> … you can use “cat” or “less” to see them … if your file does not start like that, you found your guilty file), or you can go strictly to the one is offending dbus-broker. If your boot is using a “quiet” directive, you need to take it off (to do that, you need to edit the /etc/default/grub and find the line starting with GRUB_CMDLINE_LINUX_DEFAULT= and remove the “quiet” from the list … after that you need to do an “update-grub” and reboot) … then the boot will show you the messages during the initialization of each service and you will get a message like the “Invalid XML in …” that will show the exact configuration file that is disturbing dbus-broker. This is the one you need to move away.