Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
*) printf "\x07\x00\x00\x00\x01\x00\x00\x00" > /sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9

Did not have a EFI "gpu-power-prefs-" variable so I thought that it will be OK to create a new one with a random UUID - in this case, taken directly from a cpu-switch script
____________________________

I am booted into an Ubuntu GUI and when I try the printf command above (preceded buy sudo) I get "Invalid argument"

The permissions on this folder are rw and I don't have an existing gpu-power... file. I tried touch to create a blank gpu-power... file, but got the same "Invalid argument"

Any suggestions? - Thanks!!!
 
Just follow this guide, use Arch live usb. It took me less than one hour to do all the steps described here starting from checking hdd and removing kexts, then downloading distro, creating usb stick etc. Be careful with chattr command, it doest't work on directory and should be applied to gpu-power-prefs file only, look for correct usage elsewhere in this thread.
 
  • Like
Reactions: AppleMacFinder
Just follow this guide, use Arch live usb. It took me less than one hour to do all the steps described here starting from checking hdd and removing kexts, then downloading distro, creating usb stick etc. Be careful with chattr command, it doest't work on directory and should be applied to gpu-power-prefs file only, look for correct usage elsewhere in this thread.

Thanks, I tried the Arch live distro and had issues. AND, the screen is still a mess booted into that version. The latest release of Ubuntu shouldn't work much differently from Arch?
 
I guess this low-level things can not be done from GUI. I am not a guru in Linux, I just have done my successful fix. I had issues too but finally it's working. If you tell more about your Arch issues, I think the community will be able to help you.
 
I guess this low-level things can not be done from GUI. I am not a guru in Linux, I just have done my successful fix. I had issues too but finally it's working. If you tell more about your Arch issues, I think the community will be able to help you.

It's a GUI with a terminal window.
 
It's a GUI with a terminal window.
You can experiment as much as you like. But it seems that Ubuntu should not be a way to go in this case.
As far as I know, Ubuntu has complicated root setup, there is no root account by default. See this thread http://askubuntu.com/questions/91598/how-do-i-login-as-root . Sudo is not the same as real root. Chances are that everything that goes after ">" in prinf is going without root rights. You need pure Linux console doing root things directly without sudo. IMHO.
 
*) printf "\x07\x00\x00\x00\x01\x00\x00\x00" > /sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9

Did not have a EFI "gpu-power-prefs-" variable so I thought that it will be OK to create a new one with a random UUID - in this case, taken directly from a cpu-switch script
____________________________

I am booted into an Ubuntu GUI and when I try the printf command above (preceded buy sudo) I get "Invalid argument"

The permissions on this folder are rw and I don't have an existing gpu-power... file. I tried touch to create a blank gpu-power... file, but got the same "Invalid argument"

Any suggestions? - Thanks!!!

Please skip this command, it is not valid and does nothing. Now I added "<----- skip this command" to the right side. Just complete a guide without this particular command (but with the completion of other, valid chattr commands) and it should be fine

