[Support] SpaceinvaderOne - Macinabox


Recommended Posts

15 minutes ago, Meller said:

Hey, so first time using this... I followed your youtube video exactly on installing a Big Slur VM.  I'm at the part where I just launched the VM for the very first time, opened up VNC, and selected MacOS Base System.  It crashes immediately, and I basically just cycle through this one part over and over again.  It tells me my "computer" restarted because of a problem.  press a key or wait for startup to continue... then it crashes.

Any clues on what I can look at that might be the issue?

 

     I am having the same issue. I have tried multiple different MacOS versions as well as both download methods. I am just stuck in a boot loop after clicking the MacOS Base System. I think it is an issue with some Intel CPUs as people with Ryzen don't seem to be affected.

Link to comment
12 minutes ago, ghost82 said:

cpu is emulated as penryn with the default configuration, having an amd or intel is not the issue. Moreover intel can run natively with a ton of less patches compared to amd.

Good to know, then what do you believe the issue is? I am running Unraid 6.9.2 and followed the guide so there should be no issues with configuration. It has to be a hardware issue as some people don't have this issue and some do.

 

I also tried booting with the Penryn patch commented out but that did not help.

Link to comment
Just now, italy333333 said:

It has to be a hardware issue as some people don't have this issue and some do

I don't think so, nearly all the hardware is emulated and the template is the same, for all.

Unfortunately, without debug logs (that of the bootloader, not that of unraid) it's nearly impossible to help.

Writing as much information as possible and attaching the logs is important to debug issues, the "it doesn't work, there's a bootloop" is of no help.

Link to comment

Take also into account that macinabox hasn't been updated from a quite long time, in respect to mac os updates.

On the other hand mojave, catalina and big sur received security upgrades and minor version upgrades.

Maybe the bootloader needs to be updated too with a more recent version, or use the included one to run an older minor version of mac os, compared to what it downloads.

I know this may be frustrating since one expects to follow a tutorial and have things working..

I have an eavily customized big sur 11.4 vm, I upgrade opencore about once/twice a week and I never had any issue.

On macinabox github I included as a pull request about one month ago a more recent debug version of opencore, which has not been included in the standard macinabox, maybe you can try that.

Edited by ghost82
Link to comment
1 minute ago, ghost82 said:

Take also into account that macinabox hasn't been updated from a quite long time.

On the other hand mojave, catalina and big sur received security upgrades and minor version upgrades.

Maybe the bootloader needs to be updated too with a more recent version, or use the included one to run an older minor version of mac os, compared to what it downloads.

I know this may be frustrating since one expects to follow a tutorial and have things working..

I have an eavily customized big sur 11.4 vm, I upgrade opencore about once/twice a week and I never had any issue.

That is a good point, maybe leaning towards opencore might be better. I did create a new image from BigSur 11.4 and that also had the same issue, the one thing the VMs shared is the opencore version. I think I am going to troubleshoot that route.

 

The reason I am leaning towards hardware being an issue is that every person with Unraid 6.9.2 should be able to 100% replicate the boot loop, but it seems like some people do not have the issue. Maybe they are running an older version of the template or a different version of Unraid.....

Link to comment
1 hour ago, ghost82 said:

I don't think so, nearly all the hardware is emulated and the template is the same, for all.

Unfortunately, without debug logs (that of the bootloader, not that of unraid) it's nearly impossible to help.

Writing as much information as possible and attaching the logs is important to debug issues, the "it doesn't work, there's a bootloop" is of no help.

Ok, well how do I go about getting you these debug logs, because I've tried everything.  The only thing I'm not doing that I see others doing is a GPU passthrough.  My unraid server has no GPUs.  all of my windows VM's just emulate the GPU.  Sucks, but it is what it is.

Link to comment

just going to add on here, I'm also experiencing this same boot-loop as described by others.

 

