[SRU] support new cab and new docking firmware upgrade in fwupd 1.2.10

Bug #1820768 reported by Yuan-Chen Cheng on 2019-03-18
30
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OEM Priority Project
Critical
Yuan-Chen Cheng
fwupd (Ubuntu)
High
Unassigned
Bionic
High
Unassigned
fwupd-signed (Ubuntu)
High
Unassigned
Bionic
High
Unassigned
libxmlb (Ubuntu)
High
Unassigned
Bionic
High
Unassigned

Bug Description

* Impact

Bios vendor is pushing to put the new design into cab file, and also new docking DW19 needs the new fwupd to support it.

That needs new fwupd to support.

* Background:
 1. most user does firmware update via gnome-software and it talk to fwupd.
 2. only very very limited user will call /usr/bin/fwupdate from the command line.
 3. the new fwupd will need a new fwupd-signed. So we will remove fwupdate-signed.

* Current test result before we have something in proposed channel:
 1. new fwupd works well with gnome-software, so we should be safe to go.
 2. for those very limited user, they can call /usr/lib/fwupd/fwupdate to replace /usr/bin/fwupdate. so it should be safe to remove fwupdate.

* Test case

I
1. install the new fwupd, and plugin the new docking - DW19.
2. fwupdmgr get-devices and check if all internal device can properly show
II.
1. If you can get new cab file, try to use fwupdmgr install XX.cab to see if can work properly.
III.
1. If you can get a machine that have some firmware update pending, try to go gnome-software, and click refresh with the new fwupd, you should be able to see the pending firmware showed there. Which proves that it can properly be integrated with gnome. (ycheng-twn have a laptop with that condition, and he can verify that one

* Regression potential

Since the upstream maintainer is back up this upgrade, and he also works in a major computer vendor and works closely with the BIOS team, it should be fairly low risk.

Changed in oem-priority:
importance: Undecided → Critical
summary: - [SRU] support new cab format by upgrading to version 1.2.5
+ [SRU] support new cab format by upgrading fwupd to version 1.2.5
description: updated
Changed in oem-priority:
status: New → Confirmed
assignee: nobody → Yuan-Chen Cheng (ycheng-twn)
Mario Limonciello (superm1) wrote :

To SRU fwupd 1.2.5 to bionic the following actions are needed.

1) libxmlb needs to be backported (which you can see was done in that branch that was linked).

2) libxmlb needs to be patched to build on an older meson. Patch available here; https://github.com/hughsie/libxmlb/commit/378e1c3049ec94f344c2d8f336e84b5a1b0fdb31

3) fwupd needs to be patched to build on an older meson. Patch available here; https://github.com/hughsie/fwupd/commit/c622d927d97226e96ed0ab8842819c3d3c1de5a0

Mario Limonciello (superm1) wrote :

4) fwupd-signed needs to be introduced

5) fwupd-signed needs to replace/transition fwupdate-signed

Changed in fwupd (Ubuntu):
status: New → Fix Released
Changed in fwupd-signed (Ubuntu):
status: New → Fix Released
Changed in libxmlb (Ubuntu):
status: New → Fix Released
Sebastien Bacher (seb128) wrote :

libxmlb backport uploaded to the bionic SRU queue, thanks Mario for the "build with the old meson" patch

Changed in fwupd (Ubuntu):
importance: Undecided → High
Changed in libxmlb (Ubuntu Bionic):
status: New → Fix Committed
Changed in fwupd-signed (Ubuntu Bionic):
importance: Undecided → High
Changed in libxmlb (Ubuntu Bionic):
importance: Undecided → High
Changed in fwupd (Ubuntu Bionic):
importance: Undecided → High
Changed in fwupd-signed (Ubuntu):
importance: Undecided → High
Changed in libxmlb (Ubuntu):
importance: Undecided → High
Changed in fwupd-signed (Ubuntu Bionic):
status: New → Fix Committed
Changed in fwupd (Ubuntu Bionic):
status: New → Fix Committed
Sebastien Bacher (seb128) wrote :

I didn't deal with fwupdate-signed but from past discussion I think we are going to want to remove this one to only have one signed binary in the archive. I don't think it's going to block the SRU to be accepted but would still be nice to handle it ... does anyone want to look at that one?

Unsure what's the deal with fwupdate then. Mario I guess you remember how upgrades were only in cosmic? Does fwupdate needs to get removed when fwupd is installed? Did you do anything to ensure the old one is not leftover on upgrade?

