Bug 1040689 - GPG keys for F19 and F20 needed for upgrades
GPG keys for F19 and F20 needed for upgrades
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: fedora-release (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Dennis Gilmore
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs
: 1043256 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-12-11 17:13 EST by Will Woods
Modified: 2013-12-28 21:44 EST (History)
8 users (show)

See Also:
Fixed In Version: fedora-release-18-6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-22 00:31:09 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)
hack around the problem (2.30 KB, patch)
2013-12-17 18:26 EST, Adam Williamson
no flags Details | Diff
F19 & fedup 0.8 (3.69 MB, image/jpeg)
2013-12-18 07:28 EST, Germano Massullo
no flags Details

  None (edit)
Description Will Woods 2013-12-11 17:13:13 EST
For fedup-0.8.x to check signatures on packages and boot images, the system must provide the appropriate key at:

  /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch

The F19 key is present but the symlinks are wrong; the F20 key is missing.

Upgrades from F18 will require '--nogpgcheck' until the keys are provided by fedup-release.
Comment 1 Will Woods 2013-12-16 09:28:32 EST
*** Bug 1043256 has been marked as a duplicate of this bug. ***
Comment 2 Adam Williamson 2013-12-16 16:16:20 EST
Will, is it a good idea to have fedup 0.8 in updates-testing for F18 without a matching fix for this issue? Do the benefits of 0.8 outweigh the disadvantage of it failing unless you know about this bug? Thanks!
Comment 3 Will Woods 2013-12-17 16:02:46 EST
Yes, 0.8.0 has a lot of important fixes. I plan to push it stable as soon as possible.
Comment 4 Adam Williamson 2013-12-17 16:07:39 EST
OK, fair enough. Let's see if we can light a fire under someone to get the GPG keys in. It shouldn't be hard.
Comment 5 Adam Williamson 2013-12-17 18:26:03 EST
Created attachment 838031 [details]
hack around the problem

So, dgilmore says pushing the GPG keys to F18 is hard.

Given that F18 dies in a month and the majority of people who want to upgrade will probably want to do so in the next week or two, can we please consider the not-correct fix? i.e., the one I'm attaching. I know it's the 'the right fix'. But in practice if we don't send out the GPG keys and don't change fedup, we'll have to tell people to pass --nogpgcheck or use fedup 0.7 anyway, and they won't get GPG checks in those cases either. Seems like a fedup 0.8 that doesn't need a magic parameter is a better choice than either of those.
Comment 6 Fedora Update System 2013-12-18 02:30:15 EST
fedora-release-18-4 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/fedora-release-18-4
Comment 7 Germano Massullo 2013-12-18 07:28:49 EST
Created attachment 838317 [details]
F19 & fedup 0.8

I am having this trouble even on Fedora 19
Comment 8 Adam Williamson 2013-12-18 14:20:40 EST
Germano: ensure you updated fedora-release, only the newest update has the GPG keys.
Comment 9 Fedora Update System 2013-12-19 20:35:55 EST
Package fedora-release-18-6:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing fedora-release-18-6'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-23598/fedora-release-18-6
then log in and leave karma (feedback).
Comment 10 Fedora End Of Life 2013-12-21 10:52:29 EST
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 11 Lonni J Friedman 2013-12-21 14:31:19 EST
Also hitting this when attempting an upgrade with fedup from 18 to 19:

################
$ fedup-cli --network 19 --debuglog /root/fedup.debug.log
setting up repos...
getting boot images...

Downloading failed: couldn't get boot images: No more mirrors to try.
Last error was: [Errno 14] curl#22 - "The requested URL returned error: 404 Not Found"
$ tail fedup.debug.log 
Traceback (most recent call last):
  File "/bin/fedup-cli", line 236, in <module>
    main(args)
  File "/bin/fedup-cli", line 150, in main
    kernel, initrd = f.download_boot_images() # TODO: force arch?
  File "/usr/lib/python2.7/site-packages/fedup/download.py", line 443, in download_boot_images
    raise YumBaseError(_("couldn't get boot images: %s") % err)
YumBaseError: couldn't get boot images: No more mirrors to try.
Last error was: [Errno 14] curl#22 - "The requested URL returned error: 404 Not Found"
[    19.836] (II) fedup:<module>() /bin/fedup-cli exiting cleanly at Sat Dec 21 11:29:23 2013
################

I've already tried updating to the testing fedora-release:
$ rpm -q fedora-release fedup
fedora-release-18-6.noarch
fedup-0.8.0-3.fc18.noarch
Comment 12 Adam Williamson 2013-12-21 14:54:34 EST
That doesn't look anything like this bug...
Comment 13 Lonni J Friedman 2013-12-21 15:58:27 EST
I disagree.  Running the same fedup command with --nogpgcheck worked around the problem.  So if its not this bug, it magically has the same workaround as this bug.
Comment 14 Fedora Update System 2013-12-22 00:31:09 EST
fedora-release-18-6 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 15 Rob Crowther 2013-12-22 08:10:31 EST
Since Lonni's comment above makes it clear he already has fedora-release-18-6 and his still getting the error, why has this been closed?

I also have fedora-release-18-6, I am also getting the error.
Comment 16 Adam Williamson 2013-12-22 14:25:51 EST
He's not getting 'the error', he's getting a 404 which does not obviously have much to do with keys.

