I have a multiboot system with several OSes on the same hardware.
Summary: OpenBSD UUID reported by dmidecode and from sysctl differ
significantly w.r.t. byte ordering. Multiple OSes report the same dmidecode
UUID, and most other OSes provide one or more alternate ways of accessing
the UUID which yields results consistent with dmidecode.
Details:
dmidecode (after fiddling with kern.allowkmem via /etc/sysctl.conf on OpenBSD)
run on each OS that has a dmidecode utility reports the same hardware UUID
(modulo hexadecimal digit case), viz.
UUID: 484B1340-D7AA-81E5-3CED-9C5C8E3D6756
OpenBSD (6.8) `sysctl hw.uuid` instead reports:
hw.uuid=40134b48-aad7-e581-3ced-9c5c8e3d6756
Note that the differences are:
1. case of hexadecimal digits (inconsequential)
2. byte ordering (but inconsistently so between the initial part
and the last 64 bits (the latter part's byte ordering is consistent
with dmidecode))
FreeBSD (12.1-RELEASE-p10) `sysctl kern.hostuuid` reports:
kern.hostuuid: 484b1340-d7aa-81e5-3ced-9c5c8e3d6756
which is essentially the same as from dmidecode, modulo
hexadecimal digit case.
FreeBSD also has a `kenv` utility, which reports:
smbios.system.uuid="484b1340-d7aa-81e5-3ced-9c5c8e3d6756"
which also corresponds to the UUID reported by dmidecode.
NetBSD (9.1) sysctl reports the hardware UUID consistent with dmidecode:
machdep.dmi.system-uuid = 484b1340-d7aa-81e5-3ced-9c5c8e3d6756
PCLinuxOS dmidecode output is also consistent with the others. There's
a variant of sysctl, but it reports only randomized IDs unrelated to the
invariant hardware UUID.
UUID: 484b1340-d7aa-81e5-3ced-9c5c8e3d6756
Windows (10) "PowersHell" gobbledygook also yields the same UUID as
dmidecode:
PS C:\Users\bruce> get-wmiobject Win32_ComputerSystemProduct |
Select-Object -ExpandProperty UUID
484B1340-D7AA-81E5-3CED-9C5C8E3D6756
Conclusion: OpenBSD `sysctl hw.uuid` yields results which are inconsistent
with other methods of obtaining hardware UUID. It appears that part of the
UUID via sysctl is affected by byte-ordering issues.
