bluetooth rfkill status not synced between upstart and systemd

[Fran Diéguez]

I cannot use bluetooth devices while using systemd as the default init system.

While going to gnome-control-center to check for bluetooth devices, all the bluetooth functionality is deactivated.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: systemd 208-8ubuntu8
Uname: Linux 3.17.1-031701-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.14.7-0ubuntu8
Architecture: amd64
CurrentDesktop: GNOME
Date: Wed Oct 29 17:43:44 2014
InstallationDate: Installed on 2014-10-22 (7 days ago)
InstallationMedia: Ubuntu-GNOME 14.10 "Utopic Unicorn" - Alpha amd64 (20140923)
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)

[Martin Pitt (pitti)]

Indeed, bluetooth.service does not get started by default any more. This used to work, but apparently got broken recently. With a manual "sudo systemctl start bluetooth.service" I get this back.

[Martin Pitt (pitti)]

Hmm, bluez looks fine at first sight. Reassigning this back, apparently the bluetooth.target behaviour changed.

[Martin Pitt (pitti)]

So the way this is *supposed* to work is that bluetooth.target is activated by udev rules, like those:

99-systemd.rules:SUBSYSTEM=="bluetooth", TAG+="systemd", ENV{SYSTEMD_ALIAS}+="/sys/subsystem/bluetooth/devices/%k"
99-systemd.rules:SUBSYSTEM=="bluetooth", TAG+="systemd", ENV{SYSTEMD_WANTS}+="bluetooth.target"

But in my current "udevadm info --export-db" I don't have any device with SUBSYSTEM=bluetooth, and /sys/class/bluetooth/ is empty. In dmesg I see

[ 6639.785913] bluetooth hci0: Direct firmware load failed with error -2
[ 6639.785918] bluetooth hci0: Falling back to user helper
[ 6639.787431] Bluetooth: hci0: BCM: patch brcm/BCM20702A0-0a5c-21e6.hcd not found

So this seems to be the reason why even after starting bluetooth.service manually (which was a red herring) there are still no BT devices. Can you please confirm that your problem is the same? I. e. run "dmesg | grep bluetooth", and you get something like above? Thanks!

[Martin Pitt (pitti)]

I compared dmesg under upstart, and the firmware issue also appears there, so this seems to be a red herring again. Comparing dmesg under upstart and systemd I see no fundamental differences, just the module loading order differs.

[Martin Pitt (pitti)]

Ah, got it! In "sudo rfkill list" I noticed that tpacpi_bluetooth_sw was "soft blocked: yes". The problem is that our rfkill package only has an upstart job, thus /etc/init/rfkill-restore.conf doesn't run under systemd. systemd has /lib/systemd/system/systemd-rfkill@.service, but that doesn't use the same format as rfkill (/var/lib/rfkill/saved-state).

[Fran Diéguez (frandieguez)]

Thanks for the progress Martin.

Do you still need my collaboration, as you asked in previous comments?

[Martin Pitt (pitti)]

Fran, to confirm that you are really seeing the same but, the output of this would be helpful:

  grep -r . /var/lib/systemd/rfkill/

But I completely understand this now, so thanks!

[Martin Pitt (pitti)]

Steps:
- Adjust our udev rules to call path_id for rfkill devices also under upstart
- Adjust rfkill upstart jobs to call lib/systemd/systemd-rfkill load/save, so that both init systems use the same state files. These include the path_id under systemd, so that needs to be consistently available.

[Launchpad Janitor (janitor)]

This bug was fixed in the package systemd - 215-5ubuntu2

---------------
systemd (215-5ubuntu2) vivid; urgency=medium

  * Merge fixes from Debian:
    - Adjust timedated and hostnamed autopkgtests to current upstream version.
    - Replace our Debian hwdb.bin location patch with what got committed
      upstream. Run hwdb update with the new --usr option to keep current
      behaviour.
    - debian/README.Debian: Document how to debug boot or shutdown problems with
      the debug shell. (Closes: #766039)
    - Skip-99-systemd.rules-when-not-running-systemd-as-in.patch: Call path_id
      under all init systems, to get consistent ID_PATH attributes. This is
      required so that tools like systemd-rfkill can be used with SysVinit or
      upstart scripts, too. (LP: #1387282)
 -- Martin Pitt <email address hidden> Mon, 03 Nov 2014 07:15:38 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package rfkill - 0.5-1ubuntu2

---------------
rfkill (0.5-1ubuntu2) vivid; urgency=medium

  * Ensure that rfkill devices have ID_PATH attribute:
    - debian/control: Add dependency for systemd >= 215-5ubuntu2.
    - debian/rfkill.postinst: udev-trigger rfkill devices to ensure systemd
      215-5ubuntu2's adjusted 99-systemd.rules are applied on upgrade.
    - This upgrade fix needs to be kept until after Ubuntu 16.04 LTS.
  * debian/rfkill-{store,restore}.upstart: Use /lib/systemd/systemd-rfkill, to
    keep rfkill state between boots synchronized between upstart and systemd.
    (LP: #1387282)
 -- Martin Pitt <email address hidden> Mon, 03 Nov 2014 07:47:56 +0100