Hello, The existing agreed upon SRU policy for firmware updates (firmware-updates - Ubuntu Wiki <https://wiki.ubuntu.com/firmware-updates>) allows for updating the fwupd/fwupdate stack as necessary within a given stable release series. This strategy has worked well for a good period of time, but recently there have been several things that have changed putting it's efficacy into question.
First: Although OEMs are enabling new hardware with LTS releases, new fwupd plugins are developed that can support firmware updates for such hardware only in newer fwupd versions. This means that even though an OEM launches a system with Ubuntu LTS typically customers won't be able to get firmware updates for new device types until the next LTS release. To give you an idea how many new device types have been introduced: Fwupd 1.3.x supported 44 plugins Fwupd 1.4.x supported 47 plugins Fwupd 1.5.x supports 66 plugins >From this limitation it's not possible to distribute a security update to some devices that are in the field. Some example issues that this causes (not at all complete): 1) To be more Agile, Dell can distribute microcode security upgrades separately from BIOS upgrades for selected systems that ship with Ubuntu, but this requires fwupd 1.4.0 or later to be upgradable. 2) Synaptics has a fingerprint reader that can be updated, but it requires fwupd 1.4.6 or later. This issue is summarized in Bug #1900935 “Support to upgrade Synaptic fingerprint firmware f...” : Bugs : fwupd package : Ubuntu (launchpad.net) <https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1900935> Second: As fwupd and LVFS have grown, a larger CDN infrastructure has been adopted. This has been largely a good thing, but it's shown some problems related to the timing of the CDN cache being updated. If poor timing is adopted between the signing of the firmware metadata and creation of that metadata a bad pair will land on some of the CDN leading to users unable to perform firmware upgrades. This issue has been compounded by the fact that fwupd 1.3.x has introduced support to display in the motd the availability of firmware upgrades. This is accomplished by a systemd service that will refresh metadata if it's not already updated by another client and then update the motd. If this process fails due to the CDN having invalid data the service has a "1" return code and some users have complained on this issue when it occurs. This has been fixed in the 1.4.x and later version via a new architecture for metadata signing and distribution. Individual metadata will not be invalidated, preventing cache misses or things getting out of sync. All of this is summarized in Bug #1909603 “Occasionally fwupd-refresh.service: Failed with re...” : Bugs : fwupd package : Ubuntu (launchpad.net) <https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1909603> as discussed in larger detail in other bugs and complaints it links to in upstream. Because of this collection of issues and the expectation that more devices will be supported by newer versions of the stack again in the future, I'm wondering if we should adopt a different policy for firmware update utilities to allow moving to a newer version of the stack in LTS releases. I would like input from the technical board on this. One more thing I'd like to note: If moving to a newer release is the direction that the technical board chooses to go, moving to a newer version of the stack (1.4.x or later) in Ubuntu 20.04 will require a MIR for libjcat. This MIR already happened for later releases. Thanks, -- Mario Limonciello supe...@ubuntu.com
-- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