So, when you say you are getting 'the error', I don't actually know what you mean. You also haven't said what exactly you're trying to do.
Comment 17 Rob Crowther 2013-12-22 14:47:57 EST
I was trying to fedup from 18 to 19.  I was getting the error Lonni posted.  My upgrade succeed when fedup was run with --nogpgcheck, as did Lonni's.  So clearly it has everything to do with keys.
Comment 18 Lonni J Friedman 2013-12-22 15:06:22 EST
Also, I didn't just pick this bug at random.  I got here via some other Bugzilla (that I can't find at the moment) which had the exact 404 errors that I was seeing, and pointed at this bug as the 'parent'. My best uneducated guess is that the 404 errors are referring to the fact that the gpg keys can't be found for whatever reason.
Comment 19 Rob Crowther 2013-12-22 15:33:57 EST
This one?

https://bugzilla.redhat.com/show_bug.cgi?id=957364
Comment 20 Lonni J Friedman 2013-12-22 15:45:25 EST
I don't think that's the one.  If only bugzilla's search wasn't so broken/useless.  You'd think searching for something as trivial as "bug 1040689" would return something, but nope.
Comment 21 Adam Williamson 2013-12-22 21:09:08 EST
I usually use google "site:bugzilla.redhat.com" to search...

The fact that you're both trying to upgrade to F19 is probably the key here. I don't think there's anything wrong with the fedora-release update, because you're getting 404s, meaning something fedup is expecting to find *on a remote server* isn't there.

At a guess, there isn't a signed treeinfo file for the F19 repo, which is why it works with --nogpgcheck.

This bug is not about that: this bug is about the inclusion of the 19 and 20 package signing keys in the F18 fedora-release package. This bug was closed because a fedora-release update with the 19 and 20 package signing keys went out, and multiple people verified that an 18->20 upgrade with GPG checking enabled works with that fedora-release.

So far it sounds like we need to fix something on the F19 mirrors to make F18->F19 upgrades with GPG checking enabled work; that's a bug, but it's not this bug. But I'll investigate to make sure.
Comment 22 Adam Williamson 2013-12-22 21:35:24 EST
Yeah, I was right. treeinfo.signed doesn't exist for F19. New bug report coming.
Comment 23 Lonni J Friedman 2013-12-22 21:36:13 EST
Thanks for tracking that down.
Comment 24 Adam Williamson 2013-12-22 21:39:24 EST
https://fedorahosted.org/rel-eng/ticket/5821
Comment 25 Adam Williamson 2013-12-22 21:40:37 EST
btw, if you're trying to get to F20 and following the philosophy that going to 19 first then 20 second is safer than doing it in one big jump...ehhhhh. it's probably about the same either way.
Comment 26 Christian Kujau 2013-12-25 05:52:06 EST
Came across this issue while trying to upgrade from F19 to F20:

$ yum --enablerepo=updates-testing install fedup
Package fedup-0.8.0-3.fc19.noarch already installed and latest version

$ fedup-cli --debuglog fedupdebug.log --network 20
[...]
Importing GPG key 0x246110C1:
 Userid     : "Fedora (20) <fedora@fedoraproject.org>"
 Fingerprint: c7c9 a9c8 9153 f201 83ce 7cba 2eb1 61fa 2461 10c1
 Package    : fedora-release-19-5.noarch (@updates/19)
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-20-i386
[ and two other keys from rpm-fusion ]
Downloading failed: Didn't install any keys

As advised in the "Common_F20_bugs" wiki page, I tried:

$ yum --enablerepo=updates-testing update --advisory=FEDORA-2013-23598
Loaded plugins: changelog, langpacks, refresh-packagekit
 --> selinux-policy-devel-3.12.1-74.16.fc19.noarch from updates-testing removed (updateinfo)
 --> rdesktop-1.8.1-1.fc19.i686 from updates-testing removed (updateinfo)
[...]
No packages needed for security; 74 packages available
Resolving Dependencies
Changes in packages about to be updated:


=> And then it exited, with no error message. Imported the F20 key manually:

$ rpm --import https://fedoraproject.org/static/246110C1.txt
[ along with the two other rpmfusion keys ]

=> This helped and fedup upgraded the box to F20. 
   Btw, "rpm --import" does not seem to be documented, I guess it's 
   really "rpmkeys --import 0x246110C1"
Comment 27 Adam Williamson 2013-12-26 12:10:37 EST
Christian: did you check you have the latest fedora-release before upgrading?
Comment 28 Adam Williamson 2013-12-26 12:13:40 EST
ah, you had 19-5. I think perhaps it's RPM Fusion screwing it up, and if you disable that it would've worked. But I'll have to test.
Comment 29 Christian Kujau 2013-12-28 21:07:54 EST
The F19 installation was up-to-date as per "yum upgrade". Yes, the RPM Fusion packages also had missing GPG keys and I had to add them manually, as I did for the Fedora repos.
Comment 30 Adam Williamson 2013-12-28 21:44:51 EST
from other reports it looks like fedup will bail if it can't find appropriate GPG keys for *all* configured repos, and ensuring it finds GPG keys for Fusion is well outside our scope. I don't think there's a bug remaining here. If you can't make Fusion play along, the advice on the 'FedUp' wiki page to disable 3rd party repos temporarily stands.

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