I am running dual E5-2690v2's and it looks like they dont support RDRAND as mentioned in the troubleshooting guide https://dortania.github.io/OpenCore-Install-Guide/troubleshooting/extended/opencore-issues.html#stuck-on-a-black-screen-before-picker could this be of any concern? also happy to provide any logs I can. I've tried twice completely from scratch with no luck.

 

Edit: It seems limited to Big Sur and Catalina? I tried Mojave and was able to get past the loop - so yeah, possibly something with OpenCore and the latest MacOS updates?

Edited by aberrix
Link to comment

Got it to work! Thanks to Ghost82 and glennv. Here are the steps I used, I will try to keep it simple so everyone can try it out.

 

-Install macinabox just as normal (default settings)-- Test to make sure it bootloops for you

-Shutdown the macinabox VM

-Connect to Unraid terminal

-Mount the opencore image file

      modprobe nbd max_part=8
      qemu-nbd --connect=/dev/nbd0 /mnt/user/isos/BigSur-opencore.img

      mkdir /mnt/user/isos/temp/
      mount /dev/nbd0p1 /mnt/user/isos/temp/

-Edit the config.plist

      nano /mnt/user/isos/temp/EFI/OC/config.plist

-Paste the patch after the PENRYN entry - glennv has a post on page 80  that explains it

-Save you file

-Dismount the image file

      umount /mnt/user/isos/temp/
      rm -r /mnt/user/isos/temp/

      qemu-nbd --disconnect /dev/nbd0
      rmmod nbd

-Rerun the user script - make sure you change the name in the settings of the script to match your VM name 

      (I also set REMOVETOPOLOGY="yes" , not sure if that is needed)

-Test it out!

Macinabox PENRYN Patch 11_3.txt

  • Like 1
  • Thanks 3
Link to comment
12 hours ago, aberrix said:

I am running dual E5-2690v2's and it looks like they dont support RDRAND as mentioned in the troubleshooting guide https://dortania.github.io/OpenCore-Install-Guide/troubleshooting/extended/opencore-issues.html#stuck-on-a-black-screen-before-picker could this be of any concern?

No, your cpus are perfectly fine, mac os is able to run with older cpus (back to pentium!); about xeon I'm running it on 2x e5-2687w (v1).

 

9 hours ago, italy333333 said:

-Paste the patch after the PENRYN entry - glennv has a post on page 80  that explains it

 

9 hours ago, italy333333 said:

(I also set REMOVETOPOLOGY="yes" , not sure if that is needed)

 

First of all glad that you got it working.

About the penryn patch, as I told to glennv, there's something strange: in the xml, in a standard macinabox installation (so no change in cpu, ram, passthrough, etc.), the cpu mode is defined in 2 places:

  <cpu mode='host-passthrough' check='none'>
    <topology sockets='1' cores='2' threads='1'/>
  </cpu>

 

Here is defined as host-passthrough, so the vm will see the same cpu type that you have in the host (unraidi), not emulated.

    <qemu:arg value='-cpu'/>
    <qemu:arg value='Penryn,kvm=on,vendor=GenuineIntel,+invtsc,vmware-cpuid-freq=on,+pcid,+ssse3,+sse4.2,+popcnt,+avx,+aes,+xsave,+xsaveopt,check'/>

and here you define with custom qemu arg the cpu emulated as penryn.

As I wrote, the qemu arg should override the first definition of host-passthrough.

If you have the custom arg at the bottom of the xml, with cpu=Penryn, once booted in mac os, in "About this mac" you should read something like "intel core 2 duo", which is the penryn cpu. If you read something different there's something that doesn't work as expected; do you have that custom arg? If so, what do you read in "about this mac"?

If mac os doesn't see the penryn cpu, then additional patches are required, in your case for intel cpu, the so-called "DhinakG - cpuid_set_cpufamily - force CPUFAMILY_INTEL_PENRYN" (for big sur >= 11.3 beta 1), or "algrey - cpuid_set_cpufamily - force CPUFAMILY_INTEL_PENRYN" (for os < big sur 11.3 beta 1).

