Hardware UUID injection for opencore

[realdenis]

Hi there! I'd like to ask for a solution of injection of hardware UUID.

I've bought some softwares (eg: paragon NTFS) and their licences are bond to the hardware UUID (from system report), not system UUID, which was generated and injected by clover configurator.
When I convert from clover to opencore, the hardware UUID can't be directly assigned but calculated by opencore itself, causing the expiry of my licences.

How should I solve the problem? Thanks!

Best regards.

[vit9696]

Hello,

HardwareUUID was deprecated in Clover for the last five years at the very least and is the legacy coming from Chameleon. The fact that Clover Configurator is unaware of this is a problem of Clover Configurator and its users as enforcing this value breaks certain mechanisms in macOS with unknown consequences. Unfortunately for you, we do not have a way to specify it and do not plan to add it in the future.

Your best options are to stay with the current bootloader or write to the mentioned software support with a request to migrate to a new computer, something like a motherboard replacement in Mac Store is a valid reason for this, for example.

[derbalkon]

Just asking another question similar to this issue: Is OpenCore designed not to automatically generate system-id with the info filled in "PlatformInfo - Generic"?

I fresh installed macOS 10.15.4 with the latest OpenCore build and found the system-id section shows ??? in Hackintool. I further ran macinfo to make sure and it only showed Hardware UUID, which is the SystemUUID I filled in Generic, but no System ID, and it shows

Failed to find to system-id in IODeviceTree:/efi/platform!

I checked my config twice to make sure the PlatformInfo is correctly filled:

• Automatic on

• Generic all good, SystemUUID filled with motherboard UUID in order not to interfere Windows Activation

• UpdateDataHub on, UpdateNVRAM on, UpdateSMBIOS on, UpdateSMBIOSMode on

I also opened a thread on forum and people who fresh install the system with OpenCore have the same problem as mine. Is it designed on purpose that system-id won't generate just like the reason there's no injection of hardware UUID option?

Thanks!

[vandroiy2013]

Your motherboard UUID may be incorrect.

[vit9696]

Just asking another question similar to this issue: Is OpenCore designed not to automatically generate system-id with the info filled in "PlatformInfo - Generic"?

Yes. You need to fill it manually. Just as Vandroiy explained, your motherboard UUID may be incorrect, so it is best to stay safe.

[mabam]

Sorry for the bump after 2.5 years but this is very relevant to me.

Do I understand correctly that OpenCore generates the system ID from the SMBIOS UUID?

I ask as I’m porting an existing macOS VM (with valid IDs) to QEMU using OpenCore. If the above is correct it would mean that the present SMBIOS UUID of my VM originates from the used OVMF.fd file. Then I’d know the route to go is finding and amending the sources for my OVMF.fd file, setting up a build toolchain for it and compile myself.

[vit9696]

Basically yes. It is EfiBoot that does it, but does not change much.

[mabam]

…, but does not change much.

What do you mean by that?

[mabam]

Never mind, my bad.

I got confused by the different names that are used for the same ID. I had put the Hardware UUID (dumped within the VM under the original virtualisation software via system_profiler SPHardwareDataType | awk '/Hardware UUID/') in PlatformInfo > Generic > SystemUUID of the config.plist.
I have now fixed that by using the System ID (ioreg -l -p IODeviceTree | grep "system-id" in the original VM). From that one the Hardware UUID gets generated correctly now. All good.

I thought there was yet another ID (the SMBIOS UID) that would probably be hidden somewhere in the virtual BIOS of my VM, but couldn’t find out where/how to change it. Now I know that there isn’t but that it’s the System UUID of my config.plist

Sorry for waisting your time.
And thank you for your instant support and all the effort in writing this software!