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
