'KERNEL BUG: "type" attribute not exported'

[LinuxOnTheDesktop]

Describe the bug
Some (all?) fwupd commands produce output that includes the following.
KERNEL BUG: 'type' attribute not exported: (failed to load type: Failed to open file “/sys/class/firmware-attributes/thinklmi/attributes/SecureBoot/type”: No such file or directory)

Steps to Reproduce

$ sudo -i flatpak run org.freedesktop.fwupd refresh
[sudo] password for [me]: 
Loading…                 [**************************             ]00:03:02:0020 FuBiosSettings       KERNEL BUG: 'type' attribute not exported: (failed to load type: Failed to open file “/sys/class/firmware-attributes/thinklmi/attributes/SecureBoot/type”: No such file or directory)
Loading…                 [-                                      ]
WARNING: This package has not been validated, it may not work properly.
Downloading…             [***************************************]
Downloading…             [***************************************]
Downloading…             [***************************************]

(As I have said before, the warning about validation is unfortunate, because it is ambiguous between the problem pertaining to (1) fwupd, (2) some particular update. With time I inferred that 1 is meant. The user should not have to make that inference.)

Expected behavior
No cryptic error message.

fwupd version information
Please provide the version of the daemon and client.

$ fwupdmgr --version
runtime   org.freedesktop.fwupd         1.7.5
compile   org.freedesktop.gusb          0.3.10
runtime   com.dell.libsmbios            2.4
runtime   org.kernel                    5.15.0-48-generic
compile   org.freedesktop.fwupd         1.7.5
runtime   org.freedesktop.gusb          0.3.10
$ flatpak list | grep fwup
fwupd	org.freedesktop.fwupd	1.8.4	stable	system

Please note how you installed it (apt, dnf, pacman, source, etc): flatpak, but I have an apt version installed too.

fwupd device information

