Fix and update opencore image for Big Sur 11.3+

[82ghost82]

Opencore: v. 0.6.9 (debug) stable VirtualSMC: v. 1.2.3 (debug) stable AppleALC: v. 1.6.0 (debug) stable Whatevergreen: v. 1.4.9 (debug) stable Lilu: v. 1.5.3 (debug) stable

Added patch DhinakG - cpuid_set_cpufamily - force CPUFAMILY_INTEL_PENRYN - from 11.3b1 for big sur 11.3+

[ljackl]

@82ghost82 A new version of OpenCore was release a few weeks ago, any chance you'd be willing to provide the steps you took to create the image you've added here?

Additionally, numerous people appear to be having a bootloop issue when using your .img, see #44

[82ghost82]

@ljackl Easier than expected, from within macos, without third party apps, place OpenCore.img on your desktop, open a terminal and give following commands:

hdiutil attach -imagekey diskimage-class=CRawDiskImage -nomount ~/Desktop/OpenCore.img mkdir ~/Desktop/EFI diskutil list

----> find the EFI partition in the img raw image (ex: disk2s1)

sudo mount -t msdos /dev/disk2s1 ~/Desktop/EFI

Now that the EFI is mounted you can do your mods.

Not a github expert, since this pr is still opened, nor rejected, nor closed, I don't know how to make a commit on this pr, so, same as above with the following updates: Opencore: v. 0.7.0 (debug) stable VirtualSMC: v. 1.2.4 (debug) stable AppleALC: v. 1.6.1 (debug) stable Whatevergreen: v. 1.5.0 (debug) stable

https://mega.nz/file/ByZBxYwZ#aOlGJGNHZplB3dNqTC8krXGC849TaEeOnfSYN_FB88s

Additionally, numerous people appear to be having a bootloop issue when using your .img, see #44

See this: https://github.com/acidanthera/bugtracker/issues/1712 https://forums.unraid.net/topic/84601-support-spaceinvaderone-macinabox/?do=findComment&comment=1010581

[ljackl]

@82ghost82 Thanks for the updated .img file and the info on how to mount the existing image from within macos, very helpful!

If its not too much trouble, would you be able to provide some further detail on how you update the various packages? Perhaps a step-by-step guide on how you make mods to the .img? I'm a comp sci grad but haven't got any experience in this area and am unsure on what needs changing if I want to create my own updated image. It could also be helpful for those who need an updated image in the future.

If a step by step guide is too much trouble, a few specific questions that come to mind are:

1. My understanding of Opencore is that it relies on a config.plist file. Do you need to make any changes to that file when updating the .img? Leave the original config file unchanged? Use the latest sample config file? 1a. If you do need to make changes, what tools/processes do you use to make them? How do you know what needs changing to work specifically in an unraid vm?
2. To confirm, you're just downloading the latest vesions of Opencore/VirtualSMC/AppleALC/Whatevergreen from their respective git repo, right?
3. What makes you use the debug versions of these packages? My understanding of debug builds is that they aren't compiled for maximum performance & can be less secure. Happy to be corrected on that though.

[82ghost82]

Hi @ljackl no problem, it's easier than expected.

1. You start with a working config.plist: for this specific case, a virtual machine in qemu+libvirt, and the default xml template, you are emulating all the hardware, so the config.plist will work for everyone who will emulate the same hardware. So you can start with the actual config.plist Then, let's say you want to upgrade opencore stable: download the package from the repo or from dortania, check the sample.plist file in the docs folder and compare it with the actual config.plist that you have to see if entries were added or removed, and update your actual config.plist with the new entries. For the comparison I use beyond compare, it's a paid app which compares 2 files, but you can use any app you want, or just compare the 2 files "by hand". In docs directory you will also find the configuration.pdf file which describes all the entries in the config.plist After you finished upgrading your config.plist you may want to run the ocvalidate utility which is in the utilities directory of opencore, just to check that there aren't code language issues or errors in the new config.plist
2. Yes, you can download stable releases from their respective repos, or you can compile yourself, or if you can't compile but you need latest commits applied instead of stable releases you can download "nightly builds" from dortania: https://dortania.github.io/builds/ Just choose a product and download the already compiled version
3. Yes, you are right, they're not for max performances, but what you loose is nothing in terms of time; you are wrong about "less secure"; however if you have issues the debug versions will output a lot more entries in the log and it will be easier to fix, that's why I prefer all debug versions. Anyway, one is free to choose the release versions.

To upgrade opencore just replace the files from the downloaded compiled version to that mounted in your efi or in the img raw file, and as said above, don't forget to check the config.plist for added/removed entries. So you want to replace for the opencore package: EFI/BOOT/BOOTx64.efi EFI/OC/Drivers/OpenCanopy.efi EFI/OC/Drivers/OpenHfsPlus.efi EFI/OC/Drivers/OpenRuntime.efi EFI/OC/Drivers/UsbMouseDxe.efi EFI/OC/Opencore.efi EFI/OC/Tools/OpenShell.efi

For kexts (each downloaded from their respective repo), these must be replaced in EFI/OC/Kexts: EFI/OC/Kexts/AGPMInjector.kext EFI/OC/Kexts/AppleALC.kext EFI/OC/Kexts/Lilu.kext EFI/OC/Kexts/MCEReporterDisabler.kext EFI/OC/Kexts/USBPorts.kext EFI/OC/Kexts/VirtualSMC.kext EFI/OC/Kexts/WhateverGreen.kext

Note that VirtualSMC is not mandatory if you use the custom qemu arg with the apple key in the xml, but I prefer to have this kext too, so if you miss that argument in the xml the vm will not hang.

For the resources in EFI/OC/Resources there's another repo: https://github.com/acidanthera/OcBinaryData

[82ghost82]

Finally I was able to reproduce the bootloops that several users are experiencing.

[82ghost82]

A new image was provided: https://github.com/SpaceinvaderOne/Macinabox/pull/47#issuecomment-868495877

Current Big Sur 11.4 BaseSystem must use an updated opencore image with SecureBootModel Disabled; as referenced in acidanthera bugtracker, "the fact that it boots without Apple Secure Boot is mere luck" (citation: vit9696)

So, this could be potentially not work in next upgrades.

[ljackl]

@82ghost82 Thank you very much for your detailed instructions, your work is greatly appreciated! Looking forward to an update from the developers regarding the need for SecureBootModel: Disabled.

[82ghost82]

Speaking about Big Sur 11.4 (I didn't test any other mac os version), SecureBootModel Disabled is needed if BaseSystem.dmg is converted to BaseSystem.img with dmg2img (which is what macinabox does now --> only an online installation through BaseSystem is possible with macinabox, look at unraid.sh, function makeimg()); once the system is installed it is possible to switch SecureBootModel to Default, since there will be no need to boot again the BaseSystem disk.

I described the correct method to install from BaseSystem here, which should replace the current dmg2img part in the code: https://forums.unraid.net/topic/84601-support-spaceinvaderone-macinabox/?do=findComment&comment=1010581

Converting BaseSystem.dmg to BaseSystem.img works now only with SecureBootModel Disabled and with an upgraded opencore image (that in the container is not working with big sur 11.4) but may not work for future releases of mac os. This will boot current converted BaseSystem.img (SecureBootModel Disabled): https://mega.nz/file/ByZBxYwZ#aOlGJGNHZplB3dNqTC8krXGC849TaEeOnfSYN_FB88s

[82ghost82]

Closing this and opening a new one with correct image.