Page MenuHome GnuPG

gpg fails with error if you delete the ~/.gnupg directory
Closed, ResolvedPublic

Description

What did you do?

  1. I ran gpg to generate my keys
  2. I then deleted the ~/.gnupg directory so I could regenerate my keys from scratch.
  3. I re-ran gpg.

What happened?

  1. The first time I ran gpg (after building a new server), gpg generated the key perfectly fine.
  2. When regenerating the key after I had deleted the ~/.gnupg directory, gpg exits with an error.
$ gpg --default-new-key-algo rsa4096 --gen-key
gpg (GnuPG) 2.4.4; Copyright (C) 2024 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Note: Use "gpg --full-generate-key" for a full featured key generation dialog.

GnuPG needs to construct a user ID to identify your key.

Real name: Fred Blogs
Email address: fred@gmail.com
You selected this USER-ID:
"Fred Blogs <fred@gmail.com>"

Change (N)ame, (E)mail, or (O)kay/(Q)uit? o
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: agent_genkey failed: No such file or directory
Key generation failed: No such file or directory

What did you expect to happen?

The key file should have been generated.

Additional information

On investigation the issue is related to the locale that gpg is expecting. I ran strace and found that one of the display messages was trying to use a file libc.mo that was not present in my en.AU locale directory tree.
I also tried a US locale - and the same error occurred.
I searched all of the English locale directories and found that en_GB had the libc.mo file, so I changed the machine locale to English United Kingdom. When I did this gpg worked without error.
I was able to identify the cause of the error with strace. Output follows:

$ strace -p 36930
strace: Process 36930 attached
read(4, "ERR 67141713 No such file or dir"..., 1002) = 51
openat(AT_FDCWD, "/usr/share/locale/en_AU.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en_AU.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en_AU/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
write(2, "gpg: agent_genkey failed: No suc"..., 51) = 51
write(2, "\n", 1)                       = 1
write(3, "Key generation failed: No such f"..., 49) = 49
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
munmap(0x7f324a23d000, 65536)           = 0
exit_group(2)                           = ?
+++ exited with 2 +++
  1. Versions
    1. Operating System: Fedora 39
    2. GPG version: 2.4.4

Event Timeline

bryonbaker updated the task description. (Show Details)
bryonbaker updated the task description. (Show Details)

I guess the agent was still running when you deleted and soon re-created the ~/.gnupg directory. The agent is responsible for the private keys subdir and it did not yet noticed that its homedir (and thie subdir) vanished. Depending on your system the agent should terminate itself after some time in case the homedirectory was deleted. Thus to remove the homedir please use

gpgconf -K all
rm -rf ~/.gnupg

gpg will then take care to re-start the agent.

werner claimed this task.

@werner I- think you were a bit quick on the trigger to shut this down.
I had rebooted the machine in between attempts. So your analysis is actually not correct.
Basically you have an issue that something in gpg is using something in a locale that is not installed. I pretty much proved that.
Anywho, I'll leave it to you to work out if you want to bother investigating it further.