requirement error in cab for org.freedesktop.fwupd prevents downgrade to resolve broken lvfs upgrade #7258
Labels
Comments
|
Inside the .exe I can see these contents; I am thinking I am interested in TglMe_15_0_47_2521_Lp_Corp.cap however, a cab file probably has some meta, that is missing from the direct capsule, if I were to guess. CLI seems to confirm the missing magic, which I assume is where the broken fwupd dependency is defined in the cab I can not seem to use. |
|
You can use |
|
Okay, installing the blob directly worked great. I know from the fwupdmgr release note breadcrumbs during the breaking upgrade that my system uses the Corporate ME engine, as opposed to the Consumer, so my confidence on the right capsule was high. The reboot followed by the long UEFI update process, so it definately got the AMT component as well. In hindsight, a safer option would have been to use cabextract and force the blob in, working around why I originally filed this bug; Rather than to push forward to a version not yet in the online database. But it worked, and it solved the broken external monitor enumeration on boot, which is great. Below is my new enumerated firmware, noting my lid is closed since my monitors are working on boot now. Following up on the original intent, to make fwupdmgr follow published instructions for older versions of the tool, like those included in the readme that comes along with the Lenovo cab file for manual installation, I did go and extract the cab, and look at the meta. There is no specification for the fwupd version in the firmware.metainfo.xml, so the dependency, it would seem on fwupd <= 1.1.0 stems from newer fwupd versions when other things are defined in the meta, likely the version, given the output "firmware with version" which is clearly not an issue with older fwupd included in Ubuntu LTS 20.04. It seems logical, another --allow-xxxx should be added for this new constraint to allow for compatability with existing documentation and to allow manual updates with older .cab files, that were packaged before the change to fwupd logic, to be applied without soo much effort. Lenovo for their part, releasing fixes for Windows without making simple tweaks to their Linux equivalent cab could be seen as just lazy, but the issue is more likely a set of missing QA procedures to catch this problem. I'll do my part to file a ticket with them, letting them know they can safely update and release a new cab supporting Ubuntu 24.04. |
I'm confused -- what's wrong with installing older files with a new fwupd? |
|
It causes the But not in 24.04, where meta with a version defined, spits out this failure with no obvious way to override and get the previous behavior. Assuming I have not made an error, it seems like a problem for any existing cab files before the change. |
|
I think this lets us detect this on the LVFS: https://gitlab.com/fwupd/lvfs-website/-/commit/81d5e5258ddd393fbdb34b0d90e49fef92522b1c -- deploying now. |
|
If you re-download https://fwupd.org/downloads/8f3899045a2d6024c6aee493632e53335b601bcea3fd149d61db9f345227eff1-Lenovo-ThinkPad-X1YogaGen6X1CarbonGen9-CorporateMEFirmware-15.0.42.2235.cab does it install locally now? |
|
Hi - Lenovo premiere support pointed me at this (I assume this got escalated to them?) Seems to me there are two problems - can I confirm my understanding:
If I've missed anything important let me know. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Lenovo continues to ship Intel ME updates via fwupdmgr that break external monitors (my case is dual 4K/60Hz via TB3 on a Dell WD19TB). The upgrade, touting several CVE fixes, works. There seems to be no simple or workable downgrade path on Linux to rollback, even manually, due to some gotcha with .cab file dependencies.
Steps to Reproduce
Expected behavior
Normal upgrade, with an ability to downgrade via lvfs or via local cab file. Neither is an option, so it seems fwupdmgr will require us to deploy Windows to revert this upgrade, which isn't a great option.
fwupd version information (Ubuntu 24.04 installed via apt)
Additional questions
Options we are considering, to try to avoid deploying Windows to fix this, are
a) try to get the .cab out of the newer .exe update for windows, and apply using fwupdmgr (if that is possible)
b) try to downgrade the whole BIOS, possibly with a version that comes with an older ME firmware as well (some research required, might introduce new dependency issues)
The text was updated successfully, but these errors were encountered: