What do I do about repetitive "CRITICAL" error in dnf.log of standard RL v8.6 image?

I’m seeing as many as 7 repetitions per day of the same “CRITICAL” error in /var/log/dnf.log. I don’t know what this means or what if anything I should do about it.

I’m running what I think is a vanilla RL v8.6 system on a robust AWS EC2 instance. There is no GUI and no front-end, which makes life easier.

Here is a representative segment from dnf.log:

2022-11-07T15:05:36+0000 CRITICAL Importing GPG key 0x442DF0F8:
 Userid     : "PostgreSQL RPM Building Project <pgsql-pkg-yum@postgresql.org>"
 Fingerprint: 68C9 E2B9 1A37 D136 FE74 D176 1F16 D2E1 442D F0F8
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG
2022-11-07T15:05:37+0000 DDEBUG Cleaning up.
2022-11-07T15:05:37+0000 SUBDEBUG 
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/dnf/repo.py", line 573, in load
    ret = self._repo.load()
  File "/usr/lib64/python3.6/site-packages/libdnf/repo.py", line 397, in load
    return _repo.Repo_load(self)
libdnf._error.Error: Failed to download metadata for repo 'pgdg15': repomd.xml GPG signature verification error: Bad GPG signature

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 67, in main
    return _main(base, args, cli_class, option_parser_class)
  File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 106, in _main
    return cli_run(cli, base)
  File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 122, in cli_run
    cli.run()
  File "/usr/lib/python3.6/site-packages/dnf/cli/cli.py", line 1055, in run
    return self.command.run()
  File "/usr/lib/python3.6/site-packages/dnf/cli/commands/makecache.py", line 50, in run
    return self.base.update_cache(timer)
  File "/usr/lib/python3.6/site-packages/dnf/base.py", line 370, in update_cache
    self.fill_sack(load_system_repo=False, load_available_repos=True)  # performs the md sync
  File "/usr/lib/python3.6/site-packages/dnf/base.py", line 399, in fill_sack
    self._add_repo_to_sack(r)
  File "/usr/lib/python3.6/site-packages/dnf/base.py", line 139, in _add_repo_to_sack
    repo.load()
  File "/usr/lib/python3.6/site-packages/dnf/repo.py", line 580, in load
    raise dnf.exceptions.RepoError(str(e))
dnf.exceptions.RepoError: Failed to download metadata for repo 'pgdg15': repomd.xml GPG signature verification error: Bad GPG signature
2022-11-07T15:05:37+0000 CRITICAL Error: Failed to download metadata for repo 'pgdg15': repomd.xml GPG signature verification error: Bad GPG signature

From my session logs, this apparently began as a result of running dnf update on 5-Oct-2022. I apparently lack the necessary credentials to upload a copy of this portion session log. I’m happy to provide it on request.

So far as I know, I’ve done nothing to provoke this. I don’t know what pgdg15 is, and I don’t remember doing a dnf add for it.

From my log files, the first occurrence of this complaint was on 5-Oct-2022.It seems to appear as many as seven times per day since then.

I invite guidance about what this “CRITICAL” dnf error is telling me and what I should do about it.

I don’t think a plain vanilla install of 8.6 would have this repository:

Failed to download metadata for repo 'pgdg15': repomd.xml GPG signature verification error: Bad GPG signature

That’s a PostgreSQL repository, so a third-party repository. That one does not have a good GPG signature it seems. Try disabling that repository and running:

dnf upgrade

And see if the error still shows in the logs.

Hmmm. I appreciate your quick response and I’ll investigate this.

I don’t remember adding PostgreSQL repository. Is this something I would do using “dnf”?

I think this began on 5-Oct-2022, so I guess I’ll look at my session logs for that day and reconstruct what I did.

You can, or you can simply edit the repository and set the enabled line to 0. Example here is using vi:

vi /etc/yum.repos.d/pgdg15.repo

Note that you probably want to list that directory location so that you can see what the repository name actually is, and then edit the repo. I’m doing a lot of guessing here! :wink:

I checked my notes, and discovered that I added this a year ago during a failed attempt to install a nodejs component/system that needed postgresql.

I did this in a stupid brute-force way:

  1. I ran dnf repolist and got the names to remove.

  2. I used dnf config-manager to get rid of them one at a time:

    dnf config-manager --disable pgdg-common
    dnf config-manager --disable pgdg10
    dnf config-manager --disable pgdg11
    dnf config-manager --disable pgdg12
    dnf config-manager --disable pgdg13
    dnf config-manager --disable pgdg14
    dnf config-manager --disable pgdg15
    
  3. I confirmed that entries in the repo had been disabled

  4. I removed the repo from /etc/yum.repos.d

  5. I ran dnf clean all

  6. I rebooted the system

Hopefully this solved the issue – I appreciate your help and I’ll mark your response as a “solution” as soon as I confirm that all is well.

2 Likes

Let us know if you still have issues and good luck!

Problem solved, marking this as a solution.