You are not logged in.
Pages: 1
Topic closed
I recently attempted a general system upgrade with
# pacman -Syu
the upgrade failed because some of the keys were not recognized.
virhe: key "94657AB20F2A092B" could not be looked up remotely
virhe: key "E62F853100F0D0F0" could not be looked up remotely
virhe: key "3C1C876030B65FE2" could not be looked up remotely
virhe: key "BBE43771487328A9" could not be looked up remotely
virhe: key "A91764759326B440" could not be looked up remotely
virhe: key "A6234074498E9CEE" could not be looked up remotely
virhe: key "A5E9288C4FA415FA" could not be looked up remotely
virhe: key "786C63F330D7CB92" could not be looked up remotely
virhe: key "7A4E76095D8A52E4" could not be looked up remotely
virhe: key "FC1B547C8D8172C8" could not be looked up remotely
virhe: key "06096A6AD1CEDDAC" could not be looked up remotely
virhe: key "51E8B148A9999C34" could not be looked up remotely
virhe: key "976AC6FA3B94FA10" could not be looked up remotely
virhe: key "771DF6627EDF681F" could not be looked up remotely
virhe: key "7F2D434B9741E8AC" could not be looked up remotely
virhe: key "B02854ED753E0F1F" could not be looked up remotely
virhe: key "A3D9562A589874AB" could not be looked up remotely
virhe: key "C06086337C50773E" could not be looked up remotely
virhe: key "396E3E25BAB142C1" could not be looked up remotely
virhe: key "AFF5D95098BC6FF5" could not be looked up remotely
virhe: key "BE01EC22A04E2E46" could not be looked up remotely
virhe: key "65C110C1EA433FC7" could not be looked up remotely
virhe: key "2E89012331361F01" could not be looked up remotely
virhe: key "DB323392796CA067" could not be looked up remotely
virhe: key "1EB2638FF56C0C53" could not be looked up remotely
virhe: key "39E4B877E62EB915" could not be looked up remotely
virhe: key "FCF3C8CB5CF9C8D4" could not be looked up remotely
virhe: key "E613C09CB4440678" could not be looked up remotely
virhe: key "6D1655C14CE1C13E" could not be looked up remotely
virhe: key "24E4CDB0013C2580" could not be looked up remotely
virhe: key "206CBC892D1493D2" could not be looked up remotely
virhe: vaadittu avain puuttuu avainrenkaasta
virhe: latauksen suorittaminen epäonnistui (odottamaton virhe)
Yhtään pakettia ei päivitetty tapahtuneiden virheiden vuoksi.
After reading up on the issue at ArchLinux Wiki, I attempted to
resolve the problem by refreshing the key database.
# pacman-key --init
# pacman-key --refresh
The last of these commands failed with the following output.
gpg: refreshing 91 keys from hkp://pool.sks-keyservers.net
gpg: keyserver refresh failed: No keyserver available
==> ERROR: A specified local key could not be updated from a keyserver.
I'm using Privoxy to supply an add-blocker to my Vimprobable browser.
I hope this does not prevent me from connecting to the key servers normally.
When I try to ping the key server, the server responds as expected.
Last edited by catnap (2017-06-01 11:57:38)
Offline
Please post error messages in English: https://wiki.archlinux.org/index.php/Co … s_and_code
Offline
I was eventually able to update the system after installing the keys from the package repository with
# pacman -S archlinux-keyring
This, however, does not solve the problem with
# pacman-key --refresh
which still gives the same error.
Please post error messages in English: https://wiki.archlinux.org/index.php/Co … s_and_code
I edited accordingly.
Offline
does something like gpg --search-keys abcdefghij work ?
The hkp protocol goes over http port 11371 , can you configure privoxy to let that port through ?
There are hkp servers that use port 80, maybe you can use one of them.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
does something like gpg --search-keys abcdefghij work ?
It gives the following result
gpg: no keyserver known (use option --keyserver)
gpg: keyserver search failed: No keyserver available
I also attempted to follow the instructions in https://wiki.archlinux.org/index.php/Pa … _via_proxy
by trying the commands
pacman-key --refresh-keys --keyserver hkp://keyserver.kjsl.com:80
pacman-key --refresh-keys --keyserver hkp://pgp.mit.edu:11371
pacman-key --refresh-keys --keyserver hkp://ipv4.pool.sks-keyservers.net:11371
with the following results
gpg: refreshing 91 keys from hkp://keyserver.kjsl.com:80
gpg: keyserver refresh failed: No keyserver available
==> ERROR: A specified local key could not be updated from a keyserver.
gpg: refreshing 91 keys from hkp://pgp.mit.edu:11371
gpg: keyserver refresh failed: No keyserver available
==> ERROR: A specified local key could not be updated from a keyserver.
gpg: refreshing 91 keys from hkp://ipv4.pool.sks-keyservers.net:11371
gpg: keyserver refresh failed: No keyserver available
==> ERROR: A specified local key could not be updated from a keyserver.
Offline
pacman-key uses gpg to verify signatures, and "gpg --search-keys" showed the problem is present when using gpg directly.
One gpg works, pacman-key should function automagickally so let's focus on troubleshooting gpg .
Post your /etc/gnupg/dirmngr.conf and /etc/pacman.d/gnupg/dirmngr.conf .
Verify they have the honor-http-proxy option set as mentioned in the wiki .
Check the debug-level sectiobn of man gpg , and run "gpg --search-keys" with the highest debug-level .
post the exact command and the output .
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
Post your /etc/gnupg/dirmngr.conf and /etc/pacman.d/gnupg/dirmngr.conf.
Verify they have the honor-http-proxy option set as mentioned in the wiki .
We seem to be close to isolating the problem. Those files do not exist. However
the file ~/.gnupg/dirmngr.conf exists and has the following content
keyserver hkp://jirk5u4osbsr34t5.onion
keyserver hkp://keys.gnupg.net
There were more lines, but in comments.
Check the debug-level sectiobn of man gpg , and run "gpg --search-keys" with the highest debug-level .
post the exact command and the output .
The command
gpg --debug-level guru --search-keys abc
gives the following output
gpg: DBG: [not enabled in the source] start
gpg: DBG: chan_3 <- # Home: /home/tommi/.gnupg
gpg: DBG: chan_3 <- # Config: /home/tommi/.gnupg/dirmngr.conf
gpg: DBG: chan_3 <- OK Dirmngr 2.1.21 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.1.21
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KS_SEARCH -- abc
gpg: DBG: chan_3 <- S PROGRESS tick ? 0 0
I worry that gpg expects the key search to be run without extra modifiers
because, after I specify the debug level, the program does not search the
keys but expects further input from the user.
Offline
Run gpg --debug-level guru --keyserver hkp://keys.gnupg.net --search-keys abcdefghij as root .
The reason for using abcdefghij as search term is that there's exactly 1 key that uses it on that specific keyserver network.
Below is the full output of that command ran on my main system.
# gpg --debug-level guru --keyserver hkp://keys.gnupg.net --search-keys abcdefghij
gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog
gpg: DBG: [not enabled in the source] start
gpg: DBG: chan_3 <- # Home: /root/.gnupg
gpg: DBG: chan_3 <- # Config: [none]
gpg: DBG: chan_3 <- OK Dirmngr 2.1.21 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.1.21
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KEYSERVER --clear hkp://keys.gnupg.net
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KS_SEARCH -- abcdefghij
gpg: DBG: chan_3 <- S SOURCE http://[2a03:b0c0:1:d0::18c2:6001]:11371
gpg: DBG: chan_3 <- D info:1:1%0Apub:6923CE7991ABF7338DB1C9AA5F0142A080E4A9A0:1:2048:1442278921::%0Auid:AbCdEfGhIj <Sagichbestimmtnet@t-online.de>:1442278921::%0A%0D%0A
gpg: data source: http://[2a03:b0c0:1:d0::18c2:6001]:11371
gpg: DBG: chan_3 <- OK
gpg: DBG: iobuf-1.0: close '?'
(1) AbCdEfGhIj <Sagichbestimmtnet@t-online.de>
2048 bit RSA key 5F0142A080E4A9A0, created: 2015-09-15
Keys 1-1 of 1 for "abcdefghij". Enter number(s), N)ext, or Q)uit > Q
gpg: error searching keyserver: Operation cancelled
gpg: keyserver search failed: Operation cancelled
gpg: DBG: chan_3 -> BYE
gpg: DBG: [not enabled in the source] stop
gpg: keydb: handles=0 locks=0 parse=0 get=0
gpg: build=0 update=0 insert=0 delete=0
gpg: reset=0 found=0 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=0 cached=0 good=0 bad=0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: secmem usage: 0/32768 bytes in 0 blocks
#
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
Run gpg --debug-level guru --keyserver hkp://keys.gnupg.net --search-keys abcdefghij as root .
This gives
gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog
gpg: DBG: [not enabled in the source] start
gpg: DBG: chan_3 <- # Home: /root/.gnupg
gpg: DBG: chan_3 <- # Config: [none]
gpg: DBG: chan_3 <- OK Dirmngr 2.1.21 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.1.21
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KEYSERVER --clear hkp://keys.gnupg.net
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KS_SEARCH -- abcdefghij
gpg: DBG: chan_3 <- ERR 167772346 No keyserver available <Dirmngr>
gpg: no keyserver known (use option --keyserver)
gpg: keyserver search failed: No keyserver available
gpg: DBG: chan_3 -> BYE
gpg: DBG: [not enabled in the source] stop
gpg: keydb: handles=0 locks=0 parse=0 get=0
gpg: build=0 update=0 insert=0 delete=0
gpg: reset=0 found=0 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=0 cached=0 good=0 bad=0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: secmem usage: 0/32768 bytes in 0 blocks
Offline
That is what i kinda expected, Dirmngr isn't able to contact the keyserver .
edit or create /etc/gnupg/dirmngr.conf and /etc/pacman.d/gnupg/dirmngr.conf .
Make sure they have the honor-http-proxy option set as mentioned in the wiki .
run "echo $http_proxy" to verify it points to your privoxy setup .
(if it's not set, just set it temporarily with export )
Then run the gpg debug-level command again and post output.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
Then run the gpg debug-level command again and post output.
The output was the same as before.
I believe to have ruled out one possible source of the problem because
disabling Privoxy had no effect.
systemctl status privoxy.service
privoxy.service - Privoxy Web Proxy With Advanced Filtering Capabilities
Loaded: loaded (/usr/lib/systemd/system/privoxy.service; disabled; vendor preset: disabled)
Active: inactive (dead)
After this I globally unset the http_proxy variable and tried
gpg --debug-level guru --keyserver hkp://keys.gnupg.net --search-keys abcdefghij
as before, and still received the same error messages
gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog
gpg: DBG: [not enabled in the source] start
gpg: DBG: chan_3 <- # Home: /root/.gnupg
gpg: DBG: chan_3 <- # Config: [none]
gpg: DBG: chan_3 <- OK Dirmngr 2.1.21 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.1.21
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KEYSERVER --clear hkp://keys.gnupg.net
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KS_SEARCH -- abcdefghij
gpg: DBG: chan_3 <- ERR 167772346 No keyserver available <Dirmngr>
gpg: no keyserver known (use option --keyserver)
gpg: keyserver search failed: No keyserver available
gpg: DBG: chan_3 -> BYE
gpg: DBG: [not enabled in the source] stop
gpg: keydb: handles=0 locks=0 parse=0 get=0
gpg: build=0 update=0 insert=0 delete=0
gpg: reset=0 found=0 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=0 cached=0 good=0 bad=0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: secmem usage: 0/32768 bytes in 0 blocks
It seems odd that the files /etc/gnupg/dirmngr.conf and /etc/pacman.d/gnupg/dirmngr.conf did not exist in my system before I created them. It might be worth the try to get these files from their standard packages. What packages should I (re)install?
Offline
There are no such default configuration files at all, since they are usually not needed.
/etc/pacman.d/gnupg is the $GNUPGHOME used internally by pacman-key, and /etc/gnupg AFAIK should not exist at all, because the gpg manpage doesn't indicate that GnuPG respects any system configurations whatsoever. dirmngr does seem to respect /etc/gnupg/trusted-certs though, which is of course totally different and as such has nothing to do with this thread.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
It seems that GPG simply does not find the specified servers with the DNS configuration because
ping hkp://keys.gnupg.net
gives
ping: hkp://keys.gnupg.net: Name or service not known
My DNS settings in /etc/resolv.conf are
# Generated by resolvconf
domain dhcp.inet.fi
nameserver 127.0.0.1
nameserver 193.210.18.18
nameserver 193.210.19.19
Last edited by catnap (2017-06-18 22:33:49)
Offline
hkp is not a protocol ping understands, so this has nothing to do with the problem.
Try a different keyserver, or check the recent gnupg connectivity bugs to see if one of the magic solutions works for you (because things have been somewhat unpredictable lately, fixing and then breaking again).
Last edited by eschwartz (2017-06-18 22:30:44)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Hello,
I also encountered the "virhe: key "XXXX" could not be looked up remotely", a friend of mine helped me through the issue:
1. I temporary bypassed the key check on pacman:
In /etc/pacman.conf
# By default, pacman accepts packages signed by keys that its local keyring
# trusts (see pacman-key and its man page), as well as unsigned packages.
SigLevel = Never
2. I updated my system:
pacman -Syu
3. Few hooks were broken (error: hook /usr/share/libalpm/hooks/XXX.hook line 2: invalid value Path)
I had to update pacman and relunch each hooks:
pacman -S pacman
pacman -S $(pacman -Qq)
note: my aur packager was also broken due to the python upgrade, I ended up by re-installing pikaur completely and run
pikaur -S $(pikaur -Qq)
)
4. Once updated, I reset the keyring to the default value in /etc/pacman.conf
(SigLevel = Required DatabaseOptional)
I hope it helps
Offline
Using this opportunity to close this old thread.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
Pages: 1
Topic closed