Bug 1833176 - GNOME offline update doesn't do anything with PackageKit 1.2.0
Summary: GNOME offline update doesn't do anything with PackageKit 1.2.0
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: PackageKit
Version: rawhide
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa
Depends On:
Blocks: F33BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2020-05-08 00:34 UTC by Adam Williamson
Modified: 2020-05-23 00:17 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-05-23 00:17:48 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github hughsie PackageKit issues 401 0 None open Offline updates broken with PackageKit 1.2.0 due to service enablement being lost in Meson conversion 2020-05-23 00:14:52 UTC

Description Adam Williamson 2020-05-08 00:34:42 UTC
Since PackageKit 1.2.0 landed in Rawhide, the openQA test that checks GNOME offline updates work is failing.

The test works by replacing the real python3-kickstart with a dummy, low-versioned replacement, then running GNOME Software, going through the update process, and checking that the real python3-kickstart got installed as an update. But since the new PackageKit appeared, it doesn't - we still have the dummy package installed after we've gone through the whole 'reboot to install updates' phase.

I'm blaming PackageKit as nothing else relevant seems to have changed in the last couple of composes - not systemd, not gnome-software, not DNF bits.

The system journal seems to show the upgrade boot running, reaching the relevant targets without really doing anything much, then shutting down and booting back to the regular system. Here's an extract:

May 07 17:09:17 localhost.localdomain systemd[1]: Reached target Offline System Update (Pre).
May 07 17:09:17 localhost.localdomain systemd[1]: Starting Updates device firmware whilst offline...
May 07 17:09:18 localhost.localdomain systemd[1]: fwupd-offline-update.service: Succeeded.
May 07 17:09:18 localhost.localdomain systemd[1]: Finished Updates device firmware whilst offline.
May 07 17:09:18 localhost.localdomain audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_>
May 07 17:09:18 localhost.localdomain audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u>
May 07 17:09:18 localhost.localdomain systemd[1]: Reached target Offline System Update.
May 07 17:09:18 localhost.localdomain systemd[1]: Starting Remove the Offline System Updates Symlink...
May 07 17:09:18 localhost.localdomain rm[670]: removed '/system-update'
May 07 17:09:18 localhost.localdomain systemd[1]: system-update-cleanup.service: Succeeded.
May 07 17:09:18 localhost.localdomain systemd[1]: Finished Remove the Offline System Updates Symlink.
May 07 17:09:18 localhost.localdomain systemd[1]: Startup finished in 3.209s (kernel) + 5.329s (initrd) + 7.181s (use>
May 07 17:09:18 localhost.localdomain audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_>
May 07 17:09:18 localhost.localdomain audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u>
May 07 17:09:18 localhost.localdomain systemd[1]: systemd-ask-password-plymouth.path: Succeeded.
May 07 17:09:18 localhost.localdomain systemd[1]: Stopped Forward Password Requests to Plymouth Directory Watch.
May 07 17:09:18 localhost.localdomain systemd[1]: Stopped target Sound Card.
May 07 17:09:18 localhost.localdomain systemd[1]: Stopped target Offline System Update.
May 07 17:09:18 localhost.localdomain systemd[1]: Stopped target Offline System Update (Pre).

I'll attach a full /var/log tarball. Proposing as a Beta blocker: "The installed system must be able appropriately to install, remove, and update software with the default tool for the relevant software type in all release-blocking desktops (e.g. default graphical package manager). This includes downloading of packages to be installed/updated."

Comment 1 Adam Williamson 2020-05-08 00:41:23 UTC
This line in the spec got commented out in the 1.2.0 spec file update:

%{_unitdir}/system-update.target.wants/

that sort of suggests that the build stopped putting files in that directory. Which seems a lot like it might be the problem here. In PackageKit-1.1.13-2.fc32.x86_64 , that directory has these files:

[adamw@adam PackageKit (master %)]$ ls /usr/lib/systemd/system/system-update.target.wants/
dnf-system-upgrade.service    grub-boot-indeterminate.service
fwupd-offline-update.service  packagekit-offline-update.service

...but in the 1.2.0 build, as the spec file implies, the directory just went missing and all those entries are gone. Which, you can see how that would result in system-update.target not doing much.

Comment 2 Adam Williamson 2020-05-08 15:28:21 UTC
Correction - only packagekit-offline-update.service actually belong(s/ed) to PackageKit, the other three on my local machine come from other packages. But packagekit-offline-update.service not being in that directory is the problem here.

Seems this is an upstream bug, the ability to install the .wants link was simply lost in the meson transition. The old autotools files had this:

https://github.com/hughsie/PackageKit/blob/PACKAGEKIT_1_1_13/data/Makefile.am#L46-L49

but the new meson.build does not appear to have any equivalent. It only installs the service file to /usr/lib/systemd/system, it doesn't deploy the symlink that actually gets the service to run when it should.

Comment 3 Adam Williamson 2020-05-08 15:39:20 UTC
I'd send a patch but I'm not sure what the Recommended Way to do this with meson would be. I can't find any kind of nice 'systemd unit' integrations, and even creating symlinks seems to be missing from Meson, with a couple of issues with three year histories:

https://github.com/mesonbuild/meson/issues/1602
https://github.com/mesonbuild/meson/pull/1768

systemd itself seems to have a little script that ultimately just runs ln:
https://github.com/systemd/systemd/blob/master/units/meson-add-wants.sh

so I guess maybe that's all we can do too?

Comment 4 Adam Williamson 2020-05-08 15:52:34 UTC
OK, so one way we could do this would be to revert this commit:

https://github.com/hughsie/PackageKit/commit/551a85fa632727e6fa3559ff7814fb159d345247

and just enable the service in the RPM spec (other distros would have to do the same in their respective packages). The justification for that commit has kind of gone, because systemd itself now has a backup service that wipes the /system-update marker file if it still exists. That's /usr/lib/systemd/system/system-update-cleanup.service , it is the thing you can see wiping the marker file in the log extract above:

May 07 17:09:18 localhost.localdomain systemd[1]: Starting Remove the Offline System Updates Symlink...
May 07 17:09:18 localhost.localdomain rm[670]: removed '/system-update'
May 07 17:09:18 localhost.localdomain systemd[1]: system-update-cleanup.service: Succeeded.
May 07 17:09:18 localhost.localdomain systemd[1]: Finished Remove the Offline System Updates Symlink.

...which is why the tests don't get trapped in a reboot loop even though packagekit-offline-update.service doesn't fire.

Comment 5 Adam Williamson 2020-05-08 16:42:42 UTC
So I've fixed this in the downstream spec for now, by just creating the symlink at the end of %install:
https://src.fedoraproject.org/rpms/PackageKit/c/66098b111d04f1441746cc0ff6ebf7cfe2e4803b?branch=master
and done a build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=44229804
so I'll mark this ON_QA and close it if the fix works. We can use the upstream issue to work on a permanent fix.

Comment 6 Adam Williamson 2020-05-23 00:17:48 UTC
Rawhide tests between 0509 and 0513 passed, so that confirms this is fixed, closing.


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