Bug 1066044

Look at /var/log/fedup.log - it should tell you why the key(s) weren't imported.

Can you attach your fedup.log here?

(user emailed me the fedup.log)

See the end of your fedup.log:

(II) fedup.yum:_GPGKeyCheck() repo 'rpmfusion-nonfree' wants to import key /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-nonfree-fedora-20
(II) fedup.yum:check_keyfile() checking keyfile /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-nonfree-fedora-20
(DD) fedup.yum:check_keyfile() keyfile owned by package rpmfusion-nonfree-release-0:19-1
(DD) fedup.yum:check_keyfile() package was signed with key cd30c86b
(II) fedup.yum:check_keyfile() REJECTED: key cd30c86b is not trusted by rpm
(II) fedup.yum:_GPGKeyCheck() no automatic trust for key %s

Your system doesn't trust the key that "rpmfusion-nonfree-release" was signed with. Probably you installed that package with "--nogpgcheck", so you never trusted the key.

The simplest solution - assuming you trust the existing package - is probably "yum reinstall rpmfusion-nonfree-release". This should make yum ask you if you trust the key it was signed with, and then fedup should import the F20 key for you.

Otherwise, you could manually trust the key:
   rpmkeys --import /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-nonfree-fedora-19

If all else fails you can run fedup with --nogpgcheck, although that's not recommended.

I had the exact same error running Fedup from Fedora 19 to 20 as in this report.

Fedup ran throught the process downloading files for over an hour then failed at the last minute with the Error regarding the failure to install keys.
  it was rpmfusion-nonfree-release-19-1 package which was flagged as the problem with me too.

The tip to re-install the "rpmfusion-nonfree-release-19-1.noarch" package using yum, solved it for me.

After I reinstalled the "Rpmfusion-nofree-release-19-1.noarch" package and accepted the package and the key, I re-ran fedup and this time it finished off the small download it still required to get the rpmfusion-nonfree-fedora-20 package and key.

Then I got the message that it had Finished and to reboot to start the upgrade.

So hopefully now when I reboot it will run the upgrade.

*** Bug 1059896 has been marked as a duplicate of this bug. ***

I've hit this bug on two different F19 systems.

The instructions at http://rpmfusion.org/Configuration say to use --nogpgcheck so presumably lots of people have rpmfusion repos configured but don't trust the keys.

https://fedoraproject.org/wiki/FedUp#Will_packages_in_third_party_repositories_be_upgraded.3F and/or https://fedoraproject.org/wiki/Common_F20_bugs#Upgrade_to_Fedora_20_with_fedup_0.8_fails_due_to_GPG_key_problems should be updated to suggest reinstalling the rpmfusion-*-release packages, rather than saying it will work, or suggesting to disable rpmfusion.

*** Bug 1172349 has been marked as a duplicate of this bug. ***

(In reply to Will Woods from comment #2)
> (user emailed me the fedup.log)
> 
> See the end of your fedup.log:
> 
> (II) fedup.yum:_GPGKeyCheck() repo 'rpmfusion-nonfree' wants to import key
> /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-nonfree-fedora-20
> (II) fedup.yum:check_keyfile() checking keyfile
> /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-nonfree-fedora-20
> (DD) fedup.yum:check_keyfile() keyfile owned by package
> rpmfusion-nonfree-release-0:19-1
> (DD) fedup.yum:check_keyfile() package was signed with key cd30c86b
> (II) fedup.yum:check_keyfile() REJECTED: key cd30c86b is not trusted by rpm
> (II) fedup.yum:_GPGKeyCheck() no automatic trust for key %s
> 
> Your system doesn't trust the key that "rpmfusion-nonfree-release" was
> signed with. Probably you installed that package with "--nogpgcheck", so you
> never trusted the key.
> 
> The simplest solution - assuming you trust the existing package - is
> probably "yum reinstall rpmfusion-nonfree-release". This should make yum ask
> you if you trust the key it was signed with, and then fedup should import
> the F20 key for you.
> 
> Otherwise, you could manually trust the key:
>    rpmkeys --import /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-nonfree-fedora-19
> 
> If all else fails you can run fedup with --nogpgcheck, although that's not
> recommended.

I would just like to chime in and say that this solution worked beautifully for me. I guess I never properly imported the right keys for RPM Fusion when I originally installed it on my laptop. However, a simple reinstall of "rpmfusion-nonfree-release" fixed this issue for me completely. My laptop is currently in the process of upgrading to Fedora 21, hooray!

I would like to propose this little problem being added to the Wiki as part of the FAQ / troubleshooting sections, as it seems to be a recurring issue. If I can find the place for it, I will add it in myself, but I am not as familiar with the order of the wiki as other users are, I am sure.

There's no (secure) way for fedup to automatically establish this trust for you, but we should probably fall back to yum's "Importing GPG key, is this ok [y/N]" dialog in this case.

Implemented in git: https://github.com/wgwoods/fedup/commit/47a824d

Should be in the next fedup package (fedup-0.9.1-2 or higher).

(In reply to Will Woods from comment #9)
> Implemented in git: https://github.com/wgwoods/fedup/commit/47a824d
> 
> Should be in the next fedup package (fedup-0.9.1-2 or higher).

Isn't this unsecure when we ask the user if they trust the key. GPG key couldn't be verified by just looking at it.

Besides there's always a "--nogpgcheck" option.

Maybe it's good to have an GPG key import on-the-go instead of rerunning fedup from the beginning after downloading the key manually. Maybe even ask the user a link to download a GPG key.

(In reply to Yuriy Lapitskiy from comment #10)
> (In reply to Will Woods from comment #9)
> > Implemented in git: https://github.com/wgwoods/fedup/commit/47a824d
> > 
> > Should be in the next fedup package (fedup-0.9.1-2 or higher).
> 
> Isn't this unsecure when we ask the user if they trust the key. GPG key
> couldn't be verified by just looking at it.

If you're asking if it's insecure to ask the user to trust a key... that's a much bigger problem, and well outside the scope of fedup. (This is basically the legendary Bug #998, if you're interested.)

To be clear, fedup has *one* special rule for GPG keys.
fedup will *only* automatically import a key if:

  a) it's a file on the local disk, and
  b) the file is owned by a package that was signed by a trusted key, and
  c) the file hasn't been modified since being installed.

