[arch-general] libgcrypt.so.20 missing
Salutations!
After an upgrade of my entire system, I am now unable to install
packages or run any programs that depend on libgcrypt. I get the
following error : libgrypt.so.20 not found.
Looking at my pacman logs it seems that This error appeared after an
update to pth (2.0.7-4 -> 2.0.7-5). I've downgraded the package but it
doesn't seem to solve the issue.
Regards,
Mark
--
Mark E. Lee
On 01/13/2014 07:08 PM, Mark E. Lee wrote:
Salutations!
After an upgrade of my entire system, I am now unable to install packages or run any programs that depend on libgcrypt. I get the following error : libgrypt.so.20 not found.
Looking at my pacman logs it seems that This error appeared after an update to pth (2.0.7-4 -> 2.0.7-5). I've downgraded the package but it doesn't seem to solve the issue.
Regards, Mark
libgcrypt.so.20 is part of libgcrypt-1.6.0 which is in [core]. I believe it has been moved there recently, so try to run pacman -Syu again. -- Note: My last name is not Krejzi.
On Mon, 2014-01-13 at 19:13 +0100, Armin K. wrote:
On 01/13/2014 07:08 PM, Mark E. Lee wrote:
Salutations!
After an upgrade of my entire system, I am now unable to install packages or run any programs that depend on libgcrypt. I get the following error : libgrypt.so.20 not found.
Looking at my pacman logs it seems that This error appeared after an update to pth (2.0.7-4 -> 2.0.7-5). I've downgraded the package but it doesn't seem to solve the issue.
Regards, Mark
libgcrypt.so.20 is part of libgcrypt-1.6.0 which is in [core]. I believe it has been moved there recently, so try to run pacman -Syu again.
Salutations,
The update to libgcrypt-1.6.0 has fixed the issue.
However, I suggest an announcement on the website regarding this
problem. I had three issues when trying to solve this problem:
1) the mirror I was using wasn't up to date (still had
libgcrypt-1.5.3-1)
2) I can't run 'pacman -Syu' after upgrading all the other packages that
relied on libgcrypt since my gpg keys were broken due to the missing
libgcrypt.so.20. Hence, libgcrypt-1.6.0 should be pulled first before
updating any other package that relies on it.
3) Failure to update libgcrypt before other packages resulted in a
kernel that seemed to be hung at booting.
Regards,
Mark
--
Mark E. Lee
Am 13.01.2014 19:33, schrieb Mark E. Lee:
However, I suggest an announcement on the website regarding this problem.
No.
I had three issues when trying to solve this problem: 1) the mirror I was using wasn't up to date (still had libgcrypt-1.5.3-1)
You see, that is impossible. The package database contains either both the old pth and old libgcrypt, or both the new pth and new libgcrypt.
3) Failure to update libgcrypt before other packages resulted in a kernel that seemed to be hung at booting.
Sorry, I can't see how that would be related in any way.
On Mon, 2014-01-13 at 20:08 +0100, Thomas Bächler wrote:
Am 13.01.2014 19:33, schrieb Mark E. Lee:
However, I suggest an announcement on the website regarding this problem.
No.
I had three issues when trying to solve this problem: 1) the mirror I was using wasn't up to date (still had libgcrypt-1.5.3-1)
You see, that is impossible. The package database contains either both the old pth and old libgcrypt, or both the new pth and new libgcrypt.
3) Failure to update libgcrypt before other packages resulted in a kernel that seemed to be hung at booting.
Sorry, I can't see how that would be related in any way.
Salutations,
pth is not related in this case. I've updated several more systems, this
time libgcrypt first and found that I couldn't update subsequent
packages. The machine failed to reboot by software and I had to hard
reset. Upon resetting, I was left with a hung kernel again.
The reason why packages couldn't upgrade was because of gnupg which is
needed for package signature verification from pacman. An updated gnupg
points to libgcrypt.so.20 while the old one points to libgcrypt.so.11.
Hence, what has to be done is gnupg must be updated before libgcrypt (or
else signature verification fails). Libgcrypt must be updated before the
system is rebooted or else gnupg fails.
Hence, an advisory should be sent out that gnupg should be updated
before libgcrypt, and libgcrypt should be updated before the system's
ever rebooted.
Regards,
Mark
--
Mark Lee
On Mon, 2014-01-13 at 14:19 -0500, Mark Lee wrote:
On Mon, 2014-01-13 at 20:08 +0100, Thomas Bächler wrote:
Am 13.01.2014 19:33, schrieb Mark E. Lee:
However, I suggest an announcement on the website regarding this problem.
No.
I had three issues when trying to solve this problem: 1) the mirror I was using wasn't up to date (still had libgcrypt-1.5.3-1)
You see, that is impossible. The package database contains either both the old pth and old libgcrypt, or both the new pth and new libgcrypt.
3) Failure to update libgcrypt before other packages resulted in a kernel that seemed to be hung at booting.
Sorry, I can't see how that would be related in any way.
Salutations,
pth is not related in this case. I've updated several more systems, this time libgcrypt first and found that I couldn't update subsequent packages. The machine failed to reboot by software and I had to hard reset. Upon resetting, I was left with a hung kernel again.
The reason why packages couldn't upgrade was because of gnupg which is needed for package signature verification from pacman. An updated gnupg points to libgcrypt.so.20 while the old one points to libgcrypt.so.11. Hence, what has to be done is gnupg must be updated before libgcrypt (or else signature verification fails). Libgcrypt must be updated before the system is rebooted or else gnupg fails.
Hence, an advisory should be sent out that gnupg should be updated before libgcrypt, and libgcrypt should be updated before the system's ever rebooted.
Regards, Mark
Salutations,
Actually scratch that, one should install gnupg 2.0.22-2 and libgcrypt
1.6.0-1 simultaneously (same pacman line) before trying to install other
things.
Regards,
Mark
--
Mark Lee
Am 13.01.2014 20:34, schrieb Mark Lee:
On Mon, 2014-01-13 at 14:19 -0500, Mark Lee wrote:
The reason why packages couldn't upgrade was because of gnupg which is needed for package signature verification from pacman. An updated gnupg points to libgcrypt.so.20 while the old one points to libgcrypt.so.11. Hence, what has to be done is gnupg must be updated before libgcrypt (or else signature verification fails). Libgcrypt must be updated before the system is rebooted or else gnupg fails.
Hence, an advisory should be sent out that gnupg should be updated before libgcrypt, and libgcrypt should be updated before the system's ever rebooted.
Salutations,
Actually scratch that, one should install gnupg 2.0.22-2 and libgcrypt 1.6.0-1 simultaneously (same pacman line) before trying to install other things.
That is all nonsense. Everything must be updated in a single transaction using `pacman -Syu`. This has been done by countless [testing] users in December without a single reported problem.
On Mon 13 Jan 2014 at 10:42:47PM +0100, Thomas Bächler wrote:
Am 13.01.2014 20:34, schrieb Mark Lee:
Salutations,
Actually scratch that, one should install gnupg 2.0.22-2 and libgcrypt 1.6.0-1 simultaneously (same pacman line) before trying to install other things.
That is all nonsense. Everything must be updated in a single transaction using `pacman -Syu`. This has been done by countless [testing] users in December without a single reported problem.
There is a problem: root# pacman -Sy; pacman -Ss | grep 'core/gnupg\|core/libgcrypt' :: Synchronizing package databases... core is up to date extra is up to date community is up to date multilib is up to date core/gnupg 2.0.22-2 [installed: 2.0.22-1] core/libgcrypt 1.5.3-1 [installed] guns
On Mon, 2014-01-13 at 22:42 +0100, Thomas Bächler wrote:
Am 13.01.2014 20:34, schrieb Mark Lee:
On Mon, 2014-01-13 at 14:19 -0500, Mark Lee wrote:
The reason why packages couldn't upgrade was because of gnupg which is needed for package signature verification from pacman. An updated gnupg points to libgcrypt.so.20 while the old one points to libgcrypt.so.11. Hence, what has to be done is gnupg must be updated before libgcrypt (or else signature verification fails). Libgcrypt must be updated before the system is rebooted or else gnupg fails.
Hence, an advisory should be sent out that gnupg should be updated before libgcrypt, and libgcrypt should be updated before the system's ever rebooted.
Salutations,
Actually scratch that, one should install gnupg 2.0.22-2 and libgcrypt 1.6.0-1 simultaneously (same pacman line) before trying to install other things.
That is all nonsense. Everything must be updated in a single transaction using `pacman -Syu`. This has been done by countless [testing] users in December without a single reported problem.
Salutations,
All right then; if it works for you guys. Will an announcement be made
on the arch website to ensure the upgrade doesn't break more systems or
will we continue the wait game and hope that all the mirrors sync and
the issue just goes away?
Regards,
Mark
--
Mark Lee
Am 13.01.2014 22:48, schrieb Mark Lee:
Salutations,
All right then; if it works for you guys. Will an announcement be made on the arch website to ensure the upgrade doesn't break more systems or will we continue the wait game and hope that all the mirrors sync and the issue just goes away?
As Lukas pointed out by now, a mistake was made when moving the packages, and libgcrypt was moved 20 minutes after the rest of the packages. Any mirror that synced in that timeframe will have an inconsistent state. There is no point in announcing anything, since all mirrors should have the corrected files already, and whoever didn't break their systems by now won't break them.
On Mon, 2014-01-13 at 22:52 +0100, Thomas Bächler wrote:
Am 13.01.2014 22:48, schrieb Mark Lee:
Salutations,
All right then; if it works for you guys. Will an announcement be made on the arch website to ensure the upgrade doesn't break more systems or will we continue the wait game and hope that all the mirrors sync and the issue just goes away?
As Lukas pointed out by now, a mistake was made when moving the packages, and libgcrypt was moved 20 minutes after the rest of the packages. Any mirror that synced in that timeframe will have an inconsistent state.
There is no point in announcing anything, since all mirrors should have the corrected files already, and whoever didn't break their systems by now won't break them.
Salutations,
I checked and the mirror's now updated with the right packages for me. I
still think an announcement should be made to beware of this issue and
the appropriate fix, but it's not my decision.
Regards,
Mark
--
Mark Lee
On 13.01.2014 22:52, Thomas Bächler wrote:
Am 13.01.2014 22:48, schrieb Mark Lee:
Salutations,
All right then; if it works for you guys. Will an announcement be made on the arch website to ensure the upgrade doesn't break more systems or will we continue the wait game and hope that all the mirrors sync and the issue just goes away?
As Lukas pointed out by now, a mistake was made when moving the packages, and libgcrypt was moved 20 minutes after the rest of the packages. Any mirror that synced in that timeframe will have an inconsistent state.
There is no point in announcing anything, since all mirrors should have the corrected files already, and whoever didn't break their systems by now won't break them.
I've had the problem on both my Arch computers. I'll have to manually install libgcrypt-1.6.0-1 now without checking its signature. Which is a bit scary :) Can anyone confirm the checksum of the 32bit package file? I used sha512sum /var/cache/pacman/pkg/libgcrypt-1.6.0-1-i686.pkg.tar.xz eb4344f7a5602aa061575b2014abea21eb20c395f063d24904c914ea49ffaaa3cb31023b17ed2221bdd483676bd15194a0df748a6914d74cfaec8d76274d1036 -- damjan
I confirm
[killruana@fanstasmic tmp]$ gpg --verify
libgcrypt-1.6.0-1-i686.pkg.tar.xz.sig
gpg: Signature made Mon Dec 16 23:30:48 2013 CET using RSA key ID 0F2A092B
gpg: Good signature from "Andreas Radke
On 13.01.2014 22:52, Thomas Bächler wrote:
Am 13.01.2014 22:48, schrieb Mark Lee:
Salutations,
All right then; if it works for you guys. Will an announcement be made on the arch website to ensure the upgrade doesn't break more systems or will we continue the wait game and hope that all the mirrors sync and the issue just goes away?
As Lukas pointed out by now, a mistake was made when moving the packages, and libgcrypt was moved 20 minutes after the rest of the packages. Any mirror that synced in that timeframe will have an inconsistent state.
There is no point in announcing anything, since all mirrors should have the corrected files already, and whoever didn't break their systems by now won't break them.
I've had the problem on both my Arch computers.
I'll have to manually install libgcrypt-1.6.0-1 now without checking its signature. Which is a bit scary :)
Can anyone confirm the checksum of the 32bit package file? I used sha512sum /var/cache/pacman/pkg/libgcrypt-1.6.0-1-i686.pkg.tar.xz
eb4344f7a5602aa061575b2014abea21eb20c395f063d24904c914ea49ffaaa3cb31023b17ed2221bdd483676bd15194a0df748a6914d74cfaec8d76274d1036
On 14/01/14 22:13, Damjan wrote:
On 13.01.2014 22:52, Thomas Bächler wrote:
Am 13.01.2014 22:48, schrieb Mark Lee:
Salutations,
All right then; if it works for you guys. Will an announcement be made on the arch website to ensure the upgrade doesn't break more systems or will we continue the wait game and hope that all the mirrors sync and the issue just goes away?
As Lukas pointed out by now, a mistake was made when moving the packages, and libgcrypt was moved 20 minutes after the rest of the packages. Any mirror that synced in that timeframe will have an inconsistent state.
There is no point in announcing anything, since all mirrors should have the corrected files already, and whoever didn't break their systems by now won't break them.
I've had the problem on both my Arch computers.
I'll have to manually install libgcrypt-1.6.0-1 now without checking its signature. Which is a bit scary :)
Can anyone confirm the checksum of the 32bit package file? I used sha512sum /var/cache/pacman/pkg/libgcrypt-1.6.0-1-i686.pkg.tar.xz
eb4344f7a5602aa061575b2014abea21eb20c395f063d24904c914ea49ffaaa3cb31023b17ed2221bdd483676bd15194a0df748a6914d74cfaec8d76274d1036
"pacman -S libgcrypt" will verify the package in your cache before reinstalling.
On вто, 14 јан 2014 13:26:15 CET, Allan McRae wrote:
On 14/01/14 22:13, Damjan wrote:
On 13.01.2014 22:52, Thomas Bächler wrote:
Am 13.01.2014 22:48, schrieb Mark Lee:
Salutations,
All right then; if it works for you guys. Will an announcement be made on the arch website to ensure the upgrade doesn't break more systems or will we continue the wait game and hope that all the mirrors sync and the issue just goes away?
As Lukas pointed out by now, a mistake was made when moving the packages, and libgcrypt was moved 20 minutes after the rest of the packages. Any mirror that synced in that timeframe will have an inconsistent state.
There is no point in announcing anything, since all mirrors should have the corrected files already, and whoever didn't break their systems by now won't break them.
I've had the problem on both my Arch computers.
I'll have to manually install libgcrypt-1.6.0-1 now without checking its signature. Which is a bit scary :)
Can anyone confirm the checksum of the 32bit package file? I used sha512sum /var/cache/pacman/pkg/libgcrypt-1.6.0-1-i686.pkg.tar.xz
eb4344f7a5602aa061575b2014abea21eb20c395f063d24904c914ea49ffaaa3cb31023b17ed2221bdd483676bd15194a0df748a6914d74cfaec8d76274d1036
"pacman -S libgcrypt" will verify the package in your cache before reinstalling.
at that point it's too late. but ok, I'm not that paranoid -- дамјан
Even though the root of this problem only lasted for 20 minutes, the effect could be felt later as well, due to mirrors lagging behind. The problem may be fixed now, but I think a news item would be in order, since people rely on it for information about problems that could arise when upgrading packages. The effects of this broke pacman on three Arch Linux installations I administer, one of them was the day after the incident. I think this should be on the front page. Not because it will will help many users right now, but because of the trustworthiness of the front page. -- Sincerely, Alexander Rødseth xyproto / TU
On Mon, 2014-01-13 at 20:08 +0100, Thomas Bächler wrote:
Am 13.01.2014 19:33, schrieb Mark E. Lee:
However, I suggest an announcement on the website regarding this problem.
No.
I had three issues when trying to solve this problem: 1) the mirror I was using wasn't up to date (still had libgcrypt-1.5.3-1)
You see, that is impossible. The package database contains either both the old pth and old libgcrypt, or both the new pth and new libgcrypt.
3) Failure to update libgcrypt before other packages resulted in a kernel that seemed to be hung at booting.
Sorry, I can't see how that would be related in any way.
Salutations,
Regarding your package database argument; here's the output of pacman -S
libgcrypt :
----
core/libgcrypt 1.5.3-1 [installed: 1.6.0-1]
General purpose cryptographic library based on the code from GnuPG
Here's the output of pacman -S pth :
----
core/pth 2.0.7-5 [installed]
The GNU Portable Threads.
Here's my mirrorlist :
-----
Server = http://mirror.umd.edu/archlinux/$repo/os/$arch
Server = http://mirrors.rutgers.edu/archlinux/$repo/os/$arch
Server = http://mirror.us.leaseweb.net/archlinux/$repo/os/$arch
Server = http://mirrors.gigenet.com/archlinux/$repo/os/$arch
Server = http://mirror.nexcess.net/archlinux/$repo/os/$arch
Server = http://mirrors.liquidweb.com/archlinux/$repo/os/$arch
Server = http://mirror.rit.edu/archlinux/$repo/os/$arch
Server = http://arch.mirror.constant.com/$repo/os/$arch
Server = http://ord.mirror.rackspace.com/archlinux/$repo/os/$arch
Server = http://cosmos.cites.illinois.edu/pub/archlinux/$repo/os/$arch
Server =
http://mirror.cc.columbia.edu/pub/linux/archlinux/$repo/os/$arch
Server = http://mirror.vtti.vt.edu/archlinux/$repo/os/$arch
Server = http://mirrors.aggregate.org/archlinux/$repo/os/$arch
Server = http://mirrors.cecsresearch.org/archlinux/$repo/os/$arch
Server = http://lug.mtu.edu/archlinux/$repo/os/$arch
Server = http://dfw.mirror.rackspace.com/archlinux/$repo/os/$arch
Server = http://mirrors.xmission.com/archlinux/$repo/os/$arch
Server = http://archlinux.surlyjake.com/archlinux/$repo/os/$arch
Server = http://cake.lib.fit.edu/archlinux/$repo/os/$arch
Server = http://mirrors.cat.pdx.edu/archlinux/$repo/os/$arch
Server = http://mirrors.lax1.thegcloud.com/arch/$repo/os/$arch
Server = http://mirrors.kernel.org/archlinux/$repo/os/$arch
Server = http://ftp.osuosl.org/pub/archlinux/$repo/os/$arch
Server = http://mirror.metrocast.net/archlinux/$repo/os/$arch
Server = http://www.gtlib.gatech.edu/pub/archlinux/$repo/os/$arch
Server = http://mirror.ancl.hawaii.edu/linux/archlinux/$repo/os/$arch
Server = http://mirror.jmu.edu/pub/archlinux/$repo/os/$arch
------
Clearly we have new pth and old libgcrypt; but as I stated that's not
the serious issue.
Regards,
Mark
--
Mark Lee
On Mon 13 Jan 2014 at 08:08:47PM +0100, Thomas Bächler wrote:
Am 13.01.2014 19:33, schrieb Mark E. Lee:
I had three issues when trying to solve this problem: 1) the mirror I was using wasn't up to date (still had libgcrypt-1.5.3-1)
You see, that is impossible. The package database contains either both the old pth and old libgcrypt, or both the new pth and new libgcrypt.
Regardless of whether this should be impossible, I have the same problem as OP: core/libgcrypt 1.5.3-1 [installed] General purpose cryptographic library based on the code from GnuPG core/gnupg 2.0.22-2 [installed: 2.0.22-1] Complete and free implementation of the OpenPGP standard core/cryptsetup 1.6.3-2 (base) [installed] Userspace setup tool for transparent encryption of block devices using dm-crypt Note that the versions of gnupg and cryptsetup above are linked against libgcrypt.so.20, which is not provided by 1.5.3-1. (I had to downgrade gnupg to write this message).
3) Failure to update libgcrypt before other packages resulted in a kernel that seemed to be hung at booting.
Sorry, I can't see how that would be related in any way.
This happens if a user has the `encrypt` hook set in their mkinitcpio.conf, but their /usr/lib/libcryptsetup.so is linked against a libgcrypt that they do not yet have: [2014-01-13 12:59] [ALPM-SCRIPTLET] >>> Updating module dependencies. Please wait ... [2014-01-13 12:59] [ALPM-SCRIPTLET] >>> Generating initial ramdisk, using mkinitcpio. Please wait... [2014-01-13 12:59] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default' [2014-01-13 12:59] [ALPM-SCRIPTLET] -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img [2014-01-13 12:59] [ALPM-SCRIPTLET] ==> Starting build: 3.12.7-2-ARCH [2014-01-13 12:59] [ALPM-SCRIPTLET] -> Running build hook: [base] [2014-01-13 12:59] [ALPM-SCRIPTLET] -> Running build hook: [udev] [2014-01-13 12:59] [ALPM-SCRIPTLET] -> Running build hook: [autodetect] [2014-01-13 12:59] [ALPM-SCRIPTLET] -> Running build hook: [modconf] [2014-01-13 12:59] [ALPM-SCRIPTLET] -> Running build hook: [block] [2014-01-13 12:59] [ALPM-SCRIPTLET] -> Running build hook: [keyboard] [2014-01-13 12:59] [ALPM-SCRIPTLET] -> Running build hook: [encrypt] [2014-01-13 12:59] [ALPM-SCRIPTLET] ==> ERROR: binary dependency `libgcrypt.so.20' not found for `cryptsetup' guns
On Mon, 2014-01-13 at 14:10 -0600, guns wrote:
On Mon 13 Jan 2014 at 08:08:47PM +0100, Thomas Bächler wrote:
Am 13.01.2014 19:33, schrieb Mark E. Lee:
I had three issues when trying to solve this problem: 1) the mirror I was using wasn't up to date (still had libgcrypt-1.5.3-1)
You see, that is impossible. The package database contains either both the old pth and old libgcrypt, or both the new pth and new libgcrypt.
Regardless of whether this should be impossible, I have the same problem as OP:
core/libgcrypt 1.5.3-1 [installed] General purpose cryptographic library based on the code from GnuPG core/gnupg 2.0.22-2 [installed: 2.0.22-1] Complete and free implementation of the OpenPGP standard core/cryptsetup 1.6.3-2 (base) [installed] Userspace setup tool for transparent encryption of block devices using dm-crypt
Note that the versions of gnupg and cryptsetup above are linked against libgcrypt.so.20, which is not provided by 1.5.3-1. (I had to downgrade gnupg to write this message).
3) Failure to update libgcrypt before other packages resulted in a kernel that seemed to be hung at booting.
Sorry, I can't see how that would be related in any way.
This happens if a user has the `encrypt` hook set in their mkinitcpio.conf, but their /usr/lib/libcryptsetup.so is linked against a libgcrypt that they do not yet have:
[2014-01-13 12:59] [ALPM-SCRIPTLET] >>> Updating module dependencies. Please wait ... [2014-01-13 12:59] [ALPM-SCRIPTLET] >>> Generating initial ramdisk, using mkinitcpio. Please wait... [2014-01-13 12:59] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default' [2014-01-13 12:59] [ALPM-SCRIPTLET] -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img [2014-01-13 12:59] [ALPM-SCRIPTLET] ==> Starting build: 3.12.7-2-ARCH [2014-01-13 12:59] [ALPM-SCRIPTLET] -> Running build hook: [base] [2014-01-13 12:59] [ALPM-SCRIPTLET] -> Running build hook: [udev] [2014-01-13 12:59] [ALPM-SCRIPTLET] -> Running build hook: [autodetect] [2014-01-13 12:59] [ALPM-SCRIPTLET] -> Running build hook: [modconf] [2014-01-13 12:59] [ALPM-SCRIPTLET] -> Running build hook: [block] [2014-01-13 12:59] [ALPM-SCRIPTLET] -> Running build hook: [keyboard] [2014-01-13 12:59] [ALPM-SCRIPTLET] -> Running build hook: [encrypt] [2014-01-13 12:59] [ALPM-SCRIPTLET] ==> ERROR: binary dependency `libgcrypt.so.20' not found for `cryptsetup'
guns
Salutations,
I don't have encrypt in my mkinitcpio hooks.
Regards,
Mark
--
Mark Lee
On Mon 13 Jan 2014 at 03:12:33PM -0500, Mark Lee wrote:
I don't have encrypt in my mkinitcpio hooks.
Regardless, the sync state of the mirrors we pulled from are inconsistent. In my case, my top mirrors are all listed under "Successfully Syncing Mirrors" with 100% completion at https://www.archlinux.org/mirrors/status/ guns
On Mon, 2014-01-13 at 14:30 -0600, guns wrote:
On Mon 13 Jan 2014 at 03:12:33PM -0500, Mark Lee wrote:
I don't have encrypt in my mkinitcpio hooks.
Regardless, the sync state of the mirrors we pulled from are inconsistent. In my case, my top mirrors are all listed under "Successfully Syncing Mirrors" with 100% completion at https://www.archlinux.org/mirrors/status/
guns
Salutations,
How are the mirrors currently checked for completion? Does it compare
checksums of a list of packages on the mirror?
Regards,
Mark
--
Mark Lee
On Mon, 13 Jan 2014 at 21:30:53, guns wrote:
On Mon 13 Jan 2014 at 03:12:33PM -0500, Mark Lee wrote:
I don't have encrypt in my mkinitcpio hooks.
Regardless, the sync state of the mirrors we pulled from are inconsistent. In my case, my top mirrors are all listed under "Successfully Syncing Mirrors" with 100% completion at https://www.archlinux.org/mirrors/status/
guns
Mh, libgcrypt was moved separately [1] quite some time after the other packages [2] have been migrated from [testing]. So I it think it is a "packaging" issue, not a mirror issue. [1] https://projects.archlinux.org/svntogit/packages.git/commit/?id=2646d69 [2] https://projects.archlinux.org/svntogit/packages.git/commit/?id=11f6154
On 2014-01-13 02:10, guns wrote:
On Mon 13 Jan 2014 at 08:08:47PM +0100, Thomas Bächler wrote:
Am 13.01.2014 19:33, schrieb Mark E. Lee:
3) Failure to update libgcrypt before other packages resulted in a kernel that seemed to be hung at booting.
Sorry, I can't see how that would be related in any way.
This happens if a user has the `encrypt` hook set in their mkinitcpio.conf, but their /usr/lib/libcryptsetup.so is linked against a libgcrypt that they do not yet have:
I've got the same problem after -Syu: ==> ERROR: binary dependency `libgcrypt.so.11' not found for `cryptsetup' Doing -Syu again: error: GPGME error: No data [...] error: database 'community' is not valid (invalid or corrupted database (PGP signature)) With SigLevel = None I get many lines like error: could not open file /var/lib/pacman/sync/community.db: Unrecognized archive format This is a *real* problem. Can anybody provide me with some info on how this may be solvable? LG basti
On 2014-01-13 10:06, Sebastian Lipp wrote:
On 2014-01-13 02:10, guns wrote:
On Mon 13 Jan 2014 at 08:08:47PM +0100, Thomas Bächler wrote:
Am 13.01.2014 19:33, schrieb Mark E. Lee:
3) Failure to update libgcrypt before other packages resulted in a kernel that seemed to be hung at booting.
Sorry, I can't see how that would be related in any way.
This happens if a user has the `encrypt` hook set in their mkinitcpio.conf, but their /usr/lib/libcryptsetup.so is linked against a libgcrypt that they do not yet have:
I've got the same problem after -Syu:
==> ERROR: binary dependency `libgcrypt.so.11' not found for `cryptsetup'
Okay, mkinitcpio seems fine again, but said pacman problems remain.
Doing -Syu again:
error: GPGME error: No data [...] error: database 'community' is not valid (invalid or corrupted database (PGP signature))
With SigLevel = None I get many lines like
error: could not open file /var/lib/pacman/sync/community.db: Unrecognized archive format
This is a *real* problem. Can anybody provide me with some info on how this may be solvable?
LG basti
On 2014-01-13 10:17, Sebastian Lipp wrote:
On 2014-01-13 10:06, Sebastian Lipp wrote:
On 2014-01-13 02:10, guns wrote:
On Mon 13 Jan 2014 at 08:08:47PM +0100, Thomas Bächler wrote:
Am 13.01.2014 19:33, schrieb Mark E. Lee:
3) Failure to update libgcrypt before other packages resulted in a kernel that seemed to be hung at booting.
Sorry, I can't see how that would be related in any way.
This happens if a user has the `encrypt` hook set in their mkinitcpio.conf, but their /usr/lib/libcryptsetup.so is linked against a libgcrypt that they do not yet have:
I've got the same problem after -Syu:
==> ERROR: binary dependency `libgcrypt.so.11' not found for `cryptsetup'
Okay, mkinitcpio seems fine again, but said pacman problems remain.
Forget it, I'm back up again. Sorry for the Noise basti
On Mon, 2014-01-13 at 20:08 +0100, Thomas Bächler wrote:
Am 13.01.2014 19:33, schrieb Mark E. Lee:
However, I suggest an announcement on the website regarding this problem.
No.
I had three issues when trying to solve this problem: 1) the mirror I was using wasn't up to date (still had libgcrypt-1.5.3-1)
You see, that is impossible. The package database contains either both the old pth and old libgcrypt, or both the new pth and new libgcrypt.
3) Failure to update libgcrypt before other packages resulted in a kernel that seemed to be hung at booting.
Sorry, I can't see how that would be related in any way.
Salutations, See the follow message board lists for people experiencing this error (if you didn't believe it existed) : https://bbs.archlinux.org/viewtopic.php?id=175640 https://bbs.archlinux.org/viewtopic.php?pid=1370454#p1370454 https://bbs.archlinux.org/viewtopic.php?id=175639 https://bbs.archlinux.org/viewtopic.php?id=174808 https://bbs.archlinux.org/viewtopic.php?id=175643 Regards, Mark
participants (11)
-
Alexander Rødseth
-
Allan McRae
-
Armin K.
-
Damjan
-
guns
-
killruana
-
Lukas Fleischer
-
Mark E. Lee
-
Mark Lee
-
Sebastian Lipp
-
Thomas Bächler