hi, This is probably not a pcsc bug, but I'm not sure exactly where I should file it. It's more of a system-integration level thing. I upgraded my system from Fedora 32 Silverblue to Fedora 33 Silverblue today. I use my yubikey to store GPG keys (which in turn I use as my SSH key). From Fedora 32 Silverblue I had to overlay the pcsc-lite package, but after I did so, this command works fine: $ gpg --card-status From Fedora 33, pcsc-lite is already installed, but the above command fails, saying it's unable to find any smartcards. I did a bit of digging, and this is down to scdaemon getting a "sharing violation" error from pcscd. Indeed, there are two processes connected to pcscd which were not connected to it in Fedora 32: rngd (from rng-tools) and gsd-smartcard (from gnome-settings-daemon). Killing rngd and gsd-smartcard allows me to use my yubikey again in Fedora 33 (ie: gpg --card-status is working). These two processes were also running on Fedora 32, but didn't seem to be causing any problems there. I don't know what changed.
I did some more investigation. The thing that changed is that the package `opensc` is now installed by default. It brings with it a pkcs11 module, and specifically, an entry in /usr/share/p11-kit/modules (opensc.module), which causes it to be found by gnome-settings-daemon and rngd. In particular, on Fedora 33: $ p11-kit list shows: opensc: opensc-pkcs11.so library-description: OpenSC smartcard framework library-manufacturer: OpenSC Project library-version: 0.20 token: OpenPGP card (User PIN) manufacturer: Yubico model: PKCS#15 emulated serial-number: 000611120611 hardware-version: 3.4 firmware-version: 3.4 whereas, I don't get this on Fedora 32.
Two possible workarounds: 1: rpm-ostree override remove opensc 2: or via configuration: ==> /etc/pkcs11/modules/opensc.module <== disable-in: rngd gsd-smartcard but rngd hardcodes the opensc driver (./configure option), so you need to do this: ==> /etc/systemd/system/rngd.service.d/disable-pkcs11.conf <== [Service] ExecStart= ExecStart=/sbin/rngd -xpkcs11 -f Note: trying to write 'module:' to /etc/pkcs11/modules/opensc.module (as suggested by the pkcs11.conf manpage) will brick your system due to a p11-kit bug. Anything using p11-kit will spin on startup (including systemd-resolved, preventing the system from booting).
A bit of background: I use a Yubikey Nano, which I leave permanently installed inside my USB port, so it's always present on startup. Also: the above workarounds are obviously just workarounds. We need to figure out a better way to allow p11-kit and scdaemon to coexist.
The root cause is the gpg's scdaemon insisting on the exclusive access to the scdaemon. There were some patches removing this from the scdaemon (probably one-liner, never upstreamed) or there is alternative scdaemon's using standard PKCS#11 [1], but I never managed to pursue either of the directions as I use my yubikey mostly for pkcs11 related stuff. If you use your yubikey only for gpg, the easiest solution is really to remove opensc package. [1] https://github.com/alonbl/gnupg-pkcs11-scd
I have same issue after upgrading from F32 to F33 Unable to access yubikey. I mainly use it for ssh login. gpg --card-edit --expert gpg: selecting card failed: No such device gpg: OpenPGP card not available: No such device
I am running Workstation not Silverblue, but the issue seems similar, if not identical. I originally had Fedora 32, and all was well, but on upgrade to 33 this issue appeared. I can also confirm that a clean install of Fedora 33 has the same issue. I should also note that this issue is only present if my Yubikey is inserted from when the computer is off. If I remove the Yubikey immediately after the login screen (I use the Yubikey to automatically fill the password field on the login screen) then the issue will not appear. To get rid of the issue I have to restart pcscd: sudo service pcscd restart and then the issue will only return after a reboot. Other info in case they are relevant: My install is encrypted My install is situated on an external bootable USB drive If you need further info just ask.
Yesterday I did a fresh install of Fedora 33 Workstation KDE. I was able to get my Yubikey 4 smartcard working with gpg2 by configuring this file ~/.gnupg/scdaemon.conf to contain these lines: pcsc-driver /usr/lib/libpcsclite.so card-timeout 5 disable-ccid and rebooting Today I: * Configured pam-u2f to require u2f for login, su, and sudo * Installed firejail * Uninstalled firejail The Yubikey is no longer working with gpg2. gpg2 --card-status says that there is no smartcard attached. I don't know if this is relevant or not, but launch Firefox with the Yubikey plugged in Firefox repeatedly asks me to unlock my PKCS#11 PIV card (which I don't think I've ever used)
It looks like pcsc-lite-libs doesn't include the symlink to libpcsclite.so, so I had to set `pcsc-driver /usr/lib64/libpcsclite.so.1` in my scdaemon.conf and that seems to work.
Same problem here after upgrading a Fedora Workstation (not Silverblue) from 32 to 33. TL;DR: > If you use your yubikey only for gpg, the easiest solution is really to remove opensc package. sudo dnf remove opensc Confirming #c4 that ^^^ this (and then rebooting) indeed did the trick for me; all fine again now. Qs: What does opensc (from https://github.com/OpenSC/OpenSC, presumably?) do for us? Why was it added in Fedora 33? What are we losing if we manually uninstall the package (at its current version 0.20.0-7.fc33) after upgrading from 32 to 33? Everything I currently use it for still seems to work... echo "pcsc-driver /usr/lib64/libpcsclite.so.1" >>~/.gnupg/scdaemon.conf from #c7 #c8 did not seem to do the trick (for me; YMMV). sudo killall rngd gsd-smartcard (from #c0), and then plugging the YK out and plugging it back into the USB port, also did the trick, but of course isn’t permanent. Some further observations, just for the record: [user@fedora32~]$ p11-kit list-modules p11-kit-trust: p11-kit-trust.so library-description: PKCS#11 Kit Trust Module library-manufacturer: PKCS#11 Kit library-version: 0.23 token: (...) [user@fedora33~]$ p11-kit list-modules p11-kit-trust: p11-kit-trust.so library-description: PKCS#11 Kit Trust Module library-manufacturer: PKCS#11 Kit library-version: 0.23 token: (...) opensc: opensc-pkcs11.so library-description: OpenSC smartcard framework library-manufacturer: OpenSC Project library-version: 0.20 token: (...) Note I had to use “p11-kit list-modules” instead of “p11-kit”, probably just a typo. [user@fedora32~]$ systemctl status rngd Initializing available sources [hwrng ]: Initialized [rdrand]: Enabling RDSEED rng support [rdrand]: Initialized [jitter]: Initializing AES buffer [jitter]: Unable to obtain AES key, disabling AES in JITTER source [jitter]: Enabling JITTER rng support [jitter]: Initialized [pkcs11]: PKCS11 Engine /usr/lib64/opensc-pkcs11.so Error: No such file or directory [pkcs11]: Initialization Failed [user@fedora33~]$ systemctl status rngd (...) [jitter]: Enabling JITTER rng support [jitter]: Initialized [pkcs11]: Slot manufacturer......: Yubico [pkcs11]: Slot description.......: Yubico YubiKey FIDO+CCID 00 00 [pkcs11]: Slot token label.......: OpenPGP card (User PIN) [pkcs11]: Slot token manufacturer: Yubico [pkcs11]: Slot token model.......: PKCS#15 emulated [pkcs11]: Slot token serial......: (...) [pkcs11]: Initialized [rtlsdr]: Initialization Failed [user@fedora32~]$ systemctl status pcscd systemd[1]: Started PC/SC Smart Card Daemon. pcscd[36372]: 00000000 ifdhandler.c:150:CreateChannelByNameOrChannel() failed pcscd[36372]: 00000051 readerfactory.c:1105:RFInitializeReader() Open Port 0x200000 Failed (usb:1050/0406:libudev:0:/dev/bus/usb/001/010) pcscd[36372]: 00000002 readerfactory.c:376:RFAddReader() Yubico YubiKey FIDO+CCID init failed. Same as this ^^^ on @fedora33 after uninstalling opensc (hadn't tried before).
It has become pain in butt, I have to restart pcscd every half an hour or so. Everytime I shutdown or reboot, I have to restart pcscd.
This isn't just a yubikey issue. I'm experiencing the same with my Nitrokey smartcard on Silverblue 33 and Fedora 33 toolbox containers.
For what it's worth, I have a reasonable workaround for at least my usecase (since I don't actually care about GPG anymore): using the PIV mode of the Yubikey directly for my SSH key. That's working lovely, modulo Bug 1949436 (which is much easier to work around).
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
FWIW this issue was present in Fedora Silverblue 34 (upgraded from 33, and also it is still present in a fresh Silverblue 35 install. To make gpg smartcards work one must always `sudo systemctl restart pcscd` every so often. Can we change the version of this ticket?
Fedora 35 gnupg should already have disabled internal ccid driver. If you need to use yubikey for both (PIV) smart card functionality and gpg, you should add shared-access to your .gnupg/scdaemon.conf so it will not explode on the requirement for exclusive access to the device.
*** Bug 1853347 has been marked as a duplicate of this bug. ***
(In reply to Jakub Jelen from comment #17) > Fedora 35 gnupg should already have disabled internal ccid driver. If you > need to use yubikey for both (PIV) smart card functionality and gpg, you > should add shared-access to your .gnupg/scdaemon.conf so it will not explode > on the requirement for exclusive access to the device. For anyone arriving here having this problem on F35 WS (I have it using a Yubikey 5 NFC) "shared-access" is not a scdaemon option, instead use pcsc-shared in the same file. No other solutions that could be found through google (posted here: https://ludovicrousseau.blogspot.com/2019/06/gnupg-and-pcsc-conflicts.html for example) worked for me.
I can't get it to work on Silverblue 35. With `.gnupg/scdaemon.conf` as in ``` log-file /tmp/scdaemon.log debug-level guru debug-ccid-driver disable-ccid pcsc-shared pcsc-driver /usr/lib64/libpcsclite.so.1 ``` I get ``` 2022-02-16 10:12:20 scdaemon[203447] pcsc_establish_context failed: no service (0x8010001d) ``` Interestingly `pcscd.service` does not get started. Manually starting it does not do much, because it's configured to stop automatically. The `pcscd.socket` unit is active.
I just ran into this same problem after upgrading to Fedora 35. After some time, I realized that `gpg --card-status` worked fine if I was root - but would hang indefinitely as a normal user. After about an hour trying all of the standard Google suggestions of editing scdaemon.conf, adding concurrent options, etc. I also tried someones suggestion of adding a udev rule but was not successful. I finally stumbled across this page: https://support.yubico.com/hc/en-us/articles/360013708900-Using-Your-U2F-YubiKey-with-Linux. Adding the file https://github.com/Yubico/libu2f-host/blob/master/70-u2f.rules to the udev rules and rebooting fixed the issue. Hope this saves someone an hour!
Ahhh! I just had to fight Yubikey + GPG + pcscd + scdaemon for over an hour. I was getting this: $ gpg --card-status gpg: selecting card failed: Service is not running gpg: OpenPGP card not available: Service is not running and I got got some odd NOT authorized on pcscd: Jun 15 00:20:41 sw-0608 systemd[1]: Started pcscd.service - PC/SC Smart Card Daemon. Jun 15 00:20:41 sw-0608 pcscd[873786]: 00000000 auth.c:137:IsClientAuthorized() Process 872679 (user: 1000) is NOT authorized for action: access_pcsc Jun 15 00:20:41 sw-0608 pcscd[873786]: 00000073 winscard_svc.c:335:ContextThread() Rejected unauthorized PC/SC client Jun 15 00:21:42 sw-0608 systemd[1]: pcscd.service: Deactivated successfully. Which lead me to find https://github.com/Yubico/libfido2/blob/main/udev/70-u2f.rules (the link that aaron from comment #21 posted is in an old archived repo). I installed those udev rules and rebooted. Then I ended up with $ gpg --card-status gpg: selecting card failed: No such device gpg: OpenPGP card not available: No such device and then after futzing around with the ~/.gnupg/scdaemon.conf file I ended up back with disable-ccid pcsc-shared pcsc-driver /usr/lib64/libpcsclite.so.1 which were the options I had commented out last week and things worked fine. Anyways, after running gpgconf --kill gpg-agent gpg-connect-agent reloadagent /bye and I am back in business with my Yubikey 5 NFC. Whatever changed in Fedora 33 w/r/t Yubikey + GPG + pcscd + scdaemon has been super frustrating. I pretty much lose an hour or two every 4 months to something related to this. Ugg! I hope this helps someone or my future self when I run into issues again.
https://github.com/vorburger/vorburger.ch-Notes/blob/develop/linux/fedora-upgrade.md
This still affects Fedora 36 (not Silverblue). No combination of settings in ~/.gnupg/scdaemon.conf really stuck. gpg --card-status would work fine, then a minute later it'd give me a card error. The timing and relation to my activity on the computer seemed totally unrelated to anything, it would just break randomly. The best I can tell from just a guess is that Firefox will use opensc, which then creates an exclusive lock on the card (may not be accurate). GnuPG can then no longer read from the card until pcscd is restarted, or the card is removed or inserted. Since I'm using the card's PIV primarily in gpg mode, I just uninstalled opensc and restarted the computer and now gnupg consistently works. I don't like this resolution though since it disables functionality. Maybe there is something that can be set in /etc/opensc.conf, but I got tired of trying various setting combinations out.
I finally got a consistent solution that doesn't remove any functionality: completely ditch opensc and replace it with Scute from GnuPG (https://gnupg.org/software/scute/index.html). Fedora doesn't package this, so it has to be installed from source. You'll probably also want to create a p11-kit module that uses it so that desktop applications can access your yubikey certificate store, which can be done by adding a /etc/pkcs11/modules/scute.module conf just containing 'module: /usr/local/lib/scute.so'. You can check out the p11-kit docs for additional settings you can use in the .module file. I don't know how installing from source works in Silverblue, but it would be great if Fedora packaged Scute as an alternative to OpenSC for situations where you want to use a smart card with both GPG and other generic smart card usage.
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Not sure if this covers your use case, but it seems related and others may end up here from Google for a workaround: https://github.com/containers/toolbox/issues/568#issuecomment-1513554674
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16. Fedora Linux 36 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.
This bug is still active on Fedora 38. It should be re-opened.
I can also confirm that the issue remains present on Fedora 38. Note also that a non-ideal workaround exists: You can remove the `opensc` package from Silverblue et. al. and it will no longer conflict with pcsc-lite. Of course, this disables opensc-specific capabilities.
(In reply to Stephen Gallagher from comment #31) > I can also confirm that the issue remains present on Fedora 38. > > Note also that a non-ideal workaround exists: You can remove the `opensc` > package from Silverblue et. al. and it will no longer conflict with > pcsc-lite. Of course, this disables opensc-specific capabilities. I removed opensc package to get yubikey working with gnupg. I need it for SSH key which I can also use on Android devices. But opensc is necessery to use S/MIME certificates in Thunderbird and Firefox. I would like to use it in the near future :-/ So, a workaround is not a solution of the problem. It's a temporary workaround.
I mentioned earlier in this bug report (comment 25) that one could use 'scute' instead of opensc. I've been going this route since I made that post and it works great for allowing S/MIME access in Thunderbird and Firefox. Fedora still doesn't package scute though, so you have to get the source and compile it yourself. At least it's a workaround that seems to meet all needs.
(In reply to Dan O. from comment #33) > I mentioned earlier in this bug report (comment 25) that one could use > 'scute' instead of opensc. I've been going this route since I made that post > and it works great for allowing S/MIME access in Thunderbird and Firefox. > Fedora still doesn't package scute though, so you have to get the source and > compile it yourself. At least it's a workaround that seems to meet all needs. I've tried to switch to scute but with no success. Here's the steps I made: 1) removed opensc package 2) compiled scute library in podman environment 3) moved scute.so to my system to /usr/lib64 4) created /etc/pkcs11/modules/scute.module with the content: module: scute.so But it didn't work. When I opened Firefox settings, I couldn't find my Yubikey. It was there with opensc installed. What did I wrong? If I get it working, there's no problem for me to create spec file to build rpm package.
Mm, I wonder what the difference could be. I don't think my setup must be too different from yours. When I open Firefox and go to Settings -> Security -> (Click "Security Devices..." button), under Security Modules and Devices I have a top-level entry called p11-kit-proxy. Under p11-kit-proxy I have a device called 'GnuPG Smart Card Daemon'. I take note of the 'Label' field in that screen. Going to 'View Certificates', I see several stored certificates under the 'Your Certificates' tab, the data in column 'Security Device' matches the 'GnuPG Smart Card Daemon' Label. It seems unlikely, but are you missing the 'p11-kit-proxy' security module? I may have had to add that module directly by clicking 'Load' and finding 'p11-kit-proxy.so'. When I was working through this a while ago, I know I loaded and unloaded several modules by hand, trying things out, so I can't remember if this is there by default.
Interestingly enough, even though the security device is called 'GnuPG Smart Card Daemon' and the manufacturer is listed as 'scdaemon', you can somewhat tell that this is being provided through scute: The FW Version is listed as 1.7 (my installed version of scute) and HW version is listed at 2.4 (my installed version of gpg)
$ p11-kit list-modules p11-kit-trust: p11-kit-trust.so library-description: PKCS#11 Kit Trust Module library-manufacturer: PKCS#11 Kit library-version: 0.24 token: System Trust manufacturer: PKCS#11 Kit model: p11-kit-trust serial-number: 1 hardware-version: 0.24 flags: write-protected token-initialized token: Default Trust manufacturer: PKCS#11 Kit model: p11-kit-trust serial-number: 1 hardware-version: 0.24 flags: write-protected token-initialized scute: /usr/local/lib/scute.so library-description: Cryptoki for GnuPG library-manufacturer: g10 Code GmbH library-version: 1.0
Second approach and scute works!! I've changed two things: 4) created /etc/pkcs11/modules/scute.module with the content: module: /usr/lib64/scute.so (full path) 5) sudo chown root: /usr/lib64/scute.so; sudo chcon -u system_u -t lib_t /usr/lib64/scute.so Thanks Dan.O for your support!
Bump Installing scute isn't the perfect solution. It works, but my logs are every second spammed with these messages: Jun 28 18:07:49 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Jun 28 18:07:49 piglet gsd-smartcard[3685]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device Jun 28 18:07:49 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Jun 28 18:07:49 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Jun 28 18:07:49 piglet firefox.desktop[10512]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device Jun 28 18:07:49 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Jun 28 18:07:49 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Jun 28 18:07:49 piglet firefox.desktop[10512]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device Jun 28 18:07:49 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Jun 28 18:07:49 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Jun 28 18:07:49 piglet firefox.desktop[10512]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device Jun 28 18:07:49 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Jun 28 18:07:49 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Jun 28 18:07:49 piglet firefox.desktop[10512]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device Jun 28 18:07:49 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Jun 28 18:07:50 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Jun 28 18:07:50 piglet gsd-smartcard[3685]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device Jun 28 18:07:50 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Jun 28 18:07:50 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Jun 28 18:07:50 piglet gsd-smartcard[3685]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device Jun 28 18:07:50 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Jun 28 18:07:50 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Jun 28 18:07:50 piglet gsd-smartcard[3685]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device Jun 28 18:07:50 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Jun 28 18:07:51 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Jun 28 18:07:51 piglet gsd-smartcard[3685]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device Jun 28 18:07:51 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Jun 28 18:07:51 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Jun 28 18:07:51 piglet gsd-smartcard[3685]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device Jun 28 18:07:51 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Jun 28 18:07:51 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Jun 28 18:07:51 piglet gsd-smartcard[3685]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device Jun 28 18:07:51 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Jun 28 18:07:52 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Jun 28 18:07:52 piglet gsd-smartcard[3685]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device Jun 28 18:07:52 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Jun 28 18:07:52 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Jun 28 18:07:52 piglet gsd-smartcard[3685]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device Jun 28 18:07:52 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Jun 28 18:07:52 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Jun 28 18:07:52 piglet gsd-smartcard[3685]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device Jun 28 18:07:52 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e) Any suggestions, how to fix it?
Broken for me also. I am on SilverBlue, for less than a week so far. Initially, it worked. Then I rebooted, maybe did a few `rpm-ostree upgrade`s, and now it does not work. I am not keen to try the `scute` approach, as it goes against the SilverBlue approach, I think. `pass` fails. It just opens `pinentry` and I am prompted to insert the YubiKey I have inserted. ``` toolbox% gpg-connect-agent > SCD SERIALNO --all ERR 100663614 Service is not running <SCD> ``` ```code $ rpm-ostree status -v State: idle AutomaticUpdates: disabled Deployments: ● fedora:fedora/38/x86_64/sericea (index: 0) Version: 38.20230705.0 (2023-07-05T00:44:27Z) Commit: fc15abf986d93720c2ba0f62f13a341c87bc097335c94750a3752fc8f05e06ca ├─ repo-0 (2023-04-14T09:32:40Z) ├─ repo-1 (2023-07-05T00:16:53Z) └─ repo-2 (2023-07-05T00:19:08Z) Staged: no StateRoot: fedora GPGSignature: 1 signature Signature made Wed 05 Jul 2023 10:44:35 using RSA key ID 809A8D7CEB10B464 Good signature from "Fedora <fedora-38-primary>" fedora:fedora/38/x86_64/sericea (index: 1) Version: 38.20230705.0 (2023-07-05T00:44:27Z) Commit: fc15abf986d93720c2ba0f62f13a341c87bc097335c94750a3752fc8f05e06ca ├─ repo-0 (2023-04-14T09:32:40Z) ├─ repo-1 (2023-07-05T00:16:53Z) └─ repo-2 (2023-07-05T00:19:08Z) StateRoot: fedora GPGSignature: 1 signature Signature made Wed 05 Jul 2023 10:44:35 using RSA key ID 809A8D7CEB10B464 Good signature from "Fedora <fedora-38-primary>" ``` ```random-shell-interactions $ p11-kit list-modules p11-kit-trust: p11-kit-trust.so library-description: PKCS#11 Kit Trust Module library-manufacturer: PKCS#11 Kit library-version: 0.24 token: System Trust manufacturer: PKCS#11 Kit model: p11-kit-trust serial-number: 1 hardware-version: 0.24 flags: write-protected token-initialized token: Default Trust manufacturer: PKCS#11 Kit model: p11-kit-trust serial-number: 1 hardware-version: 0.24 flags: write-protected token-initialized opensc: opensc-pkcs11.so library-description: OpenSC smartcard framework library-manufacturer: OpenSC Project library-version: 0.23 ```
(In reply to Krzysztof Raczkowski from comment #39) > Bump > > Installing scute isn't the perfect solution. It works, but my logs are every > second spammed with these messages: > > Jun 28 18:07:49 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers > failed: no readers available (0x8010002e) > Jun 28 18:07:49 piglet gsd-smartcard[3685]: scute: agent_simple_cmd:194: > *** SNIP *** > > > Any suggestions, how to fix it? Odd, I haven't seen those errors before, but it looks like something is using the yubikey exclusively. I wonder if it has to do with gnupg settings? .gnupg/scdaemon.conf: disable-ccid .gnupg/gpg-agent.conf: enable-ssh-support default-cache-ttl 60 max-cache-ttl 120 pinentry-program /usr/bin/pinentry-gnome3 None of those look like they'd influence that though. I'm not sure, sorry. Beto: It looks as though your rpm-ostree upgrade removed scute from your system, as p11-kit is reporting that you have opensc instead of scute now. I'm not really familiar with how Silverblue allows for out-of-tree installations.
My mistake as I haven't noticed that this bug is opened for Silverblue. I use Fedora Workstation 38 but I think, the problem here is independent. It's not that something is using the yubikey as I've got this on the system which has never seen yubikey yet: lip 06 19:32:57 pooh gpg-agent[4885]: scdaemon[4885]: pcsc_list_readers failed: no readers available (0x8010002e) lip 06 19:32:57 pooh gpg-agent[4885]: scdaemon[4885]: pcsc_list_readers failed: no readers available (0x8010002e) lip 06 19:32:57 pooh gpg-agent[4885]: scdaemon[4885]: pcsc_list_readers failed: no readers available (0x8010002e) lip 06 19:32:57 pooh gpg-agent[4885]: scdaemon[4885]: pcsc_list_readers failed: no readers available (0x8010002e) lip 06 19:32:57 pooh gpg-agent[4885]: scdaemon[4885]: pcsc_list_readers failed: no readers available (0x8010002e) lip 06 19:32:57 pooh gpg-agent[4885]: scdaemon[4885]: pcsc_list_readers failed: no readers available (0x8010002e) It's from my second workstation named pooh. It's configured the same way as my first workstation (piglet) but at the moment I'm using my yubikey only on piglet. I've managed to workaround these errors in log with these steps: 1) I've patched scute and changed log level from DBG_CRIT to DBG_INFO in one place: diff -uNr scute-1.7.0.orig/src/agent.c scute-1.7.0/src/agent.c --- scute-1.7.0.orig/src/agent.c 2020-11-24 15:10:59.000000000 +0100 +++ scute-1.7.0/src/agent.c 2023-06-28 18:27:36.160268002 +0200 @@ -191,7 +191,7 @@ err = assuan_transact (ctx, optstr, NULL, NULL, default_inq_cb, NULL, NULL, NULL); if (err) - DEBUG (DBG_CRIT, "gpg-agent command '%s' failed: %s", optstr, + DEBUG (DBG_INFO, "gpg-agent command '%s' failed: %s", optstr, gpg_strerror (err)); free (optstr); 2) I've changed logging configuration of scdaemon (last line): # ~/.gnupg/scdaemon.conf disable-ccid reader-port Yubico Yubi quiet log-file /dev/null 3) I've changed logging configuration of pcscd daemon: # /etc/default/pcscd PCSCD_ARGS="--critical" and restarted the daemone: sudo systemctl restart pcscd
(In reply to Dan O. from comment #41) > Beto: It looks as though your rpm-ostree upgrade removed scute from your > system, as p11-kit is reporting that you have opensc instead of scute now. > I'm not really familiar with how Silverblue allows for out-of-tree > installations. Took a two week break from SilverBlue, hoping for a fix to trickle down. Just did `rpm-ostree update` and rebooted. Works again. Not sure what changed. I still have opensc.
Did another `rpm-ostree update; reboot` and again, stopped working. Per the goog: ``` gpgconf --kill gpg-agent gpg-connect-agent updatestartuptty /bye ``` That fixed it. No idea whats going on. I was getting lots of ``` apdu_open_reader: failed to open driver '/usr/lib64/libpcsclite.so.1': /usr/lib64/libpcsclite.so.1: cannot open shared object file: No such file or directory ``` Now that it works again, I find the unlock does not stick. I have to unlock it for every `pass -c xxx` operation. That significantly reduces usability.
This message is a reminder that Fedora Linux 38 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 38 on 2024-05-21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '38'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 38 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21. Fedora Linux 38 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.