Rick Stevens writes:
On 06/24/2016 03:32 PM, Sam Varshavchik wrote:
> On one of my machines:
>
> dnf system-upgrade download --releasever 24
>
> this does its thing for a while, but after downloading everything (or
> rechecking that everything is already downloaded), dnf blows up with:
>
> warning:
> /var/lib/dnf/system-upgrade/docker-1.10.3-19.gitee81b72.fc24.x86_64.rpm:
> Header V3 RSA/SHA256 Signature, key ID 81b46521: NOKEY
> Curl error (37): Couldn't read a file:// file for
> file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-x86_64 [Couldn't open file
> /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-x86_64]
> The downloaded packages were saved in cache until the next successful
> transaction.
> You can remove cached packages by executing 'dnf clean packages'.
>
>
> The right filename is /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-24-x86_64
>
> So, after a quick application of:
>
> ln -s /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-24-x86_64
> /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-x86_64
>
> This made dnf happy. But the question remains is why dnf is using the
> wrong path on this particular machine. dnf had no issues with finding
> the gpg key on all the other machines I updated to 24, but what it's
> major malfunction here?
Is this the only machine with docker installed? It's specifically saying
the docker RPM is specifying the wrong GPG key.
Nope. I just checked, and I found docker-1.10.3-19.gitee81b72.fc24.x86_64 on
one of the other machines that had no issues getting updated to F24.
TMK, RPM files do not specify full pathnames, or even just the filenames;
they just have a signature and it's up to the installer to verify it.
It's the repo configuration that points to the keys. In
/etc/yum.repos.d/fedora.repo:
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
… but I just answered my own question, it was a minor screwup. Grepping
around I found a busted gpgkey setting in the .repo for my local
updates .repo.
What must be happening is that the first package signed by an unknown key
makes the installer prompt to import it, and on this machine, during an
upgrade the first package selected for installation was from my local
updates mirror. On the other machine the first package selected from
installation was from the non-local fedora primary repo, which had a valid
gpgkey pathname. Once imported, there was no reason to go look for keys
again, since packages that got pulled from my local updates mirror can
already have their signatures checked.