Error launch

[DIMANRUS]

Hello. I created everything step by step using scripts in Readme, but this problem occurred when starting. What could be the reason for this? I have attached a file with logs below. opencore-2024-10-26-210258.txt

[Qonfused]

This is an early kernel panic caused by an unsupported CPUID. 11th gen (Rocket Lake) CPUs aren't natively supported so you'll need to spoof as 10th gen (Comet Lake).

00:021 00:001 OCCPU: Found 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz
00:023 00:001 OCCPU: Signature 806C1 Stepping 1 Model 8C Family 6 Type 0 ExtModel 8 ExtFamily 0 uCode FFFFFFFF CPUID MAX (1B/80000008)

You'll want to add the below entries under the Kernel > Emulate section of your config.plist (or add this to the config.yml file and re-build this repo):

Kernel:
  Emulate:
    Cpuid1Data: Data | EB060900 00000000 00000000 00000000
    Cpuid1Mask: Data | FFFFFFFF 00000000 00000000 00000000

Also see https://github.com/Qonfused/OSX-Hyper-V/issues/2 as this is the same case for Alder Lake (12th gen) and Raptor Lake (13th/14th gen) CPUs.

[DIMANRUS]

Thank you very much for your reply. I have moved further, but I am stuck on an error, as I understand it, not displaying the GUI for selecting a language. I have seen this in other issues, but I have an Intel processor. Any thoughts on why it does not give? I tried UEFI from another repository, the installer starts there, but after that the system does not want to start.

[Qonfused]

Interesting. I haven't been able to reproduce that on AMD so I wasn't sure if it was some kind of misconfiguration on the user's part. In this case, the only configuration needed for 11th gen was the CPUID spoof.

Can you try with 55060A00 instead of EB060900 for the first CPUID bit?

Kernel:
  Emulate:
    Cpuid1Data: Data | 55060A00 00000000 00000000 00000000

This corresponds to a Comet-Lake CPUID instead of a Coffee-Lake CPUID (which use the same driver). I'm curious if there is any CPUID-related startup behavior behind this issue.

[DIMANRUS]

Thanks for the answer. I tried replacing it, but the error remained. I attached the log and the configuration I use. The log still shows the name of my 11th generation processor when I start it, is that how it should be? Maybe I wrote the lines you mentioned above in the wrong place? opencore-2024-10-27-233153.txt config.zip

[Qonfused]

The OpenCore log will always display the CPU information correctly even if you spoof it; the CPUID spoof just tricks macOS into treating the CPU as supported.

This gets logged very early on before later applying the CPUID patch:

00:031 00:002 OCCPU: Found 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz
00:034 00:002 OCCPU: Signature 806C1 Stepping 1 Model 8C Family 6 Type 0 ExtModel 8 ExtFamily 0 uCode FFFFFFFF CPUID MAX (1B/80000008)
...
18:415 00:002 OCAK: [OK] Patch success CPUID release

I also just tested the i9-11900KF on the same configuration but still haven't figured out how to reproduce this issue.

I'm curious if this issue is flaky and somehow performance related since the i7-11370H shouldn't face any compatibility issues. Just to make sure there isn't any blocking virtual disk I/O or VMQ issues, I'd disable checkpoints for your VM:

Set-VM -Name <name> -AutomaticCheckpointsEnabled $false

May be worth re-creating the VM in Hyper-V with this setting disabled just to verify.

[DIMANRUS]

I always disable checkpoints, so without them it is also a mistake.

[DIMANRUS]

I have a GUI running with this EFI. I opened the EFI disk and replaced your EFI with this one. EFI.zip

[Qonfused]

These were the only functional changes I noticed:

Kernel:
  Emulate:
    DummyPowerManagement:  Boolean | false
PlatformInfo:
  Generic:
    SystemProductName:     String  | "MacBookAir8,1"

Omitted are changes applied for legacy/32-bit systems that are present in both.

Curious why the SMBIOS is set to the MacBookAir8,1 since this was just dropped in Sequoia. It's not generally a good fit for this CPU (and most desktop and laptop CPUs) as it's based on an Amber-Lake Y model laptop.

If it doesn't make a difference it might just be a flaky issue.

[DIMANRUS]

Thanks for the answer. I tried with and without it on the i3-12100 processor, the problem is the same in both cases. Later I will try again on the i7-11370H

[DIMANRUS]

Hello. I went through the process of elimination on the configuration. In the end, I added 3 kext folders and added to the configuration. This ran on an i3-12100. In a few hours I will try on an i7 and report the results. Kexts.zip Config Plis.txt

[Qonfused]

Those VirtualSMC plugins shouldn't affect boot as far as I'm aware.

[DIMANRUS]

I tested it on i7-11370H. In the end I had to leave a few more drivers and I got into recovery gui. EFI.zip

[Qonfused]

Not sure if the BiosVideo.efi driver will do anything without ReconnectGraphicsOnConnect enabled:

CSM video driver implementing graphics output protocol based on VESA and legacy BIOS interfaces. Used for UEFI firmware with fragile GOP support (e.g. low resolution). Requires ReconnectGraphicsOnConnect. Included in OpenDuet out of the box.

I'd try booting with this disabled just to verify. Maybe there aren't any graphics drivers 'connected' when this driver gets loaded? There should always be the HyperVGraphicsBridge loaded so I'm unsure if does anything.

[DIMANRUS]

After the installation has started on the screen with the apple, then with the current kext and drivers it turns into the screen below But if I turn off the machine, remove what I added, that is, return the plist to your configuration, then the installation goes through and starts.

[Qonfused]

Normally the installer would require a few restarts, which I think would have to be done manually. The 'Ø' symbol is possibly the result of the BiosVideo driver not being properly configured (or otherwise some misconfiguration in that EFI).

It seems that there was a build issue in #23 that affected the previous nightly build of OCE-Build which is why I couldn't reproduce it. The current build configuration should now correctly load MacHyperVSupport and boot into the installer.