This seems to be a pretty universal experience. Further discussion about this issue can be found in this thread.
After installing Windows 10 on a secondary drive, my fingerprint reader does not work anymore. I enrolled my fingerprint in Windows, booted back into Arch, and my finger no longer works. I attempted to remove and then re-enroll my finger but now when I try, fprintd service crashes after the first scan. I am running GDM, and have tried both via CL and in the gnome settings gui.
I uninstalled and reinstalled fprintd and libfprint, no luck after that. Any help would be appreciated!
I often have to rmmod and modprobe btusb on two of my Lenovo laptops running Arch and Intel 8260 wifi/bt cards. Do you get BT back if you run those commands?
After executing:
modprobe -r btusb
modprobe btusb
Nothing happened. Bluetooth remained off. Ironically, bluetooth.service
is still running.
According to the “bug” report, it is expected that you will be prompted to enter your password if you log in using biometrics. This is because of the GNOME keyring which cannot be unlocked using the fingerprint sensor. According to the developer:
That is the expected behaviour. The keyring contains sensitive data, it is encrypted and a fingerprint cannot be used as an encryption key.
Thus the only method to decrypt the keyring is by entering your password. This definitely an inconvenience when initially logging into your machine, but is necessary to maintain security.
A paradigm shift I’ve taken is to use your password to login once you boot up (this also unlocking the keyring), then using biometrics when signing into your computer from sleep.
Do check out this article briefly explaining the GNOME keyring: Explained! The Concept of Keyring in Ubuntu Linux
To anyone having issues with the fingerprint reader after having installed Windows on a secondary drive, here’s a link to a guide that helped me get it working again!
I got Arch Linux installed. One issue, there seems to be an issue with IWD 1.19. It crashed every time I tried to connect to a wifi network. The thing is, the live environment comes with 1.18, so everything would look OK in the live environment but when I booted from the installed environment Wifi would not work. I downgraded the installed environment to 1.18 and it worked. NetworkManager seems to work fine.
Is anyone else having issues with the upgrade to kernel 5.15.2? After updating this morning, running into constant random GPU hangs. Getting errors like [drm] GPU HANG: ecode 12:1:85dffffb, in sddm-greeter
, but sometimes it’s in Xorg
or in QSGRenderThread
or in plasmashell
. Sometimes it will freeze before login, sometimes plasma starts normally and it freezes randomly (usually when opening a program, like firefox), but most times it freezes during xorg or plasma initialization. I’m running plasma/x11, but since it sometimes freezes during SDDM I’m not sure if that matters.
Downgrading the kernel to 5.14.16 seems to have worked, although I am seeing weird visual artifacts in Firefox that I’m not sure were there before.
Update: Visual artifacts in 5.14.16 were fixed by installing xf86-video-intel and configuring as suggested on the arch wiki. Still seeing GPU hangs on 5.15.2 with the new config, though.
Another update: It looks like maybe Plasma disables some compositing features if it detects a GPU crash, which is probably why I started noticing visual artifacts after rolling back.
@mcdoogs I am seeing the same thing. 5.15.2 makes plasma utilities unsuable, causing GPU HANGs. I downgraded all the way to 5.14.9 and am not seeing any visual artifacts nor hangs.
Looks like the i915 driver got messed up on last release.
I’m guessing it’s the same as this issue. Although they’re encountering it in just SDDM, might be some difference between hardware or distro letting us get to plasma occasionally
I am seeing the same thing. I upgraded to 5.15.2 yesterday morning. General programs like Firefox ran like normal, however attempting to interface with any Plasma widgets like the battery indicator or application menu caused the system to completely hang. I ended up downgrading to my previous kernel where the symptoms went away. This is the first time I’ve had to downgrade a kernel, so I’m hoping there aren’t any complications.
For those wanting to get bluetooth working on the latest kernel, there is a patch currently available that you can compile into a kernel: [v2] Bluetooth: btintel: Fix bdaddress comparison with garbage value - Patchwork
Or you can wait for the patch to make it into the latest kernel
I have the same issues with kernel 5.15.2. I downgraded to 5.14.11, which helped recover most problems except the bluetooth. Would pacman upgrade to the new and hopefully fixed kernel when it becomes available? I don’t feel comfortable compiling the darn thing, lol.
After updating to the latest kernel (5.15.2), my HDMI adaptor stopped working. Booting to LTS (5.10.80) and the hdmi works. Has anybody else seen this?
Edit: Actually, looking through my logs, 5.15.2 was working originally, so something else I updated after initial install must be at fault. Booting LTS does fix it, though
I tried it just now and it works for me (running 5.15.2-arch1-1)
Have you updated everything today? It looks like the kernel isn’t the problem, but using the LTS kernel fixes it. I am guessing some other module was updated, but nothing strikes me as likely in the pacman.log
I updated today to 5.15.3, and it is working again. It is a mystery…
No luck for me with the kernel 5.15.3 upgrade. Bluetooth not detected, KDE freezes for a few seconds before re-responding, etc. Downgraded to 5.14.16 , most issues fixed. Baloo got excited and using significant system resources at the moment, probably nothing to do with the process and just a random coincidence.
I had the same experience after upgrading this weekend. I just downgraded to 5.14.9-arch2-1
(just because it was the only other version I had in /var/cache/pacman/pkg
) and everything is normal again for now.