After more indeep tests, I recap:
I do own a white macbook 2010 with core 2 duo Penryn architecture, Nvidia 320m MCP89 controller very similar to Nvidia 9400m MCP79.
We know that to boot on an unsupported mac the nvram parameter "-no_compat_check" (maybe in conjunction with "-kext-dev-mode=1") is mandatory.
I cannot install a Mojave system directly into my old macbook but I’ve installed it completely from another supported mac.
Without any alterations, or virtualization, or Clover boot loader, using instead a usb Mojave installer or a Mojave recovery partition or his basesystem.dmg restored to a internal disk partition, I can boot them till to GUI but without any USB devices detected and so without any input devices.
While if try to boot main mojave system it boots until a certain phase but then results in quick reboot or kp after GPU kexts are loaded but to me they are not the guilty.
Maybe due to ACPI SSDT issues, SSE4.2 instruction, USB family, we have no certainly.
That’s the focus point.
Compiling LZVN (thanks to who developed the sources from Yosemite beta), I have decompressed a prelinkedkernel file in “S/L/PLKernles” inside which there are:
- some general basilar kexts (they are in total about 140)
- a general dictionary plist file containing more than 2500 lines of plain text with refences to all the infos.plist of those kext
- the kernel unix executable file
Well after deep comparison I noticed that they fit to the same contained inside a compressed LZVN prelinkedkernel file withdrawn from a clean Mojave system installed on a supported mac, usb installer or recovery partition, exactly the same no differences.
I have to a premise:
the prelinkedkernel file since Yosemite release is the KEY to boot any future MacOS version’s frameworks, services, processes and any additional kexts.
When a prelinkedkernel is generated typically after a system installation, it creates a Kernecache ID with a signature, and after done you can boot a MacOS system even without a kernel file in S/L/Kernels while the Extensions folder is EVER required because there is a matching between the kext folder archived inside the prelinkedkernel and the real Extensions folder, instead the kernel is EMBEDDED IN.
I have done many attempts, I would say the relevance is:
Mojave kernel is XNU Darwin 18.0.0
Well, I have tried to cheat the main system, wanted to embed one of these:
Sierra 10.12.6 kernel = Darwin 16.7.0
High Sierra 10.13.6 beta 3 kernel = Darwin 17.7.0
But I could not succeeded, I mean the Mojave system, I don’t know how, calls ever his original Darwin 18.0.0, doesn’t care of S/L/Kernels folder content, even boot with a empty kernels folder since it has his original kernel embedded in prelinkedkernel file.
Just to point out, if you delete the prelinkedkernel file cannot more boot nothing and will see a Prohibitory symbol after the apple logo, but you can easily fix it copying the prelinkedkernel file from another Mojave installation to your Mojave S/L/Prelinkedkernels path.
In conclusion, I think that Metal feature in this case is the last of our issues since you can reach the GUI of MacOS even with a generic WXGA or non accelerated GPU kext.
So if you would like boot (without kernel panic or quick reboot and with input usb devices) Mojave on these kind old hardware core 2 duo, I would suggest these attempts only to those who feel very confident:
- Locate your parameter path boot plist and forcing to boot mac with a previous macOS kernel (or better embed it in LZVN archive creating a patched prelinkedkernel) and valuate the behavior.
- Or try to install Mojave with its required patch (osinstall.mpkg) directly from an unsupported mac and force a risky EFI firmware update on the unsupported mac maybe luckily eluding the platform hardware and features checks.
If I get some new ideas will do other tests and share my opinion.