coreos-modules: enable the Bluetooth subsystem - #4197
Conversation
There was a problem hiding this comment.
Pull request overview
Enables Linux kernel Bluetooth support in Flatcar by turning on the Bluetooth subsystem and key HCI transports as loadable modules, so Bluetooth capabilities are available without rebuilding the OS image while keeping runtime impact minimal unless modules are loaded.
Changes:
- Enable the core Bluetooth stack (BR/EDR + LE) and common HCI transports (USB, UART/serdev, virtio, VHCI) as modules in the shared kernel config.
- Enable supporting kernel symbols needed by the Bluetooth closure (e.g., RFKILL, SERIAL_DEV_BUS).
- Add a changelog entry documenting Bluetooth kernel enablement (userspace intentionally excluded).
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-modules/files/commonconfig-6.12 | Enables Bluetooth subsystem + transports and supporting symbols as modules. |
| sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-modules/files/amd64_defconfig-6.12 | Explicitly disables DELL_RBTN to avoid pulling in an unrelated module when RFKILL is enabled. |
| changelog/changes/2026-08-09-bluetooth-support.md | Documents the change for release notes. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Sorry, something went wrong.
| @@ -0,0 +1 @@ | |||
| - Enabled the Bluetooth subsystem (BR/EDR and LE) in the kernel, together with the USB, UART, virtio and vhci HCI transports. All of it builds as modules, so it is only loaded when Bluetooth hardware is present or the modules are loaded explicitly. Userspace (BlueZ) is not part of the image and can be added with a systemd-sysext ([scripts#PRNUM](https://github.com/flatcar/scripts/pull/PRNUM)) | |||
tormath1
left a comment
There was a problem hiding this comment.
I'm curious, what would be the use case for this?
Sorry, something went wrong.
|
I've got a few automation devices in my homelab datacenter that can be controlled over BLE like the AC units and access control locks. I've been migrating my servers over to Flatcar and I'd like to control those with services running on Flatcar. |
Sorry, something went wrong.
You can also use one or more Bluetooth proxies for that, this also allows you to be closer to the Bluetooth devices. |
Sorry, something went wrong.
|
Yeah that is what I'm doing now. I can close this PR if flatcar doesn't want to support bluetooth. |
Sorry, something went wrong.
I'm fine with this as long as it does not increase a lot the kernel size. Right now it fails to build with: * ERROR: sys-kernel/coreos-modules-6.12.102::coreos-overlay failed (configure phase):
* Requested options not enabled in build:
* CONFIG_BT_HCIUART_BCM
*
* Call stack:
* ebuild.sh, line 143: Called src_configure
* environment, line 1768: Called coreos-kernel_src_configure
* environment, line 822: Called die
* The specific snippet of code:
* die "Requested options not enabled in build:
* ${missing}";
|
Sorry, something went wrong.
|
It won't meaningfully move the size of the kernel by much. I'll take a look at that build failure. |
Sorry, something went wrong.
Adds a bluez extension providing bluetoothd plus bluetoothctl, btmon, btmgmt and btattach, so Bluetooth can be used on Flatcar without baking BlueZ into the OS image. BlueZ has no upstream static or portable release and links glib, dbus and readline, so the binaries are bundled with their library closure (glibc and the dynamic loader included) from a Debian container and handed to tools/flix.sh, which patchelf's them onto a private loader/rpath. This is the same approach as qemu.sysext and tilde.sysext. Debian packages BlueZ, so the version parameter selects the suite (stable/testing) shipping it. The extension is userspace only. Bluetooth kernel modules must match the running kernel exactly, so they belong in the image; flatcar/scripts#4197 enables them. bluetooth.service is guarded by ConditionPathIsDirectory on /sys/class/bluetooth, so on an image without those modules the unit is skipped rather than failed, and the Upholds= drop-in does not retry it in a loop. The unit reloads D-Bus configuration before starting bluetoothd: the extension drops a new policy file into /usr/share/dbus-1/system.d, which a running dbus-daemon has not read yet, and without the reload bluetoothd cannot take the org.bluez name until the next reboot. Built and checked for both architectures against Debian stable (BlueZ 5.82): the bundled bluetoothd, bluetoothctl and btmon all run and report their version on an Alpine (musl, non-Debian) host, confirming the closure is self-contained. Signed-off-by: Ananth Bhaskararaman <antsub@gmail.com>
Flatcar currently ships no Bluetooth support at all: CONFIG_BT is absent
from the kernel configs, so olddefconfig resolves the whole subsystem to
n and no Bluetooth modules are built.
Enable the core stack (BR/EDR and LE) plus the HCI transports that matter
on the hardware Flatcar runs on:
- btusb, the transport used by essentially every USB adapter and by the
Bluetooth radio in Intel/Realtek/MediaTek/Qualcomm combo chips
- hci_uart with serdev, the usual transport on arm64 edge boards
- virtio_bt, for VMs with a paravirtualised adapter
- hci_vhci, which lets the stack be exercised without real hardware
Everything is a module, so nothing is loaded unless Bluetooth hardware is
present or the modules are loaded explicitly. RFKILL is enabled because
BlueZ needs it to unblock and power adapters, and SERIAL_DEV_BUS because
BT_HCIUART_SERDEV depends on it. CRYPTO_ECC/CRYPTO_ECDH are selected by
BT for LE Secure Connections.
DELL_RBTN is explicitly disabled in the amd64 config: it becomes visible
once RFKILL is enabled (X86_PLATFORM_DRIVERS_DELL is already y) but it is
a laptop radio-button driver unrelated to this change, and leaving it out
keeps the new module set to exactly the Bluetooth closure.
This adds 17 modules totalling ~2.45 MiB (arm64, stripped, uncompressed)
to /usr/lib/modules. Verified with olddefconfig against linux-6.12.102 for
both amd64 and arm64: apart from the symbols listed above, the resulting
.config is byte-identical to the current one on both architectures.
Userspace is deliberately left out of the image; BlueZ is a better fit for
a systemd-sysext.
Signed-off-by: Ananth Bhaskararaman <antsub@gmail.com>
CONFIG_BT_HCIUART_BCM depends on (!ACPI || SERIAL_DEV_CTRL_TTYPORT), and
Flatcar sets CONFIG_ACPI=y, so SERIAL_DEV_CTRL_TTYPORT is required. That
symbol is gated behind "depends on SERIAL_DEV_BUS != m", so with the bus
built as a module it can never be selected and olddefconfig silently left
BT_HCIUART_BCM unset, failing the build:
Requested options not enabled in build:
CONFIG_BT_HCIUART_BCM
Build the serial device bus in and enable the TTY port controller. The bus
is a small core driver and was only introduced as a module by the preceding
Bluetooth commit, so nothing outside this series changes behaviour.
Signed-off-by: Ananth Bhaskararaman <antsub@gmail.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.
Suppressed comments (1)sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-modules/files/amd64_defconfig-6.12:28
- This new override disables Dell's Wireless Radio Control driver. With CONFIG_RFKILL now enabled, Dell platforms can use this driver to expose the physical wireless/Bluetooth switch through rfkill; forcing it off can leave the Bluetooth adapter blocked and make the hotkey ineffective. Please keep the driver available as a module instead of disabling it.
# CONFIG_DELL_RBTN is not set
Sorry, something went wrong.
Reviewers
At least 1 approving review is required to merge this pull request.
This PR enables the Bluetooth stack as modules.
What's enabled
Core stack (BR/EDR + LE) plus some transports.
Userspace
Pulling BlueZ into the base image would grow every Flatcar image for a feature many users won't use. I've added a bluez sysext instead: flatcar/sysext-bakery#253.