** Hackintosh ** Tips to make a bare metal MacOS

[ghost82]

5 hours ago, doesntaffect said:

 

I don't get why I could get into the OS installer and 3hrs later I cannot

If the panic is really random, it could be related to cpu sync; some cases were reported on acidanthera bugtracker with monterey and amd, but they were closed since opencore doesn't officially support amd cpus.

I don't get why you want to passthrough the cpu without spoofing it to an intel one: we use vms for this reason too, and you get no performance increase with this.

[doesntaffect]

the answer is simple - because I don't know better.  I am reading through the dortania guide and get stuck again, translating this to virtualization. I understand that this guide is for bare metal installations. So my interpretation is that I somehow need to fake/spoof hardware for OSX - And there I am simply lost. 

[RiDDiX]

1 hour ago, ghost82 said:

If the panic is really random, it could be related to cpu sync; some cases were reported on acidanthera bugtracker with monterey and amd, but they were closed since opencore doesn't officially support amd cpus.

I don't get why you want to passthrough the cpu without spoofing it to an intel one: we use vms for this reason too, and you get no performance increase with this.

 

This doenst matter if he set up the vms xml correctly. Then the cpu get spoofed as a Intel one.

I never tried to just rename a dmg into img. What I could try to assist you further will be with a Monterey ISO and a OpenCore.img.

Maybe this is the problem.

[doesntaffect]

I made the effort to check if my GPU is the issue. 

Removed all OSX VMs and Macinabox completely incl. templates, appdata and reinstalled it.

 

Created a Macinabox BigSur VM and attached my GPU to it. Had boot problems again but then found out that the GPU wants to sit on BUS 0x03, else it will not work.

 

The other days I allways moved the GPU to 0x04 or 0x05. So for whatever reason I changed the Bus for the NIC and could keep the GPU on 0x03. So I fixed that and changed the NIC to Vmxnet.

 

Booted into Recovery Mode to install BigSur, formatted the Vdisk (M2 SSD to test later), started installation and now Monterey is being installed - from a BigSur'inabox Recovery?!? Even if this gets to the end, I assume I need to apply the Kepler Patch to get the GT710 working. 

 

 

So I am not sure since all the try and error during last days wasn't easy, but that Bus 0x03 (and Vmxnet on 0x06) allowed it to boot immediately and repeatedly. 

 

Installation finished, rebooted a few times and then after a final long scroll of text went back to boot menu, and that's it. OSX does not start, I assume because it would require further patching?

 

 

 

Edited November 1, 2021 by doesntaffect

[ghost82]

8 hours ago, doesntaffect said:

started installation and now Monterey is being installed - from a BigSur'inabox Recovery?!?

That's because of apple updates.

https://github.com/SpaceinvaderOne/Macinabox/pull/54

 

and also these will be relevant:

https://github.com/SpaceinvaderOne/Macinabox/pull/55

https://github.com/SpaceinvaderOne/Macinabox/pull/53

 

For macinabox either apply the prs manually or wait for the prs to be merged and download again macinabox.

[RiDDiX]

Hm.... I would say this seems just to be annoying.

The Kepler Patch is requiered if you want the correct resolution for your monitor. What I dont get is, when you installed it with macinabox why it is already monterey But Lucky you. When the iso is already there you could now try to edit the also existing OpenCore.img to update this to OpenCore 0.7.5 with my mentioned kexts and config.plist.

 

Maybe we when could get closer together. Write me a PM with Discord or any other instant-messenger. 🙂 I will help you as much as I can.

Edited November 2, 2021 by RiDDiX

[doesntaffect]

2 hours ago, ghost82 said:

That's because of apple updates.

https://github.com/SpaceinvaderOne/Macinabox/pull/54

 

and also these will be relevant:

https://github.com/SpaceinvaderOne/Macinabox/pull/55

https://github.com/SpaceinvaderOne/Macinabox/pull/53

 

For macinabox either apply the prs manually or wait for the prs to be merged and download again macinabox.

 

Do you have any insights if @SpaceInvaderOne plans to update this for Monterey?

[ghost82]

3 minutes ago, doesntaffect said:

Do you have any insights if @SpaceInvaderOne plans to update this for Monterey?

No, sorry, we are not in contact.

[doesntaffect]

I am getting there, slowly. 

 

Using a BigSur Recovery Image which I build, based on Opencore 075. GPU and M.2 Passthrough seem to work well.

 

However, seems like I cannot get the Installation language to switch to ENG or German, even though I changed the String (Which is the right one I think). 

 

 

I am using Opencore configurator atm.

Any advise? My Russian is a bit rusty, ENG/GER would be nice.

 

[ghost82]

9 minutes ago, doesntaffect said:

However, seems like I cannot get the Installation language to switch to ENG or German

Check in config.plist prev-lang:kbd nvram argument.

Opencore developers set it by default to ru-RU:252.

For en-US:0 set it to <data>ZW4tVVM6MA==</data>

or use a text to base64 converter to input your value.

 

Uh sorry, I saw that you changed it..try only de-DE

Edited November 2, 2021 by ghost82

[doesntaffect]

Thought I did that, changed value to German.

 

Will check with Propertree in the morning.

[ghost82]

7 minutes ago, doesntaffect said:

Thought I did that, changed value to German.

 

Will check with Propertree in the morning.

yes sorry I saw now..try with de:0 only as "string", or ZGUtREU6MA== as "data".

Reset nvram if it still doesn't work.

Edited November 2, 2021 by ghost82

[doesntaffect]

How do I do that? Within OC or within the Boatmenu? With other VMs I have seen a boot menu entry to reset the NVRAM but this one does not show this option, even though I set the flag in OC (the right one?)

 

 

OC also throws this error when I start it and load the config I am using. Is this connected to the issue above? I am using OC 2.52.0.1

 

Edited November 3, 2021 by doesntaffect

[ghost82]

20 minutes ago, doesntaffect said:

Within OC or within the Boatmenu?

Within the boot menu: either change in your config.plist showpicker from false to true, or press '0' and let it pressed once you start the vm and the boot menu should appear.

However, are you able to see the boot menu but there's no entry for nvram reset? if so share the efi, because from that 2 errors it seems you are not opening the right config.plist..

About the error I don't know, if you can share the efi folder or image in private I can try to replicate it.

Edited November 3, 2021 by ghost82

[MountainMining]

On 11/2/2021 at 3:57 AM, ghost82 said:

No, sorry, we are not in contact.

@ghost82 I'm a noob trying to learn by following along this thread and the macinabox thread.  Since you seem to know what you are doing and spaceinvaderone might be busy, is it possible for you to fork the macinabox project and merge your contributions that seem to fix a number of issues I'm having trying to get this to work?

[ghost82]

2 hours ago, MountainMining said:

is it possible for you to fork the macinabox project and merge your contributions that seem to fix a number of issues I'm having trying to get this to work?

Hi, though this may be possible, I can't because of lack of knowledge with dockers in general.

As far as I know, github hosts only the source code of the docker, then it is connected in some way with unraid community application which download a docker image.

So, I think a docker image must be built and stored somewhere.

I tried several months ago to build the whole machinabox container without any luck, I even asked here in the forum how to build it, without any useful reply, so for testing purposes I ended downloading the original container and manually apply the prs.

 

So, without knowing how to build it, and without knowing how dockers work in general for unraid, it's a no go for me.

Edited November 4, 2021 by ghost82

[MountainMining]

On 10/25/2021 at 5:54 AM, ghost82 said:

I understand it can be difficult to manually edit the config.plist to update smbios data.

As I wrote I pushed a pr to the container.

Since it's not merged yet, you can "manually" apply the changes by following these advices:

0. clean the container, delete all files

1. Setup Macinabox in Apps (uncheck Autostart)

2. 

