cat2devnull

Everything you need to fix it is here; https://dortania.github.io/OpenCore-Post-Install/universal/iservices.html#using-gensmbios 1) Set SystemProductName to iMacPro1,1 unless you really know what you are doing. 2) Generate a unique serial number, UUID and Board number using GenSMBIOS. 3) Check the serial number with the Apple Tool. It is fine to use an invalid serial number if your Apple ID is in good standing. I've been doing this for years on multiple VMs and never had an issue. 4) Set the MAC address of your VMs virtual network card to an Apple Inc address. 5) Set the ROM address to be the same. 6) Make sure your ethernet interface is "en0" and marked as internal. Then you should be good to go.

Yep, of course... Feel like a bit of an idiot My understanding is that there is nothing special about this file between Macinabox and a generic install. It just holds the NVRAM vars. As such all @Kodiak51103 should need to do is check to see if he has a VARS file under; /mnt/user/system/custom_ovmf/ and that they are correctly defined in the <OS> section of his VM config. or use the copy made when the VM was created under; /etc/libvirt/qemu/nvram/ In the interest of keeping everything stock standard, I would recommend pulling the file(s) down from GitHub and put them back into the custom_ovmf directory. Then return the VM config back to default. <os> <type arch='x86_64' machine='pc-q35-4.2'>hvm</type> <loader readonly='yes' type='pflash'>/mnt/user/system/custom_ovmf/Macinabox_CODE-pure-efi.fd</loader> <nvram>/mnt/user/system/custom_ovmf/Macinabox_VARS-pure-efi.fd</nvram> </os>

Ok, so we have ruled out the obvious. I did a quick bit of googling and nothing jumped out at me. You could always try using the default OVMF file rather than the Macinabox version and you could try using a newer q35 machine model. v4.2 is pretty old and you may be hitting a weird bug. <os> <type arch='x86_64' machine='pc-q35-5.1'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/055c9315-8848-0404-267f-4ddbae41e8bf_VARS-pure-efi.fd</nvram> </os> Of course update the VM identifier accordingly for the nvram file or keep using your existing Macinabox nvram file.

Please don't take this as me being mean... Just trying to get the the bottom of the issue... So you haven't demonstrated that the file is in the right place, the pic only shows the directory, not the file. Also I'm not familiar with the app you are using and what this "Custom Path" business is about. If you open a terminal window for your server from the Unraid web GUI you should see the following; root@Tower:~# ls -la /mnt/user/system/custom_ovmf/Macinabox_CODE-pure-efi.fd -rwxrwxrwx 1 root root 3653632 Apr 5 06:54 /mnt/user/system/custom_ovmf/Macinabox_CODE-pure-efi.fd Also check what you have defined in the <OS> section of the VM template as it will need to match. <loader readonly='yes' type='pflash'>/mnt/user/system/custom_ovmf/Macinabox_CODE-pure-efi.fd</loader> Unraid is just looking to read this file. There has to be something simple happening. Eg the file is missing, the permissions are set incorrectly, etc.

Macinabox uses custom OVMF files. Have you checked to see if the files exist? The error message is pretty clear... It can't find /mnt/user/system/custom_ovmf/Macinabox_Code-pure-efi.fd Usually when people get these types of errors it is because they have changed the default locations for files during the installation or deleted the files by mistake. You can always download them again from GitHub. https://github.com/SpaceinvaderOne/Macinabox/tree/master/ovmf

I believe Macinabox uses SecureBootModel=Disabled for compatibility reasons. As per the instructions from Opencore I have been using SecureBootModel=x86legacy which is recommended for VMs on 11.0 and above. (Virtual Machines will want to use x86legacy for Secure Boot support.) Also don't forget to set ForceSecureBootScheme to false. https://dortania.github.io/OpenCore-Post-Install/universal/security/applesecureboot.html#securebootmodel

The goto place for vbios files is https://www.techpowerup.com/vgabios/ but most people recommend that you rip your own bios. Spaceinvader has written some software and made a video that is easy to follow. https://www.youtube.com/watch?v=FWn6OCWl63o I had run my system for over a year without needing to pass a bios to on my Mac VM with an RX550. Then I decided to upgrade from 6.9.0 RC to 6.9.2 and the Mac VM refused to boot with a bunch of difficult to debug hardware errors related to being unable to communicate with the video card. I tried debugging the issue for days and even downgraded back to 6.9.0 without any luck. So as a last resort I pulled the bios using Spaceinvader's instructions, passed it to the VM and bingo, everything working again. Go figure...

