MBP 1,1-10,2 Force 2011 MacBook Pro 8,2 with failed AMD GPU to ALWAYS use Intel integrated GPU (EFI variable fix)

[nsgr]

There is an alternative reset SMC. I once solved the problem of MagSafe not charging the battery.

The “normal” reset SMC do not work for me.

If you can not solve the problem of high fan speed, maybe this is an alternative.


1 - Turn off the Macbook Pro.

2 - Disconnect the MagSafe.

3 - Open the bottom of Macbook Pro 2011 (screws).

4 - Disconnect the plug battery that is connected to the logic board (Photo).

https://d3nevzfk7ii3be.cloudfront.net/igi/eTItfxSqYQIKnTf1.medium


5 - Press the Power button for 30 seconds.

The Macbook Pro 2011 will try to turn on but there is no power (Magsafe unplugged and battery connector unplugged).

Any remaining charge from the logic board and the rest of the Macbook Pro will be discharge.


6 - Reconnect the battery plug to the logic board.

7 - Close the bottom of the Macbook Pro 2011 with the screws.

8 - Connect the MagSafe in Macbook Pro 2011 and press the Power button to turn on the Macbook.


Example:

In my case I added press the Power button for 30 seconds. Old times of PC notebook.

Some people disconnect the plug from the battery and wait for 2 minutes.

 

[saldin]

I am interested in seeing a link to that hardware solution!

#

No.
SIP just makes the procedure cumbersome. Fix is confirmed working in everything from Yosemite up to High Sierra.
And if you moved the kexts: it is only necessary to move AMDRadeonX3000.kext.

It sounds like you followed the instructions from very first post in this thread.
Right now I am getting the impression that going the linux root is a bit vulnerable to not getting a sticking solution. (For a number of possible reasons. It should stay whether linux route or the NVRAM-route are used properly.)

Try this:
We assume that the hack worked once and that the one offending kext is moved out of /System/Library/Extensions.
Shut down the machine.
Perform SMC/PRAM/NVRAM reset:
disconnect everything except power chord.
hold <leftShift><Ctrl><Opt><Power> for two seconds, release at the same time.
Machine is still powered down.
Now hold <Cmd><Opt><p><r> while powering on and wait until you hear the startup chime two times.
NVRAM is now at factory settings. Previous hack is now deleted.
Boot into SingleUserMode by pressing immediately <Cmd><s> on boot.

issue the following commands in this mode:
nvram boot-args="-v"
nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00
reboot

Fix is now written to NVRAM and should stay. If the system hangs on the next reboot you need to check the locations of your AMD kexts.

If it works only for one boot, come back with more details (posting no. for the guide used, error messages etc.).

Hi,

My 2011 MBP 15" failed this year and can't go to Apple for help anymore. I was looking for ways to disable the AMD GPU and found this thread just now (seriously).

I have one question: do the NVRAM commands you just listed supersede the solution detailed in post #1?

How could it be undone in case I get a AMD reflow/reball later on?

Thank you very much!

 

[MikeyN]

My 2011 MBP 15" failed this year and can't go to Apple for help anymore. I was looking for ways to disable the AMD GPU and found this thread just now (seriously).

I have one question: do the NVRAM commands you just listed supersede the solution detailed in post #1?

How could it be undone in case I get a AMD reflow/reball later on?

They are not superseding the historic post No. 1. They are just a different method to achieve effectively the same result. Going the NVRAM route is just much faster, easier and quite a bit less error prone.

The hack will come off clean, that is: it is entirely, easily and quickly eliminated by doing NVRAM/PRAM/SMC reset. I redid it several times.

Oh. And in case of reflowing/baking (possible, but not recommended: you should prefer a complete chip replacement instead) there is the added benefit that you probably do not have to intervene at all.
See the method for resetting the NVRAM just posted by this great guy: https://forums.macrumors.com/thread...fi-variable-fix.2037591/page-34#post-24938097

 

[Kjeld Flarup]

Thanks to all the good people writing on this thread.

