Hide Forgot
Description of problem: Bluetooth icon shows bluetooth disabled all the time. Placing mouse on it shows "Bluetooth: Disabled", pressing on it offers "Turn off Bluetooth" (?!) (I had tried to turn it on before, to no avail). It seems to depend on kernel version (works on and off). Version-Release number of selected component (if applicable): gnome-panel-2.31.4-3.fc14.x86_64 kernel-2.6.35-0.56.rc6.git1.fc14.x86_64 How reproducible: Always. Steps to Reproduce: 1. Place mouse on bluetooth icon (disabled) ~~-> "Bluetooth: Disabled" 2. Click on icon, offers to turn on. Do so. Icon doesn't change, no try to connect to my phone. 3. Place mouse on bluetooth icon (disabled) ~~-> "Bluetooth: Disabled" 4. Click on icon, offers to turn _off_ (?!) Actual results: See steps. Expected results: Additional info:
I suspended the machine, and when it came up again Bluetooth was enabled, and it works (?!)
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I have the same exact problem with a Macbook 2,1, Bus 005 Device 005: ID 05ac:8205 Apple, Inc. Bluetooth HCI Suspending and resuming on this system also gets bluetooth working.
It looks like maybe bluetoothd --udev isn't getting run by udev-post on startup; running this is all it takes to get it working.
Yup, running "bluetoothd --udev" as root enables bluetooth. Note this machine is on systemd-8-3.fc14.x86_64, udev-161-1.fc15.x86_64, udev-post is enabled in runlevel 5 (default). # systemctl status udev.service udev.service - /dev and kernel device manager Loaded: loaded (/lib/systemd/system/udev.service) Active: inactive (dead) CGroup: name=systemd:/systemd-1/udev.service But udevd is running thrice (?!)
I took a look at a Fedora 13 system and found the cause for this failure. /etc/init.d/bluetooth runs this command on both Fedora 13 and Fedora 14: udevadm trigger --subsystem-match=bluetooth The problem has come about because the default udevadm trigger action has changed from "add" in udev-153-3.fc13 to "change" in udev-161-1.fc14. which in turn causes the udev rule to not be triggered via /lib/udev/rules.d/97-bluetooth.rules: ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="/usr/sbin/bluetoothd --udev" This can be verified both by reading the man page for udevadm and by watching the output on each system: udevadm monitor --subsystem-match=bluetooth and watching the results for: udevadm trigger --subsystem-match=bluetooth So this is easily corrected by changing /etc/init.d/bluetooth to run: udevadm trigger --subsystem-match=bluetooth --action=add
Fixed now, closing.