fwupdtool reports an error (KERNEL BUG) when refreshing

[Alberto Donato]

when running the "refresh" command I get the following message

$ sudo fwupdtool refresh
Loading… [************************** ]07:43:19:0893 FuBiosSettings KERNEL BUG: 'type' attribute not exported: (failed to load type: Failed to open file “/sys/class/firmware-attributes/thinklmi/attributes/TotalMemoryEncryption/type”: No such file or directory)
Loading… [- ]
Downloading… [***************************************]
Downloading… [***************************************]
Downloading… [************************************** ]

Not sure if it's just a warning or an actual error.

ProblemType: Bug
DistroRelease: Ubuntu 22.10
Package: fwupd 1.8.4-2
ProcVersionSignature: Ubuntu 5.19.0-16.16-generic 5.19.7
Uname: Linux 5.19.0-16-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.23.0-0ubuntu1
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: GNOME
Date: Sun Sep 18 09:43:50 2022
InstallationDate: Installed on 2022-09-11 (6 days ago)
InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Alpha amd64 (20220829)
SourcePackage: fwupd
UpgradeStatus: No upgrade log present (probably fresh install)
---
ProblemType: Bug
ApportVersion: 2.23.0-0ubuntu1
Architecture: amd64
CRDA: N/A
CasperMD5CheckResult: pass
CurrentDesktop: GNOME
DistroRelease: Ubuntu 22.10
InstallationDate: Installed on 2022-09-11 (7 days ago)
InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Alpha amd64 (20220829)
MachineType: LENOVO 21AHCTO1WW
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
Package: linux (not installed)
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.19.0-16-generic root=UUID=77d67dcd-a70a-4ee7-be9d-00c2cf6248c2 ro rootflags=subvol=@ quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 5.19.0-16.16-generic 5.19.7
RelatedPackageVersions:
 linux-restricted-modules-5.19.0-16-generic N/A
 linux-backports-modules-5.19.0-16-generic N/A
 linux-firmware 20220831.gitd3c92280-0ubuntu1
Tags: kinetic wayland-session
Uname: Linux 5.19.0-16-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip libvirt lpadmin lxd plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 09/13/2022
dmi.bios.release: 1.5
dmi.bios.vendor: LENOVO
dmi.bios.version: N3MET08W (1.05 )
dmi.board.asset.tag: Not Available
dmi.board.name: 21AHCTO1WW
dmi.board.vendor: LENOVO
dmi.board.version: Not Defined
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.ec.firmware.release: 1.3
dmi.modalias: dmi:bvnLENOVO:bvrN3MET08W(1.05):bd09/13/2022:br1.5:efr1.3:svnLENOVO:pn21AHCTO1WW:pvrThinkPadT14Gen3:rvnLENOVO:rn21AHCTO1WW:rvrNotDefined:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_21AH_BU_Think_FM_ThinkPadT14Gen3:
dmi.product.family: ThinkPad T14 Gen 3
dmi.product.name: 21AHCTO1WW
dmi.product.sku: LENOVO_MT_21AH_BU_Think_FM_ThinkPad T14 Gen 3
dmi.product.version: ThinkPad T14 Gen 3
dmi.sys.vendor: LENOVO

[mario.limonciello (mario.limonciello-linux-kernel-bugs)]

The firmware-attributes documentation ( https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-firmware-attributes) indicates that all drivers that support firmware-attributes need to support the 'type' attribute.

This is important for userspace software to know how to interact with the driver.

fwupd 1.8.4 added support for the firmware-attributes class API, but since lenovo-thinklmi doesn't meet it shows the following error on every boot.

KERNEL BUG: 'type' attribute not exported: (failed to load type: Failed to open file “/sys/class/firmware-attributes/thinklmi/attributes/MCRUSBHeader/type”: No such file or directory)

A workaround has been landed in fwupd to avoid this attribute and hardcode the known behavior of the current driver when it finds it.

It seems like all the attributes are actually "enumeration", so the lenovo-thinklmi kernel driver should probably just export a type sysfs file with "enumeration" hardcoded for all attributes.

Also though, the possible_values key is not populated either. Instead the values are put into the "current_value" string. On a Lenovo P620 the following happens:

$ sudo cat /sys/class/firmware-attributes/thinklmi/attributes/NUMA/current_value
Auto;[Optional:NPS1,NPS2,NPS4,Auto]
$ sudo cat /sys/class/firmware-attributes/thinklmi/attributes/NUMA/possible_values
cat: /sys/class/firmware-attributes/thinklmi/attributes/NUMA/possible_values: Operation not supported

That is the userspace software tears apart the current_value string and instead puts it into what the possible_values are. This should be the responsibility of the kernel driver. Even if the firwmare returns all that in current_value, the kernel driver should be doing the splitting so that userspace doesn't need to carry quirks for different kernel drivers behaving differently.

[Mario Limonciello (superm1)]

Here is the kernel bug report.
https://bugzilla.kernel.org/show_bug.cgi?id=216460

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1990052

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Alberto Donato (ack)]

apport information

[Alberto Donato (ack)]

apport information

[Alberto Donato (ack)]

apport information

[Alberto Donato (ack)]

apport information

[Alberto Donato (ack)]

apport information

[Alberto Donato (ack)]

apport information

[Alberto Donato (ack)]

apport information

[Alberto Donato (ack)]

apport information

[Alberto Donato (ack)]

apport information

[Alberto Donato (ack)]

apport information

[Alberto Donato (ack)]

apport information

[Alberto Donato (ack)]

apport information

[Alberto Donato (ack)]

apport information

[Alberto Donato (ack)]

apport information

[Alberto Donato (ack)]

apport information

[Alberto Donato (ack)]