I guess this low-level things can not be done from GUI. I am not a guru in Linux, I just have done my successful fix. I had issues too but finally it's working. If you tell more about your Arch issues, I think the community will be able to help you.
It should be possible at Ubuntu if you open its' Terminal and type sudo su or su - root to enter the root mode
(you may need to additionally run sudo passwd root to set root's password before trying these commands).

Problem there is that your failed GPU might prevent from successfully booting the Ubuntu, so Arch Linux (or any other Linux distro whose LiveCD has a naked console) is more reliable in this case

Thanks, I tried the Arch live distro and had issues. AND, the screen is still a mess booted into that version. The latest release of Ubuntu shouldn't work much differently from Arch?

Screen is supposed to be a mess in any operating system, until you do this EFI variable fix. In theory, EFI variable fix under Ubuntu should work as good as under Arch Linux, but in practice (at least in my case) Ubuntu couldn't be booted probably because it gets stuck while trying to launch its' graphical interface using this failed GPU. Arch Linux LiveUSB does not have the graphical interface at all, so it boots fine and is perfectly usable for conducting this fix
[doublepost=1491398344][/doublepost]
I tried the Arch live distro and had issues
Please describe these issues, we might be able to help you. Will be useful if you still would like to go Arch Linux route instead of trying it with Ubuntu's root account
 
Last edited:
Please skip this command, it is not valid and does nothing. Now I added "<----- skip this command" to the right side. Just complete a guide without this particular command (but with the completion of other, valid chattr commands) and it should be fine

It should be possible at Ubuntu if you open its' Terminal and type sudo su or su - root to enter the root mode
(you may need to additionally run sudo passwd root to set root's password before trying these commands)

Problem there is that your failed GPU might prevent from successfully booting the Ubuntu, so Arch Linux (or any other Linux distro whose LiveCD has a naked console) is more reliable in this case



Screen is supposed to be a mess in any operating system, until you do this EFI variable fix. In theory, EFI variable fix under Ubuntu should work as good as under Arch Linux, but in practice (at least in my case) Ubuntu couldn't be booted probably because it gets stuck while trying to launch its' graphical interface using this failed GPU. Arch Linux LiveUSB does not have the graphical interface at all, so it boots fine and is perfectly usable for conducting this fix
[doublepost=1491398344][/doublepost] Please describe these issues, we might be able to help you. Will be useful if you still would like to go Arch Linux route instead of trying it with Ubuntu's root account

I am not sure what the issue was, but I am willing to try Arch Linux again. Not having a real root user in Ubuntu would explain the issues I am having executing the printf command (I tried everything with sudo). For what it's worth, this kernel hack works great to get an Ubuntu GUI loaded on an affected MBP and it is based on the same instructions you have:


But, I didn't do the installation (and create a root user) as instructed. I imagine this would work fine if you want an Ubuntu machine.

So, I tried Arch Linux and got the message that '/dev/disk/by-label/ARCH_201704' did not show up after 30 seconds. I was still able to do everything until I got to printf again. I get the same "Invalid argument" message?
 
Last edited:
Is it guaranteed the dgpu will go bad like many original xbox 360 and nvidia chips from 2008ish. My wife has one and it work perfectly fine but I may replace it before the inevitable.

My Xbox 360 has gone haywire some years ago [2013 i think] but my 2008 Mac with the Nvidia GPU is still going strong. Next year the computer will turn 10 years [bought it on launch day] and no signs of a bad GPU.
Based on my experience I'll say it's 'very likely', but not 'guaranteed'

:p
 
  • Like
Reactions: AppleMacFinder
Hi guys, thanks for the updates.

I've attempted the gfxcardstatus 2.0 fix, doesn't seem to work for me.

Right now if I try to log into single user mode I get a line a code it skips past real quick, see attached image.

When I attempt to log into cmd r to disable SIP the Mac hangs.

Question, if I remove my hard drive and put it in an enclosure, then USB boot from another Mac how do I to gain access to single user and repair modes?

Thanks in advance!

Error says
builduser 0 : error building a user of type 0x20010008

Update;

Seems that strange code is due to HDD being encrypted by FileVault.
So that's resolved.

I still can't boot cmd R to disable SIP, ideas?

Can I disable Sip without revivers terminal?
Or can I boot to recovery terminal with my HDD in an enclosure and USB boot to another Mac?

Thanks
 

Attachments

  • IMG_7749.JPG
    IMG_7749.JPG
    969.6 KB · Views: 517
Last edited:
  • Like
Reactions: AppleMacFinder
Hi guys, thanks for the updates.

I've attempted the gfxcardstatus 2.0 fix, doesn't seem to work for me.

Right now if I try to log into single user mode I get a line a code it skips past real quick, see attached image.

When I attempt to log into cmd r to disable SIP the Mac hangs.

Question, if I remove my hard drive and put it in an enclosure, then USB boot from another Mac how do I to gain access to single user and repair modes?

Thanks in advance!

Error says
builduser 0 : error building a user of type 0x20010008

Update;

Seems that strange code is due to HDD being encrypted by FileVault.
So that's resolved.

I still can't boot cmd R to disable SIP, ideas?

Can I disable Sip without revivers terminal?
Or can I boot to recovery terminal with my HDD in an enclosure and USB boot to another Mac?

Thanks


Now this

****[IObluetoothfamily][searchfortransporteventtimeouthandler] -- missing Bluetooth controller transport!

Disk1s1: device is write locked.
Airport_brcm4331::apple80211requestIocdisk1s1: device is write locked.
 

Attachments

  • IMG_7754.JPG
    IMG_7754.JPG
    1.9 MB · Views: 782
  • Like
Reactions: AppleMacFinder
Not having a real root user in Ubuntu would explain the issues I am having executing the printf command (I tried everything with sudo)
Ubuntu has a real root user, even at LiveCD, - you just need to set a password for him and then you are able to switch to him. See the commands in my previous message... But in any case Arch Linux is more convenient for performing this fix, Ubuntu may fail to load because of the failing GPU
For what it's worth, this kernel hack works great to get an Ubuntu GUI loaded on an affected MBP and it is based on the same instructions you have
I disagree. Their hack on video - is operating system specific (e.g. doesn't work at OS X).
In comparison, EFI variable hack is universal - after EFI variable hack, any system should work fine!
So, I tried Arch Linux and got the message that '/dev/disk/by-label/ARCH_201704' did not show up after 30 seconds. I was still able to do everything until I got to printf again. I get the same "Invalid argument" message?
Did you skip a wrong command this time? (recently marked as "<----- skip this command" at my 1st message)
[doublepost=1491604985][/doublepost]
I've attempted the gfxcardstatus 2.0 fix, doesn't seem to work for me
As expected, gfxcardstatus doesn't work in this situation, only EFI variable fix works
Right now if I try to log into single user mode I get a line a code it skips past real quick, see attached image.

When I attempt to log into cmd r to disable SIP the Mac hangs

Question, if I remove my hard drive and put it in an enclosure, then USB boot from another Mac how do I to gain access to single user and repair modes?
Disk1s1: device is write locked.
Airport_brcm4331::apple80211requestIocdisk1s1: device is write locked.
I think your main problem right now is corrupted HFS+ file system, corruption happened because of too many emergency shutdowns and filesystem became read-only. To repair your HFS+ filesystem you should either use another Mac or another computer with Linux (more tricky, described at the 1st post of this thread). After you repair it, you will get the write permissions

By the way, you could perform these removal operations instantly after repairing a filesystem, while your MBP's HDD is still inside the enclosure and is connected to another computer. Because, while HDD's OS X is shutdown, SIP is not blocking you! In short: while your MBP's HDD is connected to another computer, on this HDD there is no active SIP, and after the filesystem's repair - anything on this HDD should become writeable and removable
 
Last edited:
@AppleMacFinder, Thanks so much for helping me restore my 17" early 2011 MacBook Pro! The guide was excellent!

Just wondering what happens when we update the OS, will we be back to square one and have to modify the EFI prefs again to force the integrated graphics?
 
  • Like
Reactions: AppleMacFinder
Ubuntu has a real root user, even at LiveCD, - you just need to set a password for him and then you are able to switch to him. See the commands in my previous message... But in any case Arch Linux is more convenient for performing this fix, Ubuntu may fail to load because of the failing GPU I disagree. Their hack on video - is operating system specific (e.g. doesn't work at OS X).
In comparison, EFI variable hack is universal - after EFI variable hack, any system should work fine! Did you skip a wrong command this time? (recently marked as "<----- skip this command" at my 1st message)
[doublepost=1491604985][/doublepost] As expected, gfxcardstatus doesn't work in this situation, only EFI variable fix works I think your main problem right now is corrupted HFS+ file system, corruption happened because of too many emergency shutdowns and filesystem became read-only. To repair your HFS+ filesystem you should either use another Mac or another computer with Linux (more tricky, described at the 1st post of this thread). After you repair it, you will get the write permissions

By the way, you could perform these removal operations instantly after repairing a filesystem, while your MBP's HDD is still inside the enclosure and is connected to another computer. Because, while HDD's OS X is shutdown, SIP is not blocking you! In short: while your MBP's HDD is connected to another computer, on this HDD there is no active SIP, and after the filesystem's repair - anything on this HDD should become writeable and removable


How do I access terminal and single user when booting from USB though?
 
  • Like
Reactions: AppleMacFinder
Just wondering what happens when we update the OS, will we be back to square one and have to modify the EFI prefs again to force the integrated graphics?
Theoretically this EFI variable fix is OS independent and should be working regardless of what you are doing with your OS, what OS you are using or installing/reinstalling/dualbooting. However, there is still a possibility that some PRAM / NVRAM / SMC reset , or if you discharge your MBP completely, etc... in short: under some circumstances the EFI variables could be reset to their default values, removing this fix. So it could be a good idea to print this instruction on paper or bookmark it at your web browser (from another device!), so that in case of a problem you will be able to quickly re-apply this EFI variable fix again

How do I access terminal and single user when booting from USB though?
Single user mode is OS X feature, you could use it only at OS X. Terminal (command line) is both OS X and Linux feature. Although their terminals are somewhat similar because of some common UNIX/Linux ancestry, the syntax and the capabilities of these terminals are very different! For example, I doubt that you could do this EFI variable fix while at OS X single user mode, and also - while at OS X, the SIP is limiting what you can do with your hardware...

So, while booting from Arch Linux LiveUSB, you are not using a "single user mode" feature, because it is OS X feature not a Linux feature. Instead, you are using a Linux terminal for root user, without any graphical interface, just a pure console
 
Last edited:
Ubuntu has a real root user, even at LiveCD, - you just need to set a password for him and then you are able to switch to him. See the commands in my previous message... But in any case Arch Linux is more convenient for performing this fix, Ubuntu may fail to load because of the failing GPU I disagree. Their hack on video - is operating system specific (e.g. doesn't work at OS X).
In comparison, EFI variable hack is universal - after EFI variable hack, any system should work fine! Did you skip a wrong command this time? (recently marked as "<----- skip this command" at my 1st message)
[doublepost=1491604985][/doublepost] As expected, gfxcardstatus doesn't work in this situation, only EFI variable fix works I think your main problem right now is corrupted HFS+ file system, corruption happened because of too many emergency shutdowns and filesystem became read-only. To repair your HFS+ filesystem you should either use another Mac or another computer with Linux (more tricky, described at the 1st post of this thread). After you repair it, you will get the write permissions

By the way, you could perform these removal operations instantly after repairing a filesystem, while your MBP's HDD is still inside the enclosure and is connected to another computer. Because, while HDD's OS X is shutdown, SIP is not blocking you! In short: while your MBP's HDD is connected to another computer, on this HDD there is no active SIP, and after the filesystem's repair - anything on this HDD should become writeable and removable

I did skip the command. In fact, I tried the command I was supposed to skip and then skipped it. I tried in Ubuntu and Arch Live. I got the same "Invalid argument" error.
 
I did skip the command. In fact, I tried the command I was supposed to skip and then skipped it. I tried in Ubuntu and Arch Live. I got the same "Invalid argument" error.
For which command you are now getting the "Invalid argument" error?
 
printf "\x07\x00\x00\x00\x01\x00\x00\x00" > /sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9

I get "Invalid argument" in both Arch Live and Ubuntu
 
printf "\x07\x00\x00\x00\x01\x00\x00\x00" > /sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9

I get "Invalid argument" in both Arch Live and Ubuntu
Probably it means that efivarfs filesystem is not mounted or mounted with read-only permissions.

Mount efivarfs filesystem with write permissions:
*) cd /
*) umount /sys/firmware/efi/efivars/
*) mount -t efivarfs rw /sys/firmware/efi/efivars/
*) cd /sys/firmware/efi/efivars/
 
Last edited:
I registred only to say thank you ! My dedicated graphic card just died a few days ago and I was looking to boot without it !!
Thanks again, everything in your tutorial is clear as cristal and easy to follow, the harder part was to find the right keys on the keyboard ^^

Again, thank you !!
 
  • Like
Reactions: AppleMacFinder
I registred only to say thank you ! My dedicated graphic card just died a few days ago and I was looking to boot without it !!
Thanks again, everything in your tutorial is clear as cristal and easy to follow, the harder part was to find the right keys on the keyboard ^^

Again, thank you !!
Everyone does realize that you can boot no problem when the adapter is not connected, as it defaults to the onboard graphics.
 
hey guys I'm slowly working through this,

I'm at the creating an arch linux installer stage from terminal.

"Copy the ISO
Now we can copy the converted image to the USB drive.

$ dd if=destination_file.img.dmg of=/dev/disk2 bs=1m

The dd command does not show any output before it has finished the copy process, so be patient and wait for it to complete. When the command does complete OS X will try to mount the drive and fail as it won't recognize the formatting. Click ignore or eject."


Ive attempted it as above but I'm getting an error

(removed)-MBP-2:~ (removed)$ dd if=/Users/(removed)/Downloads/destination_file.img.dmg of=/dev/disk2 bs=1m

dd: /dev/disk2: Permission denied
 
Ok I may have solved the above issue,

I seem to touching on a new one though.

The computer I'm using is a friends and as far as they know there is not password, terminal is requiring one for DD command.

Ideas?
 
Last edited:
  • Like
Reactions: AppleMacFinder
@AppleMacFinder I lost my fix again today. Something is happening in the background that removes this fix. I've been using the computer daily since the fix with NO problems - and I've installed no further OSX updates.

Today out of the blue it wouldn't play a netflix video, and I got an error code from netflix that there could be a problem with old info being stored in the browser, and the computer needed to be restarted. I did, and got my blue and white stripes back and then grey login screen with no further progression.

Any ideas what could be happening? I'm running Sierra 10.12.3

Decided to order this but I still need to keep this one up and running for a while before it can be installed:

https://www.aliexpress.com/item/DC-...0028-216-0810028-BGA-Chipset/32764872143.html
 
  • Like
Reactions: AppleMacFinder
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.