Thanks a lot Queen6 for your explanations.
I may tell you more about the fixes i applied thanks to the contributors here, and a little bit of searches for any more recent hacks...
First : i don’t feel any overheating touching the case between keyboard and screen (apart during some of the the aborted boots to black or white screen during the process of multi-patching)
Macs Fan Control shows that, when MBP is resting, none of the probe listed is heating above 40-42°C, apart from the RAM temp° which is around 56° when my MBP early 2012 shows 36°.
I don’t know if that has bad repercussion but i don’t see any so far.
I will try another set of RAM, maybe 4GB (2x2) is not enough.
I have 12GB in the MBP2012...
I have built a recovery volume with
Repository of scripts Moof IT share with the community - moofit/scripts
github.com
I could replace the macOS 10.13.6 AppleGraphicsKext v.3.20.13 with v. 3.18.48, which gave me back the full screen and keyboards lights control with ability to put to sleep thru Apple Menu and by closing the lid (white led remains solid for about 30s then begins to pulsate).
That’s here.
Thanks to
this .sh script at GitHub, i could get one of the Mojave improvements i would have missed a lot : NightShift*.
But when i manually activated it until the next morning and let the MBP rest, i ended up with the dreaded Kernel_task CPU mayhem.
Yes it stills happens in HS, even though it is rare and always after trying a new "fix".
No way to know if it is related to NS, but i have some clue : after rebooting and unticking all settings in NightShift pane, CPU is and remains nearly idle (when MBP just rests, iStatMenus shows 0 to 1% cpu usage !!!) .
Tonite i’m going to try the automatic setting without ticking the manual bit...
Shutdown and reboot from Apple menu is still a Russian roulette game.
Most of the time the mouse cursor remains on screen forever. So i dropped 2 text clips on my desktop and have a bash window opened to drag them and
sudo shutdown -h now or
sudo Shutdown -r now when needed.
I’m pretty sure i also replaced the core.brightness framework in S/L/PrivateFrameworks, but i can’t find any trace of finding that new one in my Safari history or tabs, neither could i find the file itself in the MBP’s download folders, nor in the desktop MacMini where i’m also running searches.
I may have
mv’d it instead of
cp.
Worse : I don’t even remember what made up my mind into to replacing it!!! 😳 🤯
I have a "clean" HS on another disk so i can compare (even though i made no backup 😡... that start to smell like a burnout !!!)
Both are V1.0 but they are not the same size. Still investigating...
As for the LoadX3000.sh, i found another script on GitHub, with a
sudo reboot at the end of the script. I don’t think it is necessary and i still don’t see what is blocking the LoginHook.sh...
The illusion is now almost perfect thanks to
this Mojave dynamic wallpaper trick.
I will follow your advice and restart the whole process with 10.12 if it goes really wrong.
All in all it seems to me that i managed to get HS
running some pretty
stealthy way.
To be continued... (?)
*specially with no proper "Dark Mode for HS" hack to be found...
EDIT :
I swap 2x2GB Hynix with 4GB+2GB Samsung RAM.
The RAM probe still reports about 56°C, which is 20° above the rest of them.
The afternoon sun comes in through a large south west window pane, so i enjoy 21° in the room).
I set Macs Fan Control to try to keep it under 50° and never above 62°, i’ll see how fast and long the fans have to spin...
I guess a full scan of the probes would report something ugly somewhere...
A friend has the skills and tool to de-tantalize the board, squeezing out the culprit resistor, so i’m going to swift to the
RealMacMods way sooner or later.
Last but not least : i have absolutely no idea what this MBP has been through in the last 12 years.
It was given to a friend by the father of the original owner who had let it sit on a board for years after taking out the hard disk. Battery was swollen to an extent that i suspected some wreckage on the MB. Bringing it back to life, as crippled as it could be, was a big surprise.
It is actually connected to a MBP2010 13" battery. It does not geometrically fit, of course, and the case remains open. So far so good...
EDIT 2 :
Bummer! It was a good surprise to wake the MBP and find out kernel_task was quiet, but...
Appstore found out that some security update 2020-6 was available, a full week after the 2020-5 was applied.
I
mv’d back the X3000 kext in the S/L/E .
For the record, and for the few who may accept the fight with one of those antiques, and opt for the 10.13.6 installation, once the store has found and installed the 2020-5, the 2020-6 is still available online there :
Security Update 2020-6 for High Sierra 10.13.6
https://support.apple.com/kb/DL2059
Following my mistake of leaving the X3000 in S/L/E-off when i applied the sec-update-2020-5, as i said before, i ended up with a new updated X3000 in S/L/E.
What i forgot to say is that after re-applying the
nvram fa4ce.... in single user the MBP booted WITH that new X3000.
Now just for the sake of art, i did let it reboot after applying sec-update-2020-6 WITH that updated X3000 loaded
The MBP rebooted fine but then i
mv’d back the X3000 to S/L/E-off, and i
hit the reboot loop.
If i try a safe boot i get a white screen after the system load bar has been filled.
I had to boot in single user mode and
sh /force-iGPU-boot to set the nvram again into ignoring dGPU.
I wonder whether my mistake could have lead me to find out that the
NEW AMDRadeonX3000.kext v1.68.25 is actually compatible with the nvram hack, and does not need to be discarded from S/L/E at boot to be loaded only at login. At least for MBP’s without failed GPU artefacts, which is my case.
Of course it might be a good idea to postpone the loading anyway before the meltdown of the dGPU, to avoid the mess when the sh*t hits the fan.
