Description of problem: Offline updates fail if a the PackageKit database is refreshed after downloading updates, because the downloaded packages are cleaned. Version-Release number of selected component (if applicable): PackageKit-0.9.3-1.fc21.x86_64 How reproducible: Always Steps to Reproduce: 1. pkcon update --only-download 2. Verify that /var/cache/PackageKit/metadata/fedora/packages is not empty 3. pkcon refresh 4. pkcon offline-trigger 5. reboot 6. Wait until offline updates fail 7. Observe that /var/cache/PackageKit/metadata/fedora/packages is empty Actual results: /var/lib/PackageKit/offline-update-competed contains [PackageKit Offline Update Results] Success=false ErrorDetails=cannot download Packages/k/kernel-3.16.0-0.rc5.git1.1.fc21.x86_64.rpm to /var/cache/PackageKit/metadata/fedora/packages/: Curl error: Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-21&arch=x86_64 ErrorCode=internal-error Expected results: System updates fine without requiring network access, all packages are used from the previous (online) download. Additional info: Proposing as a beta blocker under the criterion: The installed system must be able to download and install updates with the default graphical package manager in all release-blocking desktops.
Forgot to mention, the backend is hif, with libhif-0.1.1-1.fc21.x86_64 and librepo-1.7.5-1.fc21.x86_64
Proposed as a Blocker for 21-beta by Fedora user gcampax using the blocker tracking app because: Violates criterion: The installed system must be able to download and install updates with the default graphical package manager in all release-blocking desktops.
Refreshing will clear the "ready to go" status of the offline updates. Manually doing the low-level "pkcon offline-trigger" will just set the file telling systemd to do into a special mode at startup, it won't actually prepare the offline update again. What did you expect to happen?
Well, the bug was first reproduced with gnome-software (I prepared the updated, clicked reboot & install updates, and it did not actually update because there were no rpms in the cache). What I gave in the summary is a small cmdline reproducer that takes gnome-shell/gnome-software out of the equation. FWIW pkcon refresh does not remove the /var/lib/PacakegeKit/prepared-update file that gnome-shell checks to trigger updates, which is why it tries to update (as shown in the error file) rather than just ignoring the system-update target and rebooting.
Is bug 1127510 a dup of this one? I can't tell if offline updates fail due to a PK or systemd bug. But both methods to initiate fail: - Software > Updates > Restart & Install - Gnome desktop click on upper right corner triangle, click on power button > check Install pending software updates > click restart
Created attachment 935038 [details] f21-Alpha TC6 Workstation PackageKit fails
#yum update works on same files. But All Settings/Details [Check for Updates] still shows "Restart & Install". After restart still shows all files needing update.
(In reply to satellit from comment #7) > #yum update works on same files. But All Settings/Details [Check for > Updates] still shows "Restart & Install". After restart still shows all > files needing update. ABRT System: caribou-0.4.14-1.fc21 killed by SIGABRT report: retrace server is unable to process package caribou-0.4.14-1.fc21.x86_64
Discussed at 2014-10-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2014-10-03/f21-blocker-review.2014-10-03-15.58.log.txt . We're inclined to accept this as a blocker, but we weren't clear on just how common it is. Is it likely to happen on all/most update attempts or just occasionally?
(In reply to Giovanni Campagna from comment #4) > FWIW pkcon refresh does not remove the /var/lib/PacakegeKit/prepared-update > file that gnome-shell checks to trigger updates, which is why it tries to > update (as shown in the error file) rather than just ignoring the > system-update target and rebooting. This works correctly with PackageKit 1.0.0 that's in F21 -- 'pkcon refresh' now definitely removes the /var/lib/PacakegeKit/prepared-update file. Also, we've redone the offline updates triggering mechanism and gnome-shell 3.14 no longer checks for the prepared-update file, but instead uses a new packagekit dbus api for offline updates. This should make the whole process much more robust. I don't think the scenario described in comment #0 can happen any more.
Discussed at 2014-10-08 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2014-10-08/f21-blocker-review.2014-10-08-15.58.log.txt . We checked with Kalev and he confirmed that c#10 means that he believes the issue is addressed and the bug can be closed. He asks that anyone still running into problems with offline updates in F21 file a new bug.