What do you mean by "daemons missing"?
Are their binaries missing or are they not starting because there's no init.d scripts for them?
I couldn't help noting your systemd options .. are you sure you want that for a Galileo build?
I'd have to look again, but aren't we using the older SystemV init-scripts?
What I mean by the 'daemons missing' is that the binaries are missing completely. In other words, when I go to /usr/bin/, I can see bluetoothclt, hcitool, etc... but no obexd and no bluetoothd.
Regarding the use of systemd options, I've tried to install BlueZ 5 with and without systemd options. Neither seems to make a difference. I'm not sure about SystemV vs systemd, I'm not super familiar with linux so I really can't comment on that.
Ok. Did they even get built then? I.e. are they inside your build tree somewhere?
Found http://www.linuxfromscratch.org/blfs/view/svn/general/bluez.html. Perhaps this can be of some use.
You don't mention your build environment. There are experimental recipes for Yocto if you want to try that.
Looking at Google, there seems to be at least some other people with your problem.
Is BlueZ 5 even in a production ready state?
You gotta forgive me if I'm making no sense; I'm not using BlueZ at all, but one place I'd go to look
would be in some of the autotools logs to see if the missing daemons are even mentioned in there.
I built BlueZ 5.17 on my Intel Galileo board running a 0.7.5-2 dev build (more information here: https://communities.intel.com/thread/48360?start=15&tstart=0).
Thanks for suggesting the Linux from scratch link. That's actually how I got started which was a few days before the latest 5.18 version was posted.
Regarding whether or not the daemons were built to begin with, I went back to my build directory (./bluez-5.17/src/) and noticed that the bluetoothd was built. Correspondingly, obexd was also built in (./bluez-5.17/obexd/src). So perhaps it was not copied over during the make install process.
Also, with regards to your comment on the production readiness of BlueZ 5, it seems like it is still in the early stages of making it fully production ready. That being said, the reason I'm interested in getting BlueZ 5 to work is that it looks like it comes with some useful OBEX tools for testing out the FTP file transfer capability. I haven't managed to install any other BlueZ 4 compatible tools that has allowed me to do this but would love to be proven wrong if such tools exists.
I've tried to install ussp-push, obexftp, and a few others but so far haven't managed to get them installed properly and working. That being said, I know my tool chain does work since I've managed to build many other libraries, including BlueZ 4 successfully on the Galileo board.
Just on some further probing, it appears that:
- my bluetoothd and obexd were copied to /usr/libexec/Bluetooth/
- /etc/dbus-1/system.d/bluetooth.conf makes references to <allow send_interface=...> for org.bluez.* for a bunch of different items but makes no reference to obex
My bluetooth.conf file contains the following:
<!-- This configuration file specifies the required security policies for Bluetooth core daemon to work. --> <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"> <busconfig> <!-- ../system.conf have denied everything, so we just punch some holes --> <policy user="root"> <allow own="org.bluez"/> <allow send_destination="org.bluez"/> <allow send_interface="org.bluez.Agent1"/> <allow send_interface="org.bluez.MediaEndpoint1"/> <allow send_interface="org.bluez.MediaPlayer1"/> <allow send_interface="org.bluez.ThermometerWatcher1"/> <allow send_interface="org.bluez.AlertAgent1"/> <allow send_interface="org.bluez.Profile1"/> <allow send_interface="org.bluez.HeartRateWatcher1"/> <allow send_interface="org.bluez.CyclingSpeedWatcher1"/> <allow send_interface="org.freedesktop.DBus.ObjectManager"/> </policy> <policy at_console="true"> <allow send_destination="org.bluez"/> </policy> <!-- allow users of lp group (printing subsystem) to communicate with bluetoothd --> <policy group="lp"> <allow send_destination="org.bluez"/> </policy> <policy context="default"> <deny send_destination="org.bluez"/> </policy> </busconfig>
Another point of concern that I have is that my /usr/share/dbus-1/system-services/org.bluez.service contains the following:
[D-BUS Service] Name=org.bluez Exec=/bin/false SystemdService=dbus-org.bluez.service
Note the Exec=/bin/false part.
Similar thing appears in my /usr/share/dbus-1/services/org.bluez.obex.service file:
[D-BUS Service] Name=org.bluez.obex Exec=/bin/false SystemdService=dbus-org.bluez.obex.service
Note again the Exec=/bin/false part
Message was edited by: Billy Chan
1 of 1 people found this helpful
Perhaps you could try to re-run ./configure with --disable-systemd and see if it produces an init.d script for you instead.
I'm pretty sure thats why the daemon doesn't start on a Galileo.
Also, just for kicks, can the bluetoothd binary in libexec be started? Perhaps in another terminal session?
I don't know for sure, but most daemons have a "don't fork" switch so you can see if it spits out some logs.
Sounds to me like you're almost there.
As a last resort, perhaps the init.d script from BlueZ 4 can be adapted to start the version 5 daemon.
1 of 1 people found this helpful
Newer versions of BlueZ support systemd only. According to the maintainer of BlueZ, distributions still using sysinit-style have to provide their own code to bring back the sysinit support.
The configure switch -disable-systemd does only stop BlueZ 5 to install the daemon as Systemd-daemon, but nothing else.
On a 0.7.5 Galileo-Yocto-full this means: If you compile BlueZ 5, the old BlueZ binaries remain untouched, the new binaries are in the libexec dir and never called by the "old" sysinit script. If you did a BlueZ 5 "make install" only, your system will still use the old BlueZ stuff.
I tried to get this stuff working, but - finally - ended just with starting the Bluez5 daemon manually (and manually starting dbus for unknown reasons) every time.
But other problems with Bluez5 will show up: BlueZ 5 is a API breaking version. There is a good chance other tools will fail. There is a good chance you will fail due to dbus policy things. Not a single python&co library for BlueZ will work.
TL;DR: You will waste a lot of time with BlueZ. BlueZ 5 will make it even worse.
Thanks for the insight Alexander,
Prior to installing BlueZ 5, I did try to uninstall BlueZ 4 using opkg. I would assume that would completely remove all the leftover stuff from the original BlueZ4 package but I could be wrong.
In any case, you're right in that BlueZ5 will break all existing tools. For me, it's more of a last ditch attempt at testing the OBEX FTP transfer on Galileo.
That being said, has anyone managed to get OBEX FTP transfers working with BlueZ4?