wget https://github.com/SpaceinvaderOne/Macinabox/raw/2a2400c44af497a00f2610523cb0c0844d2aae27/bootloader/OpenCore.img.zip

3. 

docker cp ./OpenCore.img.zip macinabox:/Macinabox/bootloader/OpenCore.img.zip

4. Start Docker Container and proceed as normal

 

Then, you can use opencore configurator, latest version at the time of writing, or better to use v. 2.51.0.0:

https://mackie100projects.altervista.org/download/opencore-configurator-2-51-0-0/

 

since the latest version 2.52.0.0 supports opencore development version (not stable) which added a couple of new options in the config.plist.

 

Is you post from a couple of weeks ago saying that we can manually install your contributions without waiting for Spaceinvaderone to merge them into macinabox?

 

If yes, I followed your steps and still had problems like Monterey downloading instead of Big Sur and the system continually rebooting before I'm able to configure install the Mac operating system.

 

My Unraid is running on an old Dell T7610 with an Intel Xeon E5-2520 v2 (Ivy Bridge EP) CPU.  I think my hardware is more similar to a MacPro6,1 than the iMac Macinabox seems to create. Would my hardware cause these problems or am I doing something else wrong?

[ghost82]

2 hours ago, MountainMining said:

or am I doing something else wrong?

You are not applying correctly the prs; I'm sorry but I can be of little help here, check for closed prs on github and you will find instructions about how to manually apply prs to the docker.

2 hours ago, MountainMining said:

I think my hardware is more similar to a MacPro6,1 than the iMac Macinabox seems to create

The platform is emulated with qemu/libvirt, imacpro1,1 is the best smbios you can have in qemu/libvirt. This is not creating issues, not applying the prs is.

2 hours ago, MountainMining said:

still had problems like Monterey downloading instead of Big Sur

If you chose the method to download the recovery this doesn't happen with this pr:

https://github.com/SpaceinvaderOne/Macinabox/pull/54

Edited November 4, 2021 by ghost82

[ghost82]

