OCB: Load image failed - Unsupported

[startergo]

Good job, but unfortunately I cant get it to boot.
First of all, you have to increase the EFI image size to at least 5G.
Second no matter what machine I choose (I tried Lion, Mavericks and Monterey) I always get an error on boot OC: Load image failed - Unsupported
Do you have a tested machine with this script?

[Qonfused]

I normally test using the create-virtual-machine script which is what I used to determine the macOS support matrix; the most extensive testing was done on Monterey and Ventura, with some manual image tweaks for legacy boot on Lion and older.

If you haven't already I'd enable these Misc -> Debug settings to see if you can get more information on the error from the OpenCore boot log:

OSX-Hyper-V/src/config.yml

Lines 79 to 102 in e8eb79b

	@ifdef(DEBUG)
	# Debugging quirks (recommended with DEBUG version of OpenCore)
	# - https://dortania.github.io/OpenCore-Install-Guide/troubleshooting/debug.html
	# - https://dortania.github.io/OpenCore-Install-Guide/troubleshooting/kernel-debugging.html#nvram
	Kernel:
	Quirks:
	PanicNoKextDump: Boolean | true
	PowerTimeoutKernelPanic: Boolean | true
	Misc:
	Debug:
	AppleDebug: Boolean | true
	ApplePanic: Boolean | true
	DisableWatchDog: Boolean | true
	Target: Number | 67
	NVRAM:
	Add:
	7C436110-AB2A-4BBB-A880-FE41995C9F82:
	# Breakdown of used boot args:
	# `-v` (verbose mode)
	# `debug=0x100` (debug mask; disables watchdog to avoid panic reboot)
	# `keepsyms=1` (show panic log debug symbols)
	# `msgbuf=1048576` (Resizes kernel msg buffer to 1 MB; avoids truncation)
	boot-args: String | "-v debug=0x100 keepsyms=1 msgbuf=1048576"
	@endif

I'd verify that the HfsPlus.efi driver is loaded and Misc -> Security -> SecureBootModel is set to "Disabled" in the config.plist which should prevent that specific error:

OSX-Hyper-V/src/config.yml

Lines 207 to 212 in e8eb79b

	# Apple Secure Boot hardware model and policy
	# - Possible values include:
	# - Disabled: No model, Secure Boot will be disabled.
	# - Default: Currently set to x86legacy
	# - @see https://dortania.github.io/OpenCore-Post-Install/universal/security/applesecureboot.html#securebootmodel
	SecureBootModel: String | "Disabled"

I am curious, what is the significance of the '5 GB' image size for the EFI disk? Is this an issue with the New-VHD cmdlet? There shouldn't be any boot issue from the image size as long as it's large enough to fit the macOS base image and EFI folder.

[startergo]

I am curious, what is the significance of the '5 GB' image size for the EFI disk?

It fails to create the recovery image. I checked the real size after I set it to 5GB and it was around 1.35 GB.
if I use git clone on the master the script does not work as shown to create specific machine because the actual script is In a different directory. And when I run it from that directory it does not work because it is designed to work in a folder structure like the one in the releases section. Which release do I use the latest or the original?

[Qonfused]

It fails to create the recovery image. I checked the real size after I set it to 5GB and it was around 1.35 GB.

Ah I see. I'll have to change the default size or adjust it with Resize-VHD as it's being built.

If I use git clone on the master the script does not work as shown to create specific machine because the actual script is In a different directory. And when I run it from that directory it does not work because it is designed to work in a folder structure like the one in the releases section.

The scripts in the scripts/lib directory aren't meant to be ran directly from there; they're intended to be run from the build output of the project (in the dist/Scripts directory) or in the release output.

You'd have to build the project with scripts/build.ps1, which will create the EFI folder and move those powershell scripts to the correct directories; it'll provide the same output as what is uploaded in release. The steps for building this project are documented in the README here.

Which release do I use the latest or the original?

