Could not start dbus

R

roelof

Hello,

I did a fresh install of KDE and on start I see this error message.

Code: 
Could not start DBUS.
Can you call qdbus?

How to solve this?

Roelof
 
I got bitten by this as well, as this step is not in the instructions in the Handbook. This article should probably be a sticky unless/until the Handbook is updated.
 
wblock@ said:
Added to the Gnome section: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x11-wm.html#x11-wm-gnome.

Please review.

I plan to add similar parts to the KDE and xfce sections also.
Click to expand...
Going by what is actually installed on my system, the hald and dbus packages were already installed.
$ which hald
Code: 
/usr/local/sbin/hald
Same check for dbus.

Confirmed with a pkg info |grep hal
Appears that these were installed when I built Xfce and KDE ports.
Might want to add to a check for these before doing a redundant install (for dummies like me).

I assume from what you've said that both of these drivers should be instantiated in /etc/rc.conf: for Xfce and KDE as well as for Gnome.
If not, please clarify.

I'm still in "walk before you run" mode learning my way around FreeBSD particulars. Been 20 years since I worked with older BSD's (Ultrix, SunOS 4, etc.) and there's a lot for me to learn.
 
Hmm. They should be installed as dependencies. That makes the setup simpler.

Several years ago, I went through the xfce ports and made sure that there were options to turn off hal in the few places left. So xfce can be installed without hal. I don't know if the defaults are that way, so the packages might still include it. KDE and Gnome still need dbus and hal.
 
A few thoughts here from someone coming from other Unix systems to FreeBSD.

1. The /proc partition should really be installed as a part of the initial install. pkill and pgrep are pretty handy and depend on the directory.

2. Appears to me that installation of hald and qdbus are needed at least by Gnome and KDE. Checking the dates on the objects that were built from ports on my box, it appears that hald was built as part of the Xfce port, but qdbus was not built until I built the KDE port later on.

I'd suggest putting the instructions for installing the above ahead of the discussions about the specific window managers as a generic "preparation to install"
set of steps, rather than including them repetitiously under each window manager.

I'll leave it up to you what changes you want to make. My rc.conf right now has:

Code: 
hostname="zinc.my.dom"  (munged for privacy)
ifconfig_em0="inet 192.168.1.18 netmask 255.255.255.0"
ifconfig_igb0="inet 192.168.1.28 netmask 255.255.255.0"
defaultrouter="192.168.1.98"
sshd_enable="YES"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="AUTO"
#kde support objects
dbus_enable="YES"
hald_enable="YES"
# Install driver
kld_list="linux nvidia"
# Start NFS server
rpcbind_enable="YES"
nfs_server_enable="YES"
nfsv4_server_enable="YES"
mountd_enable="YES"
mountd_flags="-r"
# Start ntpd
ntpd_enable="YES"
 
Oldrancher said:
1. The /proc partition should really be installed as a part of the initial install. pkill and pgrep are pretty handy and depend on the directory.
Click to expand...

No they don't. There is nothing in the base system that directly depend on procfs(5) for their operation.

You're probably thinking of the Linux counterparts that are based on an entirely different implementation.
 
Oldrancher said:
I'd suggest putting the instructions for installing the above ahead of the discussions about the specific window managers as a generic "preparation to install"
set of steps, rather than including them repetitiously under each window manager.
Click to expand...
I thought of that, but they already have different requirements. Xfce does not need hal. Gnome and KDE will also move away from it, but almost certainly not at the same time.
 
kpa said:
No they don't. There is nothing in the base system that directly depend on procfs(5) for their operation.

You're probably thinking of the Linux counterparts that are based on an entirely different implementation.
Click to expand...

If not, then explain to me why pgrep didn't work until I installed /proc. The manpage for pgrep acknowledges the Solaris setup, which does use /proc. Also, the contents of FreeBSD /proc match those of Solaris /proc.

Linux? I haven't looked seriously at Linux in it's various forms for years. The FreeBSD test box I've set up is in a Solaris network, so I can examine either system from the same terminal.
 
Oldrancher said:
If not, then explain to me why pgrep didn't work until I installed /proc. The manpage for pgrep acknowledges the Solaris setup, which does use /proc. Also, the contents of FreeBSD /proc match those of Solaris /proc.
Click to expand...
I would encourage you to unmount /proc and try again. pgrep does not rely on it being there, but instead uses kvm_getprocs(3), which in pgrep's case uses the sysctl
Code: 
kern.proc.proc: Return process table, no threads
under the hood to get process information.

I don't see any reference to procfs in pgrep(1).
 
Code: 
freebsd10 ~ % mount
/dev/gpt/fb10root on / (ufs, local, soft-updates)
devfs on /dev (devfs, local, multilabel)
freebsd10 ~ % pgrep zsh
628
freebsd10 ~ %
 
You must log in or register to reply here.
Back
Top