On 3/9/25 04:41, Faidon Liambotis wrote:
Hi Mario, On Sun, Mar 09, 2025 at 12:27:38AM -0600, Mario Limonciello wrote:The libsmbios package previously had consumers in the fwupd package for Dell systems. This has been changed in fwupd and it directly talks to the kernel instead of using the libsmbios library. There have been bug reports forwarded upstream that are totally ignored. There hasn't been any changes upstream in 5 years. The project is effectively dead upstream and tech debt to maintain in Debian without much utility or need.AIUI you are the previous upstream for this package as well as a contributor to relevant bits in upstream Linux. (That's a good opportunity to say: thank you for your work!)
Sure! Yeah when I was at Dell I worked on this package. I tried to hand it off when I left but it seems that no one ever picked it up :/
I looked into smbios recently due to an FTBFS RC bug (that Steve McIntyre fixed almost immediately), #1092525, and left a comment there. I am not involved with its maintenance, just a drive-by interested party. With you being the subject-matter expert, perhaps it's worth rehashing here and get your take as well!
Yeah, good idea. My main thought process is to avoid maintaining dead upstream software in Debian, when there are other ways/knobs to get the same information.
FWIW that was the same thought process that went into dropping it in fwupd too.
First of all, it is also my understanding that libsmbios does not have any reverse dependencies/third-party consumers in Debian. However, src:libsmbios also produces the binary "smbios-utils" with several command-line utilities. So it's not just a matter of whether the library is useful, but also whether the utilities themselves are.
Right.
As I mentioned in #1092525, I am aware that most, if not all, of the low-level functionality of these CLI utilities can now be performed using the dell_* (dell_smbios especially) Linux kernel modules & sysfs.
And dell-wmi-sysman which provides the firmware-attributes interface.
However, to my knowledge, there is no clear replacement in terms of a higher-level interface. For example, looking at the very straightforward "getSystemId": Libsmbios version: 2.4.3 Product Name: Latitude 7420 Vendor: Dell Inc. BIOS Version: 1.34.2 System ID: 0x0A36 Service Tag: <removed> Express Service Code: <removed> Asset Tag: Not Specified Property Ownership Tag: The modern alternative is to fetch e.g. the Service Tag with: cat /sys/class/dmi/id/chassis_serial However, listing the Express Service Code is: echo $((36#$(cat /sys/class/dmi/id/chassis_serial))) So you need to know where to look, and what conversion to run.
Right. But this could easily be information in a wiki page instead of a full software stack.
In an even more pronounced example, "smbios-token-ctl" can fetch and set
a bunch of tokens ("BIOS" settings) with their names and descriptions:
# smbios-token-ctl
================================================================================
Token: 0x001e - Speaker (Disable)
value: bool = false
Desc: Disable the built-in speaker.
================================================================================
Token: 0x0028 - Auto-on (Disable)
value: bool = true
Desc: Disable the system's auto-on capabilities
================================================================================
[...]
The equivalent sysfs interface is:
# cat /sys/devices/platform/dell-smbios.0/tokens/001e_value; echo
00000000
However, there is no description of any of those (234 in my system)
tokens.
AFAIK the token ID->name is encoded in this CSV in the libsmbios source
package:
https://github.com/dell/libsmbios/blob/master/doc/token_list.csv
I think fwupd implements some of this functionality, but I am not sure
if it's equivalent or if there is feature parity.
Does your machine load the dell-wmi-sysman driver? That is the modern replacement for all this. It includes descriptions, what options can support etc.
As I final data point, I believe smbios-battery-ctl's functionality was only very recently implemented in the kernel (v6.12); so while libsmbios is indeed abandonware for the past 5 years, it was certainly still the only way to perform a very useful function until a few months ago.
Yeah; this is part of why I was waiting a while to file this request. Seeing 1092525 and with the impending freeze I figured now is the right time to discuss it so it's not more software to maintain for the next few years.
So all in all, I suppose the question is: are there modern replacements for all of the utilities shipped by smbios-utils? If not, and given smbios-utils now builds and works, are there any downsides in continuing to ship it in unstable and trixie?
It's a lot of C code, and most if not all the functionality is covered natively by the kernel in other ways. While it had static analysis done with coverity a number of years back when I was at Dell I don't know how well it has aged as other dependencies and libraries it uses have moved along.
Thanks for your input in advance! Regards, Faidon
OpenPGP_0x2D192CA624770276.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
