Bluez should notify users when they need to reboot to apply changes on Raspberry Pi

Attached is a patch for Hirsute. If this is accepted I will SRU to focal and groovy.

Thank you for the work, could give a bit more context why a reboot is needed in those cases? Isn't restarting the service enough?

Having hardcoded addresses in the script seems a bit fragile. And is that the sort of change we could try to upstream to Debian to not increase our delta?

Also the description states 'In the case of upgrading bluez', is that specific to some version? if the issue is with upgrade the postinst code should check that we are in the upgrade case and not a new install no?

Seb,

A reboot is needed in this case because the bluetooth device on the raspberry pi has to be initialized at boot time. Restarting the service will not cause the device to be brought up.

The hardcoded addresses are the approach used in the pi-bluetooth package, and recommended by waveform.

As for the description, I could certainly change that to be more descriptive. This code would want to run on a fresh install of bluez, as the bluetooth device would not be initialized if the pi had been booted without bluez installed.

Thanks for the details. You did address the part about upstreaming the change to Debian. How important is that notification in practice? If feels like we should have bluez preinstall on the raspi images if that's not the case, and if it's pre-install is that really worth the packaging overhead to have to carry a delta over Debian?

I have submitted a Debian bug report with the patch suggested, and updated the bug description.

bluez is pre-installed on the desktop images, but not the server images. This warning would be very useful for server users that want to install bluez for the first time.

@William, thanks, could you share the Debian bug url? I browsed https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=yes&src=bluez but I'm not finding it...

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986836

Apparently I had not created the bug report correctly the first time.

Thanks!

Maybe unsubscribe Ubuntu Sponsors for the moment? Seb dropped this fix from the latest update: https://launchpad.net/ubuntu/+source/bluez/5.56-0ubuntu4

> Thanks for the details. You did address the part about upstreaming the change to Debian. How important is that notification in practice? If feels like we should have bluez preinstall on the raspi images if that's not the case, and if it's pre-install is that really worth the packaging overhead to have to carry a delta over Debian?

Just to give a bit of context here, the bluetooth situation on the pi is somewhat complicated and there's compromises that we make between the desktop and server images:

The bluetooth module on the Pi is controlled via a UART. Two UARTs are available on the Pi (there's more on the Pi 4, but it's the same situation for the bits we're talking about here):

* the PL011 which is full featured (buffers, flow-control, etc.), and

* the mini-UART which is ... not. Furthermore, the mini-UART's baud rate is tied to the GPU's clock, so if that floats then the mini-UART's baud rate floats too

On models of Pi with a bluetooth module (everything except the Pi 2, the CM3/3+ and some models of the CM4), the PL011 is used to talk to the bluetooth module and by default the mini-UART is disabled. This is the configuration we use on the desktop images as we make the assumption a serial console is less important on something which almost certainly has a monitor, and this configuration permits the GPU clock to float (important for something relying upon graphical acceleration).

On the server images, we assume that the serial console *is* important, and so this is enabled by default. We don't *disable* the bluetooth module, but we don't pre-install the packages for it either. This means that the PL011 is tied to the bluetooth module by default (but unused), and the mini-UART to the serial console. Because the mini-UART is in use, the GPU's clock is locked to the base speed. This is a compromise because all the alternatives are nastier in some way for some of the typical use cases:

* If the server image is used without a graphical environment, and without bluetooth, this is fine (this is the default). The GPU's clock doesn't really matter in this scenario and the serial console will still work reliably.

* If the server image is used without a graphical environment, but with bluetooth, all the user needs to do is install pi-bluetooth and reboot (personally I don't think the reboot warning is terribly necessary; like knowing to install pi-bluetooth in the first place, it's fairly widespread knowledge and tends to be part of first-time setup steps anyway). This again leaves the GPU's clock locked (but without a graphical environment that doesn't really matter), the serial console still works, and bluetooth works.

* If the server image is used with a graphical environment, without bluetooth, the user needs to either disable the serial console (if they don't want it, this is a one-line change in the boot configuration), or alternatively add the line "dtoverlay=disable-bt" to the boot configuration which disables the bluetooth module entirely, allowing the serial console to use the "full" PL011 UART. Either option unlocks the GPU's clock.

* If the server image is used with a graphical environment, with bluetooth, that's effectively th...