Opencore included in macinabox has the penryn patch, but it's not valid from big sur 11.3 beta 1.

 

About topology definition, if you have a kernel panic/bootloop, you need the MCEReporterDisabler.kext, which is included in opencore downloaded with macinabox.

 

The pull request to macinabox I was mentioning includes both the new penryn patch and the MCEReporterDisabler.kext.

Here is the link to the zipped opencore image in the pull request: unzip it and replace:

https://github.com/SpaceinvaderOne/Macinabox/raw/c1d7ecbf4eb01029d98fdda29166391ba5077dc3/bootloader/OpenCore.img.zip

 

Note: bootloops can be caused also by passing odd cores number.

Boot with the standard number of cores (1 socket, 2 cores, 1 thread) to avoid further issues, then experiment with changing sockets/cores/threads

Edited by ghost82
Link to comment

See the differences:

 

Emulated Penryn cpu

xml

xmlpenryn1.png.309d3829fd709bf42d75c07704a8de65.png

 

xmlpenryn2.png.e289f0b2a227710c0798540225c572ee.png

 

xmlpenryn3.png.3ad68d30a27fb5aec304a46aed1957b0.png

 

xmlpenryn4.thumb.png.4d0ba9ecf4831db5682dedb728b604e1.png

 

This results in:

Penryn-2.png.db8128fc959b7db96086e847290d41b2.png

 

penryn-3.png.7bd3da8960d57f66b09dedcc18900814.png

 

Note "Intel Core 2 Duo"

 

cpu host passthrough

host-passthrough-5.png.1e76be7d4ca084684656629e61f4f5da.png

 

host-passthrough-6.png.a170092ad085e7dde79e74405d358242.png

 

host-passthrough-1.png.63554875450acffa4b3ec81e040d0eeb.png

 

host-passthrough-2.thumb.png.a0286e2885d1709a3d1391eb7d533333.png

 

This results in:

host-passthrough-3.png.2fca2da3562c8ea82dea2cf2f256636d.png

 

host-passthrough-4.png.89e999076176089cc182ef333d9fb3fc.png

 

Note "Intel Xeon E5 8 core"

 

N.B.: when I use the host-passthrough I define topology with -smp custom qemu args instead of libvirt, it's the same, it doesn't change anything.

 

So, if you don't read "Intel Core 2 Duo" your configuration is wrong.

Edited by ghost82
Link to comment

So I nuked everything and started fresh, here are my findings and default settings. I run a Intel G4560 CPU

<cpu mode='host-passthrough' check='none' migratable='on'>
    <topology sockets='1' dies='1' cores='1' threads='2'/>
    <cache mode='passthrough'/>
</cpu>

<qemu:commandline>
    <qemu:arg value='-usb'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='usb-kbd,bus=usb-bus.0'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='************************'/>
    <qemu:arg value='-smbios'/>
    <qemu:arg value='type=2'/>
    <qemu:arg value='-cpu'/>
    <qemu:arg value='Penryn,kvm=on,vendor=GenuineIntel,+invtsc,vmware-cpuid-freq=on,+pcid,+ssse3,+sse4.2,+popcnt,+avx,+aes,+xsave,+xsaveopt,check'/>
</qemu:commandline>

Ran macinabox from apps with all default settings except Big Sur as the image

Ran 1_macinabox_helper script after the download finished

Started the VM

Clicked enter on the MacOS Base System disk

The VM bootloops

 

I then tried the file you posted and the VM bootlooped as well

 

I then changed the config.plist file and added the PENRYN patch and the VM booted fine.

image.png.6b3ff9b0f84bba725f42046e2d4f8962.png

Link to comment

ghost82 - thanks for all your help with this, I am learning a lot.

 

So it looks like the CPU emulation is working but MacOS sees it as a Core 2 solo and the patch is needed in my situation, is that correct? Is there any harm or reason not to include that patch in the config.plist for everyone?

Link to comment
3 hours ago, italy333333 said:

 

I then tried the file you posted and the VM bootlooped as well

something here sounds strange, because the image I linked is the same macinabox image, with updated opencore version, same settings, with added new patch for penryn.

So if you were able to boot by adding the penryn patch on "your" image, you should boot also with "my" image.

3 hours ago, italy333333 said:

So it looks like the CPU emulation is working but MacOS sees it as a Core 2 solo and the patch is needed in my situation,

Here I'm not sure, because if the cpu is seen as penryn, the patch shouldn't be needed.

Tomorrow I will have some spare time, I will test and report back, I'm just ready for some kernel panics :D

3 hours ago, italy333333 said:

Is there any harm or reason not to include that patch in the config.plist for everyone?

No reason as far as I know.

Link to comment

I don't know if this has been covered in the 83 pages but I had an issue running the helper script the first time. I didn't see the appdata, Macinabox only data, and Basesystem settings in the docker because you have to expand it to see them and my appdata folder is different from the default. Once I figured this out I figured it would be better to start over than to change the helper script. I deleted the scripts, the vm, the docker, and the appdata folder. When I reinstall the docker, the script still has the default appdata folder. I'm waiting for the image to download from the Apple servers but I anticipate this being a problem. Shouldn't the script show a different folder if I changed my docker template? Did I overlook something when starting over?

Link to comment

Yes, yes, yes !!!!!

Many thanks for all this hard struggle !

I apply @italy333333 step by step mod.

1st time still et the bootloop but redo the step by step (expect the plist file patch because it was good) then install start as per @SpaceInvaderOne video 😃

 

Installation still in progress, but I was in a hurry to share that !

 

Update: installation finished. All went fine as per the video.

Edited by urbatecte
Update
Link to comment

If you have a modern CPU there is no reason why you have to emulate Penryn. I believe Macinabox has it set that way for maximum compatibility. I'm running an AMD 3950 so I emulate a Skylake processor. If I didn't use emulation then I would need to apply a bunch of patches to OS X to support AMD.

<qemu:arg value='Skylake-Client,kvm=on,vendor=GenuineIntel,+invtsc,+hypervisor,vmware-cpuid-freq=on,+pcid,+popcnt,check'/>

This results in the OS reporting my CPU as - 3.5 GHz Intel Core i3

From sysctl -a

machdep.cpu.brand_string: Intel Core Processor (Skylake)
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH MMX FXSR SSE SSE2 SSE3 PCLMULQDQ SSSE3 FMA CX16 SSE4.1 SSE4.2 x2APIC MOVBE POPCNT AES VMM XSAVE OSXSAVE TSCTMR AVX1.0 RDRAND F16C
machdep.cpu.leaf7_features: RDWRFSGS BMI1 AVX2 SMEP BMI2 RDSEED ADX SMAP

Obviously no AVX512 support being AMD Zen3 underneath.

 

Still I got about a 15% speed improvement by shifting from Penryn to Skylake emulation. I'm not sure exactly where that came but I expect there are features that are available in Skylake that are otherwise missing.

Link to comment

Here the results of my tests, they were very fast, all results are expected.

Note that these were done on an already installed Big Sur 11.4 (20F71) disc.

Passed through cpu(s) are intel xeon E5-2687w (3,1 GHz).

 

Emulated Penryn cpu

DhinakG Penryn patch: NO

CPU: Penryn 1 socket, 2 cores, 1 thread

System booted? YES

CPU detected as: 3,1 GHz Intel Core 2 Duo

 

DhinakG Penryn patch: NO

CPU: Penryn 1 socket, 1 core, 1 thread

System booted? YES

CPU detected as: 3,1 GHz Intel Core 2 Solo

 

DhinakG Penryn patch: NO

CPU: Penryn 1 socket, 1 core, 2 threads

System booted? YES

CPU detected as: 3,1 GHz Intel Core 2 Solo

 

DhinakG Penryn patch: NO

CPU: Penryn, 2 sockets, 8 cores, 1 thread

System booted? YES

CPU detected as: 2 x 3,1 GHz Unknown

 

Passed through cpu

DhinakG Penryn patch: NO

CPU: Passthrough, 2 sockets, 8 cores, 1 thread

System booted? NO, stuck at bootloader

CPU detected as: Unavailable, system stuck (cpu detected by opencore, and so mac os as 2 x 3,1 GHz Intel Xeon E5 8 core)

 

So from my tests with an emulated cpu as Penryn we don't need the Penryn patch (as expected)

 

8 hours ago, cat2devnull said:

If you have a modern CPU there is no reason why you have to emulate Penryn. I believe Macinabox has it set that way for maximum compatibility

Correct, but as you stated this is for maximum compatibility: the vm will not be fast, but it needs less headache to boot. Of course, once booted, it is preferred to emulate a more modern cpu or pass it through.

If you emulate a Skylake cpu you still need the penryn patch to boot.

Usually emulating more modern cpu is done on "problematic" cpus, such as amd (so you don't need the ton of patches to boot), to have more cpu features compared to penryn.

Edited by ghost82
Link to comment
On 12/9/2020 at 6:13 PM, tryhardcodemaster said:

If you are getting the nc: command not found: I/O error, you need to install netcat-openbsd-1.105 from Nerd Pack. Do not install nc-1.10 as it doesn't support the "-U" flag and won't work with virt-manager.

THANK YOU! I was doing a lot of head scratching wondering why my attempt to use VirtManager were failing. This did the trick!

Link to comment

Hello,

 

I haven't updated the Macinabox Docker for ages (way before the "How to Install Big Sur and Other macOS Versions with New Macinabox" video came out). I am also running a Catalina VM I created a long time ago.

I tried finding instructions on how to upgrade my existing VM, but with >2070 posts in this topic, I was unsuccessful 😞

Are there some instructions around somewhere?

 

Thank you and kind regards,

SnakeZZ

Link to comment

Question: In the tutorial on how to use macinabox a vbios file for a Sapphire Pulse 580 was shown. I happen to have the exact same video card, but tried several vbios files I could find online and I could not get any of them to run with the GPU passthrough following the same steps (got it working fine in VNC).  Does anyone happen to know where that file came from?  Thanks in advance for you help.

 

Link to comment
1 hour ago, WorldTraveller said:

Question: In the tutorial on how to use macinabox a vbios file for a Sapphire Pulse 580 was shown. I happen to have the exact same video card, but tried several vbios files I could find online and I could not get any of them to run with the GPU passthrough following the same steps (got it working fine in VNC).  Does anyone happen to know where that file came from?  Thanks in advance for you help.

The goto place for vbios files is https://www.techpowerup.com/vgabios/ but most people recommend that you rip your own bios. Spaceinvader has written some software and made a video that is easy to follow.

https://www.youtube.com/watch?v=FWn6OCWl63o

 

I had run my system for over a year without needing to pass a bios to on my Mac VM with an RX550. Then I decided to upgrade from 6.9.0 RC to 6.9.2 and the Mac VM refused to boot with a bunch of difficult to debug hardware errors related to being unable to communicate with the video card. I tried debugging the issue for days and even downgraded back to 6.9.0 without any luck. So as a last resort I pulled the bios using Spaceinvader's instructions, passed it to the VM and bingo, everything working again. Go figure...

Link to comment
18 hours ago, cat2devnull said:

The goto place for vbios files is https://www.techpowerup.com/vgabios/ but most people recommend that you rip your own bios. Spaceinvader has written some software and made a video that is easy to follow.

https://www.youtube.com/watch?v=FWn6OCWl63o

 

I had run my system for over a year without needing to pass a bios to on my Mac VM with an RX550. Then I decided to upgrade from 6.9.0 RC to 6.9.2 and the Mac VM refused to boot with a bunch of difficult to debug hardware errors related to being unable to communicate with the video card. I tried debugging the issue for days and even downgraded back to 6.9.0 without any luck. So as a last resort I pulled the bios using Spaceinvader's instructions, passed it to the VM and bingo, everything working again. Go figure...

 

Thanks! Actually I tried the tech power up but was not working for me.  But tried the bios rip trick you suggested and that worked and produced a vbios that I could successfully passthrough to the macinabox!  I had to put in another GPU in the primary slot because the putting to server to sleep would not work (every time i pressed the power button to restart it, nothing would happen...finally kept pressing longer and longer, nothing, until the server compeltely restarted and tried that several times..)

Link to comment

So, since I had some spare time, I tried to understand why for some users the macinabox container works and for someone else it doesn't work.

Premise: I don't use the container, I prefer to do things manually.

Premise2: I'm talking about new installations

Premise3: I'm not considering user errors, such as not working/modified xml (this means also different cpu cores and ram)

Premise4: I'm considering BigSur

 

I looked at the macinabox code hosted on github and I'm not sure if I found the root of the issue..

 

I didn't install macinabox, but just followed the code and replicated on my linux machine.

 

Everyone is using the same xml template.

There is no passthrough (cpu included, it's emulated).

Physical hardware doesn't matter, all it's emulated!

 

At first we thought about the "force penryn" patch: from my tests an original macinabox installation doesn't require at all any "force penryn" patch (macinabox still emulates penryn!)

Opencore: I'm using it from 2-3 years now, I checked the included image in macinabox, apart being a prior version it has nothing wrong in it.

I provided in github an updated image, with both "force penryn" patches, still some users have issue. Did they do something wrong in configuration? I'm supposing not.

 

So, what's next?

The installation media.

 

There are 2 methods to download big sur: method1 and method2.

The first method (method 2) calls fetch-macos.py, the second method (method 1) calls fetch-macos2.py.

 

fetch-macos.py downloads directly BaseSystem.dmg, fetch-macos2.py downloads more data, including InstallAssistant.pkg.

It extracts SharedSupport.dmg from InstallAssistant.pkg, from SharedSupport.dmg it extracts a zip file (0ff07e22b367f4fe0f6d2047ad5c917202716c8b.zip for Big Sur 11.4), and finally it extracts BaseSystem.dmg from this archive.

For this method I had to modify the command since the product-id in the macinabox code doesn't exist anymore:

from:

fetch.sh -v 10.16 -c PublicRelease -p 071-05432

To:

fetch.sh -v 10.16 -c PublicRelease -p 071-00696

 

071-00696 is the current (at the time of writing) product id for big sur 11.4.

 

So at the end, both methods end with the BaseSystem.dmg

 

This is the recovery image, so once mounted by opencore, one should open disk utilities, format the hard drive and proceed with the online installation.

 

I downloaded both BaseSystem.dmg following the code and....look at this picture:

base.png.ac9b9e7f9da590089b202d8a9e7f0b2b.png

 

The top one is the mounted BaseSystem.dmg downloaded with fetch-macos2.py, the bottom one is BaseSystem.dmg downloaded with fetch-macos.py

 

They are not the same!

The one downloaded with fetch-macos.py seems "more complete" (??)

 

Maybe this is the root of the issues (?)

 

I would choose fetch-macos.py, or in other words method 2, to have the "complete" BaseSystem.dmg (or may be the other method? Check and report :D )

 

Would be interesting to have feedbacks from users who have issues, if they used method 1 or method 2.

 

NOTE:

# Method 1 or 2
if [ "$method" = "method 1" ] ; then		
# method 1 uses script2
python3 fetch-macos2.py 
# method 2 uses script 1 
elif [ "$method" = "method 2" ] ; then
python3 fetch-macos.py "$@"
fi

this is in macinabox:

Method 1 = fetch-macos2.py

Method 2 = fetch-macos.py

 

Note 2: I never installed mac os from the BaseSystem, I always created an installation media from the complete package (including InstallAssistant.pkg), so I'm not sure if and what is the correct method to have a good BaseSystem.dmg image.

Edited by ghost82
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.