RDRAND should be included in the kernel of next 12.1 monterey (it's included in 12.1 beta 1): this means ivy bridge+.

Just to alert you if you don't have RDRAND support and you notice errors (users are reporting to be able to install monterey 12.1 beta, but not being able to boot once installed).

 

Some issues could also happen in Big Sur 11.3+ on cpu not supporting RDRAND.

Patches are called "SurPlus", credits go to user Syncretic (macrumors):

https://github.com/reenigneorcim/SurPlus

Following kernel patches are advised for Sandy Bridge and older, and more in general to all that cpus that don't support RDRAND, and Big Sur 11.3+.

			<dict>
				<key>Arch</key>
				<string>x86_64</string>
				<key>Base</key>
				<string>_early_random</string>
				<key>Comment</key>
				<string>SurPlus v1 - PART 1 of 2 - Patch read_erandom (inlined in _early_random)</string>
				<key>Count</key>
				<integer>1</integer>
				<key>Enabled</key>
				<true/>
				<key>Find</key>
				<data>
				AHQjSIs=
				</data>
				<key>Identifier</key>
				<string>kernel</string>
				<key>Limit</key>
				<integer>800</integer>
				<key>Mask</key>
				<data>
				</data>
				<key>MaxKernel</key>
				<string>21.2.0</string>
				<key>MinKernel</key>
				<string>20.4.0</string>
				<key>Replace</key>
				<data>
				AOsjSIs=
				</data>
				<key>ReplaceMask</key>
				<data>
				</data>
				<key>Skip</key>
				<integer>0</integer>
			</dict>
			<dict>
				<key>Arch</key>
				<string>x86_64</string>
				<key>Base</key>
				<string>_register_and_init_prng</string>
				<key>Comment</key>
				<string>SurPlus v1 - PART 2 of 2 - Patch register_and_init_prng</string>
				<key>Count</key>
				<integer>1</integer>
				<key>Enabled</key>
				<true/>
				<key>Find</key>
				<data>
				ukgBAAAx9g==
				</data>
				<key>Identifier</key>
				<string>kernel</string>
				<key>Limit</key>
				<integer>256</integer>
				<key>Mask</key>
				<data>
				</data>
				<key>MaxKernel</key>
				<string>21.2.0</string>
				<key>MinKernel</key>
				<string>20.4.0</string>
				<key>Replace</key>
				<data>
				ukgBAADrBQ==
				</data>
				<key>ReplaceMask</key>
				<data>
				</data>
				<key>Skip</key>
				<integer>0</integer>
			</dict>

 

"MonteRand" patches will be required starting from monterey 12.1 for cpu lacking RDRAND.

Will update this post once 12.1 will come out.

Edited November 5, 2021 by ghost82

[ghost82]

On 11/4/2021 at 2:23 PM, MountainMining said:

Is you post from a couple of weeks ago saying that we can manually install your contributions without waiting for Spaceinvaderone to merge them into macinabox?

You can try this, written for another user via pm:

 

you should apply these:

https://github.com/SpaceinvaderOne/Macinabox/pull/54

https://github.com/SpaceinvaderOne/Macinabox/pull/55

https://github.com/SpaceinvaderOne/Macinabox/pull/61

 

I cannot guarantee that what I'm proposing herein below will work, I'm not a docker expert, but you can try:

1. Start fresh by deleting macinabox related files in /appdata/, /domains/, /isos/, and /system/

2. Setup Macinabox in Apps (ok to autostart).

3. Once started, wait for user scripts to install and then stop Macinabox docker.

4. Open unraid terminal and download these 3 files:

wget https://raw.githubusercontent.com/SpaceinvaderOne/Macinabox/cdbd730f52d5bcd1d269533dbf5417b328fa763f/tools/FetchMacOS/fetch-macos2.py

wget https://raw.githubusercontent.com/SpaceinvaderOne/Macinabox/18a2811f7236a0f88ac26704fef75b79ae302987/unraid.sh

wget https://github.com/SpaceinvaderOne/Macinabox/raw/84a82e54ae5f596f492ead2f2d98767029e2826a/bootloader/OpenCore.img.zip

5. In the same terminal give these commands to copy the downloaded files inside the container:

docker cp unraid.sh macinabox:/Macinabox/unraid.sh

docker cp OpenCore.img.zip macinabox:/Macinabox/bootloader/OpenCore.img.zip

docker cp fetch-macos2.py macinabox:/Macinabox/tools/FetchMacOS/fetch-macos2.py

6. Start the macinabox docker

7. Go back to terminal and give these commands:

docker exec -it macinabox bash

cd /Macinabox

chmod +x unraid.sh

cd tools/FetchMacOS

chmod +x fetch-macos2.py

8. Note: Remember to delete old version of Catalina-opencore.img (or whatever it was downlaoded) in /isos/ (or wherever you put your img file) then run in the terminal:

cd /Macinabox

./unraid.sh

and you should see confirmation that opencore was created.

 

9. Go back to user scripts and run the vmready_notify and verify that the VM was created and catalina-install.img (or whatever you downloaded) downloaded.

10. Edit the helper script with details for NAME="Macinabox Catalina" (or whatever your VM name is) and verify that FIRSTINSTALL="yes" and REMOVETOPOLOGY="yes" and save and run it.

Edited January 5, 2022 by ghost82

[ghost82]

On 11/5/2021 at 12:46 PM, ghost82 said:

"MonteRand" patches will be required starting from monterey 12.1 for cpu lacking RDRAND.

Patches are not required in 12.1 beta 2, apple is playing with this, not clear if this was a test and it will be included in future releases: at the time of writing MonteRand patches are not required to boot Monterey 12.1 beta 2 (but required for 12.1 beta 1).

 

----------------------------------------------------------------------------------------------

If you look at the AMD Vanilla patches:

https://github.com/AMD-OSX/AMD_Vanilla

 

which includes (in the file patches.plist) some of the patches we need for our custom builds (i.e. force penryn cpu family), you will notice big changes during the past few months: they are no more splitted in 15h,16h,17h,19h, they are universal, and moreover the number of needed patches decreased a lot.

Since now I was using the disable x86_validate_topology and the Force CPUFAMILY_INTEL_PENRYN patches.

 

Well..., while the Force CPUFAMILY_INTEL_PENRYN patch is still needed, x86_validate_topology can be removed: in its place, ProvideCurrentCpuInfo must be changed from false to true in opencore configuration.

This quirk is able to disable the cpu topology validation, so no more kernel panic without the disable x86_validate_topology patch.

 

OpenCore 0.7.1 or newer required.

Edited November 14, 2021 by ghost82

[cat2devnull]

Ok, so I'm running out of ideas so hoping the community can help. I've been running a Mac VM for years on my AMD system. Originally on Clover native, then switched to OpenCore in Unraid. It's been relatively smooth sailing excluding the odd AMD GPU bug etc. OpenCore and OS X upgrades have been straight forward.

 

A few days ago I wanted to go to OC 0.7.5 and trial Monterey, (currently on 0.7.1 with BigSur). I decided to build a fresh VM to test with before migrating my production desktop.
I downloaded the Monterey installer, made a 16GB GPD HFS+ .dmg, used createinstallmedia to make the install media. Followed the OC install guide to make my EFI folder and put that into the .dmg. Renamed it to a .img and fired it up.
OC boots but no option for install media, just reset NVRAM and OpenShell.efi

I've tried setting ScanPolicy to 0, changing SecureBootModel from Default to Disabled and a myriad of other bits and pieces but nothing makes a difference.
I can only assume I am missing something silly...
I am only running the basic latest drivers (OpenCanopy.efi, OpenHfsPlus.efi, OpenRuntime.efi) and kexts (AppleALC, IntelMausi, Lilu, VirtualSMC, WhateverGreen). A pretty simple setup.

 

I've attached the OC logs, which seem to show it finding 2 valid filesystems. This boot I pulled the EFI partition into a separate .img file so I could mount/unmount easily. I think it should have found 3 filesystems.

1) EFI-075.img - EFI partition
2) Monterey.img - EFI partition

