[Support] SpaceinvaderOne - Macinabox


Recommended Posts

Hello all,

 

I have watched the video carefully, I have deleted everything and started from scratch like 10 times, and I still cannot install Big Sur. I managed to install Catalina. What I do to retry:

 

1. delete docker container macinabox

2. delete container template

3. delete macinabox in appdata

4. delete downloaded isos

5. delete macOS vms

6. delete macos domains

 

Issues that I face.

 

- Scripts only installed if Catalina is selected

- Big Sur with method 1 in download will always download Catalina

- If method 2 is selected and VM is created when I run it I can see a black screen with a mouse cursor on the upper left corner. I cannot move that cursor and that's pretty much it.

- At some point I managed to reach the installation process (with horrendous mouse offset), did all the UI navigation with keyboard and reached a point where installation would complain about network error and could not proceed further (I did not note down the error).

 

I am pretty much stuck, I think if I try again Catalina with method 1 will succeed but my hands are tied as far as Big Sur is concerned.

 

Any help, guideline or something would be appreciated.

 

Cheers to spaceinvaderone for his tremendous efforts. There would be no Unraid without him.

 

EDIT:

I redid everything, Now at first VM start I get "guest has not initialized the display yet".

Please note that I have a Windows 10 VM with GPU passthrough that I tried controlling again with VNC instead of the GPU and I get the same error there (GPU works). I am reading around that once you pass through a GPU, VNC gets broken. I thought that was the case for the specific VM, is it possible that it breaks VNC altogether?

 

EDIT 2:

 

Reducing VM memory by 500MB brought back the black screen with the cursor stuck on upper left corner.

 

 

Edited by snolly
Link to comment

2.png.93d8075d6dd24aac3cab22aa98252c3d.png

After install macinabox ,I met this problem .It seems like some sort of permission problem. Hope you can give me some guide to work it out.

"[services.d] starting app...
 [app] starting Macinabox with VirtManager...
 [services.d] done.
 unzip: can't change directory to '/userscripts/': Permission denied
 unzip: can't change directory to '/userscripts/': Permission denied
 chmod: /userscripts/1_macinabox_helper/: Permission denied
 chmod: /userscripts/1_macinabox_vmready_notify/: Permission denied"

 

 

And I have to say it is so weird that I devote 3 days but still in van. I have tried reinstall ,changing hardware and reinstall unraid system. I HOPE SOMEONE CAN HELP!

Edited by Arno142038
Link to comment

Hey John, thanks for the reply. To answer, no my unraid server is a physical appliance.  Every time I run through the process, I get the "can not connect to a recovery server" error message. I even checked the network utility and its not passing any traffic (no ping, traceroute, etc). I have a windows VM that works beautifully thanks to the instructions SpaceInvaderOne had in the video. I have wiped all the records built by Macinabox and retried...but it seems futile to chase the wrong MacOS issue until the connecting to recovery server issue is resolved. I appreciate any help folks, and thanks in advance.

Link to comment

I used an early version of the container to make a Big Sur VM, though it wasn't as straight-forward as the instructions suggest and I had to re-try several times. It has since been updated two or three times and it seems not to work properly in its current state. Certainly, getting it to download the Big Sur recovery media seems problematic and the user scripts seem to take longer than expected to show up. Maybe I'll try to set up a Catalina VM from scratch on a test server and see how it goes. If I have any success, I'll report back. One thing that seems certain to cause failure is if you change certain paths from their defaults as they appear to be hard-coded into the script that patches the XML. I see a lot of frustration in the comments on the last two or three pages here. I'm just another user, though. Perhaps a comment from the author would help.

Link to comment

I've only just started, on a test server that has never had any version of MacInABox installed before and it's looking promising so far. I just accepted all the defaults and made sure Catalina was the macOS version chosen (it is the default).

 

1502438998_ScreenShot2021-01-25at18_52_36.thumb.png.873f94d19c36d8b85a2ed6f50de7221c.png

 

1850246141_ScreenShot2021-01-25at18_54_20.thumb.png.9241e7333e4091da97497580df70f30a.png

 

257239020_ScreenShot2021-01-25at19_07_18.png.16d4e6ba20d58328fd0c25c6d319dd53.png

 

The VM icon is the default one because I don't use Ed's method. I'll add my own later.

 

Link to comment

Well, that worked fine. It's all installed and it found a security update and a new version of Safari, which also installed without a problem. There's also an update to Big Sur offered but I'm ignoring that - other people have tried it and report that it trashes the existing Catalina VM.

 

358284968_ScreenShot2021-01-25at21_06_55.thumb.png.db58f3d74cffe9759ccb7fcd6f8aecb6.png

 

I don't have a suitable GPU in this server to try to pass through but I have an RX 580 in another server that works.

 

