OcMainLib: treat empty Generic->SystemUUID like "OEM" - #620
OcMainLib: treat empty Generic->SystemUUID like "OEM"#620albert-mueller wants to merge 2 commits into
Conversation
PlatformInfo->Generic->SystemUUID being empty is documented (Configuration.pdf, ValidatePlatformInfo.c) as legal and equivalent to "OEM", but OcLoadPlatformSupport()/OcGetLegacySecureBootECID() only recognised the literal "OEM" string. An empty value instead fell through to OcAsciiStrToRawGuid() on an empty string, whose failure status was not checked, leaving MacInfo->Oem.SystemUuid zeroed. A zero UUID is skipped when writing the Data Hub entry and the system-id NVRAM variable, but SMBIOS_OVERRIDE_V falls back to the real hardware UUID from the original SMBIOS table instead of leaving it zero. So with an empty SystemUUID, PlatformInfo->SMBIOS ended up with the real hardware UUID while PlatformInfo->Generic (Data Hub/NVRAM/IOPlatformUUID) got nothing set, letting the OS mint its own value independently - exposing two different, sometimes per-boot-varying UUIDs instead of one consistent one. Add PlatformInfoUuidIsOem() and use it at both call sites so empty and "OEM" are handled identically, matching the documented failsafe.
|
I recommend to review the changes carefully as these are written using Claude. |
Removes AI generated comments to increase readability of the code. Both two commits are designed to fix these issues: albert-mueller/OpenCore-Legacy-Patcher-T2#222 and albert-mueller/OpenCore-Legacy-Patcher-T2#130
|
I just tested it on my 2018 Mac mini and I found that with this latest commit, now at least it tries to mount the volume (it fails). To fix the mounting issue on T2 Macs it requires a bit more research. |
This is lies. It is documented as:
This reads if it was set to OEM value, then it remains set. I.e. it is left as is by default, not forcibly set to OEM in all variables like you might think of. Please stop posting junk here. It takes time to review but gives little to no benefit to the project. |
PlatformInfo->Generic->SystemUUID being empty is documented (Configuration.pdf, ValidatePlatformInfo.c) as legal and equivalent to "OEM", but OcLoadPlatformSupport()/OcGetLegacySecureBootECID() only recognised the literal "OEM" string. An empty value instead fell through to OcAsciiStrToRawGuid() on an empty string, whose failure status was not checked, leaving MacInfo->Oem.SystemUuid zeroed.
A zero UUID is skipped when writing the Data Hub entry and the system-id NVRAM variable, but SMBIOS_OVERRIDE_V falls back to the real hardware UUID from the original SMBIOS table instead of leaving it zero. So with an empty SystemUUID, PlatformInfo->SMBIOS ended up with the real hardware UUID while PlatformInfo->Generic (Data Hub/NVRAM/IOPlatformUUID) got nothing set, letting the OS mint its own value independently - exposing two different, sometimes per-boot-varying UUIDs instead of one consistent one.
Add PlatformInfoUuidIsOem() and use it at both call sites so empty and "OEM" are handled identically, matching the documented failsafe.
Again commited using Claude.

This is designed to attempt to fix this on unsupported T2 Macs:
This picture is from my 2018 Mac mini booted inside macOS 26's installer with the buggy OC version before this fix:
Here's the EFI with the buggy version before this fix:
Archiv.zip