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.

Improve this question
7
  • did you follow the instruction from the error message? Commented Jan 2, 2017 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? Commented Jan 2, 2017 at 11:47
  • 2
    Run gpg --fix-trustdb Commented Jan 2, 2017 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! Commented Jan 2, 2017 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. Commented Jan 2, 2017 at 12:13

2 Answers 2

Reset to default
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.

Improve this answer
1
  • Thanks, it helped! I think as part of commands it is using rm which fails if it is interactive "rm -i" Commented Mar 15, 2019 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.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.