There are a lot of steps to complete after the installation, including setting up OpenCore to make the vdisk bootable, choosing a machine type and checking that the serial number is NOT valid, then shutting down, editing the template to add RAM and CPU cores to the VM and remove no longer required vdisks, editing the helper user script and finally running it. They have to be performed precisely and in the right order, so no wonder some people are having problems. However, it's all dealt with in the YouTube video and I found it very useful to have the video open on one monitor, playing and pausing it, while working on another.

Link to comment

This might prove useful to those unable to get Big Sur downloaded and running: https://github.com/munki/macadmin-scripts/blob/main/installinstallmacos.py


This script can download the Big Sur install image:

Product ID    Version    Build    Date          Title
001-86606     11.1       20C69    2020-12-14    macOS Big Sur

 

That install file is 12.22 GB when completely downloaded, and you'll need to download a copy and then convert it (the script does this for you) so you'll need about 25GB of free space.

Link to comment
On 1/25/2021 at 7:33 AM, snolly said:

- Scripts only installed if Catalina is selected

- Big Sur with method 1 in download will always download Catalina

 

Exactly my experience, I got the VM working and started the OpenCore setup and realized I had installed Catalina and not Big Sur. I went back and checked all the settings and I had selected Big Sur all along. After deleting everything and starting over, I could never get Big Sur installed. I appreciate the effort put into this, of course, but something funky is going on making this installation harder to get working than a more manual process.

Edited by wcg66
Fixed a word
Link to comment
9 hours ago, ghost82 said:

So why you just not update from Catalina to Big Sur within mac os?

 

Has anyone had any success doing that? Several people have reported failure - I'm not aware of anyone reporting success in this thread. Even people attempting it on actual Apple hardware have reported problems.

  • Like 1
Link to comment

Hi, I just tried to install Macinabox. When I applied the template, I didn't realize that I did not have user scripts installed. So I tried to remove the docker and start again after installing the CA app for user scripts. The Macinabox docker would not stop so I tried to delete it. The progress wheel just spun for about half and hour. So I rebooted the Unraid server, which started a parity check. I reinstalled the Macinabox docker, and it just stays in started status. The WebUI loads with an error message. The logs imply that stuff is happening, but I'm not sure if the Big Sur image is downloading or not. Here are the last few lines of the log below.

 

Should I just let this continue? Its been about 90 minutes.

 

28/01/2021 22:33:24 - WebSockets client version hybi-13
28/01/2021 22:33:24 Disabled X server key autorepeat.
28/01/2021 22:33:24 to force back on run: 'xset r on' (3 times)
28/01/2021 22:33:24 incr accepted_client=6 for 127.0.0.1:47372 sock=10
28/01/2021 22:33:24 Client Protocol Version 3.8
28/01/2021 22:33:24 Protocol version sent 3.8, using 3.8
28/01/2021 22:33:24 rfbProcessClientSecurityType: executing handler for type 1
28/01/2021 22:33:24 rfbProcessClientSecurityType: returning securityResult for client rfb version >= 3.8
28/01/2021 22:33:25 Pixel format for client 127.0.0.1:
28/01/2021 22:33:25 32 bpp, depth 24, little endian
28/01/2021 22:33:25 true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0
28/01/2021 22:33:25 no translation needed
28/01/2021 22:33:25 Enabling NewFBSize protocol extension for client 127.0.0.1
28/01/2021 22:33:25 Enabling full-color cursor updates for client 127.0.0.1
28/01/2021 22:33:25 Using image quality level 6 for client 127.0.0.1
28/01/2021 22:33:25 Using JPEG subsampling 0, Q79 for client 127.0.0.1
28/01/2021 22:33:25 Using compression level 9 for client 127.0.0.1
28/01/2021 22:33:25 Enabling LastRect protocol extension for client 127.0.0.1
28/01/2021 22:33:25 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFECC)
28/01/2021 22:33:25 Using tight encoding for client 127.0.0.1
28/01/2021 22:33:25 client_set_net: 127.0.0.1 0.0000
28/01/2021 22:33:25 active keyboard: turning X autorepeat off.
28/01/2021 22:33:25 created xdamage object: 0x20002e
28/01/2021 22:34:39 copy_tiles: allocating first_line at size 41
28/01/2021 22:38:25 idle keyboard: turning X autorepeat back on.

Link to comment
10 hours ago, John_M said:

Has anyone had any success doing that? Several people have reported failure - I'm not aware of anyone reporting success in this thread. Even people attempting it on actual Apple hardware have reported problems.

 

Since it's a regular mac os vm, there should be no issue in updating from Catalina, as far as the correct quirks are set in the bootloader: that is how I updated to my Big Sur.

I confirm, Big Sur has several issues, not because it runs in a vm, it's the os itself that has still issues.

Link to comment
9 hours ago, ghost82 said:

There's really nothing to explain in details, I think I didn't explain well; once booted in catalina, system preferences, software update, and update to big sur.

 

Other people have reported that simply running the software update doesn't work and that is trashes their Catalina installation, making it not bootable.

 

On 1/29/2021 at 12:47 PM, ghost82 said:

there should be no issue in updating from Catalina, as far as the correct quirks are set in the bootloader

 

