Bug 1121409

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.