Description of problem: [root@vmf17 ~]# pkcon -y install !$ pkcon -y install ruby-mysql Installing [=========================] Waiting in queue [=========================] Waiting for authentication [=========================] Waiting in queue [=========================] Starting [=========================] Running [=========================] Resolving dependencies [=========================] Downloading update information[=========================] Downloading packages [=========================] Checking signatures [=========================] Installing signature [=========================] Waiting in queue [=========================] Fatal error: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._pk_5ftransaction_5ferror.Code14: Invalid input passed to daemon: char '<' in text! /var/log/messages Feb 17 15:38:51 vmf17 dbus-daemon[430]: dbus[430]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper) Feb 17 15:38:51 vmf17 dbus[430]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper) Feb 17 15:38:52 vmf17 dbus-daemon[430]: dbus[430]: [system] Activating via systemd: service name='org.freedesktop.ConsoleKit' unit='console-kit-daemon.service' Feb 17 15:38:52 vmf17 dbus[430]: [system] Activating via systemd: service name='org.freedesktop.ConsoleKit' unit='console-kit-daemon.service' Feb 17 15:38:52 vmf17 dbus-daemon[430]: dbus[430]: [system] Successfully activated service 'org.freedesktop.ConsoleKit' Feb 17 15:38:52 vmf17 dbus[430]: [system] Successfully activated service 'org.freedesktop.ConsoleKit' Feb 17 15:38:52 vmf17 dbus-daemon[430]: dbus[430]: [system] Successfully activated service 'org.freedesktop.PackageKit' Feb 17 15:38:52 vmf17 dbus[430]: [system] Successfully activated service 'org.freedesktop.PackageKit' Feb 17 15:38:57 vmf17 dbus-daemon[430]: PkPlugin-WARNING **: no updates cache Version-Release number of selected component (if applicable): PackageKit-0.7.2-5.fc17.x86_64
I can install other packages okay: # pkcon -y install wxGTK-devel More than one package matches: 1. wxGTK-devel-2.8.12-3.fc17.x86_64 [fedora] 2. wxGTK-devel-2.8.12-3.fc17.i686 [fedora] Please choose the correct package: 1 Installing [=========================] Waiting in queue [=========================] Waiting for authentication [=========================] Waiting in queue [=========================] Starting [=========================] Running [=========================] Resolving dependencies [=========================] Downloading packages [=========================] Checking signatures [=========================] Testing changes [=========================] Installing packages [=========================] Scanning applications [=========================] Getting information [=========================] [root@vmf17 c++]#
Any updates to this I am having problems opening all packages whether it be from fedora add/remove, or web install packages. Please advise as I am new to fedora. Thanks, Ray
I was getting this n' all, trying through yum CLI instead ...
Ray, it seems to be working. Go to the Activities menu, search for "terminal" and open it. From there, type .. su Put in your root password. Then just type ... yum -y update That should install all the updates the old fashioned way.
This seems to happen when using rpmfusion.
I just hit this trying to test update installation in 17 RC1: * Do a stock install from DVD * grab an older gedit build from koji, and 'yum downgrade' to it * Wait for an update notification, and clicky clicky It asked me to accept a signature, which seemed a bit odd. I accepted it, then I got this error. GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._pk_5ftransaction_5ferror.Code14: Invalid input passed to daemon: char '<' in text! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
If I manually rpm --import the key it seemed to want to import - /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-x86_64 - it then installs the 'update' fine. So, it seems like PK isn't actually successful in importing the key?
Yeah, um. PK seems to have serious problems importing keys. This isn't good. If I set up Fusion and try to install anything from it, PK asks for root password, downloads the packages, then pops up a 'Do you trust the source of the packages?' dialog. I click 'Yes', and it just...goes right back to the PK interface. Nothing has been installed. yum can correctly import the key. Some kind of permissions snafu perhaps? I'm flagging this up as a blocker. We might waive it if updates from the official update repo work, but I don't want to take any chances. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
OK, this is looking like a genuine blocker. tflink reproduced. I can confirm that this seems to have happened between TC4 and TC5. If you install TC4 and try to update via PK, you get a dialog claiming the packages are from an untrusted source and you need to enter your root password. It never tries to import a GPG key. This is obviously bad, but at least the updates actually install. With TC5, PK superficially does the right thing - asking if it's okay to import a GPG key, rather than claiming the packages are untrusted and asking for a root password - but it can't actually successfully import the key and consequently can't install anything. Oh, and you have to install from netinst or DVD to re-create this, because the live images have 'rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora' run in %post during creation, so they have the key imported already. You'd probably see neither of the bugs on an install from live. Obviously, we need this fixed yesterday. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I also got the same error message after installing RC1 and attempting to update with updates-testing. I used a slightly different method of confirming this - installed RC1 from DVD, downloaded the packages from the PackageKit-0.7.4-1.fc17 update, downgraded them (so no keys were involved) and attempted to update from updates-testing. As expected, I was prompted for a password but after that, the updates installed without incident and I was prompted to log out. I'm +1 blocker on this due to violation of the following Fedora 17 alpha release criterion [1]: The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops [1] http://fedoraproject.org/wiki/Fedora_17_Alpha_Release_Criteria
(In reply to comment #9) > Obviously, we need this fixed yesterday. Well, I can't do yesterday, but I can do today :) I can reproduce this issue, and have fixed it upstream. I've patched the F17 package and done a build here: http://koji.fedoraproject.org/koji/taskinfo?taskID=4083152 -- if one of you guys could test this and if it works file an update I would appreciate it. I don't know the required steps to et it put directly into stable and the ISOs. I have no idea how this obvious bug managed to get committed upstream, so sorry about that. I'll work out if F16 and F15 is affected too and do the required builds. Ohh, and QA FTW. Good catch guys -- thanks.
+1 blocker Trying to re-test now.
(In reply to comment #11) > http://koji.fedoraproject.org/koji/taskinfo?taskID=4083152 It fixes the bug. But there are some buts... I have RC1 DVD i686 installed system. I enabled updates-testing and tried to use gpk-update-viewer to update a single package. Received the same error message as in comment 6. I have downloaded new PackageKit build, installed it and tried again. This time it correctly imported the key, but your user needs to have admin privileges to do that (you have to provide the password). Is this desired? Broken PK in TC4 also required admin password for packages to be installed and we considered it a blocker... so I'm not sure. This is related to bug 748320, solving that one would solve it.
The requirement to import the key on the first update has been around for a while, IIRC. And yeah, 748320 is the place for it. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Discussed at the 2012-05-17 Fedora 17 final go/no-go meeting. Accepted as a blocker for Fedora 17 final due to violation of the following Fedora 17 alpha release criterion [1]: The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops. [1] http://fedoraproject.org/wiki/Fedora_17_Alpha_Release_Criteria
I did a fresh install of RC1 + the builds from comment #11 and I don't get the key importing error that we were seeing before. However, I did seem to hit #822430 when all the builds from updates-testing were selected. How do we want to handle the admin password requirement? It isn't an explicit requirement but we did accept another bug for requiring an administrative password in order to do updates. Do we want to call the builds from comment #11 good for now and file a new bug for the admin password or wait until we have something that satisfies both requirements?
PackageKit-0.7.4-3.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/PackageKit-0.7.4-3.fc17
We don't need a new bug for the admin password requirement. We've got enough of the bloody things already. It's quite simply https://bugzilla.redhat.com/show_bug.cgi?id=748320 . There is nothing at all more to it. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Discussed in the 2012-05-18 blocker bug review meeting. The update from comment #17 was included in Fedora 17 final RC2. It needs testing so that we can figure out if this bug can be closed or not.
We have multiple tests that the fix works, so setting VERIFIED. Will be pushed soon. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
*** Bug 811772 has been marked as a duplicate of this bug. ***
PackageKit-0.7.4-3.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.