Open g-bougard opened 3 years ago
Can you provide which UUID are you interested in a dmidecode
output in a GNU/Linux distribution running upon bare metal?
Hi @Biswa96
the one from type 1, as example:
[root@dev ~]$ dmidecode -t 1
# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 3.2.0 present.
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: System manufacturer
Product Name: System Product Name
Version: System Version
Serial Number: System Serial Number
UUID: ea38cc5b-92eb-18b6-ec5e-04d9f521c6e3
Wake-up Type: Power Switch
SKU Number: SKU
Family: To be filled by O.E.M.
And other informations could be useful for any inventory products.
Interop is one way to go:
This is not what I expect as this will provide the UUID of the host, not an UUID for the WSL instance. By UUID, I mean a unique identifier for a system and I separate host from WSL instances as different systems. And indeed, your way will also give the same UUID for all local WSL instances when you have many WSL instances.
Why do you need the WSL instance ID? May you explain your actual issue? In original post, you have mentioned the UUID from BIOS which is a whole different thing than WSL instance ID. Generally a program should not behave differently in Linux realm in WSL and in bare metal.
UUID of the host, not an UUID for the WSL instance
Understood, but in the hypothetical that this request is "/sys/class/dmi/id
is missing on WSL" that is the only rational value it would return. If the ask is a unique id for each distribution installed, that would be a userspace thing. On Ubuntu (and other Debian derived distros), /etc/machine-id
.
@Biswa96 from an inventory point of view, we need to identify any system. WSL1 instance is maybe considered as a container, but WSL2 is using virtualization, so it's more a VM than a container. Other virtualization systems, like VMWare or VirtualBox permit to give a system UUID different from the host and even a BIOS is really emulated. In WSL2, you can even limit memory and vcpu and this probably should be reported to the WSL system via a BIOS emulation. Anyway the WSL kernel do not report anything under /sys/class/dmi/id
at the moment.
For GLPI inventory software, we uses UUID to link VM and containers to their host: from the host, we collect VMs and containers and try to detect their system UUIDs. If the agent is run into the VM or container is simply reports its discovered UUID and then we can link it to the host into the inventory. I guess this is what expect any inventory software.
@therealkenc /etc/machine-id
could be used, but this is actually not supported as it has to be setup by systemd... and systemd is not used with WSL. Also this id would only be visible from the distribution.
I found a way to pass some information to the distribution using the kernelCommandLine
in .wslconfig
, but this will be shared toward all WSL instances from one user.
What would be even fine is so see "wsl.guid=<registry-instance-guid>
would be the GUID found under HK_USERS/<user sid>/SOFTWARE/Microsoft/Windows/CurrentVersion/Lxss/
for a given WSL instance. But a more portable would be to populate WSL system files under under /sys/class/dmi/id
and keep or configure the UUID in registry for each instance (or derive it from the GUID).
I am not familiar with the project that you have mentioned, this is just my opinion. If UUID is used just to verify server-client pair I would generate my own ID and pass it through command line or network or pipe or with any IPC thingy. As of writing, the WSL instance ID is not a documented neither should be used in critical** software. The WSL1 instance ID is strictly undocumented. The WSL2 VM ID is somewhat undocumented but can be retrieved using documented Hyper-V Compute System (HCS) APIs.
The WSL2 VM ID
Pretty clear Guillaume wants an id by distro (amounting to /etc/machine-id
), so that won't get him there.
But a more portable would be to populate WSL system files under under /sys/class/dmi/id
There is only one kernel for all running distributions by-design. So that won't get you there either.
under HK_USERS/
/SOFTWARE/Microsoft/Windows/CurrentVersion/Lxss/ for a given WSL instance
The registry entries are implementation detail. Querying them is... not recommended.
You can treat the distribution names as unique. To the extent they need to be (or you want them to be) universally unique, you can hash them with the Windows user's SID. On recent WSL, the distribution name is available via $WSL_DISTRO_NAME
. Something like:
Pretty clear Guillaume wants an id by distro
It was not clear from original post. The WSL instance ID is totally different than the distribution registration/installation ID in registry.
It was not clear from original post.
For the purposes of the OP, "/sys/class/dmi/id/product_uuid
is missing on WSL" is a legit enough ask. It just doesn't get one an inventory of WSL distributions installed.
Since we're going to arrive here eventually:
#!/usr/bin/env bash
sid=$(whoami.exe /user | sed 's/\r$//' | tail -n 1 | awk '{print $2}')
dists=$(wsl.exe -l -v | sed 's/\r$//' | cut -b 5- | tail -n +2 - | awk '{ print $1 }' | tr -d '\0')
for d in $dists; do
hash=$({ echo $sid && echo $d; } | md5sum - | awk '{print $1}')
echo $hash $d
done
Could be rewritten in C#, Powershell, Perl, or player's choice.
Any updates on providing /sys/class/dmi/id/product_uuid
and /sys/devices/virtual/dmi/id/product_uuid
in WSL?
Is your feature request related to a problem? Yes, this is related to a little problem indeed. I work on GLPI-Agent an inventory agent for GLPI to support WSL. We rely on some hardware informations to make accurate inventory assumption. On linux, these informations can be obtain from /sys/class/dmi/id or by running dmidecode. The most important one is probably UUID and
Describe the solution you'd like It would be nice to be able to get UUID from registry on host side and from /sys/class/dmi/id/product_uuid on wsl side. A clear product_name would also be nice so we can be sure we are running under WSL. A serialnumber could also be nice.
Describe alternatives you've considered Actually I implemented a WSL support for GLPI-Agent. The UUID on host is extracted from the GUID found in registry. In the case of WSL1 I'm able to write a file in the WSL FS so any running agent can read it back to find it's uuid. I've no solution actually for WSL2.
Additional context Nothing to add here.