If you have a modern CPU there is no reason why you have to emulate Penryn. I believe Macinabox has it set that way for maximum compatibility. I'm running an AMD 3950 so I emulate a Skylake processor. If I didn't use emulation then I would need to apply a bunch of patches to OS X to support AMD. <qemu:arg value='Skylake-Client,kvm=on,vendor=GenuineIntel,+invtsc,+hypervisor,vmware-cpuid-freq=on,+pcid,+popcnt,check'/> This results in the OS reporting my CPU as - 3.5 GHz Intel Core i3 From sysctl -a machdep.cpu.brand_string: Intel Core Processor (Skylake) machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH MMX FXSR SSE SSE2 SSE3 PCLMULQDQ SSSE3 FMA CX16 SSE4.1 SSE4.2 x2APIC MOVBE POPCNT AES VMM XSAVE OSXSAVE TSCTMR AVX1.0 RDRAND F16C machdep.cpu.leaf7_features: RDWRFSGS BMI1 AVX2 SMEP BMI2 RDSEED ADX SMAP Obviously no AVX512 support being AMD Zen3 underneath. Still I got about a 15% speed improvement by shifting from Penryn to Skylake emulation. I'm not sure exactly where that came but I expect there are features that are available in Skylake that are otherwise missing.

Ok, so I am not very experienced with this situation but what has happened is that the VM is booting into the UEFI, but then the UEFI cannot find a valid OS (BOOTx64.efi) to boot, so stops. This means that you have either damaged your EFI partition. Deleted or remapped your virtual disk to somewhere it isn't expecting, or similar. This wouldn't happen from just adding the boot-args to your config.plist file since the boot process hasn't even got that far yet. OpenCore Booting: (from https://dortania.github.io/OpenCore-Install-Guide/troubleshooting/boot.html#xnu-kernel-handoff) System powers on and searches for boot devices <- you're stuck here System locates BOOTx64.efi on your OpenCore USB under EFI/BOOT/ BOOTx64.efi is loaded which then chain-loads OpenCore.efi from EFI/OC/ NVRAM Properties are applied <- this is where you made the change EFI drivers are loaded from EFI/OC/Drivers Graphics Output Protocol(GOP) is installed ACPI Tables are loaded from EFI/OC/ACPI SMBIOS Data is applied OpenCore loads and shows you all possible boot options You now boot your macOS installer I would start by checking your EFI partition/vdisk and check that you somehow didn't break your disk mappings in your VM XML config.

I’ve used the term debugging and verbose interchangeably, which may have been confusing. Add the boot-args "-v keepsyms=1" to your config.plist as I mentioned above, and is documented here . https://dortania.github.io/OpenCore-Install-Guide/troubleshooting/kernel-debugging.html#config-plist-setup This will turn on verbose mode when OS X boots and then you should be able to see what is causing the kernel panic. This isn't an error. It's just the UEFI logging which HDD it's booting from.

Your VM log looks fine. With what info I have to go on, at this stage I don't think this is an OC bug. This is likely something between OS X and the VM (kernelspace/userspace). At this point you will need to get your hands dirty. Start by reading the Dortania Troubleshooting guide. https://dortania.github.io/OpenCore-Install-Guide/troubleshooting/troubleshooting.html#table-of-contents (keep in mind that some options in this guide will different as it is based on OC 0.7.0 and you are using 0.6.4) You should look at enabling the OS X debugging first as that is likely to give you what you need. Only if that doesn't work would I bother to install the debugging version of OC. In you config.plist there is a string under NVRAM -> Add -> 7C436110-AB2A-4BBB-A880-FE41995C9F82 -> boot-args Change to "-v keepsyms=1" This will enable verbose mode and hopefully allow you to see what's breaking.

That's not an error message, it's just logging about which drive it is going to boot from. See my post about about needing more information to help you debug further.

See my post about common issues. I would try cleaning up the CPU topology as a first point. Beyond that, we would need more debugging info. Good luck.

