#Bluetooth adapter no longer recognized

1 messages · Page 1 of 1 (latest)

night steeple
#

Running HAOS on a minisforum n100 as a VM in Proxmox. Onboard bluetooth adapter was working fine until recently, but now Bluetooth fails to set up. Tried restarting the VM, tried removing/readding the BLE adapter, no dice. At a loss for what to do here...please help?

night steeple
#

so this is either an issue with proxmox no longer passing the bluetooth controller through to the VM, or it's an issue with HA not recognizing it anymore. lsusb from the HAOS VM does not show the bluetooth controller at all

drowsy inlet
#

i have had a a simalar issue with my system on a n150 beelink machine. i have been meaning to try and work out the problem but as i have a bunch of bluetooth proxies its been a non issue for me

jade stirrup
#

run lsusb in the Proxmox Nodes shell to retrieve the ID

# As the device is a USB device (although built in), we have to find the Bluetooth adapters device ID
root@pve1:~# lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 8087:0026 Intel Corp. AX201 Bluetooth    <<-----
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Then add that to your VM (example VM ID is 101)

qm set 101 -usb0 host=8087:0026
night steeple
#

yeah, it's already set up like that

#

was working previously...not sure if it was a recent proxmox update or a recent HAOS update that caused it to break

jade stirrup
#

I know someone else mentioned this issue, instead try passing through the full port

night steeple
#

I've got ID 8087:0026 Intel Corp. AX201 Bluetooth, and my VM hardware setup is this...

#

it's an integrated wifi/bluetooth chip

drowsy inlet
#

yeah i am in the same position, very aware on how to passthrough. it just seems to have just stopped at some point.

drowsy inlet
#

i havent spent much time on fixing it so havent tried port. although it did occur to me that maybe upgrading to proxmox 9 might also help although i have no direct reason for beleiving that

night steeple
#

possibly...I only have two devices show up under ports...one is an actual USB NIC, and the other doesn't identify itself

drowsy inlet
#

i guess technically it is a port its just the port is integrated into the a+e key slot

night steeple
#

I just switched it to Port, and I'm rebooting HA to see if it picks it up this time

#

yeah, it still doesn't seem to be passing through

jade stirrup
#

do you see the WiFi with the port passed through?

drowsy inlet
#

wifi is usually on the pcie bus

#

most a+e wifi/BT cards put the wifi on pcie and BT on usb

jade stirrup
night steeple
#

not sure anything is actually getting passed through

#

if I lsusb on the proxmox, I see the bluetooth adapter...if I do it in the VM, whether setting up passthru via device or port, it doesn't show up in the VM

#

I'm debating updating to PM9, but I don't have any spare machines to test it on...and I don't want to bork my stuff

drowsy inlet
jade stirrup
#
placid mulch
jade stirrup
#

Can you see it when you do an lsusb in the VM, if not then I think this is a Proxmox issue and not HA

placid mulch
#

It's available in proxmox..

:~# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 1a86:55d4 QinHeng Electronics SONOFF Zigbee 3.0 USB Dongle Plus V2
Bus 001 Device 014: ID 8087:0026 Intel Corp. AX201 Bluetooth
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
jade stirrup
#

Is that on the Proxmox Node, or in the VM?

#

also, what does 'dmesg' show when run in the VM

#

To get to the HOST OS type login and press enter at the 'HA >' prompt

placid mulch
#

That's on the node. I also see it's a AX201, when in fact it should be a AX101.
iwlwifi correctly picks up a AX101.

dmesg | egrep -i iwlwifi
[    3.912982] iwlwifi 0000:00:14.3: enabling device (0000 -> 0002)
[    3.921240] iwlwifi 0000:00:14.3: Detected crf-id 0x501, cnv-id 0x80400 wfpm id 0x80000030
[    3.921282] iwlwifi 0000:00:14.3: PCI dev 54f0/0244, rev=0x370, rfid=0x10c000
[    3.921285] iwlwifi 0000:00:14.3: Detected Intel(R) Wi-Fi 6 AX101
[    3.977784] iwlwifi 0000:00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version: 0.0.2.42
jade stirrup
#

forget the Node as you need to see it in the VM

#

I just tried passthrough on a Beelink U59 Pro. I just added the USB Device to the VM by Vendor/ID - note that it shows as unknown (mine has same vendor / id)

placid mulch
#

I can't for the life of my figure out how to copy stuff from my HASOS.

#

So only screenshots. (Terminal & SSH addon)

placid mulch
#

lsusb doesn't show it.

jade stirrup
#

it is working for me on Proxmox v8.4.11

#

Kernel 6.8.12-13-pve #1 SMP PREEMPT_DYNAMIC PMX 6.8.12-13 (2025-07-22T10:00Z) x86_64

#

I have one nic passed through to another VM
Sonoff USB Stick passed through to LXC running Zigbee2MQTT
Bluetooth passed through to HA VM

#

Here's my VM Hardware

placid mulch
#

I think it's an issue with Proxmox v9 and the HA VM 2025.08.1

#

Pass through has been working fine for me all these years, but this weekend did a HA + proxmox upgrade. I believe HA first.. But not sure where/how to check this

jade stirrup
#

My HA Supervisor is 2025.08.1 but Core is 2025.8.2 (all latest)

#

I believe it is an issue with the passthrough since lsusb in the VM is not hsowing it

#

What you could try is creating another VM using a generic Linux install and seeing if you can passthrough to that

placid mulch
#
# On a Container
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 017: ID 8087:0026 Intel Corp. AX201 Bluetooth
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
# On a new Debian 13 VM
$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0026 Intel Corp. AX201 Bluetooth
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

$ dmesg | grep -i 'bluetooth'
[    3.613816] Bluetooth: Core ver 2.22
[    3.614269] NET: Registered PF_BLUETOOTH protocol family
[    3.614806] Bluetooth: HCI device and connection manager initialized
[    3.615480] Bluetooth: HCI socket layer initialized
[    3.616006] Bluetooth: L2CAP socket layer initialized
[    3.616653] Bluetooth: SCO socket layer initialized
[    3.672221] Bluetooth: hci0: Firmware timestamp 2025.13 buildtype 1 build 82008
[    3.672969] Bluetooth: hci0: Firmware SHA1: 0x47cf9d0e
[    3.674824] bluetooth hci0: firmware: failed to load intel/ibt-0040-1050.sfi (-2)
[    3.676764] bluetooth hci0: firmware: failed to load intel/ibt-0040-1050.sfi (-2)
[    3.676771] bluetooth hci0: firmware: failed to load intel/ibt-0040-1050.sfi (-2)
[    3.685905] Bluetooth: hci0: Fseq status: Success (0x00)
[    3.686941] Bluetooth: hci0: Fseq executed: 00.00.02.41
[    3.687724] Bluetooth: hci0: Fseq BT Top: 00.00.02.41

I'd say the issue is on HAOS side..

jade stirrup
#

I'd still say this is a Proxmox issue.

What you can try is spinning up a new HA VM - and seeing if passthrough works on that.

#

i think it will, in which case you can restore a backup of your HA and then remove the old VM

placid mulch
jade stirrup
#

Have you power cycled the server?

#

I'm thinking the bluetooth device might be in an odd state and power cycling might clear this.

placid mulch
#

Power cycled.. (both VM + server physically)

jade stirrup
#

ok - I am out of ideas.

#

I am assuming you are using the same BIOS and Machine type that I am (see my hardware settings in earlier post)

placid mulch
#

I am on a Beelink MiniPC.. (MINI-S12 Pro N100) (same as the Github issue..)
My spidey senses point towards some incompatibility with the firmware bundle in the buildroot of the HASOS and the host..

drowsy inlet
#

@night steeple @placid mulch

I spent some time on it today and I have resolved the issue on my EQ14:
The problem: when proxmox boots it loads the BT drivers which puts the BT adaptor into its loaded state which is not reset when it is moved to the VM via passthrough.
so when the VM tries to set it up its in the wrong state.

the solution: prevent proxmox from loading the BT drivers so that that the adaptor stays in its non-loaded state which can then be "loaded" by the guest OS (in this case HAOS)

the method:
on proxmox shell open /etc/modprobe.d/blacklist.conf with your preferred text editor (create the file if needed)
add the following lines

blacklist btusb
blacklist bluetooth
install bluetooth /bin/true

reboot the host system.

HAOS should now be able to see the device correctly.

theory on why it started happening: a proxmox/kernel update somewhere that changed how stuff is loaded.

warning: This assumes you dont ever want to use a bluetooth adaptor on your host OS for any reason though. i feel its unlikly someone might have multiple bluetooth adaptors and sues one on the host for a different purpose but its theoretically a possible issue to look out for

#

have also posted in the github issue

placid mulch
#

Just saw you Github post, will try it! Thanks!

jade stirrup
drowsy inlet
placid mulch
#

Thanks @drowsy inlet that fixes my issue.. Not sure if my jump to pve 9 or an update of HAOS caused this..
But bt is back up and running!

drowsy inlet
placid mulch
#

Out of curiosity, how did you debug this? HA has soo many layers of abstraction I get soo lost..

drowsy inlet
# placid mulch Out of curiosity, how did you debug this? HA has soo many layers of abstraction ...

dmesg on host and client to see what it was doing where, on boot and when attaching/detaching.
then also knowledge that this issue can happen with passed through GPU's in some cases too which is why proxmox documentation recommends blacklisting gpu drivers when using passthrough.

put the pieces together given the outputs and figured that figured blacklisting was worth a shot and it worked great.

jade stirrup
#

What is confusing is that for HiitsameAsh passthrough to a new Debian VM seemed to work without the need to blacklist

drowsy inlet
#

maybe debian has something different in its setup that realises something is not right and slaps the device a bit to get it to work.

jade stirrup
#

possibly, especially as Proxmox is based on Debian

drowsy inlet
#

yeah debian to debian might pass off to each other better for some reason

jade stirrup
#

To be honest, the last time I had to blacklist a device it was an HBA that I use to connect a DELL MD1200 disk array

#

Anyway, thanks for giuring this out and posting here

night steeple
drowsy inlet
#

blacklisting it just means it doesn't load the driver, but you dont want/need the driver on the host because its a full device passthrough.

placid mulch
drowsy inlet
night steeple
#

got my bluetooth adapter back up and working in HA. Thanks again!