Closed thmo closed 1 year ago
Thanks, same issue on Void Linux (fwupd 1.8.1), same machine T460s.
What's the Management Engine get-devices output before the update was applied please?
in my case, it was here https://github.com/fwupd/firmware-lenovo/issues/89#issuecomment-1270618963
so it was version 3093041278
In my case https://github.com/fwupd/firmware-lenovo/issues/208#issuecomment-1296186509, so version 3093041278.
That's correctly assigned "triplet" -- and fwupd should have got the "convert the random integer value to a.b.c" from the metadata. If you do "fwupdmgr refresh" to get the metadata from the lvfs remote, did the ME device get assigned a a.b.c value?
I don't think so. Cannot go back, but I am almost 100% sure that I always used refresh --force
.
After the manual update (i.e., now), it is also displayed as 3093106915 and not as triplet.
it is also displayed as 3093106915 and not as triplet.
Can you get the log of sudo fwupdtool --verbose get-devices --plugins uefi_capsule
please -- we should see lots of changing version....
type messages.
e.g. I see:
19:05:57.680 FuDevice 349bb341230b1a86e5effe7dfe4337e1590227bd device overwriting name value: UEFI Device Firmware->Intel Management Engine
19:05:57.680 FuDevice changing verfmt for 349bb341230b1a86e5effe7dfe4337e1590227bd: number->triplet
19:05:57.680 FuDevice changing version for 349bb341230b1a86e5effe7dfe4337e1590227bd: 3779135409->225.65.1969
Nope. I see:
# fwupdtool --verbose get-devices --plugins uefi_capsule |& grep 'changing version for'
19:40:15:0574 FuDevice changing version for a45df35ac0e948ee180fe216a5f703f32dda163f: 65593->0.1.57
19:40:15:0704 FuDevice changing version for 2292ae5236790b47884e37cf162dcf23bfcd1c60: 65550->0.1.14
but
# fwupdtool --verbose get-devices --plugins uefi_capsule |& grep 3093106915
Version: 3093106915
19:41:16:0263 FuEngine ignoring 184.80.3746 < 3093106915
19:41:16:0263 FuEngine ignoring 184.79.3722 < 3093106915
19:41:16:0263 FuEngine ignoring 184.77.3664 < 3093106915
19:41:16:0264 FuEngine ignoring 184.70.3626 < 3093106915
19:41:16:0264 FuEngine ignoring 184.65.3590 < 3093106915
19:41:16:0264 FuEngine ignoring 184.60.3561 < 3093106915
19:41:16:0264 FuEngine ignoring 184.55.3510 < 3093106915
19:41:16:0264 FuEngine ignoring 184.50.3339 < 3093106915
19:41:16:0264 FuEngine ignoring 182.29.3287 < 3093106915
19:41:16:0264 FuEngine ignoring 182.10.1196 < 3093106915
19:41:16:0264 FuEngine ignoring 184.93.4323 < 3093106915
19:41:16:0264 FuEngine ignoring 184.92.4222 < 3093106915
19:41:16:0264 FuEngine ignoring 184.90.3987 < 3093106915
Version: 3093106915
which indeed looks like it's comparing apples and oranges.
And btw:
19:44:36:0207 FuMain FuUefiNvramDevice:
DeviceId: 349bb341230b1a86e5effe7dfe4337e1590227bd
Name: Intel Management Engine
Guid: 03d3297b-3851-4379-95ad-12e21a96c80a
Summary: UEFI ESRT device
Plugin: uefi_capsule
Protocol: org.uefi.capsule
Flags: internal|updatable|require-ac|supported|registered|needs-reboot|usable-during-update
Vendor: Lenovo
VendorId: DMI:LENOVO
Version: 3093106915
VersionLowest: 1
VersionFormat: number
VersionRaw: 0xb85d10e3
VersionLowestRaw: 0x00000001
Created: 2022-11-10
UpdateState: success
has VersionFormat number, not triplet.
I've found a metadata-generation thinko, I'm just testing a fix on the LVFS.
FYI: https://gitlab.com/fwupd/lvfs-website/-/commit/7d2edccc674e3ec9ccbb7f47555e9f6d2fd5d4a6
I'm deploying it now, and the 2nd half is running the new fsck action: https://gitlab.com/fwupd/lvfs-website/-/commit/894337d494c85f41a71ab95d3e08260953002a85
I've deployed that, and run the fsck action. @thmo can you try a fwupdmgr refresh --force
and try again to get the version number please.
Thanks, it now works for me
├─Intel Management Engine:
│ Device ID: 349bb341230b1a86e5effe7dfe4337e1590227bd
│ Summary: UEFI ESRT device
│ Current version: 184.93.4323
│ Minimum Version: 0.0.1
│ Vendor: Lenovo (DMI:LENOVO)
│ Update State: Success
I'll let OP confirm.
Woo! That's a good way to finish Friday.
Confirmed:
# fwupdtool --verbose get-devices --plugins uefi_capsule |& grep 'changing version for'
17:59:11:0624 FuDevice changing version for a45df35ac0e948ee180fe216a5f703f32dda163f: 65593->0.1.57
17:59:11:0764 FuDevice changing version for 349bb341230b1a86e5effe7dfe4337e1590227bd: 3093106915->184.93.4323
17:59:11:0796 FuDevice changing version for 2292ae5236790b47884e37cf162dcf23bfcd1c60: 65550->0.1.14
─Intel Management Engine:
│ Device ID: 349bb341230b1a86e5effe7dfe4337e1590227bd
│ Summary: UEFI ESRT device
│ Current version: 184.93.4323
│ Minimum Version: 0.0.1
│ Vendor: Lenovo (DMI:LENOVO)
│ Update State: Success
│ GUID: 03d3297b-3851-4379-95ad-12e21a96c80a
│ Device Flags: • Internal device
│ • Updatable
│ • System requires external power source
│ • Supported on remote server
│ • Needs a reboot after installation
│ • Device is usable for the duration of the update
Thanks for fixing!
This is a follow-up for https://github.com/fwupd/firmware-lenovo/issues/208#issuecomment-1309874473.
On Fedora 36 at least (and maybe on other OS),
fwupdmgr
does not automatically update to the version 11.8.93.4323 aka 184.93.4323 aka 3093106915.The
fwupdmgr refresh --force
andfwupdmgr update
combo does nothing. Downloading the cab from https://fwupd.org/lvfs/devices/com.lenovo.ThinkPadN1CRN.firmware however and installing withfwupdmgr --allow-older --allow-reinstall install <cab_filename.cab>
works.The reason is unclear. Maybe a version check fails due to different version formatting (grouping), but this is a wild guess.
/cc @kmauleon @hughsie @dkwo