Closed sashko closed 5 years ago
I also wonder why it used to work in our MuxPi builds. Do you know when and why it started failing?
Should perhaps file a meta-raspberrypi issue about this (Bluetooth must be enabled or service will fail and systemd will think system is degraded). Would be nice if we could fix it and send a PR but at least an issue?
I also wonder why it used to work in our MuxPi builds.
When?
Looks like Jenkins is down at the moment, but RPI MuxPI builds were green until less than X builds or so ago (do not remember how many could still see saved green jobs yesterday).
But looking at https://github.com/Pelagicore/vagrant-cookbook/blob/bba26063323b18453e44dc237c5f43571c1deb0d/muxpi/rpi/set-up-image.sh#L103 I am not sure now that bthelper failing would result in the job failing.
But looking at https://github.com/Pelagicore/vagrant-cookbook/blob/bba26063323b18453e44dc237c5f43571c1deb0d/muxpi/rpi/set-up-image.sh#L103 I am not sure now that bthelper failing would result in the job failing.
It would not. I have tried to track down the issue by checking the job history: it's been green for a while now.
If we can not figure out how to make bthelper work when Bluetooth is RF-killed, perhaps it is enough with an issue in meta-raspberrypi then?
I think it is weird to have a requirment for Bluetooth to be enabled to have a clean boot, right?
If we can not figure out how to make bthelper work when Bluetooth is RF-killed, perhaps it is enough with an issue in meta-raspberrypi then?
ok, let's try: https://github.com/agherzan/meta-raspberrypi/issues/460
So Bluetooth must always be enabled (not RF-killed) or that bthelper service will always fail. No simple way to fix this? Always requiring Bluetooth to be enabled seems like a band-aid to me.
(Just boot, disabe Bluetooth => service will fail again.)