Steve Langasek (vorlon) wrote :

> 4) fwupd-signed needs to be introduced

> 5) fwupd-signed needs to replace/transition fwupdate-signed

Yes, this is going to be the part of this SRU that is going to need the most due diligence, because from an archive and key management point of view, we do not want to have both fwupd-signed and fwupdate-signed being updated in bionic, and we also do not want bionic users who have fwupdate-signed installed by default from main islanded where they cannot get fixes to this package.

So this needs to be treated as an exceptional SRU of fwupdate with a high standard of care.

summary: - [SRU] support new cab format by upgrading fwupd to version 1.2.5
+ [SRU] support new cab and new docking firmware upgrade in version 1.2.5
description: updated
summary: - [SRU] support new cab and new docking firmware upgrade in version 1.2.5
+ [SRU] support new cab and new docking firmware upgrade in fwupd 1.2.5
tags: added: originate-from-1806857

an archive admin should review all of these at the same time, since libxmlb/fwupd-signed are in source NEW

Rex Tsai (chihchun) on 2019-06-13
tags: added: oem-priority
Yuan-Chen Cheng (ycheng-twn) wrote :

per doing some investigation:

in bionic,

fwupdate-signed: /usr/lib/fwupdate/fwupx64.efi.signed
fwupdate: /usr/lib/fwupdate/fwupx64.efi

and there install script will install them to /boot/efi/EFI/ubuntu/

in disco, it becomes

fwupd-signed: /usr/lib/fwupd/efi/fwupdx64.efi.signed
fwupd: /usr/lib/fwupd/efi/fwupdx64.efi

for the machine I test, it does not install the file to any place under /boot/efi.

Yuan-Chen Cheng (ycheng-twn) wrote :

per check apt-cache show fwupd / fwupd-signed, I didn't find any conflict and break on fwupdate.

So maybe the transition is done by other methods per upgrade path from bionic to disco.

Yuan-Chen Cheng (ycheng-twn) wrote :

A firmware download from lvfs is in cab format.

We can use the command "fwupdmgr install [--allow-reinstall] file.cab", and a reboot to install it. [it could brick your computer, don't do it unless you have someone to save you.]

fwupd 1.0.9-0ubuntu2
libfwupd2:amd64 1.0.9-0ubuntu2

There is not libfwupd2-dev package.

We can also use gcab to extract firmware.bin from the cab file. You need to get guid from "fwupdate -l" and then command "fwupdate -a guid firmware.bin" and a reboot can install it. [it could brick your computer, don't do it unless you have someone to save you.]

fwupdate 12-3bionic2
fwupdate-signed 1.19bionic2+12-3bionic2
libfwup-dev:amd64 12-3bionic2
libfwup1:amd64 12-3bionic2

As replace fwupdate-signed by fwupd-signed, we also need to make sure the command "fwupdate -a guid firmware.bin" is compatiable with fwupd-signed per what I understand.

Yuan-Chen Cheng (ycheng-twn) wrote :

for #8, in disco, after using "fwupdmgr install xxx.cab", fwupdx64.efi does been installed in /boot/efi/EFI/ubuntu.

description: updated
Changed in oem-priority:
status: Confirmed → In Progress
Mario Limonciello (superm1) wrote :

Per comment #8 and #9, #12

I would like to clarify that the way it works with newer fwupd is that the binary is installed into the EFI system partition dynamically as needed rather than at install time. This means that only people that are performing firmware upgrades would have the file installed.

A sample link to the code in question that accomplishes this:
https://github.com/hughsie/fwupd/blob/master/plugins/uefi/fu-uefi-bootmgr.c#L341

Where are we at in an terms of review on this SRU?

Yuan-Chen Cheng (ycheng-twn) wrote :

this sru will break fwupdate package in bionic/main. However fwupdate is in disco/universe.

Given that, maybe we shall go a clean break.

Yuan-Chen Cheng (ycheng-twn) wrote :

Per information from Mario, we need the new fwupd efi app from the new fwupd. However it's not compatiable with existing fwupdate. That's how fwupd break fwupdate.

new fwupd does provide compatiable command, which live in /usr/lib/fwupd/fwupdate.

Hello Yuan-Chen, or anyone else affected,

Accepted libxmlb into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libxmlb/0.1.8-1~ubuntu18.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

tags: added: verification-needed verification-needed-bionic

libxmlb is accepted now into -proposed which is ok, and fwupd-signed has also been accepted into -proposed but is dep-wait because the corresponding fwupd has not yet been accepted, so this is also ok (though the accepting of fwupd-signed may have been an accident).

Accepting fwupd is BLOCKED until there is a clear plan for how we will migrate users from fwupdate to fwupd in SRU, with mitigation of any risk of regressions.

Changed in fwupd (Ubuntu Bionic):
status: Fix Committed → Incomplete
description: updated
description: updated
Mario Limonciello (superm1) wrote :

I'm unclear on the specifics goals required in terms of fwupdate compatibility during this transition.
1) 1 signed EFI binary in bionic?
2) Command line compatibility?
3) Other?

