Invalid signature, corrupt database #2058
Comments
|
In the Arch forum it was suggested that |
|
I think I have a similar issue, which I outlined here: msys2/MINGW-packages#6717. |
|
If i follow the guide from the homepage, the keyring verification fails see: https://ci.appveyor.com/project/lovetox/gajim/builds/34604241/job/6b9d0ab7m4925v56 |
|
@lovetox see msys2/msys2.github.io@49cb77c. Looks like pacman-key argument handling has changed some versions ago. |
|
Correct. The version shipped with appveyor takes just one argument, the signature: |
|
I was originally having this problem, but while I was writing this post, it got fixed, so I just post this for reference. I updated via Today I get this error, and I found this bug, and I'm trying to follow the steps: Previously, at this point, I restarted the MSYS2 terminal, and then ran Restarted MSYS2 terminal here - and now |
|
error: mingw32: key "4A6129F4E4B84AE46ED7F635628F528CF3053E04" is unknown I tried all of the option that you have suggested over here but none of it doesnt work for me |
|
|
please help me with this i just reinstalled msys2 just for it to worsen |
|
i686 msys2 installer was deprecatee since 22-05-2020, news link. You can use x86_64 installer if you've x86_64 OS. Also you can access mingw32 packages there. |
|
I tried to follow the The statement |
|
I have the same issue as @bardware, except if I try to run the
And I can't progress further? Any tips on what I can do to fix this? My /dev/fd is not a directory. |
|
I followed the steps by sdbbs and it works fine. |
|
after I followed all these steps and did an update I get lots of no idea if this is because of the steps or something else. Should I open a new issue? This is really annoying :( |
|
restarting windows should help (or close all msys2 processes, but restarting is easier) |
|
Thanks, I just did and indeed that fixed it. Sorry for the noise |
|
This useless link is mentioned in all tickets related to that failure with msys2 update (it doesn't work for me, not sure what I need to run, and I don't want to read that long poem). I've used msys2 for many years, have never had any problems, and this update with key is a huge failure imo. No clear answer what to run to make and update/upgrade. This should have been handled properly instead of breaking things for everybody. After running all possible commands mentioned all over the place, I still cannot update and get this error from running |
|
@pps83rbx
|
|
@dmn-star Perhaps something what you did would work for me also. |
Regarding keys, hypothetically speaking, we could've improved the upgrade path for irregularly updated installations, but it'd create complications for everyone. Given MSYS2 is a rolling release distro, I don't think it's unheard of to not support these installations 100 percent. |
Yes, it was intentional. I've created a "news" entry describing this including the fix for older installations (copied from @dmn-star). |
ghost
mentioned this issue
|
U-Boot Azure Windows build started to fail since yesterday (Jun 21, 2021) Switching to the latest installer (version 20210604) seems to fix it. |
Analysis of the problem'pacman-key --populate msys2' will not work, as the new package listing new packagers has not be installed (and can't be) due to key issues. Likewise, 'pacman-key --refresh-key' will do nothing, as it can't know who the new packagers are If adding keys manually to work around that, pacman-key will fail as the keyserver seems to default to a non working pool (hkps://hkps.pool.sks-keyservers.net): Adding hkp://pgp.mit.edu:11371 doesn't seem to work either Proposed workaroundIn 3 steps:
Step 1 : add the key manually Step 2: add a keyserver manually Step 3: refresh the keys manually What happensBefore: package installation or upgrade failed After: the temporary workaround allows the new key to be properly added: I believe this is sufficient to close this issue. |
|
It's not fixed. I tried about every workaround in this threat and I still get: error: wget: signature from "David Macek [email protected]" is unknown trust For 111 packages.... UPDATE: The only way for me to update was to disable signature checking entirely in pacman.conf. But even after pacman -Syu passed, re-enabling it still prevents me from installing any new packages. I'm out of ideas at this point. |
|
I was able to fix this by roughly following what @csdvrx proposed. But it felt wrong to just trust some key downloaded from somewhere (I'm talking about the First, this was the error I was getting when running The way I fixed it:
> wget "https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x87771331b3f1ff5263856a6d974c8be49078f532" -O key
> pacman-key -a key --gpgdir /etc/pacman.d/gnupg/
> echo "keyserver hkp://keyserver.ubuntu.com" >> /etc/pacman.d/gnupg/gpg.conf
> pacman-key --refresh-keysAfter this |
|
This worked! Thanks @wickedmic! |
This proposal updates INSTALL.md for the following: * stack comes with `msys2-20200903` * MSYS2 `pacman -Syu` has further keyring issues which can be overcome (msys2/MSYS2-packages#2058 (comment)) * The incorrect `hmatrix-gsl-0.19.0.1` is still the latest on Hackage (haskell-numerics#312) * Invoking `stack ghci` in the respository root folder fails, apparently because of a bug in GHC, but `stack ghci` works in the `tests` folder if an appropriate `stack.yaml` is created * The unit tests actually fail (haskell-numerics#333)
|
I did not get errors initially, but I've been having new packages fail to verify. The solution for me turned out to be |
When updating msys after ~8 months, the instructions from news + ^this actually helped! |
|
Sad to find my buildbot scripted automated test vm's started failing with this ridiculous trust error message from David Macek's key. How long is this going to be an issue without getting automatically resolved? It's literally the same dude's key from 2020 and here I am 2 full years later suddenly impacted by this exact issue. :( |
|
Googling the error, it redirects here. After doing The error still persists: Maybe 3 or 4 years ago, I've posted a workaround here to a different MSYS error preventing me to upgrade the system. The exact same workaround works with this one:
Now everything should be working. Hope it helps. |
|
This is not an issue anymore. Workaround available ☝️ |
I had that same problem, what worked for me was to uninstall Ruby, then went and download a fresh copy of Ruby 3.1.1 with devkit installer, when I installed it, I did not get any errors and its working fine. I am using windows 10(without WSL) and Ruby 3.1.1 with Ruby on Rails version 7.0.4. |
|
Funny enough, got the same issue again after I don't know how many months of not using my msys2. The same old |
|
thanks！ It did help. |
|
I had this issue on multiple fresh installs of MSYS2 a couple days ago while trying to build the MinGW64 toolchain. It kept hanging while trying to update a package just called msys I think, forcing me to close the terminal, at which point MSYS2 seemingly corrupted and refused to recognize any signatures from thereon out. The problem persisted even with antivirus disabled. The advice to populate keys, refresh keys, use the config trick, reset the pacman key store etc. did nothing. After uninstalling and reinstalling MSYS2 about 4-5 times, the only way I was able to somehow dodge the problem was to throw the commands listed here at the wall and hope they stuck. (I'm a new user, no experience with Arch Linux or pacman.) |
and others
The text was updated successfully, but these errors were encountered: