8

I have tried deleting my .gnupg directory but the error returns.

I get this:

gpg: lookup_hashtable failed: eof
gpg: lookup_hashtable failed: eof
gpg: upd_hashtable: read failed: eof
gpg: trust record 2, type 12: write failed: eof
gpg: Error: The trustdb is corrupted.
gpg: You may try to re-create the trustdb using the commands:
gpg:   cd ~/.gnupg
gpg:   gpg2 --export-ownertrust > otrust.tmp
gpg:   rm trustdb.gpg
gpg:   gpg2 --import-ownertrust < otrust.tmp
gpg: If that does not work, please consult the manual

I tried following the advice thrown out by the error and that doesn't work either. Tried Googling the problem but nothing comes up for "lookup_hastable".

I also installed seahorse and have my ssh keys stored in seahorse. Could there be confict going on with seahorse?

I'm running gpg --gen-key from my normal user account and not trying to do anything fancy: just create a standard gpg key.

  • did you follow the instruction from the error message? – Timothy Truckle Jan 2 '17 at 11:42
  • 1
    What version of GnuPG is this? Is there an instance of gpg-agent running that is interfering, and that might need to be killed? – Kusalananda Jan 2 '17 at 11:47
  • 2
    Run gpg --fix-trustdb – GAD3R Jan 2 '17 at 12:01
  • 1
    I did have gpg-agent running. I killed it and tried to create another key: same problem. Then I deleted my ~/.gnupg directory and it works! I am going to try rebooting to see if gpg-agent comes back to stop me again. Thanks! – bitofagoob Jan 2 '17 at 12:01
  • 2
    gpg-agent will automatically start when doing key operations with GnuPG 2.1, as it should do. The problem was either that you're using two different versions of GnuPG at once, or that something else modified the contents of the .gnupg directory in such a way that gpg-agent got confused. When deleting the .gnupg directory, the running gpg-agent was unaware of it. That's very much a "hand waving" type of explanation. – Kusalananda Jan 2 '17 at 12:13
2

I faced a similar issue with lookup_hashtable failing due to Unknown system error instead.

I figured it happened after importing a private key through gpg (and not gpg2) using gpg --allow-secret-key-import --import private.key

After setting trust level following this post, the error was gone.

  • Thanks, it helped! I think as part of commands it is using rm which fails if it is interactive "rm -i" – kumar Mar 15 at 8:24
0

I had the same problem. What is important to realize, is that there are two main versions of GnuPG ('classic' and 'stable', and also there is a 'modern' 2.1): gpg and gpg2 (on Fedora Core they are provided by packages gnupg and gnupg2 respectively).

I searched the Internet about trustdb extensively, removed ~/.gnupg, but could find very little information and that did not help.

Since in my OS repository there was an old version of gpg, I downloaded a 'modern' gpg from the official site. There was a problem with libgrypt, I needed to install a newer library version for gpg to work. When I did it manually, my system refused to boot at all. I think I'll fix that soon, but now I work from another laptop.

Finally I realized that there is a package gnupg2 and I used the command gpg2 instead of gpg. That worked flawlessly. You may set a bash alias gpg=gpg2 in your .bash_profile if you wish to forget about numbers at all.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.