The v0.0.0 release is a stable release with OpenCore 0.9.4 -- if you're trying to boot 10.4-10.7 I'd make sure you have at least OpenCore 0.9.6 and look into #7 (though I'm still working on improving image loading for those OS versions).

The v0.1.0 release is technically still a 'work in progress' but it should match what is built locally. I haven't tested all release outputs end-to-end, though I have tested them from source.

[startergo]

The v0.1.0 release is technically still a 'work in progress' but it should match what is built locally. I haven't tested all release outputs end-to-end, though I have tested them from source.

The release folders are corrupted, they cannot be opened.
Debug and secure boot model are set properly, and I still get this error when building Lion. FixupAppleEfiImages was not set, but even with it set I get the same error. Will try Monterey again.

[startergo]

Once I deleted the previous machine it compiled fine. Went to the recovery screen.

[startergo]

I had to delete and recreate the network switch to make internet work.

[Qonfused]

#8 (comment)
Is there any way to create my own installer disk? I tried:

qemu-img.exe convert -f raw -O vhdx InstallMacOSX.dmg InstallMacOSX.vhdx

But the disk is not even recognized.

You may need to convert the image to an intermediate ISO image and run qemu-img on that instead:

dmg2img InstallMacOSX.dmg InstallMacOSX.iso

qemu-img convert -O vhdx InstallMacOSX.iso InstallMacOSX.vhdx

#8 (comment)
I had to delete and recreate the network switch to make internet work.

This has also been fixed in 1ce9be2 (v0.1.0) to override the default network switch. Will have to note that in the release notes -- it should just work in the updated release or from source.

I also fixed the EFI VHDX size issue just now in 25e9275. For now, the pre-allocated size is fixed to 5GB but will shrink after building the disk.

[Qonfused]

#8 (comment)
Once I deleted the previous machine it compiled fine. Went to the recovery screen.

Sounds like the original issue was resolved then? I'll close this issue for now, though let me know if that issue pops up again.

[startergo]

Sounds like the original issue was resolved then?

For Monterey only. Can't get Lion to boot. Still the same error.
OCB: Load image failed - Unsupported

[startergo]

Tried changing the platform info to iMac12,2, but it did not help. Tried both recovery images.

[Qonfused]

Are you using the HfsPlusLegacy.efi driver when booting Lion (10.7)? It looks like it's missing from the build spec in v0.1.0:

OSX-Hyper-V/src/build.yml

Lines 11 to 17 in 25e9275

	Drivers:
	- HfsPlus
	@ifdef(RELEASE)
	- OpenCanopy
	@endif
	- OpenRuntime
	- ResetNvramEntry

