A couple of things.

• Testing a Windows VM doesn't mean that the Apple server nearest to you is accessible, just as some people lose access to GitHub occasionally and complain that updates aren't available, but others don't.
• You have to run the helper script unedited before you run the VM for the first time to do the installation. Then, after the installation, you need to edit the user script and run it again. Are you doing that?

 

1 minute ago, John_M said:

A couple of things.

• Testing a Windows VM doesn't mean that the Apple server nearest to you is accessible, just as some people lose access to GitHub occasionally and complain that updates aren't available, but others don't.
• You have to run the helper script unedited before you run the VM for the first time to do the installation. Then, after the installation, you need to edit the user script and run it again. Are you doing that?

 

I understand, and thanks for clarifying that John_M. I was using that example as a troubleshooting opportunity to show no firewall blocking or anything. To answer your next question, I let my last install of Macinabox sit overnight, then ran the scripts as directed. I wasnt aware of having to edit the user script again...I dont recall seeing that in the video. I really appreciate you taking the time to assist, just not sure of the editing of the user script a second time.

Just now, cloudgeek said:

I dont recall seeing that in the video.

 

It's there. I suggest you watch it again and using play and pause do the operations in real time. There are a lot of them and the order is important. I certainly can't remember them all!

 

1 minute ago, John_M said:

 

It's there. I suggest you watch it again and using play and pause do the operations in real time. There are a lot of them and the order is important. I certainly can't remember them all!

 

Nor would I expect you to. LOL - I will comb back through the most current video to see what I missed. Thank you for pointing me in that direction.

2 minutes ago, cloudgeek said:

Nor would I expect you to. LOL - I will comb back through the most current video to see what I missed. Thank you for pointing me in that direction. To make sure I am using the correct video, I am refering to the Dec 9th youtube video, correct? That is the latest one I have found.

 

2 minutes ago, cloudgeek said:

Thank you for pointing me in that direction.

 

That's ok. The timecode of the first run of the helper is 8:10 and of the edit and second run 14:00.

 

Correct. 9th December. "How to Install Big Sur and Other macOS Versions with New Macinabox"

 

 

2 minutes ago, John_M said:

 

That's ok. The timecode of the first run of the helper is 8:10 and of the edit and second run 14:00.

 

Ok, after reviewing I need to correct myself. Referring to the video, at 9:19 (following all steps religiously) I get to this point and this is where it tells me it can not contact the recovery server. I dont any further than this. I think this is where the other person is getting stuck as well. 

1 minute ago, cloudgeek said:

Ok, after reviewing I need to correct myself. Referring to the video, at 9:19 (following all steps religiously) I get to this point and this is where it tells me it can not contact the recovery server. I dont get any further forward than this. I think this is where the other person is getting stuck as well.  I am wondering if my default network bridge needs to be virbr0 in the VM Manager. Can anyone confirm?

 

Edited February 2, 20215 yr by cloudgeek

1 hour ago, avinyc said:

The recovery server error persists

 

1 hour ago, John_M said:

Could there be a local connectivity issue that's unrelated to Unraid?

That was what I though, start a terminal in recovery and ping some website (and apple servers) to see if you have connectivity.

 

PS: I don't use macinabox but only here to try to help and figure out what's happening.

Apart the issue in downloading the wrong os, everything should work ok to setup a mac os basic vm...

And that's also strange that method 2 fails for somebody: method 2 is macrecovery script from acidanthera:
https://github.com/acidanthera/OpenCorePkg/blob/master/Utilities/macrecovery/macrecovery.py

 

with some custom modifications for macinabox.

Acidanthera's script was updated during time and nobody opened issues in the bugtracker..

Edited February 2, 20215 yr by ghost82

49 minutes ago, cloudgeek said:

Would there be any value to pasting the XML of the VM here for you much more experienced folks to review?

 

It can be useful, but most of the time I see that issues are with the bootloader configuration.

Setting up a near perfect and optimized mac os vm is far away from having a windows vm up and running.

25 minutes ago, cloudgeek said:

I am wondering if my default network bridge needs to be virbr0 in the VM Manager. Can anyone confirm?

I've been trying other troubleshooting options. Shutting down my only othe VM and stopping all dockers except macinabox.  Still nothing.  

 

I tried googling for this error, but none of the solutions work for VM.  Clock is set correctly.  I don't know how to copy the installer log from VNC (copy and paste doesn't work) but there are errors in there that might be helpful too.

58 minutes ago, cloudgeek said:

I am wondering if my default network bridge needs to be virbr0 in the VM Manager. Can anyone confirm?

 

Are you using virbr0 in the vm instead of br0?

You should use br0 and make sure the router assigns a local ip address to the vm.

Setup also the vm so it has only one network, the bridge with internet access.

Start a terminal, type "date" and enter, what's the output?

Edited February 2, 20215 yr by ghost82

8 minutes ago, ghost82 said:

 

Are you using virbr0 in the vm instead of br0?

Na, I was just asking for troubleshooting. I just blew everything away again and restarted the process and its showing source bridge as br0 

   <interface type='bridge'>
      <mac address='52:54:00:XX:XX:XX'/>
      <source bridge='br0'/>
      <target dev='vnet0'/>
      <model type='vmxnet3'/>
      <alias name='net0'/>