3) Monterey.img - HFS+ install media partition

I wonder if it is ignoring HFS+ partitions???

If anyone has any thoughts it would be greatly appreciated.

config.txt VM.xml opencore-2021-11-19-090547.txt

[ghost82]

41 minutes ago, cat2devnull said:

If anyone has any thoughts it would be greatly appreciated.

 

In your opencore log you have:

00:378 00:011 OC: Got 0 drivers

 

This means that OpenCanopy.efi, OpenHfsPlus.efi and OpenRuntime.efi are not loaded at all.

config.plist is wrong.

In 0.7.5 drivers are inside an array, each inside a dict:

 

you have:

		<key>Drivers</key>
		<array>
			<string>OpenCanopy.efi</string>
			<string>OpenHfsPlus.efi</string>
			<string>OpenRuntime.efi</string>
		</array>

 

Replace with:

		<key>Drivers</key>
		<array>
			<dict>
				<key>Arguments</key>
				<string></string>
				<key>Comment</key>
				<string>HFS+ Driver</string>
				<key>Enabled</key>
				<true/>
				<key>Path</key>
				<string>OpenHfsPlus.efi</string>
			</dict>
			<dict>
				<key>Arguments</key>
				<string></string>
				<key>Comment</key>
				<string></string>
				<key>Enabled</key>
				<true/>
				<key>Path</key>
				<string>OpenRuntime.efi</string>
			</dict>
			<dict>
				<key>Arguments</key>
				<string></string>
				<key>Comment</key>
				<string></string>
				<key>Enabled</key>
				<true/>
				<key>Path</key>
				<string>OpenCanopy.efi</string>
			</dict>
		</array>

 

Make sure to validate the whole config.plist with ocvalidate utility (within opencore)