$ fwupdmgr get-devices --show-all-devices
20KH001UKP
│
├─Core™ i7-8550U CPU @ 1.80GHz:
│     Device ID:          4bde70ba4e39b28f9eab1628f9dd6e6244c03027
│     Current version:    0x000000f0
│     Vendor:             Intel
│     GUIDs:              b9a2dd81-159e-5537-a7db-e7101d164d3f
│                         30249f37-d140-5d3e-9319-186b1bd5cac3
│                         561403e8-143a-5071-ab09-bf5e4c146983
│                         54bdc429-0179-5019-9cb6-8a343324c97c
│     Device Flags:       • Internal device
│   
├─Embedded Controller:
│     Device ID:          2292ae5236790b47884e37cf162dcf23bfcd1c60
│     Summary:            UEFI ESRT device
│     Current version:    0.1.22
│     Minimum Version:    0.1.22
│     Vendor:             Lenovo (DMI:LENOVO)
│     Update State:       Success
│     GUIDs:              3babca5f-b2bf-4f4b-a72e-2bdc84eb4019
│                         7090c94a-ee40-593e-91bc-8cfd5a8c0a5d
│     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
│   
├─Intel Management Engine:
│     Device ID:          349bb341230b1a86e5effe7dfe4337e1590227bd
│     Summary:            UEFI ESRT device
│     Current version:    184.92.4222
│     Minimum Version:    0.0.1
│     Vendor:             Lenovo (DMI:LENOVO)
│     Update State:       Success
│     GUIDs:              9c9d9769-32fa-4841-b550-ea998e754e99
│                         1a4eea87-292a-5d99-82bd-fd244d4e0194
│     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
│   
├─LENSE20512GMSP34MEAT2TA:
│     Device ID:          04e17fcf7d3de91da49a163ffe4907855c3648be
│     Summary:            NVM Express solid state drive
│     Current version:    2.8.8341
│     Vendor:             Lenovo (NVME:0x17AA)
│     GUIDs:              22eade43-1bc6-5eb2-ae69-b7d59beedeb8
│                         762c02f3-333f-5f89-a0c6-289659ae3cb6
│                         963522d7-bc73-51fa-a70c-cf615f42bcf6
│                         b0cd8903-04e1-51f7-a69a-f08b77e4a6ad
│                         ef93a17b-97f6-550e-a5bc-32c22ff6cdf8
│     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
│   
├─System Firmware:
│ │   Device ID:          a45df35ac0e948ee180fe216a5f703f32dda163f
│ │   Summary:            UEFI ESRT device
│ │   Current version:    0.1.57
│ │   Minimum Version:    0.0.1
│ │   Vendor:             Lenovo (DMI:LENOVO)
│ │   Update State:       Success
│ │   Update Message:     The computer will be restarted automatically after updating BIOS completely . Do NOT turn off your computer or remove the AC adaptor while update is in progress.
│ │   GUIDs:              a4b51dca-8f97-4310-8821-3330f83c9135
│ │                       230c8b18-8d9b-53ec-838b-6cfc0383493a
│ │                       6b3879ff-921f-5bc5-a0c2-5cec28f31d2f
│ │   Device Flags:       • Internal device
│ │                       • Updatable
│ │                       • System requires external power source
│ │                       • Supported on remote server
│ │                       • Needs a reboot after installation
│ │                       • Cryptographic hash verification is available
│ │                       • Device is usable for the duration of the update
│ │ 
│ └─UEFI dbx:
│       Device ID:        362301da643102b9f38477387e2193e57abaa590
│       Summary:          UEFI revocation database
│       Current version:  77
│       Minimum Version:  77
│       Vendor:           UEFI:Linux Foundation
│       Install Duration: 1 second
│       GUIDs:            14503b3d-73ce-5d06-8137-77c68972a341
│                         5971a208-da00-5fce-b5f5-1234342f9cf7
│                         c6682ade-b5ec-57c4-b687-676351208742
│                         f8ba2887-9411-5c36-9cee-88995bb39731
│       Device Flags:     • Internal device
│                         • Updatable
│                         • Supported on remote server
│                         • Needs a reboot after installation
│                         • Only version upgrades are allowed
│     
├─TPM:
│     Device ID:          c6a80ac3a22083423992a3cb15018989f37834d6
│     Current version:    71.12.17568.4100
│     Vendor:             ST Microelectronics (TPM:STM)
│     GUIDs:              ff71992e-52f7-5eea-94ef-883e56e034c6
│                         84df3581-f896-54d2-bd1a-372602f04c32
│                         bfaed10a-bbc1-525b-a329-35da2f63e918
│                         70b7b833-7e1a-550a-a291-b94a12d0f319
│                         06f005e9-cb62-5d1a-82d9-13c534c53c48
│     Device Flags:       • Internal device
│   
├─UEFI Device Firmware:
│     Device ID:          f95c9218acd12697af946874bfe4239587209232
│     Summary:            UEFI ESRT device
│     Current version:    0.71.12
│     Minimum Version:    0.71.12
│     Vendor:             Lenovo (DMI:LENOVO)
│     Update State:       Success
│     GUIDs:              cea87551-1701-43fb-afbc-6e8ce9728345
│                         9ce4f5c8-e787-5f82-a7ef-a22c071c9423
│     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
│   
├─UHD Graphics 620:
│     Device ID:          5792b48846ce271fab11c4a545f7a3df0d36e00a
│     Current version:    07
│     Vendor:             Intel Corporation (PCI:0x8086)
│     GUIDs:              2920038a-3772-52ef-8f3d-92c2fb1ac115
│                         0284ca6a-a235-5433-b190-1de21c753494
│                         fed2efa4-7045-55a1-b4fc-b29283d59fe5
│                         8b72a10c-1279-5f8e-a28a-34fb11a58240
│     Device Flags:       • Internal device
│                         • Cryptographic hash verification is available
│   
└─Unifying Receiver:
      Device ID:          fb1a5fd6e7d8cbf5d5a2ba7df68aee106ce41027
      Summary:            Miniaturised USB wireless receiver
      Current version:    RQR24.10_B0036
      Bootloader Version: BOT03.01_B0008
      Vendor:             HIDRAW:0x046D|USB:0x046D
      Install Duration:   30 seconds
      GUIDs:              cc4cbfa9-bf9d-540b-b92b-172ce31013c1
                          fcf55bf5-767b-51ce-9c17-f6f538c4ee9f
                          279ed287-3607-549e-bacc-f873bb9838c4
      Device Flags:       • Updatable
                          • Supported on remote server
    
Idle…                    [***************************************]
Update failure is a known issue, visit this URL for more information: https://github.com/fwupd/fwupd/wiki/LVFS-Triaged-Issue:-Failed-to-run-update-on-reboot
Successfully uploaded 1 report

Additional questions

• Operating system and version: Mint 21 Cinnamon
• Have you tried rebooting? Yes.
• Is this a regression? I don't know (and: from what version?)

[superm1]

https://bugzilla.kernel.org/show_bug.cgi?id=216460

[LinuxOnTheDesktop]

So, the following two things are the case, are they? (I had trouble interpreting the bug report.) (1) The bug is with software by Lenovo. (2) The bug does not affect fwupd's functionality (at least on recent versions of fwupd).