Perhaps this is what people need to do to make the update work. Maybe some guidance here would help.

 

Link to comment

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" Is this some XML or something I am missing because this really doesnt seem like it needs to be this difficult. I follow the video to the word, so I don't know what I am doing wrong.

 

Logs from VM:

-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \
-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \
-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/Catalina-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/Catalina-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 Catalina/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 vmxnet3,netdev=hostnet0,id=net0,mac=52:54:00:63:a7:c7,bus=pci.1,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:1,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=pcie.0,addr=0x1 \
-device virtio-balloon-pci,id=balloon0,bus=pci.3,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
2021-01-31 19:21:15.415+0000: Domain id=18 is tainted: high-privileges
2021-01-31 19:21:15.415+0000: Domain id=18 is tainted: custom-argv
2021-01-31 19:21:15.415+0000: Domain id=18 is tainted: host-cpu
char device redirected to /dev/pts/0 (label charserial0)
2021-01-31T19:37:15.229471Z qemu-system-x86_64: terminating on signal 15 from pid 15011 (/usr/sbin/libvirtd)
2021-01-31 19:37:15.429+0000: shutting down, reason=destroyed

 

Thanks in advance folks, I truly appreciate any advice.

Edited by cloudgeek
additional note
Link to comment

So, today I started once again from scratch.

 

I deleted macinabox related:
ISOs

Domains

Docker

AppData

Docket Template

Custom OVF

 

Then reinstalled macinabox with default settings (Catalina, download method 1).

 

This installed properly (as the previous time) and I reached the macOS Catalina desktop. I shut down the VM and took a copy of the vdisk. I then booted it up again and upgraded to big sur from system preferences. After a couple of restarts I ended up in the Big Sur desktop.

 

Note that I never completed the SpaceInvaderOne video guide (involving opencore connfigurator etc). I will do that tomorrow now that I am in Big Sur. So, maybe natively updating to Big Sur breaks the VM after all the boot modifications described in Space Invader Video Guide.

 

Link to comment
4 hours ago, John_M said:

Perhaps this is what people need to do to make the update work. Maybe some guidance here would help.

The fact is that the config.plist and the included kexts and drivers in macinabox are perfectly fine to run big sur or catalina, or to upgrade from catalina to big sur, so there's no need to change things, unless one is passing through "special" things, for example cpu, which may need additional patches. But the default libvirt/opencore should work with no issues.

Unfortunately, without logs it's very difficult to understand where the problem is, that's why I proposed to include in macinabox the debug version instead of the release.

No logs = little help

Edited by ghost82
Link to comment
48 minutes ago, ghost82 said:

No logs = little help

 

I wasn't asking on my behalf, but because so many people posting here seem frustrated and because you've had some success. I'm happy with my set-up. Thanks anyway.

 

2 hours ago, snolly said:

Note that I never completed the SpaceInvaderOne video guide (involving opencore connfigurator etc). I will do that tomorrow now that I am in Big Sur.

 

Perhaps this is the clue that will help those who are struggling.

Link to comment
On 1/30/2021 at 8:36 PM, snolly said:

Note that I never completed the SpaceInvaderOne video guide (involving opencore connfigurator etc).

 

On 1/30/2021 at 10:45 PM, John_M said:

Perhaps this is the clue that will help those who are struggling.

 

Ok, I watched sio's video and there could be an issue if one doesn't know what he/she is doing.

Once mac os is installed (catalina or big sur or others) sio copies the EFI folder from the opencore image to the mac os EFI partition.

Then he edits the xml by removing the opencore disk because he copied the efi into mac os.

So now the efi partition in mac os has opencore, but what happens when you update from catalina to big sur (as an example)?

The efi partition could be replaced with a new efi (mac os efi of the upgraded os) but you could not boot anymore (if run-efi-updater/BlacklistAppleUpdate are not set to No and true --> I cannot check what are the set value on the image). Because opencore may be gone.

You may need to add again an external opencore disk to boot from.

So, as I always said, I prefer to not copy the efi files into mac os efi partition, and let the 2 disks separated (mac os and opencore) so you wont have any issue when you upgrade the os.

--------

I just checked and run-efi-updater is set to No and BlacklistAppleUpdate is set to true, so there should be no issue in default opencore settings.

Edited by ghost82
  • Like 2
Link to comment

I am not sure if this may be true for others, but at first I thought I was having problems because I would run the container with big sur and not see the user scripts show up quickly.  As I checked the logs, the container was running and nothing was happening for about 30 minutes.  Once I checked after it finished running, I see the user scripts show up (which makes the vmready_notify useless now for me).

 

So I don't know if that could be the issue with some installs, but I would recommend patience for this one despite SI1's speedy video tutorial.

 

EDIT: Spoke to soon, tried to run install and it only shows Catalina and returns an error saying "The recovery server could not be contacted."  Will have to either wait for an update for this container or try again another time.

Edited by avinyc
spoke to soon
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.