Bug 1029834 - Couldn't open 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
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: fedora-release (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Dennis Gilmore
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-13 05:26 EST by Yann Droneaud
Modified: 2014-02-19 07:53 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-19 07:53:19 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Log of yum distro-sync, yum upgrade and ls /etc/pki/rpm-gpg/ (30.01 KB, text/plain)
2013-11-13 05:26 EST, Yann Droneaud
no flags Details

  None (edit)
Description Yann Droneaud 2013-11-13 05:26:42 EST
Created attachment 823338 [details]
Log of yum distro-sync, yum upgrade and ls /etc/pki/rpm-gpg/

After upgrade from Fedora 19 to Fedora 20 using fedup,
yum upgrade or yum distro-sync failed with error:

GPG key retrieval failed: [Errno 14] curl#37 - "Couldn't open file /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-x86_64"

It might be related to usage of -testing repo: I had testing repo enabled on Fedora 19, and did not disable them and ran yum distro-sync to remove -testing package from Fedora 19 before doing fedup --network 20
Comment 1 Zdeněk Pavlas 2013-11-13 06:43:55 EST
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-x86_64 should be provided by generic-release-20-0.2.noarch from the fedora repo.. Is it installed?  If not, what does "rpm -q --whatprovides system-release" say?
Comment 2 Yann Droneaud 2013-11-13 08:13:21 EST
generic-release is not installed on my system:

# rpm -qa "*-release"
fedora-release-20-0.7.noarch
rpmfusion-free-release-20-0.2.noarch
rpmfusion-nonfree-release-20-0.2.noarch

# rpm -q --whatprovides system-release
fedora-release-20-0.7.noarch
Comment 3 Zdeněk Pavlas 2013-11-13 09:13:56 EST
There seems to have been a change in naming convention .. fedora-release 19-2 didn't include $release in arch-specific symlinks, but fedora-release 19-4 from updates does.  That seems odd, such changes should not happen without a release change.  Also, generic-release should reflect that, but it didn't change.

Additionally, some fedora 20 packages were probably signed with keys that used the old naming convention (have no idea why).

This is definitely not a bug in yum.. either the fedora-release package from fedora 20 should contain symlinks without $release, or fedora packages should not use them (but they do).

To fix the problem: 

I'd try importing the gpg key manually with

# rpmkeys --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-20-x86_64

Once imported, the transaction should proceed without errors. (assuming the keys were actually the same, of course).
Comment 4 Zdeněk Pavlas 2013-11-13 09:46:04 EST
verified that RPM-GPG-KEY-fedora-20-x86_64 from fedora-release indeed matches RPM-GPG-KEY-fedora-x86_64 from generic-release.
Comment 5 Tom "spot" Callaway 2013-11-13 11:08:35 EST
That's intentional. What is the bug here exactly?
Comment 6 Yann Droneaud 2013-11-13 11:50:19 EST
(In reply to Tom "spot" Callaway from comment #5)
> That's intentional. What is the bug here exactly?

From my point of view: not being able to complete yum upgrade or yum distro-sync after updating from Fedora 19 with fedup due to missing GPG key
Comment 7 Tom "spot" Callaway 2013-11-13 12:11:19 EST
But... the key isn't missing from either fedora-release or generic-release.
Comment 8 Yann Droneaud 2013-11-13 15:27:36 EST
(In reply to Tom "spot" Callaway from comment #7)
> But... the key isn't missing from either fedora-release or generic-release.

After upgrade with fedup I haven't generic-release package installed.
Regarding fedora-release package:

$ rpm -q  fedora-release
fedora-release-20-0.7.noarch

$ rpm -ql fedora-release | grep -i gpg
/etc/pki/rpm-gpg
/etc/pki/rpm-gpg/RPM-GPG-KEY-20-fedora
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-20-aarch64
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-20-armhfp
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-20-i386
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-20-ppc
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-20-ppc64
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-20-primary
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-20-s390
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-20-s390x
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-20-secondary
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-20-x86_64

So my system is lacking /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-x86_64, but some packages need it when running yum upgrade or yum distro-sync.
Comment 9 Tom "spot" Callaway 2013-11-13 15:38:50 EST
Reassigning to fedora-release, since generic-release is not involved with this bug.
Comment 10 Dennis Gilmore 2013-11-13 23:23:02 EST
have you modified your repo files?  is there .rpmnew repo files in /etc/yum.repos.d/ ? 

We changed the path to enable fedup to be able to verify things. the only way i see this happening is modified .repo files resulting in them not being updated and you getting a miss match
Comment 11 Yann Droneaud 2013-11-14 02:17:56 EST
(In reply to Dennis Gilmore from comment #10)
> have you modified your repo files?  is there .rpmnew repo files in
> /etc/yum.repos.d/ ? 
>

I had the -debuginfo repositories enabled, so fedora.repo, fedora-updates.repo and fedora-updates-testing.repo were modified on this system.
So I have 3 .rpmnew files waiting for me in /etc/yum.repos.d/

> We changed the path to enable fedup to be able to verify things. the only
> way i see this happening is modified .repo files resulting in them not being
> updated and you getting a miss match

You have found the problem.

I had fixed the .repo files and now yum is able to locate the keys.

I'm a bit ashamed not having fixed the .rpmnew before filling this bug report.

Thanks a lot.
Comment 12 Dennis Gilmore 2014-02-19 07:53:19 EST
closing this since its a non issue

Note You need to log in before you can comment on or make changes to this bug.