dmidecode and product_uuid are reporting the system uuid with different endianness: # dmidecode -s system-uuid 3E001700-008E-3200-37B2-D46E0620D672 cat /sys/class/dmi/id/product_uuid 0017003E-8E00-0032-37B2-D46E0620D672 I believe this behavior could be related to: commit 95be58df74a5b21e5a78e45fddb2fd59112524c5 Author: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Date: Wed Feb 18 13:33:20 2015 +0200 firmware: dmi_scan: Use full dmi version for SMBIOS3 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=95be58df74a5b21e5a78e45fddb2fd59112524c5 Unless there's some specific reason to use a different endianness in product_uuid, it seems to me that the correct one is the one reported by dmidecode. Also, with qemu instances: $ qemu-kvm -uuid 3E001700-008E-3200-37B2-D46E0620D672 ... the correct one (same endianness) in the guest is the one reported by dmidecode.
My best guess at the moment is that the check modified in the patch mentioned above: - if (dmi_ver >= 0x0206) + if (dmi_ver >= 0x020600) is not correct (it shouldn't have been necessary).
A fix has been proposed here: https://lkml.org/lkml/2015/12/22/315
Fixed in kernel v4.4: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ff4319dc7cd58c92b389960e375038335d157a60