• Posts

  • Joined

  • Last visited


  • Gender

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

cat2devnull's Achievements


Rookie (2/14)



  1. Again unfortunately there isn't enough here for us to go on. It's complaining about the OS.dmg.root_hash which makes me think that there is an issue with the image that was downloaded... Given that you are working with a VM, most of the normal hardware compatibility issues should not exist because it's all virtualized. Hence there is most likely something about your VM config that is incorrect and causing an issue. Start again from scratch with a fresh docker and OS download. Don't try to pass any hardware through at first, just get the system booting and then worry about USB/GPU/etc. Apple have a tendency to keep changing the product IDs of their OS images and of course new versions come out all the time. It is a lot of work to keep the Macinabox code up to date and probably more than Spacinvaderone was counting on. @ghost82 has been hard at work to fix a lot of these issues; This was for OpenCore 0.7.0 and Mac OS 11.4 I'm not sure on the state of this work now with OpenCore 0.7.2 and Mac OS 11.5 being out. Take a look at the dortania debug guide. You may need to install the debug version of OpenCore to get more information. You can also just try building your own setup from scratch. It isn't that bad if you don't mind investing some time to tinker. It's pretty rewarding.
  2. Hi @ritty, Not sure exactly what is going on here because you haven't given us enough to work with... I can't say for sure if this is a show stopping error or just a warning. So I don't know if the error is with the VM or the OS. What is your system AMD/Intel and what video cards do you have installed? What type of GT640 do you have? - Fermi GF108/GF116 with support up to High Sierra or Kepler GK107/GK208 support up to Big Sur. Have you tried dumping the GPU ROM and loading it in your VM XML? Have you tried getting the card working on Win10 VM? Are you passing both the video and audio component of the card using multifunction? Point #3 on this post; Have you tried stubbing the card under system devices? Passing through Nvidia cards that are your primary GPU can be a bit tricky. Not sure if you have seen this post, along with the SpaceInvaderOne video. Just some ideas to get you started...
  3. It was discussed a few pages back. See here;
  4. So you need to look at the permissions to understand why you can't edit the file. Also check that the filesystem is mounted as read/write.
  5. Actually there are 20 items in that plist file as you can see in the "value" column. You just need to click on the "> Add" to get it to expand. But I am not sure why you are editing the pcidevices.plist file. You need to add the built-in settings to your config.plist in your EFI disk/partition. If you look at my earlier post, you can see I am editing /Volumes/EFI/EFI/OC/config.plist Also I noticed that you are still using the VMX ethernet driver. This should have been updated to be the intel e1000 driver when you ran the Macinabox helper script. I believe that you need to be using the intel virtual NIC to avoid issues with iServices. You can check your virtual machines XML configuration in Unraid and make sure the NIC model is set to e1000-82545em as per my example below. You may also just be able to run the the helper script again to fix it. Just make sure you updated the FIRSTINSTALL variable to "no". Spacinvader One talks about this here; <interface type='bridge'> <mac address='60:03:08:aa:bb:cc'/> <source bridge='br0'/> <target dev='vnet0'/> <model type='e1000-82545em'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface>
  6. Actually it does talk about how to fix the en0 not having a check mark, but I agree that it's not well written. "Here under Network Interfaces (network card icon), look for en0 under BSD and check whether the device has a check mark under Builtin. If there is a check mark, skip to Fixing ROM section otherwise continue reading." After running the two commands to delete the .plist files it actually gives instructions about what to do if you don't have an en0 interface so you can ignore the section about NullEthernet.kext and ssdt-rmne.aml since that isn't your issue. Jump to "Now head under the PCI tab of Hackintool and export your PCI DeviceProperties, this will create a pcidevices.plist on your desktop..." You just need to add the en0 interface PCI root to your config.plist to tell the OS that it is built-in. In my case I had to define the built-in option for the WiFI, Bluetooth and the NVMe SSD.
  7. Everything you need to fix it is here; 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.
  8. 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>
  9. 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.
  10. 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.
  11. 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.
  12. Unraid can pass a virtual e1000 intel ethernet device to your OS X VM that will work just fine. You still need a WiFi card and Bluetooth if you want to use iServices and Handoff. You may be able to pass the wifi card... It depends on the IOMMU groups. Also in general, most onboard Bluetooth is actually attached to the motherboard via a dedicated internal virtual (no connector) USB port. This means that you will have to pass through that entire USB controller as well. OS X is very fussy about WiFi and Bluetooth cards and they almost exclusively use a subset of Broadcom chips. If you want OS X to work well then you may need to add a combo card. Eg; You will still need to connect this to an internal USB2 header to see the Bluetooth and that USB has to be passed through. Any card based on the FL1100 chip should work OTB. Inateck have a good rep but there are other options. If you get the hardware right, then everything just works. Otherwise you will have to use kexts to support other chipsets from Intel/Realtek/etc and you will likely just keep hitting all sorts of weird compatibility issues. I've just thrown hardware at the problem (dedicated GPU, USB, Wifi, SSD)... IOMMU group 31:[1b73:1100] 0b:00.0 USB controller: Fresco Logic FL1100 USB 3.0 Host Controller (rev 10) IOMMU group 32:[14e4:43ba] 0c:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43602 802.11ac Wireless LAN SoC IOMMU group 34:[1bb1:5012] 11:00.0 Non-Volatile memory controller: Seagate Technology PLC FireCuda 510 SSD IOMMU group 35:[1002:67ff] 12:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Baffin [Radeon RX 550 640SP / RX 560/560X] [1002:aae0] 12:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Baffin HDMI/DP Audio [Radeon RX 550 640SP / RX 560/560X]
  13. Yep... On my rig I run dual GPUs, one for OS X and one for Windows. The Unraid server is headless. You will end up with the same setup but for a VM and docker. You might want to keep an eye on how many slots wide the GPUs are as you don't want to block off a PCIe port that you need for an add in card. In my case I have a PCIe USB controller and a WiFi card being passed direct to the OS X VM (that's how I get iServices and Handoff working). So I have a single slot RX550 GPU. The onboard USB and second GPU are for windows.
  14. 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.