Looks like scdaemon was removed from the base image, which means Silverblue users will lose it by default (I dunno if it gets removed automatically for non-Atomic variants).
I assume the solution is only to run rpm-ostree install gnupg2-scdaemon but I was blocked by the subkeys bug so I just reverted to F42 for now.
Anyway, hopefully this gives someone a hint as to why their Yubikey stopped working when they upgraded 
Sounds like this is a side effect of this:
I implemented this Change in a way that users get all subcomponents on upgrade but only common ones on fresh install - but that solution doesn’t apply to ostree based systems since they’re basically “fresh” installs every time. Hopefully that subkeys issue can be resolved quickly so you can at least install the -scdaemon package as needed 
As an aside: getting Yubikeys working is always a fuck-around, on all OSs. It would be cool if they worked out-of-the-box in Fedora.
I should document how I get them working on a new laptop.
Alternatively, we could adapt the gnupg2 package so it pulls in scdaemon by default, so it would be on the base image for OSTree based systems too?
I should clarify - it didn’t work out of the box before 
I don’t think it’s a problem to have to install scdaemon, I just didn’t know it was being removed. But there a few other steps to getting it working properly on a vanilla install.
Two days ago I installed Fedora Kinoite 43 on my laptop, after having been a Debian+KDE user for years. I use Yubikeys extensively, and as a result I quickly ran into the same issue described in this thread. My installation is mostly stock. I enabled third-party repositories and installed about a dozen Flatpaks.
/var/home/hutson
❯ gpg --card-status
gpg: error getting version from 'scdaemon': No SmartCard daemon
gpg: OpenPGP card not available: No SmartCard daemon
So I followed the suggestion from @jamesbelchamber and installed the gnupg2-scdaemon package.
/var/home/hutson
❯ sudo rpm-ostree install gnupg2-scdaemon
Checking out tree 9147acf... done
Enabled rpm-md repositories: fedora-cisco-openh264 updates fedora copr:copr.fedorainfracloud.org:phracek:PyCharm rpmfusion-nonfree-steam rpmfusion-nonfree-nvidia-driver updates-archive
Importing rpm-md... done
rpm-md repo 'fedora-cisco-openh264' (cached); generated: 2025-03-05T10:45:56Z solvables: 6
rpm-md repo 'updates' (cached); generated: 2025-11-03T01:33:42Z solvables: 7643
rpm-md repo 'fedora' (cached); generated: 2025-10-24T04:56:13Z solvables: 77663
rpm-md repo 'copr:copr.fedorainfracloud.org:phracek:PyCharm' (cached); generated: 2025-11-03T08:53:24Z solvables: 13
rpm-md repo 'rpmfusion-nonfree-steam' (cached); generated: 2025-10-24T15:40:30Z solvables: 1
rpm-md repo 'rpmfusion-nonfree-nvidia-driver' (cached); generated: 2025-10-24T15:40:13Z solvables: 17
rpm-md repo 'updates-archive' (cached); generated: 2025-11-03T02:50:56Z solvables: 5734
Resolving dependencies... done
Will download: 1 package (316.0 kB)
Downloading from 'fedora'... done
Importing packages... done
Checking out packages... done
Running systemd-sysusers... done
Running pre scripts... done
Running post scripts... done
Running posttrans scripts... done
Writing rpmdb... done
Writing OSTree commit... done
Staging deployment... done
Freed: 2.4 GB (pkgcache branches: 0)
Added:
gnupg2-scdaemon-2.4.8-4.fc43.x86_64
Changes queued for next boot. Run "systemctl reboot" to start a reboot
After a reboot, I am able to view the status of my Yubikeys
/var/home/hutson
❯ gpg --card-status
Reader ...........: Yubico YubiKey OTP FIDO CCID 00 00
@decathorpe you mentioned that the gnupg2 package could be modified to include scdaemon by default. May I request that, or if there is a more appropriate place to ask for that change, so that Yubikeys can work without needing to touch ostree.
Operating System: Fedora Linux 43
KDE Plasma Version: 6.5.1
KDE Frameworks Version: 6.19.0
Qt Version: 6.10.0
Kernel Version: 6.17.6-300.fc43.x86_64 (64-bit)
Graphics Platform: Wayland
While it would be possible to do this, I’m not sure it’s a good idea to include that package by default. scdaemon accesses hardware in “exclusive” mode by default, which conflicts with any other software that attempts to use it.
Making it installed by default would mean other software that accesses smartcards would need more workarounds.
And one of the reasons why gnupg2 was split up into different packages was to enable non-gnupg software to work better on Fedora, so that would be a step backwards
Out of interest, is there a different/newer/better way to use gpg keys on yubikeys (and, I assume, other smart cards)? Or is scdaemon still the “best" way to be doing that?
Understood @decathorpe . I’ll second James’ comment. My understanding is that I should not be modifying the OS using ostree. Is there a guide on how to use the GPG on a Fedora atomic system?
I came across a few articles that left me with the impression that the pcsc service might be sufficient for GPG. It’s installed in Fedora Kinoite 43:
/var/home/hutson
❯ rpm -q pcsc-lite
pcsc-lite-2.3.3-2.fc43.x86_64
However, I still get a smartcard error. Of course, it’s never that easy . Also, I suspect the conflict between scdaemon and pcsc might be what you were referring to earlier. So, it looks like I could configured scdaemon to use pcsc and avoid the conflict. However, that still requires I install scdaemon. So I am kind of back to the same issue. How do I get my gpg agent to talk through pcsc to my Yubikey without using ostree to install gnupg2-scdaemon?
That’s the entire point of Silverblue - use rpm-ostree at will to layer whatever you need to, while still benefiting from the immutable base, easy reset and rollback, etc etc. I have a couple of things layered - Chrome, Tailscale, some printer drivers..
Seriously, it’s fine.
Thank you @jamesbelchamber for the confidence. When I was looking into immutable operating systems over the weekend (Fedora atomics, along with the Universal Blues), I got the impression I should not use rpm-ostree, but instead, use Flatpaks for apps and toolbox (distrobox in other immutable systems) for development and CLI tools. However, it seems pretty necessary here, and fairly low risk.
@decathorpe it looks like gnupg has a --disable-ccid-driver build flag. … and actually Fedora builds with that flag. So the scdaemon should have been falling back to the pcsc service to interact with attached smart card devices. RedHat bug report explaining the purpose of the inclusion of the --disable-ccid-driver.
Yes, but - assuming I understand this correctly - gnupg uses pcsc in “exclusive” mode, which blocks other applications from accessing the smart card. There is an option for using pcsc in “shared” mode, but that’s documented as being “dangerous” and not fully working: https://www.gnupg.org/(en)/documentation/manuals/gnupg24/scdaemon.1.html
For some reason default gnupg2-scdaemon didn’t work with the shared mode on Silverblue. I had do force it into shared mode by setting pcsc-shared in ~/.gnupg/scdaemon.conf. Maybe dangerous, but it now my Yubikey shows up
You’ll always need to do this, Fedora doesn’t ship with that set by default (I don’t know if anyone does).
The danger is overstated IMO.
Not sure whether SUSE does, but on my work machine, a Tumbleweed derivative, I do not need to set this. Maybe it’s due to the udev rules we specify?
Regardless, if it’s just about caching it shouldn’t really matter to me either
Hi, I just upgraded to F43 and my yubikeys broke and with it quite a few things stopped working. Before upgraded, I checked the common issues at #f43 topics to know what to expect, but this issue was not listed there.
Would it be possible to include this in the common issues for visibility?
EDIT: For context, I was rebasing from 42 to 43 Sericea and rpm-ostree install gnupg2-scdaemon was all I needed it seems.
I’ve filed an RFC in the atomic desktops issue tracker, maybe this can be resolved somehow: https://gitlab.com/fedora/ostree/sig/-/issues/101
In a general sense I think it’s a bad idea to leave things installed that have been removed from the base OS, since it creates a “drift” in deployment configuration which causes people on the same version of an OS to have very different experiences based on which version they started on. This is of course one of the reasons I value Silverblue - it doesn’t do this.
The problem here is that nobody noticed that this change affected the functionality of security keys, right. So if this is important then just add it as a QA test.
I can’t change the tags on this thread but yes I think this would be a good idea.
Common Issues is a subcategory in the Ask Fedora category. Adding or creating a topic there will likely require confirmation from the Fedora QE team. Also, the Ask Fedora category doesn’t have an common-issues tag, but I could add others if that would be useful.