package bluez 5.35-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 (without linux-image-extra*)

[Michał Sawicz]

Bluez installation fails on vivid and wily without linux-image-extra* because BT kernel modules are unavailable.

ProblemType: Package
DistroRelease: Ubuntu 15.10
Package: bluez 5.35-0ubuntu1
ProcVersionSignature: Ubuntu 4.2.0-16.19-generic 4.2.3
Uname: Linux 4.2.0-16-generic x86_64
ApportVersion: 2.19.1-0ubuntu2
Architecture: amd64
Date: Thu Oct 15 22:06:50 2015
DuplicateSignature: package:bluez:5.35-0ubuntu1:subprocess installed post-installation script returned error exit status 1
Ec2AMI: ami-00000f6e
Ec2AMIManifest: FIXME
Ec2AvailabilityZone: nova
Ec2InstanceType: cpu10-ram10-disk10-ephemeral20
Ec2Kernel: aki-0000022a
Ec2Ramdisk: ari-0000022a
ErrorMessage: subprocess installed post-installation script returned error exit status 1
InterestingModules: bnep bluetooth
Lsusb:
 Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd
 Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MachineType: OpenStack Foundation OpenStack Nova
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.2.0-16-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0
RelatedPackageVersions:
 dpkg 1.18.2ubuntu4
 apt 1.0.10.2ubuntu1
SourcePackage: bluez
Title: package bluez 5.35-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 01/01/2011
dmi.bios.vendor: Bochs
dmi.bios.version: Bochs
dmi.chassis.type: 1
dmi.chassis.vendor: Bochs
dmi.modalias: dmi:bvnBochs:bvrBochs:bd01/01/2011:svnOpenStackFoundation:pnOpenStackNova:pvr2013.2.3:cvnBochs:ct1:cvr:
dmi.product.name: OpenStack Nova
dmi.product.version: 2013.2.3
dmi.sys.vendor: OpenStack Foundation
hciconfig:

[Martin Pitt (pitti)]

Trivially reproduces on e. g. the cloud images, but for completeness:

$ sudo systemctl status -l bluetooth.service
● bluetooth.service - Bluetooth service
   Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2015-10-20 09:08:20 CEST; 27s ago
     Docs: man:bluetoothd(8)
 Main PID: 1640 (code=exited, status=1/FAILURE)
   Status: "Starting up"

Oct 20 09:08:20 autopkgtest systemd[1]: Starting Bluetooth service...
Oct 20 09:08:20 autopkgtest bluetoothd[1640]: Bluetooth daemon 5.35
Oct 20 09:08:20 autopkgtest bluetoothd[1640]: Failed to access management interface
Oct 20 09:08:20 autopkgtest bluetoothd[1640]: Adapter handling initialization failed
Oct 20 09:08:20 autopkgtest systemd[1]: bluetooth.service: Main process exited, code=exited, status=1/FAILURE
Oct 20 09:08:20 autopkgtest systemd[1]: Failed to start Bluetooth service.
Oct 20 09:08:20 autopkgtest systemd[1]: bluetooth.service: Unit entered failed state.
Oct 20 09:08:20 autopkgtest systemd[1]: bluetooth.service: Failed with result 'exit-code'.

[Simon Fels (morphis)]

There is nothing we can do from bluez side. If the kernel interface we need to do *any* work is not available we can't do anything else but fail. The "bluetooth" module needs to be loaded or the kernel compiled with CONFIG_BT=y rather than CONFIG_BT=m.

Is there any reason not to compile bluetooth support directly into the kernel? Any driver can still be loaded as module but the subsystem should be always available.

[Martin Pitt (pitti)]

> There is nothing we can do from bluez side.

Perhaps not from the daemon itself, but the packaging certainly needs to be fixed. It could be that the .service file grows some Condition*= to not start if we already know that it won't work; or the .postinst shouldn't fail when the service fails (e. g. dh_installinit --error-handler=true).

[Martin Pitt (pitti)]

Even if we would change our kernel package to always include bluetooth, that still would make the package fail for custom/third-party kernels, so I'd say this is neither required nor sufficient. Let's fix the bluez packaging instead.

[Simon Fels (morphis)]

We could just bind this to the condition if /sys/class/bluetooth is available or not. So a

 ...
 ConditionPathIsDirectory=/sys/class/bluetooth

[Martin Pitt (pitti)]

> ConditionPathIsDirectory=/sys/class/bluetooth

Sounds perfect!

[Martin Pitt (pitti)]

Wily fix uploaded (might end up as an SRU, though). I also sent the patch upstream, will add a link once it hits the upstream ML archives.

[Martin Pitt (pitti)]

Forwarded upstream: http://article.gmane.org/gmane.linux.bluez.kernel/65182

[Simon Fels (morphis)]

Great!

[Launchpad Janitor (janitor)]

This bug was fixed in the package bluez - 5.35-0ubuntu2

---------------
bluez (5.35-0ubuntu2) wily; urgency=medium

  * Add 0001-systemd-Check-if-bluetooth-is-supported-in-the-kerne.patch:
    bluetooth.service: Check if bluetooth is supported in the kernel, to avoid
    failing package installation on a kernel without bluetooth support.
    (LP: #1506774)

 -- Martin Pitt <email address hidden> Tue, 20 Oct 2015 12:27:06 +0200

[Flames_in_Paradise (ellisistfroh-deactivatedaccount)]

pitti

this sru has hit Kubuntu in a strange way -> bug #1509334 (30 seconds delay for final desktop)

JUST be4 the final release :-(

The fix for Wily is stuck now in the "proposed-queue", actually thinking this bitesize-bugfix (there) should enter "wily-updates"

Could you take a look at it?

best regards

[Martin Pitt (pitti)]

Hello,

Flames_in_Paradise [2015-11-06 15:49 -0000]:
> this sru has hit Kubuntu in a strange way -> bug #1509334 (30 seconds
> delay for final desktop)
>
> JUST be4 the final release :-(
>
> The fix for Wily is stuck now in the "proposed-queue", actually thinking
> this bitesize-bugfix (there) should enter "wily-updates"

It's 8 days now, so ready to be released; the SRU team should do that
soon (but they might avoid releasing updates on Fridays).

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)