jantari
commented
1 year ago Hi, thanks for the issue report.
On that computer please run Get-LSUpdate -Verbose -Debug and post the output to help diagnose the problem. Thanks!
Closed swoonhusker1 closed 1 year ago
jantari
commented
1 year ago Hi, thanks for the issue report.
On that computer please run Get-LSUpdate -Verbose -Debug and post the output to help diagnose the problem. Thanks!
swoonhusker1
commented
1 year ago jantari
commented
1 year ago Thank you, it looks like the problem is the unsupported _Firmware test in the package. I have to add support for that, can you run:
Get-PnpDevice -Class Firmware | Format-List *
Get-PnpDevice -InstanceId 'UEFI\*' | Format-List *on the same machine and post the results?
swoonhusker1
commented
1 year ago jantari
commented
1 year ago Thanks - can you download the develop branch version of LSUClient and try with that? I've added support for the _Firmware test and I think it should solve this issue. It would be great if you could validate it.
swoonhusker1
commented
1 year ago Sorry, I must be doing something wrong. I'm having trouble importing the develop branch module. Can you help me figure out what I'm doing wrong? here is what I've tried:
Here is what I have in the folder that I'm trying to import:
jantari
commented
1 year ago That reads like your PowerShell ExecutionPolicy is set to RemoteSigned and the script isn't run because it's marked as being downloaded from the internet and thus potentially untrusted.
You could either change the executionpolicy for just one PowerShell window you have open (I wouldn't change it permanently, RemoteSigned is a good setting generally):
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope Process -Forceor you can mark the script files in that directory as safe/not downloaded from the internet with Unblock-File as described in this example.
swoonhusker1
commented
1 year ago It looks like it worked and it didn't return the "Intel Management Engine Firmware" but it did return the Thermal Solution Driver.
I tried importing the regular LSUClient module and it no longer returns the "Intel Management Engine Firmware" either. So I'm confused why that is no longer being required even with the regular module.
Here is what I see with the dev module you asked me to try:
Here is what I see when I tried using the normal module again:
swoonhusker1
commented
1 year ago Here is the output of the same command using your Dev Module:
It looks like it doesn't have the line that says "VERBOSE: Unsupported dependency encountered: Firmware".
I do see "VERBOSE: Unsupported dependency encountered: _Coreq" in it though. Not sure what that means.
swoonhusker1
commented
1 year ago It looks like Lenovo made a change to their Fwdetect Tool as well, so that is why it didn't show up in the normal module anymore-
jantari
commented
1 year ago Comparing the old and the new package, it looks like they didn't so much as update the fwdetect tool but rather newly added it as it wasn't used at all previously. This must be the reason the update is not returned anymore by the current 1.5.0 version of LSUClient either anymore.
Unfortunately this means we can't validate that the new _Firmware support works but at least the problem is fixed 😄
I will consider this fixed and close the issue when the next version of LSUClient releases.
animentork
commented
1 year ago Several things regarding your commit f10f906:
$Dependency.Version instead of $Dependency.Version.'#text', which gives no result. Edit: But it's necessary when other attributes like hex2dec are set, so we need to differentiate:
$dependency_version = if ($Dependency.Version.psobject.Properties.Value -icontains '#text') {$Dependency.Version.'#text'} else {$Dependency.Version}&REV_ - are you sure that's the case? Otherwise, IndexOf() would return -1 and produce a bogus PnPDeviceFirmwareRev:
[string]$PnpDeviceFirmwareRev = $PnpDevice.HardwareID[0].Substring($PnpDevice.HardwareID[0].IndexOf('&REV_') + 5)
But maybe that's intended, because that would also translate to not matching the Dependeny.Version?
# Is 63 greater than 47?
[int] ("0x{0}" -f "3f") -gt [int] ("0x{0}" -f "2f")
True[int] ("0x{0}" -f "3f") -gt [int] ("0x{0}" -f "5f") False
Could that be a step in the right direction?if ([int] ("0x{0}" -f $PnpDeviceFirmwareRev.Trim('^')) -ge [int] ("0x{0}" -f $Dependency.Version)) {
I hope you don't mind me digging through your code ...
Edit: It's really HardwareIDs with a plural s for _Firmware. Lenovo and consistency ...
Edit2: Okay, $Dependency.Version must be checked for attributes first ...Oh, don't worry I'm happy when someone else is double-checking the code, so thank you!
Regarding your first point, I had recognized the problem and fixed it in https://github.com/jantari/LSUClient/commit/7bfbef10477ca592dc5442b91b7525879def21b6 already. The inconsistent deserialization surprised me as well:
…\Programmieren\PowerShell\lsuclient on develop [?]
❯ ([xml]'<Version>Example</Version>').Version.GetType()
IsPublic IsSerial Name BaseType
-------- -------- ---- --------
True True String System.Object
…\Programmieren\PowerShell\lsuclient on develop [?]
❯ ([xml]'<Version attr="test">Example</Version>').Version.GetType()
IsPublic IsSerial Name BaseType
-------- -------- ---- --------
True False XmlElement System.Xml.XmlLinkedNodeThe Microsoft example script I linked in the comment (this) suggests in a comment that:
# Firmware resource devices have two Hardware IDs. One with the revision # and one without. We are interested the one with the Revision and that is the # first one.
I kind of read that like it's guaranteed to be honest. But it could be a good idea to text for &REV_ not existing and fail outright when that's the case rather than trust that the bogus PnPDeviceFirmwareRev won't match.
I intended to support this later so that the initial _Firmware support can be released sooner. One thing that confused me is that, when you create a custom update package with the "Update Retriever" GUI, checking the box that the version of the Firmware is in hexadecimal will set hex2dec="True", but in this package the version is clearly in hexadecimal but hex2dec is set to False. So, technically, I think it's not being treated as hex?? It's not quite obvious to me yet how it works.
animentork
commented
1 year ago Interesting read, so many details to consider!
And having a hexadecimal version, but hex2dec set to False looks like a mistake to me, but does it really matter? If either one of the version numbers look like they could be hexadecimal, just treat them as such: Convert them both to decimal integers and compare them:
if ($PnpDeviceFirmwareRev -imatch '[a-f]" -or $LenovoVersion -imatch '[a-f]') {
# Hexadecimal comparison
else {
# Decimal comparison
}If it looks like a duck ... ;)
jantari
commented
1 year ago Yea, I think that's what I'll do. I can just support hexadecimal numbers in Test-VersionPattern and not even consider hex2dec.
jantari
commented
1 year ago Published Version 1.5.1 which includes this fix
I have a X1 Yoga gen 5 model type 20UC and LSUclient is showing that it needs the following driver: n2wrg16w Intel Management Engine Firmware - 10/11 Firmware 9/28/2022 12:00:00 AM 14.1.67.2046 Critical
But when I check the BIOS or by running fwdetect.exe it shows that it is already updated:
I thought maybe it was an issue with Lenovo, but when I run System Update it shows that no packages applicable to my system are found:
Please help