[Support] SpaceinvaderOne - Macinabox

[ijuarez]

On 11/10/2023 at 12:14 PM, Exlife said:

I think so. All you can do is wait for a new release or try to manually create a VM yourself

Yep switch back to big sur and it worked.

 

 

[bmartino1]

On 11/12/2023 at 2:11 AM, Exlife said:

I was able to successfully install Monterey 12.6.7

If you need, I can share the opencore and img installer. I can also tell you how to make the installer yourself.
XML from BigSur worked for me.

You can write me a private message, I can tell you how I did it.

 

DM you I would love to know what I'm doing wrong in making the installer.

[DWomack]

On 10/25/2019 at 4:12 PM, SpaceInvaderOne said:

09 Dec 2020

 

Basic usage instructions.

 

Macinabox needs the following other apps to be installed.

CA User Scripts (macinabox will inject a user script. This is what fixes the xml after edits made in the Unraid VM manager)

Custom VM icons  (install this if you want the custom icons for macOS in your vm)

 

Install the new macinabox.

 

1. In the template select the OS which you want to install

2. Choose auto (default) or manual install. (manual install will just put the install media and opencore into your iso share)

3. Choose a vdisk size for the vm

4. In VM Images: Here you must put the VM image location  (this path will put the vdisk in for the vm)

5. In VM Images again : re enter the same location  as above. Here its stored as a variable. This will be used when macinabox generate the xml template.

6. In Isos Share Location: Here you must put the location of your iso share. Macinabox will put named install media and opencore here.

7. In Isos Share Location Again: Again this must be the same as above. Here its stored as a variable. Macinabox will use this when it genarates the template.

8. Download method. Leave as default unless for some reason method 1 doesnt work

9. Run mode. Choose between macinabox_with_virtmanager or virtmanager only.

 

( When I started rewriting macinabox i was going to only use virtmanager to make changes to the xml. However I thought it much easier and better to be able to use the Unraid vm manager to add a gpu cores ram etc, then have macinabox fix the xml afterwards.

I deceided to leave vitmanager in anyway, in case its needed. For example there is a bug in Unraid 6.9.beta (including beta 35.) When you have any vm that uses vnc graphics then you change that to a passed through gpu it adds the gpu as a second gpu leaving the vnc in place.  This was also a major reason i left virtmanger in macinabox. For situations like this its nice to have another tool. I show all of this in the video guide. )

 

After the container starts it will download the install media and put it in the iso share. Big Sur seems to take alot longer than the other macOS versions. So to know when its finished goto userscripts and run the macinabox notify script (in background) a message will pop up on the unraid webui when its finished.

 

At this point you can run the macinabox helper script. It will check to see if there is a new autoinstall ready to install then it will install the custom xml template into the VM tab.

Goto the vm tab now and run the vm

This will boot up into the Opencore bootloader and then the install media.

Install macOS as normal.

 

After install you can change the vm in the Unraid VM Manager. Add cores ram gpu etc if you want.

Then go back to the macinabox helper script. Put in the name of the vm at the top of the script and then run the script.

It will add back all the custom xml to the vm and its ready to run.

 

Hope you guys like this new macinabox

What version of OpenCore Configurator is used in the YouTube.  
 

Looks like the version of open core used is 78 from the picker screen. 

 

This a bit dated.  Looking forward to your update. 
 

Dennis

Edited November 28, 2023 by DWomack
Add info.

[ibbanez]

I have a question. I tried searching, but maybe I'm using the wrong keywords. What additional steps do I need to do to build different VM's? Like I have a Big Sur one running, but I want to try Monterey. Also, Can you simply update the VM like normal to get OS updates to newer versions? 

[Unraid_Student]

I love all the community support here to get it working while we wait!

 

I will practice my zen and still wait for SpaceInvaders version as I’m sure there’s a logical reason behind delay (Work is kicking up,etc) 😌

[Pirokiki]

On 11/29/2023 at 6:58 PM, ibbanez said:

I have a question. I tried searching, but maybe I'm using the wrong keywords. What additional steps do I need to do to build different VM's? Like I have a Big Sur one running, but I want to try Monterey. Also, Can you simply update the VM like normal to get OS updates to newer versions? 

From My experience, you just have to delete macinabox docker app data folder, and rename template script for vm, so when you run new monterey docker it won't overwrite your Big Sur script (but you have to rename it through terminal, not web gui), and in case of updates, I was able to update Big Sur, monterey and Sonoma normally, I just updated opencore, components and it worked every time.

[mackid1993]

Question, once I have a working BigSur VM, what happens if I upgrade to a newer version of macOS from within the VM? Will everything break?

[DWomack]

I have successfully installed BigSur several times on more than one UnRaid instance.  I have edited the VM instance so that only the BigSur, recovery, and EFI show on the opencore boot screen. 
 

How do I get it to automatically boot BigSur after a timeout?

 

Next question is how do you completely remove a VM?  I tried to install Monterey but had issues.  I have deleted domains, appdata for Monterey, but still it shows up in the list of VMs.  Selecting remove with files, just spins.  What places do I  have to touch to get rid of it?

 

Thanks for the help.

 

 

Dennis

Edited December 11, 2023 by DWomack
Spelling

[Pirokiki]

On 12/10/2023 at 7:34 PM, mackid1993 said:

Question, once I have a working BigSur VM, what happens if I upgrade to a newer version of macOS from within the VM? Will everything break?

I think so

[Pirokiki]

On 12/11/2023 at 3:28 PM, DWomack said:

I have successfully installed BigSur several times on more than one UnRaid instance.  I have edited the VM instance so that only the BigSur, recovery, and EFI show on the opencore boot screen. 
 

How do I get it to automatically boot BigSur after a timeout?

 

Next question is how do you completely remove a VM?  I tried to install Monterey but had issues.  I have deleted domains, appdata for Monterey, but still it shows up in the list of VMs.  Selecting remove with files, just spins.  What places do I  have to touch to get rid of it?

 

Thanks for the help.

 

 

Dennis

If it just spins, you have to edit xml manually and remove Nvram line completely, now it should be removable, but if You want the manual way, You can remove files manually (assuming that all your oaths are default)

from:

/etc/libvirt/qemu

/mnt/user/domains

/mnt/user/isos

and macinabox files from

/mnt/user/appdata

i think that are all locations, but someone correct me if I am wrong

 

[Pirokiki]

On 11/29/2023 at 6:58 PM, ibbanez said:

I have a question. I tried searching, but maybe I'm using the wrong keywords. What additional steps do I need to do to build different VM's? Like I have a Big Sur one running, but I want to try Monterey. Also, Can you simply update the VM like normal to get OS updates to newer versions? 

You have to delete appdata folder of macinabox and remove container, also you have to change macinabox_helper script name (manually from commandline, Because when you change it in the ui, physical names remain intact) so it won’t be overwritten when you will run new docker image. Lastly you just run new macinabox container with new settings for different macOS

[austin]

Ok so everything went smooth as butter following the older spaceinvader video

 

the only weird part was when I downloaded OpenCore configurator it said this is an older efi, i just ignore this and continued following along. The next "weird" thing was that the EFI partition didn't include the NvVars file, just the EFI folder. Again, ignore and copied it to the correct partition.

After this, I shutdown and followed some of his edits to the VM helper script (adding name, etc). I tried adding some CPU's and updating RAM and I've never been able to boot again.

 

I get this error in the log at the moment:

2024-01-13T22:46:40.073081Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
2024-01-13T22:46:40.073111Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.fma4 [bit 16]
2024-01-13T22:46:40.074095Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
2024-01-13T22:46:40.074103Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.fma4 [bit 16]
2024-01-13T22:46:40.074948Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
2024-01-13T22:46:40.074955Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.fma4 [bit 16]
2024-01-13T22:46:40.075725Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
2024-01-13T22:46:40.075732Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.fma4 [bit 16]
qxl_send_events: spice-server bug: guest stopped, ignoring

 

I tried changing the topology setting in the helper script and changing the custom to "unraid" neither of those changes made any difference. So I also tried putting my CPU's and memory back to where they started thinking it was related to that and it seemed to still have an issue. Any ideas what I can try or do I have to start over all together?

[ghost82]

10 hours ago, austin said:

2024-01-13T22:46:40.073081Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]

These are warnings and that features are simply ignored because your native cpu doesn't support them.

 

10 hours ago, austin said:

The next "weird" thing was that the EFI partition didn't include the NvVars file

You don't need that file, that is for emulated nvram, and you will not emulate it.

 

10 hours ago, austin said:

OpenCore configurator it said this is an older efi, i just ignore this and continued following along.

This is the issue, if you use the configurator with an older or newer version of opencore it will mess your configuration file.

What is not working is opencore because it's not configured properly/wrongly or because the image you are using is too old for the os you're trying to boot.

 

10 hours ago, austin said:

Again, ignore and copied it to the correct partition.

I suggest to not copy the efi folder to the macos disk, but let it stay alone in its own disk and configure the vm boot from it, so that the original efi in the macos disk will be simply ignored, otherwise if you mess things with the efi it will be more difficult to mount that partition.

Edited January 14 by ghost82

[austin]

8 hours ago, ghost82 said:

I suggest to not copy the efi folder to the macos disk, but let it stay alone in its own disk and configure the vm boot from it, so that the original efi in the macos disk will be simply ignored, otherwise if you mess things with the efi it will be more difficult to mount that partition.

 

Thank you Ghost! Trying this now. One question, can I still use the OpenCore configurator to set my serial number? Does anyone know which version of OpenCore Configurator is compatible with this macinabox method?

[Pirokiki]

23 hours ago, austin said:

 

Thank you Ghost! Trying this now. One question, can I still use the OpenCore configurator to set my serial number? Does anyone know which version of OpenCore Configurator is compatible with this macinabox method?

You can download Hackintool to check what version of OpenCore You have and then download suitable OpenCoreConfigurator, and I would advise You to use GenSMBIOS script to generate serial number instead of OCC.

[austin]

So I successfully booted up and even got updated to the latest OpenCore! I was hodge poding a lot of docs but at the end of the day, it's working perfect. I have iMessage working (I cloned an actual serial number for an old broken laptop I have laying around) and everything is smooth!

 

I learned pretty quickly that people seem to hate on OpenCore Configurator, so I switched and used a number of different tools to get to the endpoint.

1. I used MountEFI.py at first https://github.com/corpnewt/MountEFI to mount my EFI

2. Then OCAT (OpenCoreAuxillaryTools) https://github.com/ic005k/OCAuxiliaryTools to upgrade my EFI to the latest opencore, there is a button to do this and it handles it all for you. You just need to mount the EFI, which I ended up having to do with OpenCoreConfigurator's mount option (I already had installed, but didnt end up using it besides for mounting) to mount the EFI that the unraid box was actually using. By default MountEFI.py was mounting the EFI of the boot drive and not the secondary disk from the unraid VM. 

3. After updating you'll have an exclamation point at the top center of OCAT, this runs OCValidate which checks your config.plst. I had to update only one configuration to fix, which I just googled. It required me to go to NVRAM in OCAT and delete one of the reocrds and replace with a new value.

4.I think I might've had to do something in ACPI by running https://github.com/acidanthera/MaciASL and changing some CPU pinning thing or something, I did so many random things that I probably have all of this wrong. BUT, it works! So I dont care.

[DWomack]

On 1/15/2024 at 9:20 PM, austin said:

So I successfully booted up and even got updated to the latest OpenCore! I was hodge poding a lot of docs but at the end of the day, it's working perfect. I have iMessage working (I cloned an actual serial number for an old broken laptop I have laying around) and everything is smooth!

 

I learned pretty quickly that people seem to hate on OpenCore Configurator, so I switched and used a number of different tools to get to the endpoint.

1. I used MountEFI.py at first https://github.com/corpnewt/MountEFI to mount my EFI

2. Then OCAT (OpenCoreAuxillaryTools) https://github.com/ic005k/OCAuxiliaryTools to upgrade my EFI to the latest opencore, there is a button to do this and it handles it all for you. You just need to mount the EFI, which I ended up having to do with OpenCoreConfigurator's mount option (I already had installed, but didnt end up using it besides for mounting) to mount the EFI that the unraid box was actually using. By default MountEFI.py was mounting the EFI of the boot drive and not the secondary disk from the unraid VM. 

3. After updating you'll have an exclamation point at the top center of OCAT, this runs OCValidate which checks your config.plst. I had to update only one configuration to fix, which I just googled. It required me to go to NVRAM in OCAT and delete one of the reocrds and replace with a new value.

4.I think I might've had to do something in ACPI by running https://github.com/acidanthera/MaciASL and changing some CPU pinning thing or something, I did so many random things that I probably have all of this wrong. BUT, it works! So I dont care.

 

Have you seen EFI-Agent on GitHub?
 

So, what version of macOS do you have running?  I am at Big Sur. 

 

When I start the VM it runs thru a bunch of code, which are boot messages from OpenCore?

 

Then it is at an OpenCore picker screen and I pick Big Sur and it boots.

 

How do I get it to go straight to Big Sur?

 

I hope SpaceInvader One is progressing along to the new release of Macinabox.

 

 

Dennis

 

Edited January 17 by DWomack
Additional info

[austin]

Well I was working and excited until I rebooted my entire unraid box and the entire VM disappeared. Is there an XML file somewhere that I can re-add it?

[iamtim2]

So I’m a bit of a unraid noob but been running bare metal and proxmox hackintosh’s for a while now so fairly confident editing plist files and opencore bootloader.

 

Having recently built a new unraid server to replace my creaking and old Synology NAS, I figured I may as well get MacOS running on it as it’s on all the time anyway and I wouldn’t need to flash up my gaming PC/Hackintosh every time I needed to do something.

 

Fast forward, I have unraid running great with loads of dockers etc, and following spaceinvaderone’s excellent tutorials, a fully working Big Sur vm with passed through WiFi card, USB PCI-E card and GPU (RX580)

 

As I’d been running Ventura on Proxmox for ages, I thought I’d tinker with the vm to see if I could get Ventura running. There seems to be no guide out there to show you how to do this and all the searching I did pointed at a couple of Docker options that were limited in functionality. I have skimmed through this thread so apologies if it's already covered! Anyway……a long while later - success

 

My setup is an intel server; Xeon E5 2697 v4 running on an ASUS X99-E WS motherboard with 128GB 2300 ECC memory. There is no reason why an AMD setup shouldn’t also work with a few tweaks. Here’s what I did:

 

1.    I used the ‘backup vm’ app from community applications to backup my BigSur vm

 

2.    I then stopped all PCI-E passthrough to the vm to mitigate any issues with passthrough breaking during the install. There is a bug in the current version of unraid where if you deselect GPU passthrough and go back to VNC, you will get the ‘guest has not initialised the display’ message and won’t be able to do anything. Luckily, I had a copy of the vm xml prior to passing through the GPU and just copied it back to the vm. I then tweaked the cpu cores and memory, reran the mackinabox helper script and that fixed the problem. There is a thread if you search for the no display error that tells you how to fix the xml but it was simpler for me to just copy back the original from the initial BigSur install.

 

3.    I then created a new user script and copied the script content from spaceinvaderone’s helper script. I then changed the custom xml entries that the script injects into the vm xml when run. I got the new values from Nick Sherlocks excellent tutorial on installing Ventura on proxmox: https://www.nicksherlock.com/2022/10/installing-macos-13-ventura-on-proxmox/ This is where you may be able to use the AMD values for CPU arguments if running an AMD CPU. Essentially, I changed my script to use the Intel CPU argument 

echo "<qemu:arg value='host,kvm=on,vendor=GenuineIntel,+invtsc,+hypervisor'/>" | tee --append /tmp/"$XML"4.xml

 

This replaced the old line:

echo "<qemu:arg value='Penryn,kvm=on,vendor=GenuineIntel,+kvm_pv_unhalt,+kvm_pv_eoi,+hypervisor,+invtsc,+pcid,+ssse3,+sse4.2,+popcnt,+avx,+avx2,+aes,+fma,+fma4,+bmi1,+bmi2,+xsave,+xsaveopt,+rdrand,check'/>" | tee --append /tmp/"$XML"4.xml

 

This then passes the CPU through to the vm and doesn’t do any CPU emulation.

 

4.    I then used Opencore Configurator to mount the EFI partition and delete all the unnecessary kexts (as I’m using a Fenvi T919 WiFi/Bluetooth card that is natively supported in Ventura, I didn’t need all the bluetooth or wifi/broadcom kexts)

 

5.    I updated all the kexts to the latest versions, especially Lilu, Whatevergreen, AppleALC and VirtualSMC. Follow the guide at https://dortania.github.io/OpenCore-Install-Guide/

 

6.    Macinabox uses an old version of opencore (0.7.8) and the latest version is 0.9.7 so next it was time to update opencore and my EFI folder and files. 

 

7.    I downloaded the latest version of opencore from https://github.com/acidanthera/OpenCorePkg/releases

 

8.    I downloaded Propertree plist editor (https://github.com/corpnewt/ProperTree), used propertree to open the config.plsit from the BigSur EFI disk (mount the disk with opencore configurator as shown in spaceinvaderone’s install video). Then open the sample.plist in the Docs folder of the opencore download, place side by side

 

9.    I followed the opencore install guide (I used Intel HEDT/Broadwell-E under the configs sidebar) but follow whichever guide matches your CPU. The thing to bear in mind is I’m passing through the CPU to the vm as ‘host’, so the vm see’s my real CPU not as an emulated Intel ‘Penryn’ CPU in the current BigSur mackinabox vm. The motherboard is obviously emulated but I followed the guide for X99 (my actual motherboard) where motherboard parameters are used and it seemed to work. You may need to tweak slightly?

 

10. There is quite a bit of discrepancy between the Dortania guide and some of the settings in the mackinabox BigSur config.plist so I used the guide as the main reference, changing values where it told me to but where it was a bit ambiguous, I matched the settings from the mackinabox config.plist.

 

11. Once all the edits to the sample.plist was done, I renamed it config.plist and saved it to my desktop. I then followed the guide to build the EFI folder, finally adding the new config.plist once done.

 

12. I then replaced the BigSur EFI folder with the newly constructed EFI folder with the new config.plist and updated kexts and driver files.

 

13. I rebooted the vm to check it all worked and BigSur booted fine but now running on Opencore 0.9.7.

 

14. Next, I opened up a terminal window and used the command 

Quote

softwareupdate --fetch-full-installer --full-installer-version 13.6.4

 

This downloads the latest Ventura install app into your applications folder

 

15. I Then simply went to the downloaded file in applications, double clicked and followed the prompts to install Ventura over the top of Big Sur

 

16. To my complete surprise, it went through the full update with no errors and I was able to boot into Ventura 13.6.4

 

17. I renamed the vm from 'Mackinabox Big Sur' to 'Ventura'. If you use qcow2 in the macinabox docker configuration when creating the initial vm you’ll have a problem when renaming. There is a bug that messes up the disk setting in the xml when renaming a vm, changing it from qcow2 to raw. If you try and now boot, you go straight to a UEFI screen and your boot disk can’t be seen. You need to go into the xml and change the disk type back to qcow2 in the line that starts <driver name=

<devices>
    <emulator>/usr/local/sbin/qemu</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='writeback'/>
      <source file='/mnt/user/domains/BigSur/macos_disk.img'/>
      <target dev='hdc' bus='sata'/>
      <boot order='1'/>
      <address type='drive' controller='0' bus='0' target='0' unit='2'/>

 

18. I then came across another issue where when passing through the USB, WiFi and RX580 again, I just got a black screen. I checked my settings and they were the same as before so I was a bit stumped. I then compared the original BigSur xml with working passthrough, to the new Ventura xml and noticed that some of the lines had subtly changed for some reason. I replaced all the lines below the second <devices> </disk> entry from the BigSur xml in the Ventura xml. Voila! GPU passthrough now works.

 

19. Any changes from now on, as long as I used the updated helper script are fine and the vm performs fine.

 

20. I used GenSMBIOS (https://github.com/corpnewt/GenSMBIOS) to generate serials etc for an iMAC19,1 mac type and all iMessage services, handoff and Airdrop work fine. The Opencore guide tells you how to do this.

 

There’s an issue with the latest kernel that causes a crash when connecting the WiFi to an encrypted WiFi net (works fine with WiFi with no password) so I can’t connect the WiFi but I’m running hard wired so not an issue for me and all iServices seem to work fine.

 

I did a second update of another macinabox BigSur install to Sonoma and that also works following the guide above but Sonoma has dropped support for Broadcom cards and I had issues with Bluetooth that I couldn't seen to fix even with the OpenCore Legacy Patcher workaround so that was a non-starter for me and Ventura is fine for my needs

 

Hopefully this mini guide will help others to get Ventura (or Sonoma) up and running on unraid.

[lomakor4]

how to change vm name?when i rename everething has broken

[iamtim2]

1 hour ago, lomakor4 said:

how to change vm name?when i rename everething has broken

To rename, click edit on the vm and simply change the name. You’ll then need to follow the instructions at paragraph 17 above if the original vm was created with qcow2 disk type to get it working again

[lomakor4]

4 hours ago, iamtim2 said:

To rename, click edit on the vm and simply change the name. You’ll then need to follow the instructions at paragraph 17 above if the original vm was created with qcow2 disk type to get it working again

ty

[lomakor4]

when i change config plist in opencore i get error

NOTE: This version of ocvalidate is only compatible with OpenCore version 0.9.6!

NVRAM->Add->7C436110-AB2A-4BBB-A880-FE41995C****->csr-active-config has illegal value!
CheckNvram returns 1 error!

Completed validating /Volumes/EFI/EFI/OC/config.plist in 2 ms. Found 1 issue requiring attention.

[lomakor4]

2 hours ago, lomakor4 said:

when i change config plist in opencore i get error

NOTE: This version of ocvalidate is only compatible with OpenCore version 0.9.6!

NVRAM->Add->7C436110-AB2A-4BBB-A880-FE41995C****->csr-active-config has illegal value!
CheckNvram returns 1 error!

Completed validating /Volumes/EFI/EFI/OC/config.plist in 2 ms. Found 1 issue requiring attention.

solved  need 0.7.7 opencore configurator        but changes dont apply after reset+config

[DWomack]

Looking for an annotated user script that will remove all of what Macinabox has touched, so a new macinabox can be created.

 

A script would be much better than touch this, and this, delete this, etc.

 

Maybe the script could remove all VMs and the dockers necessary.

 

Sure I can stumble through all the steps, but a script that always works without mistakes would be much better.

 

Thanks to iamtim2 for posting his guide above.