apport information

[Alberto Donato (ack)]

apport information

[Alberto Donato (ack)]

apport information

[fkrueger (fkrueger-linux-kernel-bugs)]

JFYI: Given fwupd 1.8.5, I am seeing "fwupd[31123]: 19:40:48:0984 FuBiosSettings KERNEL BUG: 'type' attribute not exported: (failed to load type: File >>/sys/class/firmware-attributes/thinklmi/attributes/SecureBoot/type<< No such file or directory)"

[fkrueger (fkrueger-linux-kernel-bugs)]

(In reply to Frank Kruger from comment #1)
> JFYI: Given fwupd 1.8.5, I am seeing "fwupd[31123]: 19:40:48:0984
> FuBiosSettings KERNEL BUG: 'type' attribute not exported: (failed to
> load type: File
> >>/sys/class/firmware-attributes/thinklmi/attributes/SecureBoot/type<< No
> such file or directory)"

...with ThinkPad T14 Gen1 and up-to-date FW 1.41.

[js (js-linux-kernel-bugs)]

Created attachment 303304
Patch to expose type attributes

I've given fixing this a shot. I've made every exported firmware attribute a "string". If this is not desired the fix will definitely be more involved.

[mario.limonciello (mario.limonciello-linux-kernel-bugs)]

I don't think that's technically the right solution. Those are mostly enumeration types and possible values need to be exported. That's what fwupd is working around.

[js (js-linux-kernel-bugs)]

I can probably fix this in the patch, but it would be nice to have some documentation of this interface. Does anyone have pointers?

[mario.limonciello (mario.limonciello-linux-kernel-bugs)]

I believe https://download.lenovo.com/ibmdl/pub/pc/pccbbs/thinkcentre_pdf/hrdeploy_en.pdf might be what you're looking for.

[js (js-linux-kernel-bugs)]

Ah, now I understand it. Then the patch may be extremely simple. We already expose `possible_values` for all firmware attributes in sysfs. This means we just have to expose type=enumeration as well.

I'm going to give this a spin on my Thinkpad.

[mario.limonciello (mario.limonciello-linux-kernel-bugs)]

Well yes and no. A new type=enumeration is needed; yes.

But this is what I see on my system:
$ cat /sys/class/firmware-attributes/thinklmi/attributes/SecureBoot/possible_values
cat: /sys/class/firmware-attributes/thinklmi/attributes/SecureBoot/possible_values: Operation not supported
$ sudo cat /sys/class/firmware-attributes/thinklmi/attributes/SecureBoot/current_value
Disable;[Optional:Disable,Enable]

What I expected to see is something like this:

$ cat /sys/class/firmware-attributes/thinklmi/attributes/SecureBoot/possible_values
Disable,Enable
$ sudo cat /sys/class/firmware-attributes/thinklmi/attributes/SecureBoot/current_value
Disable

[js (js-linux-kernel-bugs)]

Created attachment 303391
Patch to expose type attributes (v2)

I've updated the patch. It now only adds the `enumeration` type field:

/sys/class/firmware-attributes/thinklmi/attributes/SecureBoot # cat current_value
Disable

/sys/class/firmware-attributes/thinklmi/attributes/SecureBoot # cat possible_values
Disable,Enable

/sys/class/firmware-attributes/thinklmi/attributes/SecureBoot # cat type
enumeration

[mario.limonciello (mario.limonciello-linux-kernel-bugs)]

That seems like part of the solution, but on my system (P620) I still see:

$ cat /sys/class/firmware-attributes/thinklmi/attributes/SecureBoot/possible_values
cat: /sys/class/firmware-attributes/thinklmi/attributes/SecureBoot/possible_values: Operation not supported

$ cat /sys/class/firmware-attributes/thinklmi/attributes/SecureBoot/current_value
Disable;[Optional:Disable,Enable]

So there needs to be further string processing.

[js (js-linux-kernel-bugs)]

I can try to dig deeper, but this may be a firmware issue. Are you running the latest firmware?

[mario.limonciello (mario.limonciello-linux-kernel-bugs)]

I just upgraded from 1.38 to 1.77 (the latest firmware), but the issue still persists on P620.

[mpearson-lenovo (mpearson-lenovo-linux-kernel-bugs)]

I've got an internal ticket open with the FW team on the possible_values issue. The ThinkStation implementation doesn't support the WMI call that provides the possible_values separately (instead they've lumped them in with the current_value).

The type - I'd forgotten about this. It's not really a thing we have in the thinklmi implementation. I'm not actually sure why it was made mandatory but regardless I should fix the driver.
Enumeration works as a fix except for AlarmDate, AlarmTime and UserDefinedAlarmTime which are strings.....sigh

[mario.limonciello (mario.limonciello-linux-kernel-bugs)]

At least from an "interface to userspace" perspective I think we should abstract the differences from one platform to another.

It might mean slicing and dicing strings in the kernel, but at least then we don't have to carry a pile of quirks for every software above the kernel.

[mario.limonciello (mario.limonciello-linux-kernel-bugs)]

Fixes for this have been landed in mainline with these commit hashes:

8a02d70679fc1c434401863333c8ea7dbf201494
cf337f27f3bfc4aeab4954c468239fd6233c7638
45e21289bfc6e257885514790a8a8887da822d40
583329dcf22e568a328a944f20427ccfc95dce01

I validated with a snapshot of 6.3rc4+ (fcd476ea6a88 ("Merge tag 'urgent-rcu.2023.03.28a' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu")) and fwupd 1.8.13.

Everything is behaving properly now on Thinkstation P620, many thanks.

[Mario Limonciello (superm1)]

AFAICT those kernel commits are now landed in Ubuntu's kernel.