[superm1]

It's a kernel module bug. Fwupd will work more as intended when it's fixed.

[LinuxOnTheDesktop]

So the fix will arrive, when it does arrive, in the form of a kernel update?

[superm1]

If a fix arrives it will be a kernel update, yes.

[hughsie]

KERNEL BUG: 'type' attribute not exported

I also got pushback about this from the RHEL QA team if that adds any argument... Maybe we could do it just for !SUPPORTED_BUILD or something?

[superm1]

I would feel a lot better doing that if the kernel bug was fixed upstream first.

[hughsie]

@mrhpearson is there anyone assigned to this on the Lenovo team? Thanks.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please note: We are just a few people who contribute to a shared project, and it's impossible for us to fix every bug with such limited resources.
If you want to investigate and try to help solve this yourself, we will review all pull requests from new contributors.
If this is issue is important to you for your business please talk with your technical account manager about arranging resources to solve this issue. You might even consider hiring someone to write the code if you're unable to do so yourself, e.g. see: https://fwupd.org/lvfs/docs/consulting

[superm1]

FYI, the fixes for this have landed in:
torvalds/linux@8a02d70
torvalds/linux@cf337f2
torvalds/linux@45e2128
torvalds/linux@583329d

I verified they're working properly on fwupd 1.8.13.

So we do have a decision what to do in fwupd now.
At a minimum the self tests need to be updated for the way that this is handled in newer kernels.

Beyond that the options I see:

1. Do nothing but fix tests. Leave warning and compatibility code forever and it will stop being used as people move to newer kernels.
2. We drop the warning to only when unsupported build, leave the compatibility code forever.
3. We drop the warning and compatibility code and (effectively) make it a requirement to be using kernel 6.3 or a kernel that backported those commits to use fwupd bios settings with think-lmi.

I think if we can make a case to backport those commits to stable, my preference is #3, but please convince me otherwise.

[hughsie]

Woo! Maybe the nag message did it's thing? :)

Maybe we do 2, and then then 3 in, say, 1 year?

[mrhpearson]

Woo! Maybe the nag message did it's thing? :)

Nah - this was me giving up on the person who was supposed to do it, and doing it myself.

I like the suggestion of 2 and then 3 in a year. Hopefully by then distro's will be updated.

I am now wondering if I should have tagged it for stable backport after all - I didn't think there was any active impact other than fwupdmgr which was already handling it so didn't. Let me know if I should forward it to Greg after all, I'm hesitant to put more work on the stable team unless it's an issue that is actually impacting users.

[superm1]

I like the suggestion of 2 and then 3 in a year. Hopefully by then distro's will be updated.

OK, I'll draft something up along these lines then.

I am now wondering if I should have tagged it for stable backport after all - I didn't think there was any active impact other than fwupdmgr which was already handling it so didn't. Let me know if I should forward it to Greg after all, I'm hesitant to put more work on the stable team unless it's an issue that is actually impacting users.

The onus of work is on you to check whether they cleanly apply to 5.15.y, 6.1.y and 6.2.y. If they cleanly apply and think-lmi can build properly then I would vote bring them to stable.

My reasoning is that even if we drop this in a year what's to say for example that Canonical doesn't update Ubuntu 22.04 to fwupd 1.10 in a year? It's unlkely given it usually stagnates in Ubuntu stable releases, but there has definitely been interest in syncing the version across all the LTS releases. I could see an argument that Ubuntu 24.04 takes fwupd 1.10, put the same thing in Ubuntu 22.04.

As they track 5.15.y for 22.04, landing it there would mean this bug doesn't show up compat code or not.

[mrhpearson]

Thanks Mario

The onus of work is on you to check whether they cleanly apply to 5.15.y, 6.1.y and 6.2.y

Yeah....that was the bit that had me groaning. They should apply but...still gotta try it and build/test.

I thought about it some more and it's the right thing to do (and better than trying to convince the distro's individually). It's added to my todo list

[superm1]

@mrhpearson I started to update the test suite and found another problem :(

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

It's expected we should just see Disable. Could you get that fixed? Ideally in 6.3 also otherwise we're going to have a pretty messy situation.

[mrhpearson]

Oh - I had some discussion on the mailing list about this and I was being cautious about messing with it too much....just because I don't have a lot of confidence in what the ThinkStation team do with their strings and didn't want to break things.

But yeah - I can see why that's not good for you...and it should be simple to fix. I'll look at doing that.

[hughsie]

Modern kernels expose this correctly, lets close here.