Solved : Bad signatures/Invalid key error when updating Lx 3

Hello,

  • OpenMandriva Lx version:
    LX 3 updates repositories

  • Desktop environment (KDE, LXQT…):
    All

  • Description of the issue (screenshots if relevant):
    Since approximately Wednesday March 14 it seems like all packages published to updates repositories are unsigned. The urpmi error message will say “The following package has bad signature:” but what is happening is that the OM signature is missing which urpmi reads as an “Invalid Key ID”.

  • Relevant informations (hardware involved, software version, logs or output…):
    Developers are aware of this issue and @TPG is going to look in to this shortly.

For now users can hold off on updating until this issue is resolved.

FWIW: The packages are supposed to be signed when published to updates repo. It has been speculated by me and others that this is perhaps caused by ongoing changes in Package Management system due to the switch from urpmi/rpm5.org to dnf/rpm.org.

Edit: It is worth mentioning also that I am a package tester and have installed all the packages in question. So far everything works fine as far as I know. So AFAIK the packages themselves are fine this is just a temporary glitch in the system regarding attaching the signature to the packages.

1 Like

Screen shot on a system with only one package to update showing the error (in Konsole):

The noteworthy part is:

The following package has bad signature:
/var/cache/urpmi/rpms/man-db-2.8.2-2-omv2015.0.x86_64.rpm: Invalid Key ID (OK (RSA/SHA1, Fri 16 Mar 2018 06:20:10 AM CDT, Key ID 8e885aef4b87191b))
Do you want to continue installation ?

Note: I ran urpmi --clean -a before running urpmi --auto-update.

In the process of trying to get screen shots of this issue I’m running in to more weirdness than I first realized. Ummm, I’m looking and trying to pin down what I’m seeing.

OK, here’s a screen shot of the weirdness I was referring to. And note that this is on a system where kernel packages have already been updated. So I don’t know of any reason why urpmi is asking these questions.

And then when you get to the “Some requested packages cannot be installed:” you see:

systemd-231-1-omv2015.0.x86_64 (in order to keep systemd-237-1-omv2015.0.x86_64)
glibc-2.23-4-omv2015.0.x86_64 (in order to keep glibc-2.27-9-omv2015.0.x86_64)

What??? I believe it should be trying to install systemd-238-1-omv2015.0.x86_64… And so on.

Hence the use of the word “weirdness”.

Is kernel 4.6.5 (and kernel server) what you really want?

1 Like

No, the kernel packages are up to date on this system (4.15.8). urpmi --auto-updates should not even be asking those questions AFAIK. And kernel 4.6.5 is ancient history. It was the ‘original’ Lx 3.0 kernel.

What is your choice?
1

1 Like

I only did that to show that the question keeps repeating. You can select anything in the list and it keeps asking until you select them all. Which is wrong. Don’t think I need to be a dev to say that.

Edit: And what I actually did was I aborted the update. Did not install anything because that dependency circle would be impossible for me to solve.

To clarify (perhaps I should have, you made a good point) here is a file with the entire output where the last selection is n for No Do Not Update. Also shows how many times it keeeps asking to install some kernel package or other which is weirdness. (And there is more weirdness after those).

auto-select-3⁄16⁄18.txt (8.1 KB)

1 Like

I think that urpmi should not ask for ancient/unused kernel(s) dependencies for first :slight_smile:
Or am I wrong?

1 Like

I have verified these issues exist also in a VirtualBox installation of OM Lx 3.03 (installed from build 1742).

You are not wrong. Plus this system already has multiple kernel-release-desktop, and kernel-release-desktop-devel installed. There is no need I ever heard of to install more or to install such old stuff.

$ rpm -qa | grep kernel-release-desktop
kernel-release-desktop-devel-4.15.2-1omv-1-1-omv2015.0.x86_64
kernel-release-desktop-4.15.2-1omv-1-1-omv2015.0.x86_64
kernel-release-desktop-devel-4.15.7-1omv-1-1-omv2015.0.x86_64
kernel-release-desktop-4.15.7-1omv-1-1-omv2015.0.x86_64
kernel-release-desktop-devel-4.15.8-1omv-1-1-omv2015.0.x86_64
kernel-release-desktop-latest-4.15.8-1-omv2015.0.x86_64
kernel-release-desktop-devel-latest-4.15.8-1-omv2015.0.x86_64
kernel-release-desktop-4.15.8-1omv-1-1-omv2015.0.x86_64
1 Like

FWIW: Those using the current GUI updater (Discover) will (if they are looking at screen when it pops) see a small window that says:

GPG failure:
Invalid or bad GPG signature

but the error message does not stay up for very long.

So, here is the full log of todays update (right now) of my vbox machine from build 1915.
Previous update was yesterday.
I don’t see anything weird. But you may want to give it a look too.
konsole-agg20180316-full.txt (70,8 KB)

Don’t see anything weird there.

Edit: But next post is relevant.

1 Like

First thing users need to know is that the weirdness I saw is gone. Now longer a problem.

Was able to update 183 packages on the hardware system in question and 284 packages on the VBox system. And both rebooted and are still working, no issue noted so far.

However, the issue with “Bad signatures/Invalid key” persists and a majority of packages showed this error. So I am changing the title of this thread back to it’s original.

Now why could this be.

  1. My first thought was that a developer or developers was/were working on the issues while I was posting about them.

OR

  1. Maybe in the context of someone moving many packages at once from testing repo to updates repo I caught it in the middle somewhere and some dependencies appeared due to some missing packages. Believe it or not this has happened to me before. Which just shows what a lucky guy I am. :rofl:

Edit: Why I think it may be the second answer is because when I got the errors there were 144 packages to update, when it worked there were 183.

People who do nothing are the most lucky :stuck_out_tongue_winking_eye:

:+1:

Great news from @TPG:

<_TPG> itchka: ben79 yes i’ve fixed rpm signing, and resigned all packages from last month

I’m in process of testing on an instance in VBox of Lx 3.03 installed from ISO build 1686 that has never been updated. 885 packages so that will go back way more than a month. (It is on kernel 4.13.12 so old). But since it is @TPG I don’t expect any issue.

Hope all our users appreciate all the work @TPG does for this distro. The sheer volume of work sometimes is just astounding.

1 Like

:+1:

1 Like