Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1757948 - fwupd.service fails to start if /var/cache/fwupd doesn't exist (e.g. clean install)
Summary: fwupd.service fails to start if /var/cache/fwupd doesn't exist (e.g. clean in...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: fwupd
Version: 31
Hardware: All
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa AcceptedBlocker
Depends On:
Blocks: F31FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2019-10-02 19:36 UTC by Adam Williamson
Modified: 2019-10-16 01:52 UTC (History)
7 users (show)

Fixed In Version: fwupd-1.2.11-2.fc31
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-10 18:26:56 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Adam Williamson 2019-10-02 19:36:39 UTC 
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.
Comment 1 Adam Williamson 2019-10-02 22:42:32 UTC 
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?
Comment 2 Richard Hughes 2019-10-04 10:28:09 UTC 
> 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?
Comment 3 Lukas Vrabec 2019-10-04 10:45:54 UTC 
Well, we could but I prefer that package will ship /var/cache/fwupd.
Comment 4 Adam Williamson 2019-10-04 14:15:20 UTC 
To answer Richard, I don't see any reason that doing both would break anything.
Comment 5 Geoffrey Marr 2019-10-08 06:13:40 UTC 
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
Comment 6 Richard Hughes 2019-10-08 13:24:33 UTC 
> 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.
Comment 7 Richard Hughes 2019-10-08 13:35:28 UTC 
Selinux issue filed: https://bugzilla.redhat.com/show_bug.cgi?id=1759554
Comment 8 Fedora Update System 2019-10-08 14:18:16 UTC 
FEDORA-2019-ed9f38086c has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-ed9f38086c
Comment 9 Adam Williamson 2019-10-08 15:19:23 UTC 
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.
Comment 10 Fedora Update System 2019-10-09 03:25:22 UTC 
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
Comment 11 František Zatloukal 2019-10-09 13:06:28 UTC 
kparal verified the fix in fwupd-1.2.11-2.fc31 .
Comment 12 Fedora Update System 2019-10-10 18:26:56 UTC 
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.
Comment 13 Adam Williamson 2019-10-16 01:52:35 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.