> I estimated that checking 270 packages will require at lease 30 minutes.
Estimated how?

> Wasn't so slow before.
Before what?

Before ... maybe a month ago.. the key and package integrity check was quite fast.
Then something happened and both steps require a lot to complete.
Unacceptable for me. I have a 1.7 ghz core i7.

estimated .. because I am still waiting. 90/270.. Maybe the estimate should be updated... It will take 1 hour at least.

> Then something happened
You'll have to be more specific than that. The last pacman release (and therefore code change) was in June.

How can I?
I changed the key server, changed the order of the mirrors, rebuilt the keyring (which resets the gpg.conf)
but no change.
And this behavior does not depend on the network. When I am at work and use a completely different network
the problem is the same.
Obviously when upgrading a package or two is not a big problem.

Ok, at 134/270 I choose to give up until a solution is found.. thanks for your quick answer and sorry for the many many typing
errors..

> How can I?
You're the one filing the bug report, so I would suspect that you're in the best place to debug this. Find out what exactly it hangs on -- gpg verification should be fast since it's essentially just comparing hashes.

I can't replicate this. On a VM with 181 packages installed, it takes me 75 seconds to reinstall all of them (validation and reinstall, no download).

I straced pacman -Suy

The latest pacman 4.1.2-4 was released on 21th october.
So maybe the "month" could be almost two monts...
Ill try to download the previous version

Which stage is this? "checking keys in keyring" or "checking package integrity"? The first should be instant...

[pid 6503] open("/dev/random", O_RDONLY) = 5
[pid 6503] fcntl(5, F_GETFD) = 0
[pid 6503] fcntl(5, F_SETFD, FD_CLOEXEC) = 0
[pid 6503] select(6, [5], NULL, NULL, {0, 100000}) = 0 (Timeout)
[pid 6503] write(7, "[GNUPG:] PROGRESS need_entropy X 0 16\n", 38) = 38
[pid 6482] <... select resumed> ) = 1 (in [5], left {0, 701522})
[pid 6503] select(6, [5], NULL, NULL, {3, 0} <unfinished ...>
[pid 6482] select(6, [5], [], NULL, {0, 0}) = 1 (in [5], left {0, 0})
[pid 6482] read(5, "[GNUPG:] PROGRESS need_entropy X 0 16\n", 1024) = 38

Why would reading a keyring require entropy?

This looks like a keyring issue. Run:

rm /etc/pacman.d/gnupg/*
pacman-key --init
pacman-key --populate archlinux

and see if this issue persists.

I think I found the reason.. the problem was due to the presence of the file /etc/gcrypt/fips_enabled
I noticed it in the strace just a few syscalls before the /dev/random open call. After the file removal
everything is fine again.

http://www.gnupg.org/documentation/manuals/gcrypt/Enabling-FIPS-mode.html

Maybe it was create for some reason and left there.


I am sorry if I wasted your time.

Thanks

pid 6505] fstat(0, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0
[pid 6505] fstat(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
[pid 6505] fstat(2, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0

[pid 6505] access("/etc/gcrypt/fips_enabled", F_OK) = 0
[pid 6505] open("/etc/gcrypt/fips_enabled", O_RDONLY) = 3 </b>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[pid 6505] fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
[pid 6505] mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2a9965e000
[pid 6505] read(3, "", 4096) = 0
[pid 6505] close(3) = 0
[pid 6505] munmap(0x7f2a9965e000, 4096) = 0
[pid 6505] getrlimit(RLIMIT_CORE, {rlim_cur=0, rlim_max=RLIM64_INFINITY}) = 0
[pid 6505] setrlimit(RLIMIT_CORE, {rlim_cur=0, rlim_max=RLIM64_INFINITY}) = 0
[pid 6505] rt_sigaction(SIGINT, NULL, {SIG_DFL, [], 0}, 8) = 0
[pid 6505] rt_sigaction(SIGINT, {0x472bd0, [], SA_RESTORER, 0x7f2a981b2450}, NULL, 8) = 0
[pid 6505] rt_sigaction(SIGHUP, NULL, {SIG_DFL, [], 0}, 8) = 0
[pid 6505] rt_sigaction(SIGHUP, {0x472bd0, [], SA_RESTORER, 0x7f2a981b2450}, NULL, 8) = 0
[pid 6505] rt_sigaction(SIGTERM, NULL, {SIG_DFL, [], 0}, 8) = 0
[pid 6505] rt_sigaction(SIGTERM, {0x472bd0, [], SA_RESTORER, 0x7f2a981b2450}, NULL, 8) = 0
[pid 6505] rt_sigaction(SIGQUIT, NULL, {SIG_DFL, [], 0}, 8) = 0
[pid 6505] rt_sigaction(SIGQUIT, {0x472bd0, [], SA_RESTORER, 0x7f2a981b2450}, NULL, 8) = 0
[pid 6505] rt_sigaction(SIGSEGV, NULL, {SIG_DFL, [], 0}, 8) = 0
[pid 6505] rt_sigaction(SIGSEGV, {0x472bd0, [], SA_RESTORER, 0x7f2a981b2450}, NULL, 8) = 0
[pid 6505] rt_sigaction(SIGUSR1, {0x472b60, [], SA_RESTORER, 0x7f2a981b2450}, NULL, 8) = 0
[pid 6505] rt_sigaction(SIGPIPE, {SIG_IGN, [], SA_RESTORER, 0x7f2a981b2450}, NULL, 8) = 0
[pid 6505] mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2a99657000
[pid 6505] getuid() = 0
[pid 6505] mlock(0x7f2a99657000, 32768) = 0
[pid 6505] access("/root/.gnupg/gpg.conf-2.0.22", R_OK) = -1 ENOENT (No such file or directory)
[pid 6505] access("/root/.gnupg/gpg.conf-2.0", R_OK) = -1 ENOENT (No such file or directory)
[pid 6505] access("/root/.gnupg/gpg.conf-2", R_OK) = -1 ENOENT (No such file or directory)
[pid 6505] access("/root/.gnupg/gpg.conf", R_OK) = -1 ENOENT (No such file or directory)
[pid 6505] access("/root/.gnupg/options", R_OK) = -1 ENOENT (No such file or directory)
[pid 6505] stat("~/.gnupg", 0x7fffe86b9340) = -1 ENOENT (No such file or directory)
[pid 6505] stat("/root/.gnupg/gpg.conf", 0x7fffe86b9340) = -1 ENOENT (No such file or directory)
[pid 6505] open("/root/.gnupg/gpg.conf", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 6505] fstat(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
[pid 6505] mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2a99656000
[pid 6505] open("/dev/random", O_RDONLY) = 3
[pid 6505] fcntl(3, F_GETFD) = 0
[pid 6505] fcntl(3, F_SETFD, FD_CLOEXEC) = 0

We could probably do better even in this configuration case:  FS#38042