bluetooth rfkill status not synced between upstart and systemd

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.

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

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!

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.

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).

Thanks for the progress Martin.

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

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!

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.

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

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