Edited November 19, 2021 by ghost82

[ghost82]

1 hour ago, cat2devnull said:

If anyone has any thoughts it would be greatly appreciated.

 

Quote

OCS: Missing key Flavour, context <Tools>!

OCS: Missing key RealPath, context <Tools>!

OCS: Missing key TextMode, context <Tools>!

OCS: Couldn't get array serialized at 0 index!

OCS: Couldn't get array serialized at 1 index!

OCS: Couldn't get array serialized at 2 index!

Serialisation returns 6 errors!

 

Booter->Quirks->ProvideCustomSlide is enabled, but OpenRuntime.efi is not loaded at UEFI->Drivers!

Booter->Quirks->EnableWriteUnprotector is enabled, but OpenRuntime.efi is not loaded at UEFI->Drivers!

CheckBooter returns 2 errors!

 

UEFI->Quirks->RequestBootVarRouting is enabled, but OpenRuntime.efi is not loaded at UEFI->Drivers!

CheckUEFI returns 1 error!

 

Completed validating /Users/Eleven/Desktop/config.plist in 1 ms. Found 9 issues requiring attention.

 

You need to change also:

 

from this:

		<key>Tools</key>
		<array>
			<dict>
				<key>Comment</key>
				<string>OpenShell.efi</string>
				<key>Name</key>
				<string>OpenShell.efi</string>
				<key>Enabled</key>
				<true/>
				<key>Arguments</key>
				<string></string>
				<key>Path</key>
				<string>OpenShell.efi</string>
				<key>Auxiliary</key>
				<true/>
			</dict>
		</array>

 

To this:

		<key>Tools</key>
		<array>
			<dict>
				<key>Arguments</key>
				<string></string>
				<key>Auxiliary</key>
				<true/>
				<key>Comment</key>
				<string>OpenShell.efi</string>
				<key>Enabled</key>
				<true/>
				<key>Flavour</key>
				<string>OpenShell:UEFIShell:Shell</string>
				<key>Name</key>
				<string>OpenShell.efi</string>
				<key>Path</key>
				<string>OpenShell.efi</string>
				<key>RealPath</key>
				<false/>
				<key>TextMode</key>
				<false/>
			</dict>
		</array>

 

With these changes you will have in ocvalidate:

Quote

OpenCanopy.efi is loaded at UEFI->Drivers, but Misc->Boot->PickerMode is not set to External!

CheckMisc returns 1 error!

 

It's not a real error, but a warning, meaning you are loading a driver but you're not using it.

To use opencanopy just change PickerMode to External and make sure you have the opencanopy themes taken from ocbinarydata repository.

Let PickerVariant to Auto or set it to a path, for example Acidanthera\GoldenGate

Edited November 19, 2021 by ghost82

[cat2devnull]

Quote

This means that OpenCanopy.efi, OpenHfsPlus.efi and OpenRuntime.efi are not loaded at all.

config.plist is wrong.

In 0.7.5 drivers are inside an array, each inside a dict:

Awesome... I new I had broken something in a dumb way and just couldn't see the forest for the trees.
So I built the config.plist from the template but ran it through a pre 0.7.5 version of Propertree that built the drivers section in the old format. That explains why it couldn't see the HFS+ volume which is what I thought but didn't understand why. I thought I had already run it through ocvalidate but I must be getting confused (I've been playing around with several VMs for the last few weeks).

 

Quote

To use opencanopy just change PickerMode to External and make sure you have the opencanopy themes taken from ocbinarydata repository.

Yep, this is just from me messing around. I have never managed to get the external picker to work. I get strange graphical distortions (each icon is huge) that make it impossible to use. It hasn't annoyed me enough to look at again since OC 0.5.x but I have always left it there for the day I have some spare time. 

 

Now I am going to rearrange my PCIe bus config which I have been meaning to do for 2 years. Then I can add my GPU, USB and NVME drives. I just have to go and refresh my memory as per your post...

Thanks again @ghost82