bluetooth/detect-output fails on UC24

[plars]

Bug Description

bluetooth/detect-output fails on RPI with Ubuntu Core 24 images with the following output:

      rfkill: cannot open /dev/rfkill: Operation not permitted
rfkill: cannot open /dev/rfkill: Operation not permitted

BT hardware not available

The reason this fails seems to be because the bluetooth controller is not powered on before the test starts. If you power it on with something like sudo bluetoothctl power on then the test works fine. For fixing it, it should be sufficient to run this before it starts the test, however it needs to be run as root and the bluetooth/detect-output test currently runs as a normal user.

We didn't have this problem with older images because previously we used to install a tool called "pi-bluetooth" which set a lot of this up. One of the side effects of running the pi-bluetooth snap/deb is that the bluetooth controller would get powered on, but it no longer works on *24 systems, nor is it required now.

To Reproduce

Run the bluetooth tests on a rpi with ubuntu-core 24

Environment

UC24
Raspberry Pi
any recent version of checkbox

Relevant log output

rfkill: cannot open /dev/rfkill: Operation not permitted
rfkill: cannot open /dev/rfkill: Operation not permitted

BT hardware not available

### Additional context

_No response_

[syncronize-issues-to-jira]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/CHECKBOX-1437.

This message was autogenerated

[baconYao]

Same symptoms be observed on Baoshan Devices with UC22

• RTC operation not permitted causes suspend/suspend_advanced_auto failed sometime #1211

[Hook25]

I think the issue brought up by @baconYao is unrelated. I'm not sure if this is a Checkbox test issue or a provisioning issue. I see this in all core24 rpi envs, so I think it is pretty high prio. @plars do you think the test itself should power on bluetooth?

EDIT: I can confirm that adding _run sudo bluetoothctl power on to the job makes the test pass

[boukeas]

I've shared this issue with Philip Meulengracht from the Core team, along with the code that the bluetooth/detect-output test runs. He said they will investigate further.

[boukeas]

The code for the bluetooth/detect-output test is:

if rfkill list bluetooth | grep -q 'Hard blocked: yes'; then
  echo "rfkill shows BT is hard blocked"
fi
if rfkill list bluetooth | grep -q 'Soft blocked: yes'; then
  echo "rfkill shows BT is soft blocked, removing before testing"
  rfkill unblock bluetooth
  sleep 3
fi
output=$(hcitool dev | tail -n+2 | awk '{print $2}' | tee "$PLAINBOX_SESSION_SHARE"/bluetooth_address)
echo "$output"
if [ -z "$output" ]; then
    echo "BT hardware not available"
    exit 1
fi

So the first two lines of the log are due to the two calls to rfkill list bluetooth and the last line (and test failure) is due to the call to hcitool dev.

I could not reproduce the rfkill problem on a fresh install of Core 24 on a Raspberry Pi 5 in the lab:

$ rfkill list bluetooth
0: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no

After installing bluez, I can confirm that the hcitool needs the bluetooth turned on:

$ hcitool dev
Devices:
$ sudo bluetoothctl power on
AdvertisementMonitor path registered
$ hcitool dev
Devices:
	hci0	D8:3A:DD:7B:FA:62

Philip says he will check but he believes that the default behaviour should be for bluetooth to be off.

[Meulengracht]

So I had time to look into this issue, and I now think I know what is wrong. The issue is that starting with apps using core24 as a base, device cgroup is now mandatory. That means any device not allowed by the connected interfaces will be denied.

This was not the case for previous versions of checkbox, and it means you must have an interface connected that allows access to /dev/rfkill.

@Hook25 cc

Will be fixed here in the coming checkbox_support interface: canonical/snapd#14911