Yes... The variable is "built-in" not "build-in". You made a simple typo. For further reading, checkout the dortania guide. https://dortania.github.io/OpenCore-Post-Install/universal/iservices.html#fixing-en0

It would be interesting to diff the old XML and new, to see what was broken. I'm sure it would be something fairly obvious. The common culprits are; 1) CPU topology issues. It's not uncommon to see people with CPU topologies defined which can upset the OS <cpu mode='host-passthrough' check='none' migratable='on'> <topology sockets='1' dies='1' cores='4' threads='2'/> <cache mode='passthrough'/> <feature policy='require' name='topoext'/> </cpu> Often safer to just passthrough without any topology. <cpu mode='host-passthrough' check='none' migratable='on'/> 2) Missing custom OS loader/nvram settings. I don't use Macinabox anymore so I might be incorrect but I think it still requires custom versions. 3) Incorrect bus settings on the video card passthrough. - Usually missing bios, multifunction settings, etc. <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x12' slot='0x00' function='0x0'/> </source> <rom file='/mnt/user/isos/vbios/Yeston-RX550-4G-LP-D5.rom'/> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0' multifunction='on'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x12' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x1'/> </hostdev> 4) Network card not updated to e1000-82545em after initial build. 5) Missing or corrupt QEMU settings. <qemu:commandline> <qemu:arg value='-usb'/> <qemu:arg value='-device'/> <qemu:arg value='usb-kbd,bus=usb-bus.0'/> <qemu:arg value='-device'/> <qemu:arg value='isa-applesmc,osk=xxxxxx'/> <qemu:arg value='-smbios'/> <qemu:arg value='type=2'/> <qemu:arg value='-cpu'/> <qemu:arg value='Penryn,kvm=on,vendor=GenuineIntel,+invtsc,vmware-cpuid-freq=on,+pcid,+ssse3,+sse4.2,+popcnt,+avx,+aes,+xsave,+xsaveopt,check'/> </qemu:commandline> And I'm sure there are more gotchas to watch out for. I'm glad to hear you got it going. I must admit I did a compete rebuild of my Unraid Hackintosh a couple of months back. Now on stock standard OC and it's flawless. I was even able to fix the NVMe drive so it appears to the OS as an internal drive which was something that used to bug me. Ta,

If you need help from the community, you will need to give us more information to go on... 1) The VM logs. 2) The apple boot loader debugging. config.plist -> NVRAM -> Add -> 7C436110-AB2A-4BBB-A880-FE41995C9F82 -> boot-args: -v debug=0x100 keepsyms=1 3) and if that doesn't point us in the right direction, the OpenCore debug logs. https://dortania.github.io/OpenCore-Install-Guide/troubleshooting/debug.html#file-swaps

It would be interesting to know if any of these patches are required if you don't try and force the CPU to Penryn. I've been using 10.15.x through 11.3.0 without issue but I have taken a slightly different route to SpaceinvaderOne. I'm trying to keep everything running as stock standard (no custom OVMF etc) with latest versions of QEMU/Opencore etc. I'm passing the CPU though as Skylake and it's been flawless for me. Installs, upgrades, all WOB, no weird patching required. I also haven't needed to disable as much of the OS security. <vcpu placement='static'>4</vcpu> <cputune> <vcpupin vcpu='0' cpuset='4'/> <vcpupin vcpu='1' cpuset='20'/> <vcpupin vcpu='2' cpuset='5'/> <vcpupin vcpu='3' cpuset='21'/> </cputune> <os> <type arch='x86_64' machine='pc-q35-5.1'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/xxxx_VARS-pure-efi.fd</nvram> </os> <cpu mode='host-passthrough' check='none' migratable='on'/> <qemu:arg value='Skylake-Client,kvm=on,vendor=GenuineIntel,+invtsc,+hypervisor,vmware-cpuid-freq=on,+pcid,+popcnt,check'/>

So first you need to create a new blank HFS image in Disk Utility. It needs to be large enough to fit the installer. Then convert it from a .dmg to a .img hdiutil convert <input.dmg> -format UDTO -o <output.img> Then mount it again and copy the installer into it. sudo /Applications/Install\ macOS\ Catalina.app/Contents/Resources/createinstallmedia --volume /Volumes/MyVolume Then you're ready to go.