Edited February 2, 20215 yr by cloudgeek

44 minutes ago, ghost82 said:

 

That was what I though, start a terminal in recovery (if it's possible..(?)..I never downloaded the os straight from the recovery) and ping some website (and apple servers) to see if you have connectivity.

 

PS: I don't use macinabox but only here to try to help and figure out what's happening.

Apart the issue in downloading the wrong os, everything should work ok to setup a mac os basic vm...

And that's also strange that method 2 fails for somebody: method 2 is macrecovery script from acidanthera:
https://github.com/acidanthera/OpenCorePkg/blob/master/Utilities/macrecovery/macrecovery.py

 

with some custom modifications for macinabox.

Acidanthera's script was updated during time and nobody opened issues in the bugtracker..

 

1 hour ago, cloudgeek said:

Does anyone have IPs for the apple servers I could try pinging other than google?

 

12 minutes ago, cloudgeek said:

 

 

I found one and got one hit from it before being shut down. This was from osrecovery.apple.com

3 minutes ago, cloudgeek said:

I found one and got one hit from it before being shut down. This was from osrecovery.apple.com

Here are the errors I received from the installer log. (errors only)

10 minutes ago, cloudgeek said:

I found one and got one hit from it before being shut down. This was from osrecovery.apple.com

 

FWIW if I ping 17.164.1.12 I get request timeout too.

 

Also FWIW, Big Sur isn't all that great at the moment, even with the update to 11.2. It's needed on Apple Silicon, of course, but Catalina is fine on AMD64.

 

I have cleaned out everything, tried reinstalling with Catalina, with method 1 and 2 and still come to a point where I get the error "The recovery server could not be contacted" Beyond getting the recovery server can not be contacted error, I got a new one. Do I need to start the process over again I guess?

Hi! I've search through the thread but I haven't found how to pass the iGPU. I have a i7 10700 and I cannot manage to pass correctly the igpu. I've set it as a second gpu, and modified the OpenCore config file to match what is says here https://dortania.github.io/OpenCore-Install-Guide/config.plist/comet-lake.html#deviceproperties PciRoot(0x0)/Pci(0x2,0x0) > new AAPL,ig-platform-id = 0300C89B as I want to use it to compute but not to drive a display.

It boot to the boot menu, apple logo and the crashes

Anyone can help me?

11 hours ago, avinyc said:

That seems like the most promising explanation.  It has to be something going on either in my server or router if this connection issue is not universal.  I'll see if I can figure out if somehow there is a firewall problem or something causing this to fail.

So I went into the vm a tried to test safari and of course it was blocked by my router.  I had set up access control to prevent new devices from connecting without approval.  So turned that off and started this from scratch.  Selecting big sur still brings up catalina instead, but no more server connection issues.  Will finish the install and see if upgrading through the VM works.

 

My apologies for wasting others time with this stupid mistake on my end.  Until the next one!

Hi, I tried to install Big Sur on the macinabox and for whatever reason, i get the macOS Catalina install? Is anyone else experiencing same issue.

 

All other items, including macinabox configuration says Big Sur, VMS states Big Sur... Seems like the big sur download file might be a catalina copy named big sur?

 

 

Quote

Hi, I tried to install Big Sur on the macinabox and for whatever reason, i get the macOS Catalina install? Is anyone else experiencing same issue.

 

All other items, including macinabox configuration says Big Sur, VMS states Big Sur... Seems like the big sur download file might be a catalina copy named big sur?

I am also having the same problem.  Trying to install Big Sur and Catalina is what is installing.

 

9 hours ago, Bullerwins said:

PciRoot(0x0)/Pci(0x2,0x0)

How did you find this address?

Check if it's correct with gfxutil:

https://github.com/acidanthera/gfxutil/releases/download/1.80b/gfxutil-1.80b-RELEASE.zip

 

gfxutil -f IGPU

 

Maybe you need to passthrough the cpu and not emulate it in libvirt, but I'm not sure.

Edited February 3, 20215 yr by ghost82

I took a look at macinabox code hosted on github.

Macinabox calls fetch.sh:
 

#!/bin/bash
# fetch method selects which method to get osx with
set +x;
SCRIPTDIR="$(dirname "$0")";
cd "$SCRIPTDIR" || exit

# Method 1
# Big Sur uses script 2 for method 1
if [ "$method" = "method 1" ] && [ "$flavour" == "Big Sur" ] ; then		
# python3 fetch-macos2.py
python3 fetch-macos.py # temporary use other big sur download method for now
# others uses script 1 for method 1
elif [ "$method" = "method 1" ] ; then
python3 fetch-macos.py "$@"
fi

# Method 2
# Big Sur uses script 1 for method 2
if [ "$method" = "method 2" ] && [ "$flavour" == "Big Sur" ] ; then	
python3 fetch-macos.py "$@"	
# others uses script 2 for method 2
elif [ "$method" = "method 2" ] ; then
python3 fetch-macos2.py
fi

exit;

 

What I understand is that even if you choose method 2 for big sur the script will use fetch-macos.py (1st method).

User chooses method 1  and big sur --> fetch-macos.py (1st method)

User chooses method 2  and big sur --> fetch-macos.py (1st method)

 

Method 2 will work only if the os is different from big sur.