On Thu, 2021-02-11 at 14:48 +0000, Daniel P. Berrangé wrote:
On Thu, Feb 11, 2021 at 02:06:45PM +0100, Andrea Bolognani wrote:
> The .repo files for Fedora Rawhide are already pointing to the
> Fedora 35 key, but all RPMs are still signed with the Fedora 34
> key, resulting in
>
> GPG key at file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-35-x86_64 (0x9867C58F) is
already installed
> The GPG keys listed for the "Fedora - Rawhide - Developmental packages for
the next Fedora release" repository
> are already installed but they are not correct for this package.
> Check that the correct key URLs are configured for this repository.. Failing
package is: nosync-1.1-10.fc34.x86_64
> GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-35-x86_64
> The downloaded packages were saved in cache until the next successful
transaction.
> You can remove cached packages by executing 'dnf clean packages'.
> Error: GPG check FAILED
>
> Temporarily tweak the .repo files so that the Fedora 34 key is
> used for validation. We should be able to revert this in a few
> days.
Hmm, isn't the real bug the ordering:
dnf install -y nosync && \
nosync dnf update -y --nogpgcheck fedora-gpg-keys && \
nosync dnf update -y && \
We installed nosync too early. We need to update fedora-gpg-keys
as the *first* thing we do in rawhide images, and only then
attempt to install nosync.
Yeah, I thought of that as well at first, and it's definitely
something that we need to fix in lcitool. I'll post a patch later.
That said, in this case the problem can't be solved by simply
inverting the commands: from the output above, you'll see that the
signing key for Fedora 35 is already present on the system; however,
since the RPMs that are currently in the Rawhide repos are still
signed with the Fedora 34 key, we need to convince dnf to use the
latter for validation. That's what the hack in this patch does.
--
Andrea Bolognani / Red Hat / Virtualization