dmidecode reports No SMBIOS nor DMI entry point found (/dev/mem exists, missing 000F0000 range)

[jrgerber]

Windows Build Number

Microsoft Windows [Version 10.0.19042.928]

WSL Version

• WSL 2
• WSL 1

Kernel Version

Linux version 5.4.72-microsoft-standard-WSL2

Distro Version

Ubuntu 20.04 and openSUSE-Leap-15.2

Other Software

No response

Repro Steps

$ sudo dmidecode
# dmidecode 3.2
Scanning /dev/mem for entry point.
# No SMBIOS nor DMI entry point found, sorry.

The reason is a hole in the range 000F0000 to 000FFFFF where SMBIOS entry point and table is normally found.

sudo hd /dev/mem|more
0009ea70  01 00 00 00 01 00 00 00  00 00 00 00 00 00 00 00  |................|
0009ea80  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000e0000  52 53 44 20 50 54 52 20  f1 56 52 54 55 41 4c 02  |RSD PTR .VRTUAL.|
000e0010  00 00 10 00 24 00 00 00  00 00 10 00 00 00 00 00  |....$...........|
000e0020  cc 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000e0030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00100000  58 53 44 54 44 00 00 00  01 50 56 52 54 55 41 4c  |XSDTD....PVRTUAL|
00100010  4d 49 43 52 4f 53 46 54  01 00 00 00 4d 53 46 54  |MICROSFT....MSFT|
00100020  01 00 00 00 00 10 10 00  00 00 00 00 54 11 10 00  |............T...|
00100030  00 00 00 00 3c f3 11 00  00 00 00 00 cc f5 11 00  |....<...........|
00100040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*

Expected Behavior

Normally SMBIOS is found in /dev/mem in the 000F0000-000FFFFF range. Azure Ubuntu example:

dmidecode -u|more
# dmidecode 3.1
Getting SMBIOS data from sysfs.
SMBIOS 2.3 present.
338 structures occupying 17307 bytes.
Table at 0x000F93D0.
... etc.

Correspondingly /dev/mem (use hd to dump) contains the SMBIOS entry point and table in the expected range:

000f93d0  00 14 00 00 01 02 00 f0  03 03 90 da cb 7f 00 00  |................|
000f93e0  00 00 34 01 41 6d 65 72  69 63 61 6e 20 4d 65 67  |..4.American Meg|
000f93f0  61 74 72 65 6e 64 73 20  49 6e 63 2e 00 30 39 30  |atrends Inc..090|
000f9400  30 30 38 20 00 31 32 2f  30 37 2f 32 30 31 38 00  |008 .12/07/2018.|
000f9410  00 01 19 01 00 01 02 03  04 ad 72 18 0b 34 20 dc  |..........r..4 .|
000f9420  4b 96 5e c7 32 8a 9f 68  c2 06 4d 69 63 72 6f 73  |K.^.2..h..Micros|
000f9430  6f 66 74 20 43 6f 72 70  6f 72 61 74 69 6f 6e 00  |oft Corporation.|
000f9440  56 69 72 74 75 61 6c 20  4d 61 63 68 69 6e 65 00  |Virtual Machine.|
000f9450  37 2e 30 00 30 30 30 30  2d 30 30 30 30 2d 37 39  |7.0.0000-0000-79|
000f9460  39 35 2d 31 35 30 32 2d  31 37 35 33 2d 34 36 39  |95-1502-1753-469|

Actual Behavior

The range 000F0000-000FFFFF is empty.

000e0030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00100000  58 53 44 54 44 00 00 00  01 50 56 52 54 55 41 4c  |XSDTD....PVRTUAL|

Diagnostic Logs

No response

[DHowett]

It may help triage to know why it would be important for WSL2 to expose an SMBIOS table!

[jrgerber]

It may help triage to know why it would be important for WSL2 to expose an SMBIOS table!

It is the normal configuration on Linux systems and some distributions of Linux come with dmidecode inbox. In my case I am developing a port of dmidecode to Rust and using WSL2 as a development platform. This bug relates to the original dmidecode (not my port).

For validation this capability should be maintained, see also Issue #4545 WSL2: dmidecode missing /dev/mem -> /sys/firmware/dmi/tables/smbios_entry_point No such file or directory. In that case /dev/mem was completely missing and therefore /sys/firmware/dmi/* was missing. In this case /dev/mem exists but is missing the 000F0000 range and therefore /sys/firmware/dmi/* is missing.

[benhillis]

Since WSL2 is a virtual machine, much of this information isn't relevant. What happens when you run dmidecode on a traditional VM?

[jrgerber]

Since WSL2 is a virtual machine, much of this information isn't relevant. What happens when you run dmidecode on a traditional VM?

Virtual Machines present a BIOS to the OS and dmidecode works as expected (Windows, Linux, FreeBSD, etc.)

[therealkenc]

What happens when you run dmidecode on a traditional VM?

It'll pretend there is one. Because it is pretending to be an IBM PC.

much of this information isn't relevant

Or maybe the phrase might be "not applicable". In a more perfect (and likely mythological) universe, the WSL kernel wouldn't know what an 'ACPI' or "PCI bus" was either. And would "boot" in 100ms. [Hey we can dream. I just wanted to second the sentiment.]

Chalking OP ask as feature - doable.

[vitalievrabie]

I also need this feature; subscribed to the issue.

[gvcallen]

+1

[MenaceSan]

SerialNumber seems like it would be a common usage of this data. Some applications will collect this as part of registration/orchestration

[llwp]

Nailed it for me, @MenaceSan ... Porting and testing; had used getting SerialNumber previously and unexpected results (re: entry point error) led me here. Subscribing but also adding my voice just in case. Sure there are other ways - suffice to say unexpected behavior is rarely a good thing. Consistent, reliable, cross-platform = better imho. Thanks, all.

[pampua84]

I would need this too. I follow the post. +1

[lixikun]

+1

[Daydream0929]

+1

[eduardo-weise]

+1

[StinkyPeach]

+1

[TemeSejko]

+1

[Taowyoo]

+1

[Taowyoo]

In best case, I would expect WSL is able to allow control over what system information is presented to the guest. Like:
https://libvirt.org/formatdomain.html#smbios-system-information