In short: if the new key came out of a package you trust, that key must also be trustworthy, and so fedup will import it. Otherwise, fedup does nothing.

> Maybe it's good to have an GPG key import on-the-go instead of rerunning
> fedup from the beginning after downloading the key manually.

Right, that's what was added in git commit 47a824d. If a key can't be auto-imported, fedup will now fall back to yum's default key-handling behavior (show the user some key info, ask if they trust it).

Whether or not that behavior is correct is up to yum, not fedup.

> Maybe even ask the user a link to download a GPG key.

That link is already in the .repo file. But most repos ship their keys inside a "repo-release" package and use "gpgkey=file:///...", because (AFAIK) yum doesn't download GPG keys for you.

But again, that's up to yum, not fedup.

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. 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 EOL if it remains open with a Fedora  'version'
of '20'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 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 this bug is closed as described in the policy above.

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.

Fixed in v0.9.2, which is in Fedora 21.

I can confirm I just experienced this in Fedora 22, when trying to upgrade to Fedora 23:

james@computer:~$ sudo dnf system-upgrade download --releasever=23 --allowerasing

(5489/5489): libreoffice-core-5.0.3.1-1.fc23.x8 141 kB/s |  74 MB     08:56
--------------------------------------------------------------------------------
Total                                           868 kB/s | 2.6 GB     53:19
warning: /var/lib/dnf/system-upgrade/efivar-libs-0.21-1.fc23.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 34ec9cba: NOKEY
Importing GPG key 0x34EC9CBA:
 Userid     : "Fedora (23) <fedora-23-primary>"
 Fingerprint: EF45 5106 80FB 0232 6B04 5AFB 3247 4CF8 34EC 9CBA
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-23-x86_64
Is this ok [y/N]: The downloaded packages were saved in cache till the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Didn't install any keys
james@computer:~$ sudo rpmkeys --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-23-x86_64

I manually ran this import command to fix the issue.

er...it doesn't look like you answered 'y' to the question whether you wanted to import the key.

(In reply to awilliam from comment #15)
> er...it doesn't look like you answered 'y' to the question whether you
> wanted to import the key.

I had the same thought, however it never prompted me, the script just exited. Either that or it had a very short timeout and I missed it somehow.

When you run dnf in some sort of non-interactive way it by default answers 'no' to all questions, you can pass '-y' to make it answer 'yes'. Possibly this is happening when you run through sudo, is my only guess? I think I usually run the dnf command directly as root, not sure about other testers.

...DNF assuming "no" on key import (if run through sudo) is a totally different problem (in a completely different package!) than the original bug here.

DNF plugins can't (AFAIK) control how the key import prompt works, so it's not really even possible for me to fix this in dnf-plugin-system-upgrade.

Therefore I've filed bug 1278969 against dnf to track the problem mentioned in comment #14 and onward.

Re-closing this bug as in comment #13.