Test: Single-User mode (Command + S) with red background screen and white stripes.

sudo nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00

I followed the archlinux way and changed the EFI, and it worked until the next reboot, then all was forgotten.
Then I tried to removed the kext files, but then I could not enter sleep mode.

After running this nvram command, it seems that my problems are gone. Seems like the nvram command is performing a better job.

Big question is, do we need the archlinux step at all, do we need to remove the SIP and the kext files?
Is all that is needed to do, just to enter single user mode and run the above command?

 

[mikecwest]

Thanks to all the good people writing on this thread.


I followed the archlinux way and changed the EFI, and it worked until the next reboot, then all was forgotten.
Then I tried to removed the kext files, but then I could not enter sleep mode.

After running this nvram command, it seems that my problems are gone. Seems like the nvram command is performing a better job.

Big question is, do we need the archlinux step at all, do we need to remove the SIP and the kext files?
Is all that is needed to do, just to enter single user mode and run the above command?

Are you saying that, when my computer starts acting like a fool with the blue squiggles, I can go into single user mode and enter that command, to get kicked back to the integrated graphics mode?

 

[noname007]

Hello.
First of all, I want to thank for the solution provided here. It had worked from the first attempt for me and brought stable work back to my mbp17(late 2011).
However, this solution has a little drawback, in my case at least. I've spend a lot of time, back when dGPU turned my mbp off every now and then, observing the temperature of the CPU and GPU ("CPU Die - Digital" and "GPU Die - Analog" in "iStat Menus"). When "Integrated only" was selected in gfxCardStatus the temperature of the GPU in idle was 15-25C and sometimes "iStat Menues" was showing "-" instead of a value. When "Discrete only" was selected the temperature of the GPU in idle was 35-45C and it seems the temperature of the CPU became higher as well. After applying the fix I see that I can't enable GPU but the temperature pattern now completely corresponds to the case when GPU was enabled, i.e. the GPU in idle is 35-45C and the CPU temperature in idle is higher on about 10C then it used to be for "Integrated only" mode. I can't say for sure if it affects a battery time as well, as I rarely use it without an ac adapter.
So, the question is am I the only affected or it's a thing I must put up with? Is there a chance that with some other parameter put in "gpu-power-pref-..." the dGPU can be disabled completely?

 

[Kjeld Flarup]

Are you saying that, when my computer starts acting like a fool with the blue squiggles, I can go into single user mode and enter that command, to get kicked back to the integrated graphics mode?

I have an assumption, but I cannot verify it on my own MBP, because I messed around with a lot of solutions already.

 

[mikecwest]

I have an assumption, but I cannot verify it on my own MBP, because I messed around with a lot of solutions already.

