So, I have been mainlining Fedora Workstation for a couple of years now. My latest setup (which I bought before moving to Portugal!) is the Beelink SER6 PRO, currently running Fedora 41 at the time of writing.
It was initially a bit too fussy for me to mess around with, so I started off with Ubuntu on it (with Regolith). But the more I used Ubuntu, the more I felt disenfranchised with it as a personal computing distro. Fedora, while not perfect, is stable, modern, and the closest thing to what I want in a Linux desktop.
I’ve been using Linux for 15 years now. Started off just before I turned 18 with an old 17-inch HP laptop that could barely run alpha builds of Minecraft without crashing. I got tired of it, wiped Windows, and installed Ubuntu 10.04 LTS (Lucid Lynx). That was my entry point. Since then, I’ve gone through the usual distro-hopping phase, but Fedora has been my home for personal use for a while now.
Here's a quick look at my current setup:
I might write an article about the Moonlander MK I soon enough.
So yeah, Fedora is a very nice distro.
But no distro is perfect.
And I’m not sure why it has decided to act up as of late, but today it did—and it’s the second time it has.
This morning, I sat down to get some work done, and two very important things didn’t work:
- Bluetooth was completely unresponsive.
- Google Chrome refused to open due to a profile lock issue.
These weren’t minor annoyances. These were core components of my workflow. Here’s what happened and how I fixed them.
Fixing Bluetooth on the Beelink SER6 PRO (Intel AX200) on Fedora 41
The Problem
The Bluetooth service was running, but my adapter wasn’t detected in bluetoothctl. Running:
dmesg | grep -i bluetooth
revealed this:
Bluetooth: hci0: command 0xfc05 tx timeout
Bluetooth: hci0: Reading Intel version command failed (-110)
This error suggests that the Intel AX200 Bluetooth firmware failed to load, which is a known issue with some kernel versions and Intel chipsets. The system loads the driver (btusb), but something in the initialization process fails.
This can be caused by:
- A firmware bug in the current Fedora kernel.
- Power management quirks, where the system suspends Bluetooth and fails to wake it.
- An issue with the
btusbkernel module, requiring a reload.
The Fix
The easiest way to resolve this issue was to manually reload the btusb module and restart the Bluetooth service:
sudo modprobe -r btusb
sudo modprobe btusb
sudo systemctl restart bluetooth
Immediately after running these commands, bluetoothctl list showed my adapter again.
Making the Fix Permanent
Since this happened twice, I didn’t want to manually fix it every time my system booted. The best way to automate the fix was by setting up a systemd service to reload the module at startup.
1️⃣ Create a systemd service file:
sudo nano /etc/systemd/system/bluetooth-fix.service
2️⃣ Add the following content:
[Unit]
Description=Fix Intel AX200 Bluetooth on Boot
After=bluetooth.service
Wants=bluetooth.service
[Service]
Type=oneshot
ExecStart=/usr/sbin/modprobe -r btusb
ExecStart=/usr/sbin/modprobe btusb
ExecStart=/bin/systemctl restart bluetooth
[Install]
WantedBy=multi-user.target
3️⃣ Enable and start the service:
sudo systemctl daemon-reload
sudo systemctl enable bluetooth-fix.service
sudo reboot
After this, Bluetooth started working on boot without any manual intervention.
Fixing Chrome’s Profile Lock Issue
The Problem
When I tried to launch Google Chrome, I got this error:
The profile appears to be in use by another Google Chrome process on another computer.
Chrome has locked the profile so that it doesn’t get corrupted.
This happens when Chrome doesn’t shut down properly and leaves behind a profile lock file. It thinks another process is using it, but there’s actually nothing running.
The likely causes:
- Chrome crashed or was force closed while running.
- A previous session didn’t clean up the profile lock file.
- Chrome was left running in the background after closing.
The Fix
First, I killed any lingering Chrome processes:
pkill -9 chrome
pkill -9 google-chrome
Then, I removed the lock files manually:
rm -rf ~/.config/google-chrome/SingletonLock
rm -rf ~/.config/google-chrome/Singleton*
After that, Chrome opened normally.
Final Thoughts
Fedora is a solid distro, but like any system, it has its quirks. The Bluetooth issue was a firmware-related bug that required a systemd fix, while the Chrome issue was a profile lock left over from a previous session.
Both problems had simple enough solutions, but if they’re happening to you, hopefully, this guide saves you some time.
Top comments (0)