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