I only recently encountered this issue again (it happened two other times, one time I did a Depot repair, the other it was fixed under the recall...

Friday, I got my new failure. I Tried the archlinux thing, and it seems to work, but so far at least once a day, I have to re-do it. It would be nice if that single line code in single user mode works. (Just boot into SU mode, and press UP arrow to select previous commands... I'll try it next time it fails.

 

[MikeyN]

I followed the archlinux way and changed the EFI, and it worked until the next reboot, then all was forgotten.
Then I tried to removed the kext files, but then I could not enter sleep mode.

After running this nvram command, it seems that my problems are gone. Seems like the nvram command is performing a better job.

Big question is, do we need the archlinux step at all, do we need to remove the SIP and the kext files?
Is all that is needed to do, just to enter single user mode and run the above command?

The Linux step is not required – anymore. It is an alternative and the original way. Since it is error prone users report limited success even though it is perfectly viable and works like a charm. One thing of note is that the post No1 in this thread has sadly not been updated in a while and is therefore incomplete regarding several findings to improve the situation a bit further. One of these findings is that the NVRAM method also works and produces the results in an easier way, therefore – in that sense – it might be said it is performing a better job.

However, this solution has a little drawback, in my case at least. I've spend a lot of time, back when dGPU turned my mbp off every now and then, observing the temperature of the CPU and GPU ("CPU Die - Digital" and "GPU Die - Analog" in "iStat Menus"). When "Integrated only" was selected in gfxCardStatus the temperature of the GPU in idle was 15-25C and sometimes "iStat Menues" was showing "-" instead of a value. When "Discrete only" was selected the temperature of the GPU in idle was 35-45C and it seems the temperature of the CPU became higher as well. After applying the fix I see that I can't enable GPU but the temperature pattern now completely corresponds to the case when GPU was enabled, i.e. the GPU in idle is 35-45C and the CPU temperature in idle is higher on about 10C then it used to be for "Integrated only" mode. I can't say for sure if it affects a battery time as well, as I rarely use it without an ac adapter.
So, the question is am I the only affected or it's a thing I must put up with? Is there a chance that with some other parameter put in "gpu-power-pref-..." the dGPU can be disabled completely?

These are not that bad temps after all. You did move X3000 kext and only that and manually loaded it afterwards, right?

I only recently encountered this issue again (it happened two other times, one time I did a Depot repair, the other it was fixed under the recall...

Friday, I got my new failure. I Tried the archlinux thing, and it seems to work, but so far at least once a day, I have to re-do it. It would be nice if that single line code in single user mode works. (Just boot into SU mode, and press UP arrow to select previous commands... I'll try it next time it fails.

Thankfully, there's a script for that: #572
But seriously.
Stop worrying about linux.
Prepare that script as described. Next time your machine fails to do your bidding: perform SMC reset, perform NVRAM reset. then boot single user, mount root as read-write as described on screen and then just run the script.
Presto, fix applied, and it should stick.

 

[noname007]

These are not that bad temps after all. You did move X3000 kext and only that and manually loaded it afterwards, right?

I moved all AMD kexts. Didn't understand what manual loading means, I just turned on mac after kext moving and it worked without issues ever since.
Temps are not bad, but I have an impression that the dGPU is still working and these older macs tend to heat up to 100C in some cases. Complete disabling of the dGPU would be great.

 

[MikeyN]

I moved all AMD kexts. Didn't understand what manual loading means, I just turned on mac after kext moving and it worked without issues ever since.
Temps are not bad, but I have an impression that the dGPU is still working and these older macs tend to heat up to 100C in some cases. Complete disabling of the dGPU would be great.

And that's the problem.
Move all the kexts back, except AMDRadeonX3000.kext.
touch /System/Library/Extensions
wait 2 minutes
reboot
everything still working as before?

Watch the temps!

sudo kextload /pathtoyour/AMDRadeonX3000.kext

That's manual load.

Watch the temps!

If you like what you see, then like #593 for inspiration and look at Update2 in #599.

 

[mac_4eva]

Assuming "latest macOS" means 10.12.6.
AMDRadeonX3000.kext versions seem to be irrelevant to success. It currently looks that they should be at their default versions for the respective systems. Some people even report that they could leave it at the default location.
Having them loaded (after boot) strips me on Yosemite from having sleep and hibernate working correctly. Also Yosemite is now quite slow to shutdown. Both features work for me in Sierra and HighSierra as they should.
The system will likely work completely without the kext, albeit quite likely with higher temperatures on the now useless dGPU.

Autoloading the kext is a problem that I do not have a solution for, and since I am still on Yosi for main work this is a goodthing™.
May be shellscript with the privileges set accordingly should do the trick. A launchd solution; haven't yet tested this, may contain errors:

Assuming that the kext was moved to /System/Library/Extensions-off

enter the following in Terminal:
$ sudo nano /Library/LaunchDaemons/com.lateX3000.plist

copy the following code into the file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.lateX3000.plist</string>
<key>ProgramArguments</key>
<array>
<string>kextload</string>
<string>/System/Library/Extensions-off/AMDRadeonX3000.kext</string>
</array>
<key>RunAtLoad</key><true/>
</dict>
</plist>

Now make it 'active':

$ sudo chown root:wheel /Library/LaunchDaemons/com.lateX3000.plist
$ sudo chmod 644 /Library/LaunchDaemons/com.lateX3000.plist
$ sudo launchctl load -w /Library/LaunchDaemons/com.lateX3000.plist

[
Update:
Naturally the plist contained a typo. Now I tested it. It works. But it is in its current form invoked too early. If someone knows how to postpone the execution?

Update 2:
$ sudo mkdir -p /Library/LoginHook
$ sudo nano /Library/LoginHook/LoadX3000.sh

contents:
#!/bin/bash
kextload /System/Library/Extensions-off/AMDRadeonX3000.kext
exit 0

$ sudo chmod a+x /Library/LoginHook/LoadX3000.sh
$ sudo defaults write com.apple.loginwindow LoginHook /Library/LoginHook/LoadX3000.sh

Method in Update2 works reliable: kext is autoloaded late enough.
Please feel free to improve on this script.
e.g. Add a line to test whether kext is already loaded?
]

The effect of the two methods – efivars vs nvram – should be the same.
nvram is way faster to accomplish and possible with onboard equipment. The efivars way may still be useful under linux, for linux and for exploring the other efivars settings.
If you are on OS X, go nvram.

Instead of using a LoginHook, you may also opt for a LaunchAgent, that runs on login. A neat solution nonetheless.
[doublepost=1503965488][/doublepost]

Unfortunately the test failed with AMD6000Controller.kext, AMDSupport.kext, and AMDRadeonX3000.kext on /System/Library/Extensions. All other kets AMD and ATI were in the /DisableExtensions directory.

Another test did not work too. Only with AMDRadeonX3000.kext in /System/Library/Extensions. All other AMD and ATI kexts were in /DisableExtensions.
[doublepost=1503713889][/doublepost]

Have you seen the information on your video card with IORegistryExplorer? I'm using Additional_Tools_for_Xcode_8.2.dmg.

https://developer.apple.com/library...nceptual/IOKitFundamentals/art/powerplane.jpg

https://developer.apple.com/library...al/IOKitFundamentals/PowerMgmt/PowerMgmt.html

https://developer.apple.com/download/more/


Update:

kextlog

This is an option in boot-args. Test to see if any information about freezing appears (IOConsoleUsers IOScreenLockState 3).


Caution: Enabling logging at a high level via boot arg can greatly slow down system startup time.


Verbose Logging in User and Kernel Space:

2 - Basic information about program progress, including files created.

sudo nvram boot-args="-v kextlog=0xff4"


3 - Individual steps (typically each kext) (= 0xff5 below)

sudo nvram boot-args="-v kextlog=0xff5"


https://developer.apple.com/library/content/releasenotes/Darwin/RN-KernelExtensions/index.html

https://developer.apple.com/legacy/...n/Reference/ManPages/man8/kext_logging.8.html


Update 2:

You can see the kexts loaded in (kextlog=0xff5):

1 - Applications -> Utilities -> Console -> All messages -> search field -> kext

2 - sudo dmesg | grep -i kext

3 - cat /var/log/system.log | grep -i kext

4 - cat /var/log/ kernel.log | grep -i kext

Thanks for that, will look into it an update.

 

[saldin]

They are not superseding the historic post No. 1. They are just a different method to achieve effectively the same result. Going the NVRAM route is just much faster, easier and quite a bit less error prone.

The hack will come off clean, that is: it is entirely, easily and quickly eliminated by doing NVRAM/PRAM/SMC reset. I redid it several times.

Oh. And in case of reflowing/baking (possible, but not recommended: you should prefer a complete chip replacement instead) there is the added benefit that you probably do not have to intervene at all.
See the method for resetting the NVRAM just posted by this great guy: https://forums.macrumors.com/thread...fi-variable-fix.2037591/page-34#post-24938097

Thank you very much, MikeyN!!!! You're a hero to every MBP 2011 owner!!! It now boots reliably and consistently!!!

BUT... I'm noticing it doesn't shutdown cleanly now. Could you please help me figure out what's wrong?

Since I changed the boot-args to verbose as advised, it shows this and gets stuck:

Process mds_stores [214] disabling system-wide I/O Throttling
Process mds_stores [214] disabling system-wide CPU Throttling
in6_unlink_ifa: IPv6 address 0x0000000000000000 has no prefix
AFP_VFS afpfs_unmount: /Volumes/AirDisk, flags 0, pid 528
ASP_TCP Disconnect: triggering reconnect by bumping reconnTrigger from curr value 0 on so 0x0000000000000000

ASP_TCP Detach: Reply queue not empty?

Mon Aug 28 22:00:00 2017 MacBookBroke.local com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.system) <Notice>: Userspace teardown took: 8006 ms

 

[Kjeld Flarup]

The Linux step is not required – anymore. It is an alternative and the original way. Since it is error prone users report limited success even though it is perfectly viable and works like a charm. One thing of note is that the post No1 in this thread has sadly not been updated in a while and is therefore incomplete regarding several findings to improve the situation a bit further. One of these findings is that the NVRAM method also works and produces the results in an easier way, therefore – in that sense – it might be said it is performing a better job.

I guess that this finding is written in some of the 300 post I didn't read. I hope for others that post #1 is updated. Or perhaps a new thread is started.

 

[mikecwest]

I guess that this finding is written in some of the 300 post I didn't read. I hope for others that post #1 is updated. Or perhaps a new thread is started.

my problem came back again, I did the NVRAM thing, and it did not do anything for me...

 

[MikeyN]

BUT... I'm noticing it doesn't shutdown cleanly now. Could you please help me figure out what's wrong?

Since I changed the boot-args to verbose as advised, it shows this and gets stuck:

Process mds_stores [214] disabling system-wide I/O Throttling
Process mds_stores [214] disabling system-wide CPU Throttling
in6_unlink_ifa: IPv6 address 0x0000000000000000 has no prefix
AFP_VFS afpfs_unmount: /Volumes/AirDisk, flags 0, pid 528
ASP_TCP Disconnect: triggering reconnect by bumping reconnTrigger from curr value 0 on so 0x0000000000000000

ASP_TCP Detach: Reply queue not empty?

Mon Aug 28 22:00:00 2017 MacBookBroke.local com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.system) <Notice>: Userspace teardown took: 8006 ms

Maybe. On Yosemite I had not the same but similar issues. It would never hang completely (my guess, I grew quite impatient with it at times) but it took sometimes an extraordinary amount of time to let it run its things and eventually shutdown cleanly.
So I very reluctantly gave up on Yosi. Sierra didn't give me issues.
If you are on 10.11 or 10.12 then you should look more into what the message above tells you. Looks more like a network issue than something caused by the hack.
Try to unmount all networks drives and close all network connections before issuing the shutdown command.

my problem came back again, I did the NVRAM thing, and it did not do anything for me...

Some more info on this would be helpful.
Exact symptoms? Did you reset NVRAM/SMC (yes, again) before (re-)applying NVRAM-hack?

 

[SergioF]

I have now tried this hack with 2 different MBP 8,3 and both times the hack worked.

Both MBP would not boot and showed vertical coloured stripes against the grey screen. These are the steps I used:
1. Created the Arch Linux LiveUSB as per instructions on first page. This enabled me to see that the gpu-power-prefs variable was present in /sys/firmware/efi/efivars. (optional step)
2. Removed the gpu-power-prefs variable and also all other gpu vars from /sys/firmware/efi/efivars by doing a
SMC/PRAM/NVRAM reset:
hold <leftShift><Ctrl><Opt><Power> for two seconds, release at the same time.
And then with machine still powered down.
Hold <Cmd><Opt><p><r> while powering on and wait until you hear the startup chime two times.
NVRAM is now at factory settings.
3. Booted to single user mode <Cmd><s> on boot. Did a fsck -fy first and then as per MikeyN instructions issued the following commands:
nvram boot-args="-v"
nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00
reboot
4. I then removed the AMDRadeonX3000.kext from the Mac OS installation by booting from an external HD with Sierra installation that already had no AMDRadeonX3000.kext. Load external HD with Sierra (minus AMDRadeonX3000.kext) and then search for the AMDRadeonX3000.kext within the internal disk /System/Library/Extensions and delete the offending kext. Without removing the AMDRadeonX3000.kext I found that on the first MBP (Sierra) the hack worked only on first boot the problem re-occurred and I had to do the hack again and on the 2nd MBP (Yosemite) it didn't boot at all.

Thanks to MikeyN for his help and instructions I have now managed to get two 17" MBP back in working condition.

 

[saldin]

Maybe. On Yosemite I had not the same but similar issues. It would never hang completely (my guess, I grew quite impatient with it at times) but it took sometimes an extraordinary amount of time to let it run its things and eventually shutdown cleanly.
So I very reluctantly gave up on Yosi. Sierra didn't give me issues.
If you are on 10.11 or 10.12 then you should look more into what the message above tells you. Looks more like a network issue than something caused by the hack.
Try to unmount all networks drives and close all network connections before issuing the shutdown command.

Some more info on this would be helpful.
Exact symptoms? Did you reset NVRAM/SMC (yes, again) before (re-)applying NVRAM-hack?

I'm running Capi 10.11.6, but the latest security update is still pending installation. The computer has maxed-out memory (16 GB PC3-12800 Corsair Vengeance) and upgraded storage (480 GB OWC Mercury Electra 6G).

When it was working fine, or in the late stages of its degenerative disease when I got it to boot correctly after much effort, it would shutdown very quickly. Now it gets stuck shutting down or rebooting. I tried to see if it would get stuck after a reboot command as well, and it didn't show the text on that occasion and then ever again. I admit I was too impatient and turned it off forcibly without giving it enough time. I also admit I didn't test sleep/hibernation or wake-up to see if it worked after applying the hack. I will wait longer (and time it) and test sleep/wakeup and report back.

I applied the hack in 3 reboot cycles: one for disabling SIP, another for moving the kext and modifying the nvram, and the last one for reenabling SIP. I didn't try to erase it and reapply after it was working, but I will try that and report back.

I'm also willing to upgrade to Sierra, I just need some pointers:

• I read it's suggested to put back the AMDRadeonX3000.kext back in the Extensions folder in order to successfully run updates and upgrades, but wouldn't that break the hack and prevent it from booting?
• After the upgrade finishes and reboots, I expect the installer to have overwritten the hack. Should I immediately access single-user mode and remove the X3000.kext and reapply the nvram hack before it tries to boot for the first time?

I thank you again, from the bottom of my heart, for all your help and dedication to us, MBP 2011 owners.

 

[nonlen]

I have now tried this hack with 2 different MBP 8,3 and both times the hack worked.

Both MBP would not boot and showed vertical coloured stripes against the grey screen. These are the steps I used:
1. Created the Arch Linux LiveUSB as per instructions on first page. This enabled me to see that the gpu-power-prefs variable was present in /sys/firmware/efi/efivars. (optional step)
2. Removed the gpu-power-prefs variable and also all other gpu vars from /sys/firmware/efi/efivars by doing a
SMC/PRAM/NVRAM reset:
hold <leftShift><Ctrl><Opt><Power> for two seconds, release at the same time.
And then with machine still powered down.
Hold <Cmd><Opt><p><r> while powering on and wait until you hear the startup chime two times.
NVRAM is now at factory settings.
3. Booted to single user mode <Cmd><s> on boot. Did a fsck -fy first and then as per MikeyN instructions issued the following commands:
nvram boot-args="-v"
nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00
reboot
4. I then removed the AMDRadeonX3000.kext from the Mac OS installation by booting from an external HD with Sierra installation that already had no AMDRadeonX3000.kext. Load external HD with Sierra (minus AMDRadeonX3000.kext) and then search for the AMDRadeonX3000.kext within the internal disk /System/Library/Extensions and delete the offending kext. Without removing the AMDRadeonX3000.kext I found that on the first MBP (Sierra) the hack worked only on first boot the problem re-occurred and I had to do the hack again and on the 2nd MBP (Yosemite) it didn't boot at all.

Thanks to MikeyN for his help and instructions I have now managed to get two 17" MBP back in working condition.

Hi, 2 questions...
3. What is "Did a fsck -fy first" ?
4. After the hack, is it possible to remove the AMDRadeonX3000.kext from the internal drive without using / booting from an external HD?

Thanks

 

[MikeyN]

I'm running Capi 10.11.6, but the latest security update is still pending installation. The computer has maxed-out memory (16 GB PC3-12800 Corsair Vengeance) and upgraded storage (480 GB OWC Mercury Electra 6G).

When it was working fine, or in the late stages of its degenerative disease when I got it to boot correctly after much effort, it would shutdown very quickly. Now it gets stuck shutting down or rebooting. I tried to see if it would get stuck after a reboot command as well, and it didn't show the text on that occasion and then ever again.

I applied the hack in 3 reboot cycles: one for disabling SIP, another for moving the kext and modifying the nvram, and the last one for reenabling SIP. I didn't try to erase it and reapply after it was working, but I will try that and report back.

I'm also willing to upgrade to Sierra, I just need some pointers:

• I read it's suggested to put back the AMDRadeonX3000.kext back in the Extensions folder in order to successfully run updates and upgrades, but wouldn't that break the hack and prevent it from booting?
• After the upgrade finishes and reboots, I expect the installer to have overwritten the hack. Should I immediately access single-user mode and remove the X3000.kext and reapply the nvram hack before it tries to boot for the first time?

Alas, for ElCap I do not have personal experience to offer. But I think I do I not understand correctly "and it didn't show the text on that occasion and then ever again.": that the problem is gone?

If you are doing the SecurityUpdate for ElCap now or soon:

Stop and Read!

"The hack" is the NVRAM-variable. The hack will not be overwritten. These installers do not trigger an NVRAM reset.
Even the frequent EFI-Updates that come with High Sierra betas do not overwrite the hack.

And just in case the hack does get removed/overwritten somehow; actually, and anyhow: Prepare the script from #572. If you loose the hack (through an NVRAM-reset) and have this script prepared, then your downtime is reduced to ~20 sec.

But: These updates install newer AMD driver kexts. A 'full' set. 'Full' is in air quotes because:
We have discovered that these SecurityUpdates for Yosemite, ElCap and also the .6-Update for Sierra contain updates/upgrades to the AMD driver kexts. Sadly these are incomplete in very subtle and minor ways. But on Yosi and ElCap at least they will bring you trouble if applied blindly.

For this reason it is at least advisable to get your latest AMDRadeonX3000.kext back into /System/Library/Extensions before the update/upgrade procedure.

This ensures that you have only one X3000 kext and that it will be complete and up-to-date. It then has just to be moved again.

It is best to not use the AppStore download. Use the standalone installer: https://support.apple.com/kb/DL1932?locale=en_US
Apply that install only after you have disabled SIP! (Update also will work with SIP enabled. Saves you headaches in the next step.)

After the update is complete, your system will have problems. That is to be expected: The kext is back in place. You have to deal with one botched boot. Since you have disabled SIP: force a reset, boot SingleUser move the kext to your preferred place, type touch /System/Library/Extensions and wait ~2 minutes. Then reboot, back into the game.

#####

If you decide to upgrade to Sierra:

This too will very likely not change the NVRAM hack.
Opt for a clean install. No upgrade, no migration assistant. This might sound painful for some.
(Try diskmakerx.com to create an install medium).

But after the installer is finished, it then tries to boot into a system with the crucial kext again in its default place.
From there on you have two options. First and maybe not so good: boot into SafeMode, finish AppleSetup with unaccelerated graphics.
Or perhaps, better to start directly with what would have to come next: you can then force reboot, boot into RecoveryMode, disable SIP, reboot SingleUser, move the kext to your preferred location. Do not forget to type touch /System/Library/Extensions and wait ~2 minutes.
Next reboot should be fine.

 

[mikecwest]

Maybe. On Yosemite I had not the same but similar issues. It would never hang completely (my guess, I grew quite impatient with it at times) but it took sometimes an extraordinary amount of time to let it run its things and eventually shutdown cleanly.
So I very reluctantly gave up on Yosi. Sierra didn't give me issues.
If you are on 10.11 or 10.12 then you should look more into what the message above tells you. Looks more like a network issue than something caused by the hack.
Try to unmount all networks drives and close all network connections before issuing the shutdown command.


Some more info on this would be helpful.
Exact symptoms? Did you reset NVRAM/SMC (yes, again) before (re-)applying NVRAM-hack?

Ok, I reset the SMC and zapped the PRAM, it came out blue squiggly after that. I ran the terminal commands, and it came out clear with the Intel video.

That is a lot easier than the Linux method.

I have made a file, to make things easier, you are free to use it if you wish...

It does the NVRAM hack, sets in in verbose mode (thats what the -v boot-args flag does.), and also sets kext-dev-mode to enabled. (just in case you have CAT installed).... You can edit out what you don't want or need. I don't believe you can disable SIP from single user mode, so you will still have to redo that everytime you SMC/PRAM reset.

To use it, just unzip the contents to the root of you boot drive. Start in single user mode and type "bash roxy" (without the quotes and press enter.....it will type out the long tedious commands and reboot automatically.

(Roxy is that little kitty wearing the Rudolph costume under my name, although she is no longer little)

 

[saldin]

Alas, for ElCap I do not have personal experience to offer. But I think I do I not understand correctly "and it didn't show the text on that occasion and then ever again.": that the problem is gone?

I reset the SMC and PRAM again and reapplied the hack. Tested rebooting and shutting down the system three times and timed them, but I stopped each attempt at 5 minutes and forcibly powered off the system. I conclude it doesn't shutdown or reboot right anymore.

I also tested closing the lid and waiting until the system started sleeping (when the light does the breathing pattern) and then opened the lid and waited two minutes. Attempted three times and the keyboard backlight powers on but the screen stays off. I can use the backlight control keys and dim them at will, though. I conclude sleep/wakeup doesn't work right anymore.

Still, I'll take inability to shutdown/reboot and sleep/wakeup to a system that doesn't even boot.

I wholeheartedly thank you for the care you put in writing detailed instructions for me to upgrade Capi with the security update and to install Sierra. It's hard for me to install Sierra clean, but I'll definitely do the security patch and retry the testing. If push comes to shove, I'll backup everything and install Sierra clean.

Do you know if the computer can keep operating with the hack and the HD3000 indefinitely, or if continued degeneration will eventually make it reach true death?

Thank you very much for all your amazing help!!!!!!

 

[nsgr]

There are some settings for Hibernate and Sleep with the pmset command.

https://en.wikipedia.org/wiki/Pmset

http://www.macos.utah.edu/documentation/administration/pmset.html

https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/pmset.1.html

http://www.manpagez.com/man/1/pmset/

 

[SergioF]

Hi, 2 questions...
3. What is "Did a fsck -fy first" ?
4. After the hack, is it possible to remove the AMDRadeonX3000.kext from the internal drive without using / booting from an external HD?

Thanks

fsck -fy checks the integrity of the files system. I did in just in case especially if the system had been shutting down abruptly because of the graphics problem fsck -fy will correct any errors on the OS.

Yes you can use a normal user with admin privileges to remove kext from an external OS installation. In my case I did it the other way, booted the system with an external drive <opt> on boot and then choose to boot from the external drive, already without the kext, and then use the external system to find and remove the kext from the internal drive. Hope that makes sense to you.

I would use the same method for upgrading in the future, if you have access to an external drive with an installation of OS. Boot from the external OS and then use it to upgrade the internal disk and then use it again to remove the kext. This way you don't have reapply the hack.

 

[afide]

Ok so I followed the guide on page one and everything seems to be working fine, should I do anything else? Thanks everyone