On my system I mount the UEFI system partition on /boot (yes, this does mean my kernel images reside on a VFAT file system; nothing seems to mind though) and keep it read-only except for when it is necessary to update something. On the other hand, puts any updates that come in the form of UEFI capsules, as well as the capsule loader itself, in /boot/EFI/gentoo/fw/. Having recently attempted to update IME firmware via fwupd without having first remounted /boot read-write, I found out that the daemon keeps thinking said file system is read-only even if it isn't. In other words (I am recalling the error messages from memory so they may not be 100% accurate but both the paths and the "read-only filesystem" bit are correct): # fwupdmgr update [...] Cannot create directory /boot/EFI/gentoo/fw: Read-only filesystem # mount /boot -o remount,rw # fwupdmgr update [...] Cannot create directory /boot/EFI/gentoo/fw: Read-only filesystem # mkdir -p /boot/EFI/gentoo/fw # fwupdmgr update [...] Cannot create file /boot/EFI/gentoo/fw/fwupd64.efi: Read-only filesystem The workaround is simple enough, just kill the running fwupd and when it gets restarted by the next invocation of fwupdmgr it will see /boot is read-write now .
Would you mind bringing this to upstream's attention please?
Still an issue with latest fwupd release?
1.2.11 still had it, will try 1.3.10 as soon as there are any updates for fwupd to install and notify upstream if the problem persists.
Finally managed to correlate me remembering about this issue with there being UEFI capsule-based updates available for one of my systems. Better late than never...
Seems this is simply the way file-system name spaces, as used for FS protection in systemd units, work.
