Raspberry Pi u-boot-rpi package version 2020.10+dfsg-1ubuntu0~20.10.1 prevents Bluetooth Devices Connecting

Bug #1914929 reported by axel
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
u-boot (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

After updating this package (u-boot-rpi) version from 2020.04+dfsg-2ubuntu1 to 2020.10+dfsg-1ubuntu0~20.10.1 any Bluetooth device on a Raspberry Pi 4 8GB will no longer be able to pair.

After the package install all previously paired devices disappear.

The devices when attempting to re-pair will then connect then disconnect immediately afterwards on initial pairing. Subsequent attempts to connect will fail with "no route to host" error. No subsequentattempts to remove and re add the devices seems to resolve the problem.

To fix the issue you have to uninstall this package and go back to the previous versions.

Any devices you had paired before the upgrade will re appear ... but if you tried to pair them *after* the upgrade they will continue to have the same connect and disconnect behavior. However this time removing the device and repairing will fix the problem.

Any device you did not attempt to connect / re pair after the upgrade work seamlessly again without any need to remove and repair the device.

I have recreated this issue on Ubuntu MATE Ubuntu 20.10 Groovy

axel (simon-simonfoley)
description: updated
description: updated
Revision history for this message
Dave Jones (waveform) wrote :

I attempted to replicate this using a Pi 4B 4GB, with a fresh Ubuntu MATE 20.10 install (which, although it has u-boot installed doesn't use it, so I expected replication to fail there), or with an Ubuntu MATE 20.04 install which was then upgraded to 20.10 (which will use u-boot unless the boot configuration is modified). However, in both cases replication of the issue failed.

I'd be slightly surprised if u-boot were involved in this particular instance given the only way it *could* interfere with the bluetooth stack (that I can think of), would be to manipulate the device-tree entries associated with setting up the module. But if that were the case then I wouldn't expect the module to initialize correctly (and it does, in both cases).

I'll mark this incomplete in case any further detail can be shed on this.

Changed in u-boot (Ubuntu):
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for u-boot (Ubuntu) because there has been no activity for 60 days.]

Changed in u-boot (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.