Could you upload the OpenCore log when booting into Lion (either with a debug release or with the instructions in #8 (comment))?

[startergo]

No, that driver is unavailable. Even from Opencore Package itself:

opencore-2024-05-27-095037.txt

[Qonfused]

You can find it under the OCBinaryData repo here:
https://github.com/acidanthera/OcBinaryData/tree/master/Drivers

I was mostly asking since it would have indicated a regression in legacy boot (originally fixed in acidanthera/OpenCorePkg@092af5d).

[startergo]

https://github.com/acidanthera/OcBinaryData/blob/master/Drivers/HfsPlusLegacy.efi
Installed it from here still the same error.
opencore-2024-05-27-101203.txt

[startergo]

Tried the one you linked:

[startergo]

Disregard the above picture. I downloaded it as a raw file. But anyway, even that one comes with
OCB: Load image failed - Unsupported

[startergo]

You may need to convert the image to an intermediate ISO image and run qemu-img on that instead:

dmg2img InstallMacOSX.dmg InstallMacOSX.iso

qemu-img convert -O vhdx InstallMacOSX.iso InstallMacOSX.vhdx

Did not work. Can I attach it as a DVD somehow?

[Qonfused]

00:013 00:002 OCCPU: Found Intel(R) Core(TM) i9-10920X CPU @ 3.50GHz
00:015 00:002 OCCPU: Signature 50657 Stepping 7 Model 55 Family 6 Type 0 ExtModel 5 ExtFamily 0 uCode FFFFFFFF CPUID MAX (16/80000008)

You appear to have a Comet-Lake i9 10920X CPU, which supports RDRAND instructions (so you wouldn't need HfsPlusLegacy).

On a related note, I'm not sure you can boot below macOS Catalina on that CPU? Initial support for Comet Lake was only added in 10.15.4. As Hyper-V is a type-1 hypervisor, you'll need to make sure your CPU is supported by that version of macOS.

[startergo]

Tried attaching directly as an ISO.

[startergo]

On a related note, I'm not sure you can boot below macOS Catalina on that CPU? Initial support for Comet Lake was only added in 10.15.4. As Hyper-V is a type-1 hypervisor, you'll need to make sure your CPU is supported by that version of macOS.

OC were saying the CPU may need to be spoofed?

Emulate
DummyPowerManagement and CPU spoofing may be required depending on the host CPU for older versions of macOS.

[startergo]

Tried:

Cpuid1Data A0060300 00000000 00000000 00000000
Cpuid1Mask FFFFFFFF 00000000 00000000 00000000

Still the same.

[Qonfused]

Ah right. You can use a CPUID patch w/ DummyPowerManagement to avoid CPUID/power management kernel panics -- I've normally done this on unsupported Pentium systems (which I completely forgot you could do).

That wouldn't prevent loading the Lion image but it would create issues while booting the installer.

[startergo]

As Hyper-V is a type-1 hypervisor

Hyper-V integration services for macOS. Requires a Generation 2 virtual machine

[Qonfused]

Type-1 generally refers to running on/with the physical hardware of the machine; something like VirtualBox or QEMU (without KVM) would have to emulate the CPU instructions without direct hardware access.

On the other hand, Hyper-V has two different generations of virtual machine types that have different virtual hardware models (and thus different supported features). It's a different concept from the level of hardware abstraction the hypervisor uses.

In previous versions of Hyper-V, there was only one generation of virtual machine. In Windows Server 2012 R2 there are two generations of virtual machines to choose from when you create a new virtual machine:

• Generation 1 Provides the same virtual hardware to the virtual machine as in previous versions of Hyper-V.

• Generation 2 Provides the following new functionality on a virtual machine:

  • PXE boot by using a standard network adapter
  • Boot from a SCSI virtual hard disk
  • Boot from a SCSI virtual DVD
  • Secure Boot (enabled by default)
  • UEFI firmware support

[startergo]

Type-1 generally refers to running on/with the physical hardware of the machine; something like VirtualBox or QEMU (without KVM) would have to emulate the CPU instructions without direct hardware access.

Is your script creating type-1?

Tried this too:

Special NOTES for Haswell+ low-end
Your support gets dropped as of 10.13 or 10.14 kindly by Apple. Sorry, I cannot tell the exact version, but it indeed is bad news. Well, I will be able to post the necessary patches if you just want to try out earlier versions with your lovely low-end models. LOL
First, apply CPUID patch via Kernel->Emulate:
Cpuid1Data: <A9 06 03 00 00 00 00 00 00 00 00 00 00 00 00 00>
Cpuid1Mask: <FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00>
This will fake CPUID as 0x306A9 (Ivy Bridge) in order to successfully boot. Yet Ivy Bridge is an XCPM-unsupported model, thus patch to _xcpm_bootstrap might be needed depending on macOS version, as well as a universal patch for AVX (see below):
For 10.11 and older, just apply the CPUID patch above and simply accompanied by boot-arg named -xcpm.

acidanthera/bugtracker#365

[startergo]

Still not sure how to make the disk appear in the boot menu converted from dmg or qcow2.

[startergo]

by the way getting panic on Monterey:

AMFIInitializeLocalSigningPublicKey: failed to get local signing public key (e00002bc)

[Qonfused]

Is your script creating type-1?

Hyper-V is always a type-1 hypervisor; the script is creating a generation 2 virtual machine mainly to support UEFI boot.

Still not sure how to make the disk appear in the boot menu converted from dmg or qcow2.

If you have the dmg you can try creating a VHD/VHDX disk with a com.apple.recovery.boot folder containing it. This should already be done in the EFI.VHDX disk for Lion which still has a downloadable base image through the macrecovery script.

OSX-Hyper-V/scripts/lib/create-macos-recovery.ps1

Lines 20 to 40 in 25e9275

	switch ($version)
	{
	"10.7" { $b="Mac-2E6FAB96566FE58C"; $m="00000000000F25Y00"; }
	"10.8" { $b="Mac-7DF2A3B5E5D671ED"; $m="00000000000F65100"; }
	"10.9" { $b="Mac-F60DEB81FF30ACF6"; $m="00000000000FNN100"; }
	"10.10" { $b="Mac-E43C1C25D4880AD6"; $m="00000000000GDVW00"; }
	"10.11" { $b="Mac-FFE5EF870D7BA81A"; $m="00000000000GQRX00"; }
	"10.12" { $b="Mac-77F17D7DA9285301"; $m="00000000000J0DX00"; }
	"10.13" { $b="Mac-7BA5B2D9E42DDD94"; $m="00000000000J80300"; }
	"10.14" { $b="Mac-7BA5B2DFE22DDD8C"; $m="00000000000KXPG00"; }
	"10.15" { $b="Mac-00BE6ED71E35EB86"; $m="00000000000000000"; }
	"11" { $b="Mac-42FD25EABCABB274"; $m="00000000000000000"; }
	"12" { $b="Mac-FFE5EF870D7BA81A"; $m="00000000000000000"; }
	"13" { $b="Mac-4B682C642B45593E"; $m="00000000000000000"; }
	"14" { $b="Mac-937A206F2EE63C01"; $m="00000000000000000"; }
	# "15" { $b=""; $m="00000000000000000"; }
	Default { $b="Mac-7BA5B2D9E42DDD94"; $m="00000000000000000"; }
	}
	# Run macrecovery.py script
	& python.exe "$macrecovery" -b "$b" -m "$m" -o "$outdir" download

[startergo]

Any Idea what is causing this panic:

[startergo]

Got past that one with:

amfi_get_out_of_my_way=1 

Make sure to add it.

[startergo]

Only 3MB VRAM?

[Qonfused]

As noted in the README there is no graphics acceleration -- at least for most cards. This would require DDA support from the host (dependent on the Windows edition) and additional work on Lilu and WhateverGreen to fix Hyper-V device detection for GPU patching.

[startergo]

Aha. Whatevergreen is not even included. Is it needed?

[Qonfused]

It doesn't detect PCI bridges early enough to do anything (and you'd need to be able to pass in the iGPU to the VM with DDA). The MacHyperVSupport package includes basic framebuffer support which is what you see with 'Hyper-V Graphics' -- I've explained this issue in #6 as well.

[startergo]

and you'd need to be able to pass in the iGPU to the VM with DDA)

My CPU has no iGPU.

[Qonfused]

It's still the same issue whether you want to pass in an iGPU or a DGPU. It'd be the only way to get graphics acceleration which is still blocked by the issues mentioned above.

[Qonfused]

#8 (comment)
Got past that one with:

amfi_get_out_of_my_way=1

Make sure to add it.

Disabling AMFI should only be done when necessary when running unsupported hardware on an unsupported OS; it can create unnecessary issues in macOS (e.g. in adding applications to System Preferences > Security & Privacy > Privacy, as mentioned here) and with handling device outputs on supported hardware.

[startergo]

Disabling AMFI should only be done when necessary when running unsupported hardware on an unsupported OS

I don't get then the panic. Monterey supports this CPU. It is very similar to the MacPro's CPU. Maybe I should change the iMac19,1 to MacPro7,1?

Nope still getting it.

[startergo]

As noted in the README there is no graphics acceleration -- at least for most cards. This would require DDA support from the host (dependent on the Windows edition) and additional work on Lilu and WhateverGreen to fix Hyper-V device detection for GPU patching.

So I got acceleration with the use of a Kext. Tested with 10.6.8 and 10.9.5. Don't know if it would work with the newer macOS, but don't see why not.
utmapp/UTM#3046 (comment)
All you need to do is find the device ID and the Vendor ID and add it to the IOPCIPrimaryMatch in the Info.plist of the kext

[Qonfused]

I'd verify that you actually have QE/CI or some basic acceleration for OpenGL (for example, with a transparent dock in modern macOS versions). This kext shouldn't give you any hardware acceleration since we don't have any VirtIO/QXL device in Hyper-V.

It may be useful if you can change your screen resolution from the default set in the HyperVGraphicsBridge module, which would suggest that it works similarly to UEFIGraphicsFB as a basic framebuffer driver.

Feel free to create a new issue for it though. I'll take a look later in case there's a way I can add support in Hyper-V.

[startergo]

since we don't have any VirtIO/QXL device in Hyper-V

It also worked with plain VGA card and manually adding vRAM of up-to 512MB.
https://gist.github.com/akihikodaki/87df4149e7ca87f18dc56807ec5a1bc5?permalink_comment_id=5255996#gistcomment-5255996

A short video is attached.

[Qonfused]

Does it require driver communication from the host or does it work as a more optimized CPU-driven framebuffer driver? I suppose I'm not really following since increasing the VRAM isn't indicative of hardware acceleration, only that there is some sort of device created.

[startergo]

Does it require driver communication from the host or does it work as a more optimized CPU-driven framebuffer driver? I suppose I'm not really following since increasing the VRAM isn't indicative of hardware acceleration, only that there is some sort of device created.

The screen saver (even in preview mode) works perfectly well. Also I don't think glxgears with software emulation will work well without an acceleration.

[Qonfused]

Have you tested this with Hyper-V or is this just with UTM?

[startergo]

Downloading now Hyper-V for testing. For now tested only in UTM (Vbox should work as well).

[startergo]

I get this error:

06:527 00:004 OCAK: Dependency com.apple.iokit.IOGraphicsFamily was not found for kext puredarwin.driver.VMQemuVGA
06:537 00:009 OCAK: Vtable patching failed for kext puredarwin.driver.VMQemuVGA
06:539 00:002 OC: Prelinked injection VMQemuVGA.kext () - Invalid Parameter
06:541 00:002 OC: Prelinked injection VMQemuVGA.kext v1.2.5d3

But the dependency appears to be loaded
Loaded Kexts.txt

[Qonfused]

That kext can't be injected through OpenCore since it requires linking with IOGraphicsFamily which is in SysKC; you'd have to put it under /System/Library/Extensions (or possibly in AuxKC under /Library/Extensions).

[startergo]

That kext can't be injected through OpenCore since it requires linking with IOGraphicsFamily which is in SysKC; you'd have to put it under /System/Library/Extensions (or possibly in AuxKC under /Library/Extensions).

That is probably for the new macOS’s. It may work up to Catalina?

Starting with macOS 11, if third-party kernel extensions (kexts) are enabled, they can’t be loaded into the kernel on demand. Instead, they’re merged into an Auxiliary Kernel Collection (AuxKC), which is loaded during the boot process. 

System extensions
macOS 10.15 allows developers to extend the capabilities of macOS by installing and managing system extensions that run in user space rather than at the kernel level. By running in user space, system extensions increase the stability and security of macOS. Even though kexts inherently have full access to the entire operating system, extensions running in user space are granted only the privileges necessary to perform their specified function.

The kext is not signed so loading from /Library/Extensions might not work.

[Qonfused]

You can disable SIP (or disable kext signing) to load it. Set the csr-active-config NVRAM variable to 03000000 to disable kext signing and filesystem protections (see disabling SIP on how to do this).

[startergo]

Panics: