[Support] SpaceinvaderOne - Macinabox


Recommended Posts

5 hours ago, SpaceInvaderOne said:

Yes.

Using opencore configurator. Mount your efi partition and open the config.plist with the configurator.

goto misc

and set as in this pic (check hideauxillary and uncheck show picker)

 

429713460_ScreenShot2020-12-10at17_13_33.thumb.png.2422d3ba33d3750cba0a578f950f3990.png

 

Thanks!  Exactly what I needed.  All booted up with graphic card passthrough on Big Sur!!!

Link to comment

SOLVED! This issue has been fixed by changing my NIC device to built-in.

Here is link to guide so its easy to find.

 

 

Have Big Sur up and running with passthrough gpu and nvme, everything is running fine apart from being able to sign into iCloud.

I can sign into the App Store fine just not iCloud, I get the following error "could not communicate with server"

I have tried with all different virtual NIC types and have even passed through an intel Nic that's working. Just no luck.

Have also tried different smbios. 

Any help would be great as this is the last thing to get this 100%

Thanks in advance 

Screen Shot 2020-12-11 at 3.09.34 PM.png

Edited by steveBBB
  • Like 2
  • Thanks 1
Link to comment

i have searched this topic with a few key terms and have not seen this come up but if it has please point me in the right direction :)

 

macinabox has installed the VM but upon boot it presents the UEFI shell and gives the option "Press ESC in 5 seconds to skip startup.nsh or any other key to continue"

1997938965_ScreenShot2020-12-11at09_29_36.png.c8b876287ff925812ce9e89864312f14.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

I can't seem to pass this screen. If I press ESC then the Shell prompt appears. When I press "any other key" such as a physical letter key or even CTRL or ALT on my keyboard - it does not seem to affect the system in anyway. I also tried using the VNC buttons to press CTRL and ALT with no difference.

 

I AM able to issue the "reset" command at the Shell prompt which resets the 5 second count-down. i AM able to issue the "exit" command which put into a BIOS looking type of screen:

1927109268_ScreenShot2020-12-11at10_27_53.thumb.png.992e7d096f4ce7e85e642e36aa6c7cae.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

This is what the log looks like:

267791013_ScreenShot2020-12-11at09_49_01.png.ea36f310d2d7ae384128e76ea4f73beb.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Any guidance is much appreciated :)

Link to comment

Question regarding the macinabox_vmready_notify script:

IF the BigSur download is completed before I run this script:

  1. Does the script show a notification that "macOS is now ready to install" ?
  2. OR will no notification appear since the downloading was not in progress when I began the userscript?

The reason I ask is because it took me several minutes to get the user script running after I started the docker.  I'm on a 1Gbps WAN connection so its theoretically possible that it completed the download before I began the script.  I've had the script running in the background for about 45 minutes without any notice that macOS is now ready to install.  I'm not sure how big the file(s) are or where they are downloading on my server.

 

I checked the isos folder and there are two files: (Note GiB, not GB as reported by Krusader)

  • BigSur-install.img (3.0 GiB)
  • BigSur-opencore.img (150.0MiB)

Not sure if anyone has any input but I will let this run for a few more hours just in case.

Link to comment
11 minutes ago, charlescc1000 said:

Question regarding the macinabox_vmready_notify script:

IF the BigSur download is completed before I run this script:

  1. Does the script show a notification that "macOS is now ready to install" ?
  2. OR will no notification appear since the downloading was not in progress when I began the userscript?

The reason I ask is because it took me several minutes to get the user script running after I started the docker.  I'm on a 1Gbps WAN connection so its theoretically possible that it completed the download before I began the script.  I've had the script running in the background for about 45 minutes without any notice that macOS is now ready to install.  I'm not sure how big the file(s) are or where they are downloading on my server.

 

I checked the isos folder and there are two files: (Note GiB, not GB as reported by Krusader)

  • BigSur-install.img (3.0 GiB)
  • BigSur-opencore.img (150.0MiB)

Not sure if anyone has any input but I will let this run for a few more hours just in case.

What the script does is check if a folder called autoinstall had been made in the macinabox appdata. This folder is made and contains the xml to define the vm.

#!/bin/bash
# script to notify on Unraid server when Macinabox has finished downloading install media 
# by SpaceinvaderOne

while [ ! -d /mnt/user/appdata/macinabox/autoinstall/ ]
do
  sleep 5 #wait 5 seconds before rechecking
done
/usr/local/emhttp/webGui/scripts/notify -e "Unraid Server Notice" -s "Macinabox" -d "macOS now ready to install (now run helper script)" -i "normal"
exit

 

This is created after the install media has been converted from dmg to img and moved into the iso share.

There may be 2 cases which happen why the notification script would not show this to be done.

1.  Manual install was selected and not auto install. With manaul install this folder and xml is not created.

2. Your appdata is not in the default unraid location.  ie ( /mnt/user/appdata/ )  the script then will not see the folder as it uses the direct path.

    So you could change the script with the location of your appdata.  But you would also need to change the location in the helper script aswell in the installvm function part of that script as it also references the appdata there too when the vm is first installed

 

Link to comment
1 hour ago, SpaceInvaderOne said:

What the script does is check if a folder called autoinstall had been made in the macinabox appdata. This folder is made and contains the xml to define the vm.


#!/bin/bash
# script to notify on Unraid server when Macinabox has finished downloading install media 
# by SpaceinvaderOne

while [ ! -d /mnt/user/appdata/macinabox/autoinstall/ ]
do
  sleep 5 #wait 5 seconds before rechecking
done
/usr/local/emhttp/webGui/scripts/notify -e "Unraid Server Notice" -s "Macinabox" -d "macOS now ready to install (now run helper script)" -i "normal"
exit

 

This is created after the install media has been converted from dmg to img and moved into the iso share.

There may be 2 cases which happen why the notification script would not show this to be done.

1.  Manual install was selected and not auto install. With manaul install this folder and xml is not created.

2. Your appdata is not in the default unraid location.  ie ( /mnt/user/appdata/ )  the script then will not see the folder as it uses the direct path.

    So you could change the script with the location of your appdata.  But you would also need to change the location in the helper script aswell in the installvm function part of that script as it also references the appdata there too when the vm is first installed

 

Hi Ed-

Thanks for offering your input.

 

I checked the appdata folder and this is what I've found:  (the parent folder of this screenshot is /mnt/user/appdata)

 

2008284606_ScreenShot2020-12-11at10_20_28AM.thumb.png.872697b41fd163826bb28e4a8a1b3c20.png

 

Here is a screenshot of /mnt/user/system/macinabox :

222732596_ScreenShot2020-12-11at10_25_55AM.thumb.png.a86b74fb319f0d3f2a2a7572ee29086d.png

 

It looks like at some point I changed my Docker default appdata location to /mnt/system ? Not sure why I would have done this - but when I started learning Unraid a few years ago I definitely had some beginner mistakes and maybe this is a leftover error that I've just noticed now.

Anyway - I think I've found my error

 

103626487_ScreenShot2020-12-11at10_27_32AM.thumb.png.2b569558471fa52bdf1a07484f05a642.png

 

I believe the three directories outlined in my red annotation should read as follows:

appdata (leave as is) /mnt/user/system/macinabox

Macinabox only data: /mnt/user/system/macinabox/macinabox

Basesystem: /mnt/user/system/macinabox/basesystem

 

OR should I switch the first directory to:

appdata: /mnt/user/appdata/macinabox ?

and then leave other two as is?

 

Not sure which is easier but I think either way I will delete all and totally redo to ensure a clean install.

 

I deleted the docker, system/macinabox, appdata/macinabox, docker template, and re-did the whole process.

 

This time I edited the appdata path to read /mnt/user/appdata/macinabox instead of the /mnt/user/system/macinabox that my server defaulted to.  Went over to user scripts and ran the notify and it was ready almost instantaneously.  Finishing the rest of the process now!

 

Thank you again for all you do for our community.

 

 

Edited by charlescc1000
Progress update
  • Like 1
Link to comment

Sooo... I might be of some help, for a change.

 

I had the problem with login to my Apple ID and had various error messages like "could not communicate withe server" or "this computer already registered to many ID's" (or something like that.

I did two things :

 

1 - I fixed the En0 following this guide.

The problem was thas I had a network adapater as En0 but it was not marked as built-in.

 

2 - I notice that even if I filled out the "PlatformInfo" tab in the OpenCore Configurator as shown in the video (with mac model, serial number etc...) when I clicked on "About this mac" I had no model specified... just "mac". And Hackintool also showed Standard PC (Q35 + ICH9, 2009)" as Model indentifier.

The error I made (or the thing I did not corrected) was that under the PlatformInfo tab the scroll down menu on the bottom right was set to "Overwrite"... But it obviously had nothing to overwrite and changing it to "create" did the trick ! On reboot I had the right model identifier and I could log in to icloud with no problem...

 

Hope that will help someone !

Edited by bjornatic
  • Thanks 1
Link to comment
3 hours ago, bjornatic said:

1 - I fixed the En0 following this guide.

The problem was thas I had a network adapater as En0 but it was not marked as built-in.

 

2 - I notice that even if I filled out the "PlatformInfo" tab in the OpenCore Configurator as shown in the video (with mac model, serial number etc...) when I clicked on "About this mac" I had no model specified... just "mac". And Hackintool also showed Standard PC (Q35 + ICH9, 2009)" as Model indentifier.

The error I made (or the thing I did not corrected) was that under the PlatformInfo tab the scroll down menu on the bottom right was set to "Overwrite"... But it obviously had nothing to overwrite and changing it to "create" did the trick ! On reboot I had the right model identifier and I could log in to icloud with no problem...

 

Hope that will help someone !

1 - How far did you have to go?  I also don't have a check-mark under built-in.  I'm not sure how to go about:

If this doesn't work, add NullEthernet.kext (opens new window) and ssdt-rmne.aml (opens new window) to your EFI and config.plist under Kernel -> Add and ACPI -> Add respectively. The SSDT is precompiled so no extra work needed, reminder compiled files have a .aml extension and .dsl can be seen as source code.

 

2 - Mine shows as Mac Pro (Late 2013) so I think I'm good there.

 

Link to comment

Wow, now that’s a coincidence, after working all day to get my more or less custom VM upgraded to Big Sur from Catalina after waiting quite a bit since release I discovered that a new version of Macinabox is out, I guess I could have just used this one.

 

I wonder though, have you done any magic regarding the AMD reset bug, SpaceInvaderOne? As I just watched your video and there was no mention about GPU passthrough issues as far as I could tell. That’s the only issue still left with my custom VM and I wonder if I should still try your Macinabox out. Basically any time my macOS VM restarts / shuts down when I use GPU passthrough I need to reboot the whole server, isn’t that an issue here?

Link to comment
On 12/10/2020 at 5:40 PM, SpaceInvaderOne said:

If when clicking webui it goes to the old macinabox youtube video then the old template was still installed when you downloaded the container. (this is not in the new template - so it has now just merged the pld and new template together)

 

Please delete the container. Then goto the bottom of the docker page. Click add template. Then click select template. From the list of your previously installed templates choose macinabox. Then to the right of its name click the black cross. It will remove the template. Then goto the apps tab search for and install macinabox and it will download the template from ca and install the new one. :)

 

Dear Ed,

 

I have:

 

  • deleted the Container, template, appdata, scripts and all MacOS vm`s. 
  • restarted the server.
  • installed the Container, first attempt failed. The second was a success.
  • followed your video instructions to the point. 
  • during macOS restarts, the first two times the disk was named "Mac OS installer", the third restart named "BigSur".
  • webUI still directs to the the YouTube video. http://[IP]:[PORT:7800] works fine.
  • when adding new connection I get the same error as some other users. 

 

 

The vm works fine, but I would really like to add a vm. So, I would be really happy if you could shed some light of possible fix.

 

 

// Frode

Screenshot 2020-12-11 at 19.48.01.png

Screenshot 2020-12-11 at 18.08.00.png

Screenshot 2020-12-10 at 19.05.32.png

Link to comment
15 hours ago, Mr_Jay84 said:

Could any one shed any light on the following error

 

 

Execution error

operation failed: unable to find any master var store for loader: /mnt/user/system/custom_ovmf/Macinabox_CODE-pure-efi.fd

 

This after install the latest version of macinabox

 

From Will Becker on YouTube

 

"I have your fix maybe!, at least, this fixed it for me. Open a unraid terminal window, go to /mnt/user/system/custom_ovmf/ and then do a "ls -a" command, which showed me that there was a .fd file in there that matched the error. Mine was named Macinabox_CODE-pure-efi.fd so I ran "rm -f Macinabox_CODE-pure-efi.fd" , then deleted everything else associated with macinabox like the MacOS iso, the domain folder for it, the appdata folder for macinabox, deleted macinabox docker, deleted its template, and now im trying again."

 

This worked. Thanks to Will.

  • Like 2
Link to comment

I am trying to install Macinabox Big Sur, too.  The problem I am getting is that when I have downloaded opencore configurator and mounted the QUEMU hard disk media EFI, there are no files to copy to the desktop.

 

Where could they have got to?  I'm seriously looking forward to not having to replace the custom XML everytime I tweek a setting on a VM.  Thanks so much for your great work Spaceinvaderone!

Link to comment

I've got a really strange bug. 

 

I was able to successfully install and boot the VM to the desktop (Big Sur). I then proceeded to add two additional CPUs and my GPU, add the name of the VM to the script, apply the script, and successfully reboot. 

 

Following this I then attempted to pass through my USB controller, following the same procedure applying the script after editing the VM, and then attempted to boot - my display then will not initialize and 1 CPU core is pegged to 100%. 

 

Removing the USB controller from the VM and rebooting Unraid does not solve the issue. I also attempted to remove the GPU, and the VNC window then says that the guest has not initialized the display. I have deleted everything and started from scratch and the same problem pops up as soon as I pass through the USB controller. The only thing that seems to resolve it is deleting all Macinabox files and starting from scratch. 

 

Here below is the log from when I have returned all VM settings to default, with the issue presenting. 

ErrorWarningSystemArrayLogin


-device pcie-root-port,port=0xb,chassis=3,id=pci.3,bus=pcie.0,addr=0x1.0x3 \
-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \
-device pcie-root-port,port=0xa,chassis=5,id=pci.5,bus=pcie.0,addr=0x1.0x2 \
-device pcie-pci-bridge,id=pci.6,bus=pci.1,addr=0x0 \
-device ich9-usb-ehci1,id=usb,bus=pcie.0,addr=0x7.0x7 \
-device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pcie.0,multifunction=on,addr=0x7 \
-device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pcie.0,addr=0x7.0x1 \
-device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pcie.0,addr=0x7.0x2 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x0 \
-blockdev '{"driver":"file","filename":"/mnt/user/isos/BigSur-opencore.img","node-name":"libvirt-3-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \
-blockdev '{"node-name":"libvirt-3-format","read-only":false,"cache":{"direct":false,"no-flush":false},"driver":"raw","file":"libvirt-3-storage"}' \
-device ide-hd,bus=ide.2,drive=libvirt-3-format,id=sata0-0-2,bootindex=1,write-cache=on \
-blockdev '{"driver":"file","filename":"/mnt/user/isos/BigSur-install.img","node-name":"libvirt-2-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \
-blockdev '{"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":false,"no-flush":false},"driver":"raw","file":"libvirt-2-storage"}' \
-device ide-hd,bus=ide.3,drive=libvirt-2-format,id=sata0-0-3,write-cache=on \
-blockdev '{"driver":"file","filename":"/mnt/user/domains/Macinabox BigSur/macos_disk.img","node-name":"libvirt-1-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \
-blockdev '{"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":false,"no-flush":false},"driver":"raw","file":"libvirt-1-storage"}' \
-device ide-hd,bus=ide.4,drive=libvirt-1-format,id=sata0-0-4,write-cache=on \
-netdev tap,fd=35,id=hostnet0 \
-device e1000-82545em,netdev=hostnet0,id=net0,mac=52:54:00:47:d7:ba,bus=pci.3,addr=0x0 \
-chardev pty,id=charserial0 \
-device isa-serial,chardev=charserial0,id=serial0 \
-chardev socket,id=charchannel0,fd=36,server,nowait \
-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \
-device usb-tablet,id=input0,bus=usb.0,port=1 \
-vnc 0.0.0.0:0,websocket=5700 \
-k en-us \
-device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.6,addr=0x1 \
-device virtio-balloon-pci,id=balloon0,bus=pci.4,addr=0x0 \
-usb \
-device usb-kbd,bus=usb-bus.0 \
-device '************************' \
-smbios type=2 \
-cpu Penryn,kvm=on,vendor=GenuineIntel,+invtsc,vmware-cpuid-freq=on,+pcid,+ssse3,+sse4.2,+popcnt,+avx,+aes,+xsave,+xsaveopt,check \
-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
-msg timestamp=on
2020-12-12 16:22:36.410+0000: Domain id=9 is tainted: high-privileges
2020-12-12 16:22:36.410+0000: Domain id=9 is tainted: custom-argv
2020-12-12 16:22:36.410+0000: Domain id=9 is tainted: host-cpu
char device redirected to /dev/pts/0 (label charserial0)

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.