Steve, can you and/or Lukasz please clarify.

Currently in bionic:
1. fwupdate provides /usr/bin/fwupdate which is a command line debugging tool.
2. fwupdate provides an EFI application fwupx64.efi that gets installed into the ESP at deb install time
3. fwupdate-signed provides a signed version of <2>.
4. libfwup1 provides a library for applications to link with. In the archive the only consumer of this is fwupd.

So which aspects are important to keep?
1. new fwupd provides /usr/lib/fwupd/fwupdate and /usr/lib/fwupd/fwupdtool which collectively support all the same functions as /usr/bin/fwupdate, but not identical syntax.
As an example /usr/bin/fwupdate supported something like # fwupdate install -a GUID file.cap
For fwupd this is /usr/lib/fwupd/fwupdtool install-blob file.cap GUID
2. new fwupd provides the EFI application fwupdx64.efi and it gets installed to ESP at first use.
3. new fwupd-signed provides signed version of <2>
4. libfwup1 library is not needed anymore.

---

Is the requirement strict command line compatibility? Then to me I think the right answer is:
1) Rev fwupdate-signed as part of this SRU, make it a transition package.
2) In that transition package include a script in /usr/bin/fwupdate that either:
a) explains that this tool has been migrated and how to use the replacement tool
or
b) provides same syntax for a few common scenarios (such as install or debugging)
3) Make the fwupdate-signed package conflict/replace fwupdate package

This will accomplish not having two signed EFI binaries in the archive anymore and let the command line tool still work from the previous path.

summary: - [SRU] support new cab and new docking firmware upgrade in fwupd 1.2.5
+ [SRU] support new cab and new docking firmware upgrade in fwupd
+ 1.2.5/1.2.10

PPA for fwupd 1.2.10.

https://launchpad.net/~ycheng-twn/+archive/ubuntu/fwupd-1.2.10-1

Beware that it add an upstream patch debian/patches/disable-cert-time-check-in-self-test.patch. Without it, both 1.2.5 and 1.2.10 won't build today.

summary: - [SRU] support new cab and new docking firmware upgrade in fwupd
- 1.2.5/1.2.10
+ [SRU] support new cab and new docking firmware upgrade in fwupd 1.2.10
Bearsh (bearsh) wrote :

Yuan-Chen, I installed fwupd from your ppa. Logitech fw-update works, thanks.
unfortunately system firmware on my xps13 does not as fwupd complains about missing signed bootloader:
"UpdateError: missing signed bootloader for secure boot: /usr/lib/fwupd/efi/fwupdx64.efi.signed cannot be found"

I hope, once working correctly this ends up either in ubuntu bionic or at least in 'dell-support' (as 1.2.5-1~somerville1 there can't handle logitech :()

Yuan-Chen Cheng (ycheng-twn) wrote :

@Bearsh, Thank you for testing.

You also need to install fwupd-signed so it can work. Currently it only avaialbe to 1.2.5 ppa which is https://launchpad.net/~ycheng-twn/+archive/ubuntu/fwupd-14

Yuan-Chen Cheng (ycheng-twn) wrote :

fwupdate has been dropped from eaon in bug #1841744.

It's also said discussed in debian to do so in debian.

https://salsa.debian.org/efi-team/fwupdate/commit/b4daba89c567d4cf52f5deaab1ea2ee13039d03f

description: updated
description: updated
Mario Limonciello (superm1) wrote :

FYI That did sync back to Ubuntu eoan as well. I think that as part of transitioning 18.04, it should come back to 18.04 with the updated SRU.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers