Arch Linux

43615

Member

Registered: 2022-01-19

Posts: 48

[SOLVED] Bluetooth support broken for a weird reason

THIS IS UNRELATED, READ THE LAST MESSAGE

I need to use CDemu to run an old game without its physical disc. According to the wiki page, it's necessary to load some kernel modules for it to work. After doing that, the following problems started:

On boot, the "Triggering uevents..." message lingers for about 60 seconds. I suspect that someting times out after that.

After startup, the btusb modules appears to be unloaded and bluetooth.service is dead because /sys/class/bluetooth doesn't exist. If I manually modprobe btusb and start the service, it still doesn't find any adapters. Unless my mainboard is lying, the integrated adapter is enabled.

This happens reliably on every boot. Regenerating the initramfs didn't help. The btusb module does not appear to be blacklisted.

Last edited by 43615 (2025-04-14 11:09:45)

Lone_Wolf

Administrator

From: Netherlands, Europe

Registered: 2005-10-04

Posts: 13,528

Re: [SOLVED] Bluetooth support broken for a weird reason

are you loading the vhba / sr / sg_mod kernel modules manually after boot ?

---

Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.

clean chroot building not flexible enough ?
Try clean chroot manager by graysky

43615

Member

Registered: 2022-01-19

Posts: 48

Re: [SOLVED] Bluetooth support broken for a weird reason

No, I loaded them once with the command on the wiki page and they appear to stay enabled.

Lone_Wolf

Administrator

From: Netherlands, Europe

Registered: 2005-10-04

Posts: 13,528

Re: [SOLVED] Bluetooth support broken for a weird reason

if you mean # modprobe -a sg sr_mod vhba that is not supposed to have any effect after next (re)boot .

Please run as root / with root rights

journalctl -b | curl -F 'file=@-' 0x0.st

Post the link it outputs .

---

Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.

clean chroot building not flexible enough ?
Try clean chroot manager by graysky

43615

Member

Registered: 2022-01-19

Posts: 48

Re: [SOLVED] Bluetooth support broken for a weird reason

https://0x0.st/8fcP.txt

Lone_Wolf

Administrator

From: Netherlands, Europe

Registered: 2005-10-04

Posts: 13,528

Re: [SOLVED] Bluetooth support broken for a weird reason

Apr 14 12:23:38 aa5f-arch systemd[1316]: Started InfiniTime Daemon (itd).
Apr 14 12:23:38 aa5f-arch systemd[1316]: Starting Update XDG user dir configuration...
Apr 14 12:23:38 aa5f-arch sddm-helper[1330]: Jumping to VT 1
Apr 14 12:23:38 aa5f-arch sddm-helper[1330]: VT mode didn't need to be fixed
Apr 14 12:23:38 aa5f-arch systemd[1]: Bluetooth service was skipped because of an unmet condition check (ConditionPathIsDirectory=/sys/class/bluetooth).
Apr 14 12:23:38 aa5f-arch itd[1328]: panic: RegisterAgent /dev/arsenm/infinitime/Agent: Could not activate remote peer 'org.bluez': unit failed
Apr 14 12:23:38 aa5f-arch itd[1328]: goroutine 1 [running]:
Apr 14 12:23:38 aa5f-arch itd[1328]: go.elara.ws/infinitime.Init({0xc000026ac8, 0x4})
Apr 14 12:23:38 aa5f-arch itd[1328]:         /go/pkg/mod/go.elara.ws/infinitime@v0.0.0-20230421025334-f2640203e9e9/btsetup.go:23 +0x185
Apr 14 12:23:38 aa5f-arch itd[1328]: main.main()
Apr 14 12:23:38 aa5f-arch itd[1328]:         /woodpecker/src/gitea.elara.ws/Elara6331/itd/main.go:65 +0x25e
Apr 14 12:23:38 aa5f-arch systemd[1316]: itd.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Apr 14 12:23:38 aa5f-arch systemd[1316]: itd.service: Failed with result 'exit-code'.

itd.service probably comes from aur package itd-bin or itd-git ?
Does removing that package help ?

Last edited by Lone_Wolf (2025-04-14 10:46:15)

---

Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.

clean chroot building not flexible enough ?
Try clean chroot manager by graysky

43615

Member

Registered: 2022-01-19

Posts: 48

Re: [SOLVED] Bluetooth support broken for a weird reason

Removing that had no effect (not a loss either), but I figured it out:

After the uevents timeout, I caught a brief glimpse of some USB errors, specifically device 3-6. I searched for it in the journal and saw a bunch of initialization-related errors.

The relation to USB suggested that it could be related to a new KVM switch I installed to access the local console of my storage server, specifically the fact that my mouse isn't going through it and the empty port might be causing undefined behavior.

Plugging in a junk wireless keyboard's receiver completely resolved the issue. The weird part is that it didn't start with my usage of the KVM switch, but only after a few switch cycles.

So, the CDemu modules are not involved and were only a coincidence.