From fwupd 1.2.11 fwupd.service will not start if /var/cache/fwupd does not already exist, which is the case on a fresh install. So on fresh F31 installs, fwupd.service will not run, which in turn breaks GNOME Software. This is why the GNOME update test fails on openQA since 1.2.11 went stable. This was broken by https://github.com/fwupd/fwupd/commit/2bf3a372df6610d274155ae4085aa762e8a3107a , which results in /var/cache/fwupd being in the ReadWritePaths line in fwupd.service: ReadWritePaths=/var/lib/fwupd /var/cache/fwupd /etc/fwupd /etc/fwupd/remotes.d -/boot/efi -/efi/EFI -/boot/EFI but if a service includes a non-existent directory in ReadWritePaths, that service will not start. This is considered correct behaviour by systemd (it's not considered a bug), so it is the software's job to ensure all paths referred to in ReadWritePaths exist. I'm proposing this as a Final blocker per Basic criterion "The installed system must be able appropriately to install, remove, and update software with the default console tool for the relevant software type (e.g. default console package manager). This includes downloading of packages to be installed/updated" - https://fedoraproject.org/wiki/Basic_Release_Criteria#Installing.2C_removing_and_updating_software . For now I'll send out a build of fwupd which creates and ships an empty /var/cache/fwupd, that should resolve the issue.
Upstream suggesting backporting a couple of patches from master to fix this: https://github.com/fwupd/fwupd/commit/00fdf83cd662291c40ebda942c9d08abe997b699 https://github.com/fwupd/fwupd/commit/277c196369f86f65f8831a049d01fab84cee4b1f that *does* work...but only with SELinux in permissive mode, because it blocks the creation of the directory: type=AVC msg=audit(1570055823.561:216): avc: denied { create } for pid=1942 comm="(fwupd)" name="fwupd" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=dir permissive=0 CCing lvrabec for that. So, we can either do the backport and also request an SELinux policy change, or we can just go with the 'make the package ship /var/cache/fwupd' approach for now as it avoids the need for an SELinux policy change. Hughsie, WDYT?
> So, we can either do the backport and also request an SELinux policy change, or we can just go with the 'make the package ship /var/cache/fwupd' approach for now as it avoids the need for an SELinux policy change. Hughsie, WDYT? Can we do both?
Well, we could but I prefer that package will ship /var/cache/fwupd.
To answer Richard, I don't see any reason that doing both would break anything.
Discussed during the 2019-10-07 blocker review meeting: [0] The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criterion: "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)." [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-10-07/f31-blocker-review.2019-10-07-16.02.txt
> but I prefer that package will ship /var/cache/fwupd. I don't think that's a long term solution. I think it's still valid to do "rm -rf /var/cache/*" and have a working system -- systemd must be allowed to create these if they do not exist when the service is started.
Selinux issue filed: https://bugzilla.redhat.com/show_bug.cgi?id=1759554
FEDORA-2019-ed9f38086c has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-ed9f38086c
FWIW, FHS says: "/var/cache is intended for cached data from applications. Such data is locally generated as a result of time-consuming I/O or calculation. The application must be able to regenerate or restore the data...Files located under /var/cache may be expired in an application specific manner, by the system administrator, or both. The application must always be able to recover from manual deletion of these files (generally because of a disk space shortage)" https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s05.html that doesn't ever quite explicitly say that apps should survive the removal of *directories* in /var/cache, but it does quite strongly imply it, I'd say.
fwupd-1.2.11-2.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-ed9f38086c
kparal verified the fix in fwupd-1.2.11-2.fc31 .
fwupd-1.2.11-2.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.
The same bug showed up in F30 because 1.2.11-1 was sent out as an update for it. I just sent a 1.2.11-2 update with the fix cherry picked from F31 branch: https://bodhi.fedoraproject.org/updates/FEDORA-2019-cb9dd3e345