Created attachment 520666 [details] emerge --info for amd64 ever since gemato has been used I have this problem on all machines. INFO:root:Refreshing keys from keyserver... ERROR:root:OpenPGP keyring refresh failed: gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net gpg: keyserver refresh failed: Server indicated a failure q: Updating ebuild cache in /usr/portage ... q: Finished 37479 entries in 0.221564 seconds Action: sync for repo: gentoo, returned code = 1
I have recompiled and added lzma & sha3 for gemato but it appears to have made no difference
Please make sure you have >=app-crypt/gnupg-2.2.4-r2, since the dependency has been updated: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9cdccbb4f67a6e3586df619a689ee9a7306ffe7d
(In reply to Zac Medico from comment #2) > Please make sure you have >=app-crypt/gnupg-2.2.4-r2, since the dependency > has been updated: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=9cdccbb4f67a6e3586df619a689ee9a7306ffe7d I noted that the wks-server flag wasn't operational and added it to gnupg as well hope this will be helpfull,it appears to not pick it up ,maybe an addition to the ebuild is necessary
It works for me without the wks-server USE flag enabled.
(In reply to Zac Medico from comment #4) > It works for me without the wks-server USE flag enabled. I still had the failure today with 2.2.4-r2 and am updating to latest version & will see what happens tomorrow
No luck today either,it does appear that the server is not replying to the request for refresh,resident version of gnupg is 2.2.5
(In reply to Geoff Madden from comment #6) > No luck today either,it does appear that the server is not replying to the > request for refresh,resident version of gnupg is 2.2.5 Could you try increasing your dirmngr logging verbosity to see what happens here? see debug and log-file for dirmngr.conf in man dirmngr, it requires a restart of the daemon -- gpgconf --kill dirmngr .
(In reply to Kristian Fiskerstrand from comment #7) > (In reply to Geoff Madden from comment #6) > > No luck today either,it does appear that the server is not replying to the > > request for refresh,resident version of gnupg is 2.2.5 > > Could you try increasing your dirmngr logging verbosity to see what happens > here? see debug and log-file for dirmngr.conf in man dirmngr, it requires a > restart of the daemon -- gpgconf --kill dirmngr . Only problem with that system is rc based not systemd
I did rejig the kernel for selinux this evening, but there does not appear to be a way of actually starting selinux under rc; ie no entry in init.d
* Running emerge --sync >>> Syncing repository 'gentoo' into '/usr/portage'... * Using keys from /var/lib/gentoo/gkeys/keyrings/gentoo/release/pubring.gpg * Refreshing keys from keyserver ...!!! Manifest verification impossible due to keyring problem: OpenPGP keyring refresh failed: gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net gpg: keyserver refresh failed: Server indicated a failure _______________________________________________________________ q: Updating ebuild cache in /usr/portage ... q: Finished 37189 entries in 0.215339 seconds Action: sync for repo: gentoo, returned code = 1 * emerge --sync failed * Time statistics: 1670 seconds for syncing 1671 seconds total this result is with gemato-12.1... the uderlined line is the consistent result I have had since gemato was instigated. Bearing in mind my location is in OZ,which is a long way from the servers being queried,and the possibility that these are blacklisted,probably can't be totally ignored. I am going to set a minus mask for portage rsync-verify and see what happens.
That certainly helped sync is now operating as I recon it is supposed to
I have been having the same issue as Geoff for the past several months - the "server indicated a failure." I am running portage-2.3.32 (currently with the rsync-verify flag disabled), gemato-13.0, and gnupg-2.2.6 (with the wks-server flag emabled).
I have the same issue since today with gnupg-2.2.7, gemato-13.0 and portage-2.3.36.
Does this error occur consistently, or is it intermittent?
(In reply to Zac Medico from comment #14) > Does this error occur consistently, or is it intermittent? very consistent
'emerge --sync' always fails consistently since yesterday with: root@lynxold:/root(4)# emerge --sync >>> Syncing repository 'gentoo' into '/usr/portage_lynxold'... * Using keys from /var/lib/gentoo/gkeys/keyrings/gentoo/release/pubring.gpg * Refreshing keys from keyserver ...OpenPGP keyring refresh failed: gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net gpg: keyserver refresh failed: Server indicated a failure OpenPGP keyring refresh failed: gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net gpg: keyserver refresh failed: Server indicated a failure OpenPGP keyring refresh failed: gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net gpg: keyserver refresh failed: Server indicated a failure ...
I tried to increase the verbosity of dirmngr. I put dirmngr.conf in /root/ and in /root/.gnupg/, but the intended log file is not created: root@lynxold:/root(5)# diff dirmngr.conf .gnupg/dirmngr.conf root@lynxold:/root(6)# tail dirmngr.conf # more root certificates. Tilde expansion is supported. hkp-cacert ~/.gnupg/sks-keyservers.netCA.pem log-file /root/.gnupg/dirmngr.log #debug-level basic debug-level advanced verbose verboseroot@lynxold:/root(7)# ll /root/.gnupg/dirmngr.log /bin/ls: cannot access '/root/.gnupg/dirmngr.log': No such file or directory
I have been getting the this failure for months every time try to emerge with the rsync-verify flag enabled in portage. This has occured regardless of which version of portage I have tried. FWIW, I am running openrc not systemd.
The issue seems to depend on my network configuration. It happens in the "home" configuration and disappears, if I go to "work" configuration.
Everyone please include the output of 'emerge --info app-crypt/gnupg'.
(In reply to Juergen Rose from comment #17) > I tried to increase the verbosity of dirmngr. I put dirmngr.conf in /root/ > and in /root/.gnupg/, but the intended log file is not created: @mgorny, please advise how to to adjust dirmgnr.conf for use by gemato.
Created attachment 530882 [details] emerge --info app-crypt/gnupg output Hope this helps. I for one would love to a resolution to this issue.
I think /etc/gnupg is the location that works.
Created attachment 530898 [details] emerge --info gnupg
(In reply to Juergen Rose from comment #19) > The issue seems to depend on my network configuration. It happens in the > "home" configuration and disappears, if I go to "work" configuration. This description seems consistent with a faulty resolver for handling SRV records c.f https://dev.gnupg.org/T3517 .
Created attachment 531136 [details] home/geoff/emerge-info
Returning to home net 'emerge sync' fails again: root@lynxold:/root(2)# emerge --sync >>> Syncing repository 'gentoo' into '/usr/portage_lynxold'... * Using keys from /var/lib/gentoo/gkeys/keyrings/gentoo/release/pubring.gpg * Refreshing keys from keyserver ...OpenPGP keyring refresh failed: gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net gpg: keyserver refresh failed: Server indicated a failure OpenPGP keyring refresh failed: gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net gpg: keyserver refresh failed: Server indicated a failure OpenPGP keyring refresh failed: gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net gpg: keyserver refresh failed: Server indicated a failure OpenPGP keyring refresh failed: gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net gpg: keyserver refresh failed: Server indicated a failure OpenPGP keyring refresh failed: gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net gpg: keyserver refresh failed: Server indicated a failure ^C Exiting on signal Signals.SIGINT root@lynxold:/root(3)# ping hkps.pool.sks-keyservers.net PING hkps.pool.sks-keyservers.net(2001:470:1:116::6) 56 data bytes 64 bytes from 2001:470:1:116::6: icmp_seq=1 ttl=58 time=98.9 ms 64 bytes from 2001:470:1:116::6: icmp_seq=2 ttl=58 time=97.8 ms 64 bytes from 2001:470:1:116::6: icmp_seq=3 ttl=58 time=98.2 ms ^C --- hkps.pool.sks-keyservers.net ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 97.857/98.334/98.910/0.566 ms
PING hkps.pool.sks-keyservers.net (68.187.0.77) 56(84) bytes of data. 64 bytes from hkps.pool.sks (68.187.0.77): icmp_seq=1 ttl=51 time=275 ms 64 bytes from hkps.pool.sks (68.187.0.77): icmp_seq=2 ttl=49 time=274 ms 64 bytes from hkps.pool.sks (68.187.0.77): icmp_seq=3 ttl=50 time=253 ms 64 bytes from hkps.pool.sks (68.187.0.77): icmp_seq=4 ttl=51 time=274 ms 64 bytes from hkps.pool.sks (68.187.0.77): icmp_seq=5 ttl=49 time=274 ms C64 bytes from hkps.pool.sks (68.187.0.77): icmp_seq=6 ttl=51 time=274 ms 64 bytes from hkps.pool.sks (68.187.0.77): icmp_seq=7 ttl=49 time=274 ms 64 bytes from hkps.pool.sks (68.187.0.77): icmp_seq=8 ttl=51 time=274 ms 64 bytes from hkps.pool.sks (68.187.0.77): icmp_seq=9 ttl=50 time=250 ms 64 bytes from hkps.pool.sks (68.187.0.77): icmp_seq=10 ttl=51 time=274 ms 64 bytes from hkps.pool.sks (68.187.0.77): icmp_seq=11 ttl=50 time=250 ms 64 bytes from hkps.pool.sks (68.187.0.77): icmp_seq=12 ttl=50 time=250 ms 64 bytes from hkps.pool.sks (68.187.0.77): icmp_seq=13 ttl=50 time=250 ms ^C --- hkps.pool.sks-keyservers.net ping statistics --- 14 packets transmitted, 13 received, 7.14286% packet loss, time 13005ms rtt min/avg/max/mdev = 250.052/265.559/275.661/11.621 ms
(In reply to Geoff Madden from comment #28) > PING hkps.pool.sks-keyservers.net (68.187.0.77) 56(84) bytes of data. > 64 bytes from hkps.pool.sks (68.187.0.77): icmp_seq=1 ttl=51 time=275 ms Right, ping doesn't use SRV so it wouldn't be susceptible to this issue
(In reply to Kristian Fiskerstrand from comment #29) > (In reply to Geoff Madden from comment #28) > > PING hkps.pool.sks-keyservers.net (68.187.0.77) 56(84) bytes of data. > > 64 bytes from hkps.pool.sks (68.187.0.77): icmp_seq=1 ttl=51 time=275 ms > > > Right, ping doesn't use SRV so it wouldn't be susceptible to this issue Try e.g $ dig srv _pgpkey-http._tcp.eu.pool.sks-keyservers.net (dig is part of net-dns/bind-tools) in the xase of eu pool it should result NOERROR, in the case of hkps it should result NXDOMAIN since there are no records (disabled for a long time due to GnuPG bug 1446 and 1447) Hoever, some flawed home routers will result in SERVFAIL for this.. if you try switching resolver (/etc/resolv.conf) to e.g 8.8.8.8 (google) you likely avoid that issue.
(In reply to Geoff Madden from comment #3) > (In reply to Zac Medico from comment #2) > > Please make sure you have >=app-crypt/gnupg-2.2.4-r2, since the dependency > > has been updated: > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > > ?id=9cdccbb4f67a6e3586df619a689ee9a7306ffe7d > > I noted that the wks-server flag wasn't operational and added it to gnupg as > well > hope this will be helpfull,it appears to not pick it up ,maybe an addition > to the ebuild is necessary just to exclude wks-servers as having any relevance for this, it is off by default. The server is only relevant for domains serving email and allowing WKD lookups ( https://wiki.gnupg.org/WKD ) . The client is installed unconditionally
Changing my resovl.conf entry solved the problem for me. Thanks.
(In reply to Kristian Fiskerstrand from comment #30) > (In reply to Kristian Fiskerstrand from comment #29) > > (In reply to Geoff Madden from comment #28) > > > PING hkps.pool.sks-keyservers.net (68.187.0.77) 56(84) bytes of data. > > > 64 bytes from hkps.pool.sks (68.187.0.77): icmp_seq=1 ttl=51 time=275 ms > > > > > > Right, ping doesn't use SRV so it wouldn't be susceptible to this issue > > Try e.g $ dig srv _pgpkey-http._tcp.eu.pool.sks-keyservers.net > (dig is part of net-dns/bind-tools) in the xase of eu pool it should result > NOERROR, in the case of hkps it should result NXDOMAIN since there are no > records (disabled for a long time due to GnuPG bug 1446 and 1447) > > Hoever, some flawed home routers will result in SERVFAIL for this.. if you > try switching resolver (/etc/resolv.conf) to e.g 8.8.8.8 (google) you likely > avoid that issue. Yep that fixed the hassle .I apparently have one of those routers that did this.
Now all I have to figure out is how to stop dhcpcd from over writing reolv.conf.
(In reply to Geoff Madden from comment #34) > Now all I have to figure out is how to stop dhcpcd from over writing > reolv.conf. If you install net-dns/openresolv then you can put persistent settings in /etc/resolvconf.conf (run `resolvconf -u` after you update the config).
There is also another issue: https://github.com/systemd/systemd/issues/8164
(In reply to Geoff Madden from comment #34) > Now all I have to figure out is how to stop dhcpcd from over writing > reolv.conf. You can add a line to /etc/resolv.conf.head It will be the start of your /etc/resolv.conf then.