If the script accidentally downloads the wrong OS, (will happen when ever Apple release new versions and mess with the ProductID). You can always just download the one you want yourself and just place the image file over the top. https://dortania.github.io/OpenCore-Install-Guide/installer-guide/mac-install.html#downloading-macos-modern-os

Since both sound devices are not working you either have a separate issue effecting each device or one issue taking out both. I probably have a very similar setup (AsRock x570 Phantom Gaming X) board. I am using HDMI audio on both my Mac and Win VMs because that way as I switch monitor input the audio source is switched at the same time. I take the audio output from my monitor and pass it to my speakers/headphones. The only issue is when using Mac with HDMI audio you loose volume control so I paid $19 for Sound Control which gives fixes a lot of Mac audio shortcomings. Make sure you have your video card passed through correctly (as is often discussed in this forum). <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x12' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0' multifunction='on'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x12' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x1'/> </hostdev> Make sure you have multifunction enabled correctly and are assigning to the same bus. As per my example above; bus='0x12' slot='0x00' function='0x0' ---> bus='0x04' slot='0x00' function='0x0' multifunction='on' bus='0x12' slot='0x00' function='0x1' ---> bus='0x04' slot='0x00' function='0x1' Your card looks like it is on bus 0x0b, I can't see where it is assigned too as you haven't posted your XML. Remember the GUI will not set this up correctly, it will not use multifunction and will put them on different destination busses. As for both audio devices. They should show up easily. You just need Lilu, WhateverGreen and AppleALC kexts. I have read a few posts reporting issues with the onboard Realtek chip, until adding boot-args alcid=1 or alcid=11. Make sure you have the latest versions of the kexts as they are adding new layout-ids all the time. Just something to start with. Let us know how you go. If no luck, I should be able to pass through my onboard card and take a look for you. Just might be a day or two till I have a chance.

It's no different than passing through any hardware to a VM (SSD, USB Controller, Video Card). 1) Go into Settings -> VFIO-PCI Config and bind the IOMMU group that has the ethernet controller (must not be the one that Unraid is using for the bridge). 2) Reboot for the change to kick in. 3) In your VM template, choose the device from the list of "Other PCI Devices" at the bottom (don't forget to then fix all the config that the GUI editor will break), or just add it by hand via the XML editor.

FYI I've upated the details about the RX550 compatibility as a bug report to Dortania. As for passing it through to the Mac VM. There is nothing special required. Just track it down in your PCIe IOMMU group. IOMMU group 33: [1002:67ff] 10:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Baffin [Radeon RX 550 640SP / RX 560/560X] (rev ff) [1002:aae0] 10:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Baffin HDMI/DP Audio [Radeon RX 550 640SP / RX 560/560X] In my case device 10:00.0 for video and 10:00.1 for audio. Then map that bus 0x10 function 0x0 and 0x1 to a spare bus in the VM. For me, I used bus 0x04 (the next unused bus) and function 0x0 and 0x1. Don't forget to use the multifunction command option to bring both the audio and video together. <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x10' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0' multifunction='on'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x10' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x1'/> </hostdev> Spaceinvader One made a video that talks about this in more details. Do make sure your have a recent Lilu and WhateverGreen kexts installed in clover/opencore. I find that sometimes the card does not initialise until the OS fires up the GUI so don't stress if you don't get the display turning on immediately, just be patient. See how you go.

It's not a bug. It's the difference between calculating drive space as decimal (1x10^3 = 1000) vs powers of 2 (2^10 = 1024). Eg is 1 kilobyte = 1000 bytes or 1024 bytes. In your case specifically, 500*1024*1024*1024= 536.870912GB There are many sites on the internet that discuss this age old problem. http://www.disk-space-guide.com/size-units.aspx

You can just build a new .img with the opencore EFI filesystem in it and just boot from that instead of your old qcow2 image by changing your Unraid config file. I talked about doing this in the following post. https://forums.unraid.net/topic/84601-support-spaceinvaderone-macinabox/page/44/?tab=comments#comment-907711

So I've just got off a 12h shift and my brain is fried but I noticed that you have split the video card and it's inbuilt audio over two bus IDs which would most likely break things. <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x1'/> This should be bus='0x03' to match the video card. You have correctly put the audio on function='0x1' so it will not collide with the video on function='0x0'.