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.
It makes absolute sense that we should be able to switch to the integrated graphics to keep our systems going. Shame on Apple for not being proactive in this department, but what do you expect, they want you to buy a new Mac.

I don't think it makes sense to Apple to create a "solution" that leaves a Mac hobbled, in the sense that it won't be able to do things it should, like run an external monitor. But it's still an excellent-enough solution for many people who love their old machines.
 
What is the easiest way to explore the gpu-power-pref-... variable?
If there is one, do I begin the statement with "rm"?
If you would like to know the current contents of this variable, could use a command like hexdump - but I dont see any point in knowing the current contents, because: 1) while still at dynamic switching my mac didn't have this variable at all, so when you want to return to dynamic switching - you can just remove this variable 2) the values of this variable for two other possible states (integrated only, discrete only) are already known - https://github.com/0xbb/gpu-switch/blob/master/gpu-switch
So: while inside the /sys/firmware/efi/efivars you just type ls and then rm a current "gpu-power-pref-..." variable if there is any. Alternatively (if your screen is so distorted that it is difficult to see the letters) just start typing the rm gpu-power-pre and then press TAB key for autocompletion. Then you create a new variable with the instructions mentioned above
all that happens is that a sad smiley appears on the right side of the screen and the command line jumps down one step and it now says 1 root at the beginning
Sad smiley probably appeared because you got the same "operation not permitted" problem as the people above. Try to remount the efivarfs and repeat the instructions. Also would be great if you could try to see at least some words in addition to that smiley
I don't think it makes sense to Apple to create a "solution" that leaves a Mac hobbled, in the sense that it won't be able to do things it should, like run an external monitor
Do you know that there are adapters like USB to HDMI ? With these adapters you could still run an external monitor! Chinese people make all the kinds of adapters, so it is possible to convert almost any interface to some another. Probably even Apple sells this kind of adapter (but for a price thats like 5x times higher than the adapter's honest price)
Shame on Apple for not being proactive in this department, but what do you expect, they want you to buy a new Mac
Exactly! I posted a link for this instruction to the end of 900 pages long thread at Apple's official forums, and their mods removed it 24 hours later because of some "prohibited practices". Apple be like: "Helping other people to fix their "obsolete" Macs is prohibited because $$$ ! They should buy our new irrepairable Macs with the glued batteries, soldered RAM & SSD and a stupid touch bar!"
[doublepost=1490090057][/doublepost]
I esperienced the same problem using an Ubuntu Live 16.10 distribution and I solved the issue with the following steps:
totoe_84, thank you again for your valuable additions, I have added them to my original post while giving a credit to you
[doublepost=1490090406][/doublepost]
My system is still running fine, but I am not holding my breath on how long that it is going to remain this way
Good thing is that this instruction works after your discrete GPU has started to fail ! So you could enjoy your discrete GPU and maybe play some video games, while it lasts...
 
Last edited:
Sad smiley probably appeared because you got the same "operation not permitted" problem as the people above. Try to remount the efivarsfs and repeat the instructions. Also would be great if you could try to see at least some words in addition to that smiley

Thank you very much for responding. I've tried this now, but it still gives me the same result = sad smiley just sitting there looking sad.

One thing that crossed my mind is that my quotation marks looks more like the symbol for inch than quotes. I'm using a Swedish keyboard and I had to press nearly every button until I found it, it was located on one of the letters that are unique to the Swedish language while pressing the shift key.

I'm including a picture of it looks. Theres nothing on the right side except for the smiley.

I'm very grateful for your help, I've been looking for exactly this fix since my dGPU failed around two months ago.
 

Attachments

  • IMG_0798.JPG
    IMG_0798.JPG
    2.1 MB · Views: 2,666
  • Like
Reactions: AppleMacFinder
I've tried this now, but it still gives me the same result = sad smiley just sitting there looking sad
Hmmmm.... What will happen if you ignore that sad smiley and try following the next instructions after this command? Maybe I had this sad smiley too but it wasn't visible to me because of a very distorted screen. Please could you try the next steps like everything is OK ?

Make sure that you are using the correct quotes, if you can't obtain them by your mac's internal keyboard, connect the external USB keyboard to input this character. You need a standard ASCII symbol for the quotes, which could be found at US keyboard
 

Attachments

  • ASCII.png
    ASCII.png
    795 bytes · Views: 647
Last edited:
  • Like
Reactions: roberthallin
I also got the sad smiley, it did not seem to affect the rest of the process.

However, the changes do not seem to work after a shutdown and restart. I cannot get my macbook to boot up from a shutdown without going through the steps again. Is there a way round this?

I should add that when I try to reboot, I get the distorted screen. The progress bar moves along. At the end of the progress bar the screen appears to be normal (but grey and blank), after that, sometimes the machine tries to boot again, sometimes it just shuts down.
 
  • Like
Reactions: AppleMacFinder
Do you know that there are adapters like USB to HDMI ? With these adapters you could still run an external monitor! Chinese people make all the kinds of adapters, so it is possible to convert almost any interface to some another. Probably even Apple sells this kind of adapter (but for a price thats like 5x times higher than the adapter's honest price)

Well, if Chinese people make them, that's different! My point remains as before. Apple won't embrace a "solution" that limits the machine to below its full specs, including all the things a working dGPU will do. No, this isn't about Apple wanting people to buy new. They wouldn't have had a recall program in that case. Would have been a lot cheaper to offer a fix like yours.

That's not a reflection on the value of your work, which I think is great. I hope I won't need it, though!
 
  • Like
Reactions: AppleMacFinder
No, this isn't about Apple wanting people to buy new. They wouldn't have had a recall program in that case.

It was not much of a recall program. They simply replaced the logic boards with the same defective equipment, it was not a fix, it was merely a gesture to maybe hold off the impending law suits and it took them nearly 5 years before they even acknowledged the problem.

It was easy for them to offer this fix as they likely had logic boards left over that they never sold in the first place (they did not go out and make new ones that is for sure), so all it cost them was the time to do the replacement, a replacement that will also ultimately fail.

So yes, in my opinion they do want people to buy new, that is what they are all about…..selling things and making money for their shareholders.

I bet you believe in the easter bunny too…….just funning with you, don’t get all bent out of shape.

And yes, I am a VERY cynical person.
 
It was not much of a recall program. They simply replaced the logic boards with the same defective equipment, it was not a fix, it was merely a gesture to maybe hold off the impending law suits and it took them nearly 5 years before they even acknowledged the problem.

It was easy for them to offer this fix as they likely had logic boards left over that they never sold in the first place (they did not go out and make new ones that is for sure), so all it cost them was the time to do the replacement, a replacement that will also ultimately fail.

So yes, in my opinion they do want people to buy new, that is what they are all about…..selling things and making money for their shareholders.

I bet you believe in the easter bunny too…….just funning with you, don’t get all bent out of shape.

And yes, I am a VERY cynical person.

Early 2011 to early 2015, when the replacement program started, is four years. The replacement program cost them money, and as a direct means of getting people to buy new ones it made no sense to extend the life of the old ones. Of course they want people to buy new ones, but they know that won't happen if people think Apple won't stand behind them.
 
Hmm, another solution for the people that want to fix their old macs: reballing or reflowing the gpu with "good" solder OR switching the chip altogether with a new one. You can find different guys on ebay to which you can send your board and they reflow it/ change it.

But I also have to post the devil's opinion :D :D:

In case you didn't see it, this will void you warranty (if you still have one)
 
Dear friends, please stop discuss apple's behavior on this issue here, as well as other "solutions". There are huge threads elsewhere. Let's discuss THIS SOLUTION, how stable/reliable is it, personal experience of using it with different mbps.

Mine is 2011 A1297 mbp 8.3 17'. I don't want to invest in (potentially failing) hardware solutions and I cannot find more suitable laptop for my tasks (I need this 17' IPS screen, firewire for my focusrite, and osx apps, and btw modern laptops are not much faster). So software switch to igpu would be just perfect for me. I tried perhaps all known ways: overheat shutdown, gfxcardstatus, gpu-switch, ubuntu install. All software "switches" are failing from time to time, I guess osx has too many undocumented and/or uncontrollable ways to access dgpu when it is visible to it. Ubuntu works, but the software is far from the level of my needs. Windows efi mode, although igpu becomes visible in it, is still a deadlock. I tried to explore clover or some other bootloader with patched DSDT with excluded dgpu, but I cannot find any success stories and its too difficult for me.

So this solution, if it really works, is like the light at the end of the tunnel and I will definitely try it asap with hope. Thanks AppleMacFinder , you are great!
 
  • Like
Reactions: AppleMacFinder
I also got the sad smiley, it did not seem to affect the rest of the process.

However, the changes do not seem to work after a shutdown and restart. I cannot get my macbook to boot up from a shutdown without going through the steps again. Is there a way round this?

I should add that when I try to reboot, I get the distorted screen. The progress bar moves along. At the end of the progress bar the screen appears to be normal (but grey and blank), after that, sometimes the machine tries to boot again, sometimes it just shuts down.

If I were you, in this situation I would have tried repeating all the instructions but after cleaning the PRAM / NVRAM / SMC :
1) PRAM / NVRAM clean: https://support.apple.com/en-us/HT204063
2) SMC clean: https://support.apple.com/en-us/HT201295
Probably something in your software configuration is somehow resetting/locking these variables, and you should retry everything in a "clean" way - after all the possible kinds of software resets! (except the OS reinstallation of course) . If nothing helps, also try removing the AMD drivers from your OS X before repeating the steps - the procedure of their removal is described at my 1st lengthy post (although I doubt that it would influence the results, at this point I would have tried ALL the possible options)
 
Last edited:
Unfortunately, the solution as presented here does not work for me. I followed every step but after the reboot I still have a hanging MBP. I have created exactly the same gpu-power-prefs file (gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9). What I also did was doing a PRAM/NVRAM + SMC reset as suggested above. After doing this, all gpu-power-prefs-xxx files are deleted. After creating a new one, unfortunately, I still have a solid Apple logo with a progress bar halfway.

It is good news that by using this Linux distribution we can change things, but for my computer (and most probably others as well) apparently we need to find something else... Just to be sure:
  • do we need to delete the other files gpu-... files like cpu-active- ... as well? (I didn't do this)
  • the statement printf "\x07\x00\x00\x00\x01\x00\x00\x00" > /sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9 creates a file, but this is an empty one. Is that correct? (since you printf something)
  • what does chattr -i "/sys/firmware/efi/efivars/" 2> /dev/null do? I have a gpu-power-pref file. Don't I need to point to that specific file?
Thanks for the good work. I really do hope that a solution via this route can be found soon!
 
  • Like
Reactions: AppleMacFinder
Do we need to delete the other files gpu-... files like cpu-active- ... as well? (I didn't do this)
No, these other files need to stay. Because if you delete them there is a possibility that it will screw up your system (to a point where a EFI reflash with external hardware programmer will be needed)
The statement printf "\x07\x00\x00\x00\x01\x00\x00\x00" > /sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9 creates a file, but this is an empty one
This printf outputs some hexdata into gpu-power-prefs-... file, this hexdata is not made of ASCII printable symbols and therefore it will either be invisible or visible as garbage - if you try to output it via cat command like you normally do to a regular text file. So to check this file you need to use some command like hexedit or hexdump (whatever is available at this LiveCD system. If this file is still empty, maybe you did something wrong
what does chattr -i "/sys/firmware/efi/efivars/" 2> /dev/null do? I have a gpu-power-pref file. Don't I need to point to that specific file?
Very good question! I just looked up what chattr command does and here are the results:

http://www.tecmint.com/chattr-command-examples/ - chattr (Change Attribute) is a command line Linux utility that is used to set/unset certain attributes to a file in Linux system to secure accidental deletion or modification of important files and folders, even though you are logged in as a root user.
...
Syntax of chattr ---> chattr [operator] [flags] [filename]
...
A file is set with ‘i‘ attribute (-i as you see in this command) ---> cannot be modified (immutable). Means no renaming, no symbolic link creation, no execution, no writable, only superuser can unset the attribute.
...

So: if I understand it correctly, this chattr command is supposed to lock a /sys/firmware/efi/efivars/ directory to make it accessible only by "superuser" and so that while booting your EFI will not change these variables - in particular, will not screw up a gpu-power-prefs-... variable

Then, 2> /dev/null (which I should have deleted from this instruction, will do it now) is hiding the errors from the user - which was OK for a script, but does more harm than good for a single command.

Please re-try this chattr command without "2> /dev/null" at the end, just chattr -i "/sys/firmware/efi/efivars/" , because there is probably an error happening while you are doing this command. And tell us what is the error that's happening. Also (important!) run chattr +i "/sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9" before unmounting/rebooting and tell us the results
[doublepost=1490273983][/doublepost]
I also got the sad smiley, it did not seem to affect the rest of the process. However, the changes do not seem to work after a shutdown and restart

Hi magicaltrevor70 , please read my post above, repeat the instructions without "2> /dev/null",
also run chattr +i "/sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9" before unmounting/rebooting and tell us the results
[doublepost=1490275888][/doublepost]=== I IMPROVED MY INSTRUCTION AT THE FIRST MESSAGE OF THIS THREAD. PLEASE REPEAT IT ! ===
 
Last edited:
No, these other files need to stay. Because if you delete them there is a possibility that it will screw up your system (to a point where a EFI reflash with external hardware programmer will be needed)

This printf outputs some hexdata into gpu-power-prefs-... file, this hexdata is not ASCII printable symbols and therefore it will either be invisible or visible as garbage - if you try to output it via cat command like you normally do to a regular text file. So to check this file you need to use some command like hexedit or hexdump (whatever is available at this LiveCD system. If this file is still empty, maybe you did something wrong

Very good question! I just looked up what chattr command does and here are the results:

http://www.tecmint.com/chattr-command-examples/

chattr (Change Attribute) is a command line Linux utility that is used to set/unset certain attributes to a file in Linux system to secure accidental deletion or modification of important files and folders, even though you are logged in as a root user.

Syntax of chattr
chattr [operator] [flags] [filename]
...
A file is set with ‘i‘ attribute (-i as you see in this command) ---> cannot be modified (immutable). Means no renaming, no symbolic link creation, no execution, no writable, only superuser can unset the attribute.
...

So: if I understand it correctly, this chattr command is supposed to lock a /sys/firmware/efi/efivars/ directory to make it accessible only by "superuser" and so that while booting your EFI will not change these variables - in particular, will not screw up a gpu-power-prefs-... variable

Then, "2> /dev/null" (which I should have deleted from this instruction, will do it now) is hiding the errors from the user - which was OK for a script, but does more harm than good for a single command.

Please re-try this chattr command without "2> /dev/null" at the end, just chattr -i "/sys/firmware/efi/efivars/" , because there is probably an error happening while you are doing this command. And tell us what is the error that's happening
[doublepost=1490273983][/doublepost]

Hi magicaltrevor70 , please read my post above, repeat the instructions without "2> /dev/null",
also run chattr -i "/sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9"
before rebooting and tell us the results
[doublepost=1490275888][/doublepost]=== I IMPROVED MY INSTRUCTION AT THE FIRST MESSAGE OF THIS THREAD. PLEASE REPEAT IT ! ===


Hi AppleMacFinder,
Thanks for your prompt reply. If I leave out the >2 /dev/null I indeed get an error:

chattr: Inappropriate ioctl for device while reading flags on /sys/firmware/efi/efivars

I don't know what this means, but perhaps this is the beast we are looking for ;-)
 
  • Like
Reactions: AppleMacFinder
Hi AppleMacFinder,
Thanks for your prompt reply. If I leave out the >2 /dev/null I indeed get an error:

chattr: Inappropriate ioctl for device while reading flags on /sys/firmware/efi/efivars

I don't know what this means, but perhaps this is the beast we are looking for ;-)
Probably this command does not work for directories and I did it by mistake.
After you run printf "\x07\x00\x00\x00\x01\x00\x00\x00" > /sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9 command, please also run chattr +i "/sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9" before unmounting/rebooting . It is supposed to lock this variable so that EFI can't screw it up even if it wants. Waiting for your test results ;)
 
Last edited:
Probably this command does not work for directories and I did it by mistake.
After you run printf "\x07\x00\x00\x00\x01\x00\x00\x00" > /sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9 command, please also run chattr -i "/sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9" before unmounting/rebooting . It is supposed to lock this variable so that EFI can't screw it up even if it wants. Waiting for your test results ;)

But the chattr on that file was already in your manual, and that did not work. Or did you just add this single line?
[doublepost=1490282368][/doublepost]
Probably this command does not work for directories and I did it by mistake.
After you run printf "\x07\x00\x00\x00\x01\x00\x00\x00" > /sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9 command, please also run chattr -i "/sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9" before unmounting/rebooting . It is supposed to lock this variable so that EFI can't screw it up even if it wants. Waiting for your test results ;)
I think you need to do chattr +i to add this attribute (not -i). I'll give it a try and let you know
 
  • Like
Reactions: AppleMacFinder
But the chattr on that file was already in your manual, and that did not work. Or did you just add this single line?
There were no "chattr" line in my manual against this file, there was only a probably incorrect "chattr" line against efivars directory. Now in my instruction there are both lines: "chattr" against a directory (which is probably incorrect) and "chattr" against a file. Please run "chattr" against a file before unmounting/rebooting
I think you need to do chattr +i to add this attribute (not -i). I'll give it a try and let you know
No, this is a standard way of command line Linux arguments. +i would not work, -i is a way to go (- does not mean a minus there)
 
Probably this command does not work for directories and I did it by mistake.
After you run printf "\x07\x00\x00\x00\x01\x00\x00\x00" > /sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9 command, please also run chattr -i "/sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9" before unmounting/rebooting . It is supposed to lock this variable so that EFI can't screw it up even if it wants. Waiting for your test results ;)
Unfortunately, +i and -i both do not work. Both stuck at the Apple logo... This is what I did, just to summarise:

*) reset NVRAM/PRAM/SMC

*) startup with Linux CD-ROM (after years I had to find out how to burn a CD again...)

*) umount /sys/firmware/efi/efivars/


*) mount –t efivarfs rw /sys/firmware/efi/efivars/

*) chattr -i /sys/firmware/efi/efivars/gpu-power-prefs-[press TAB to autocomplete]

*) rm /sys/firmware/efi/efivars/gpu-power-prefs-[press TAB to autocomplete]

*) printf "\x07\x00\x00\x00\x01\x00\x00\x00" > /sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9

*) chattr -i “/sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9"

(or +i to see whether this makes a difference)

*) cd /

*) umount /sys/firmware/efi/efivars/

*) reboot

But no luck :-(

[doublepost=1490285015][/doublepost]
There were no "chattr" line in my manual against this file, there was only a probably incorrect "chattr" line against efivars directory. Now in my instruction there are both lines: "chattr" against a directory (which is probably incorrect) and "chattr" against a file. Please run "chattr" against a file before unmounting/rebooting
No, this is a standard way of command line Linux arguments. +i would not work, -i is a way to go (- does not mean a minus there)

chattr can be used with a plus sign:

# chattr [operator] [flags] [filename]

flag:
i : A file is set with ‘i‘ attribute, cannot be modified (immutable). Means no renaming, no symbolic link creation, no execution, no writable, only superuser can unset the attribute.

Operator:
+ : Adds the attribute to the existing attribute of the files.
– : Removes the attribute to the existing attribute of the files.
= : Keep the existing attributes that the files have.
 
  • Like
Reactions: AppleMacFinder
Unfortunately, +i and -i both do not work. Both stuck at the Apple logo...
How this screen with Apple logo looks like - normal gray screen, or a heavily distorted screen that is ruined by a failing discrete GPU ?
chattr can be used with a plus sign:
Thanks for this discovery, looks like I was incorrect... After learning this I was going to offer you to put "+i" for this file before rebooting, but looks like even that didn't help you. But we could check more things: e.g. after noticing that even +i before reboot didn't help you, you boot again to Arch LiveCD and with a hexdump please check if the hex values of this variable have been changed. Maybe EFI somehow screwing up the things for you. After that you can remove this variable completely, reboot a few times, reset all the things, then add it again and repeat everything
 
How this screen with Apple logo looks like - normal gray screen, or a heavily distorted screen that is ruined by a failing discrete GPU ? Thanks for this discovery, looks like I was incorrect... After learning this I was going to offer you to put "+i" for this file before rebooting, but looks like even that didn't help you. But we could check more things: e.g. after noticing that even +i before reboot didn't help you, you boot again to Arch LiveCD and with a hexdump please check if the hex values of this variable have been changed. Maybe EFI somehow screwing up the things for you. After that you can remove this variable completely, reboot a few times, reset all the things, then add it again and repeat everything

No succes. Tried everything, but still a frozen MBP. By the way: I cannot make a hex dump of the file, it gives me "Invalid argument" all the time. On my other Mac this just works, just like xxd or od.

hexdump gpu-power-prefs-....

xxd gpu-power-prefs....

During startup of Linux I get two times the error message : **ERROR* no UMS support in radeon module. But I guess this is due to the fact that you change the gpu-power variable.

The size of the gpu-power-prefs file is "4" (I can see this by doing ls -la)

Another finding: if I do chattr -i (and not +i) and reboot the system the progress bar under the Apple logo moves to about 55%. After 30 seconds, the MBP shuts down by itself. If I do chattr +i, however, the progress bar under the Apple logo goes until say 40%. I am not sure whether this is important, but you never know
 
  • Like
Reactions: AppleMacFinder
I really don't know what I'm doing in terminal :(
I'm currently trying to make a boot disk on my macair to use on the 17in MBP

https://forums.macrumors.com/threads/17-in-mbp-wont-load-replaced-ssd-not-sure-what-to-do.2038073/

I'm currently at this step:

sudo dd if=path/to/arch.iso of=/dev/rdisk2 bs=1m

Does this mean I need to replace the "path" with the actual path to the .iso file to make it look like this:

sudo dd if=Macintosh HDM/Users?HOME1/Desktop/to/arch.iso of=/dev/rdisk2 bs=1m

At this point I'm just copying and pasting off this guide:

https://wiki.archlinux.org/index.php/USB_flash_installation_media#In_macOS
 
I really don't know what I'm doing in terminal :(
I'm currently trying to make a boot disk on my macair to use on the 17in MBP

https://forums.macrumors.com/threads/17-in-mbp-wont-load-replaced-ssd-not-sure-what-to-do.2038073/

I'm currently at this step:

sudo dd if=path/to/arch.iso of=/dev/rdisk2 bs=1m

Does this mean I need to replace the "path" with the actual path to the .iso file to make it look like this:

sudo dd if=Macintosh HDM/Users?HOME1/Desktop/to/arch.iso of=/dev/rdisk2 bs=1m

At this point I'm just copying and pasting off this guide:

https://wiki.archlinux.org/index.php/USB_flash_installation_media#In_macOS
Just download the iso under OSX on your Air and install the USB there?
 
Just download the iso under OSX on your Air and install the USB there?
That's what I'm trying to do, but the instructions force an unmount of the USB before the install, and it's all got to be done through terminal, from what I'm reading.

?
 
No success. Tried everything, but still a frozen MBP. By the way: I cannot make a hex dump of the file, it gives me "Invalid argument" all the time. On my other Mac this just works, just like xxd or od.
Maybe you are doing something wrong, because Mac and Linux command lines are different... But here is easy workaround for you:
1) prepare a second USB drive, format it to FAT32 and plug it to your MBP together with a first USB drive (which contains Arch Linux)
2) after booting to Arch Linux, mount this second USB drive to some mount point, for example:
mount -t msdos /dev/sdXN /mnt/
where X is a drive letter, N is a partition number. If have some problems, search in the Internet for tutorials
3) copy gpu-power-prefs-... file to this second USB drive, unmount it, plug it to another PC and view the contents of file with a hexdump
During startup of Linux I get two times the error message : **ERROR* no UMS support in radeon module
This is a normal message, I have been getting it even on the "not-yet-changed" Mac...
So this error does not indicate that your MBP feels this variable change. There should be some visible changes, like MBP's screen becoming normal again while booting! If there are no visible changes after changing the EFI variable, it means that somehow the EFI variable has not been loaded and we accidentally did something wrong...
Another finding: if I do chattr -i (and not +i) and reboot the system the progress bar under the Apple logo moves to about 55%. After 30 seconds, the MBP shuts down by itself. If I do chattr +i, however, the progress bar under the Apple logo goes until say 40%. I am not sure whether this is important, but you never know

By the way you could try completely removing the AMD drivers from your MBP - this is described at my first message. Of course that will not fix a display of your Mac, but at least it will boot every time. And (although unlikely) this may somehow impact your success with EFI variable
[doublepost=1490299287][/doublepost]
I really don't know what I'm doing in terminal :(
If you have the problems with terminal, you could just find a PC with windows and use Rufus utility to create Arch Linux bootable USB - https://rufus.akeo.ie/ , https://wiki.archlinux.org/index.php/USB_flash_installation_media#Using_Rufus . It is really straightforward

I'm currently at this step: sudo dd if=path/to/arch.iso of=/dev/rdisk2 bs=1m . Does this mean I need to replace the "path" with the actual path to the .iso file to make it look like this: sudo dd if=Macintosh HDM/Users?HOME1/Desktop/to/arch.iso of=/dev/rdisk2 bs=1m
Almost. if=input device or file (in this case, ISO file) . of=output device or file (in this case USB drive) . So you also need to choose a correct path to your USB drive. "of" value is VERY IMPORTANT, because if you accidentally choose a Macbook's HDD device path instead of USB drive device path - that will screw up your partition table and you can lose all your data from Macbook's HDD !

So, if you never worked in a terminal before, I recommend you to just find a Windows PC and use Rufus, for your own safety
 
Last edited:
Thanks for this; saved me lots of time. Created an account just to comment.

After disabling the dGPU using Arch, normal boot would hang halfway. Although safe boot would work. I wound up having to remove all the AMD kext files in the Terminal in Recovery Console.

Trying to remove them in Single User just gave me sandbox errors.

I also have FileVault, which required an unlock first.
Boot into Recovery.
Start Terminal.
diskutil cs list (find UUID for drive)
diskutil coreStorage unlockVolume UUID
cd /Volumes/Macintosh\ HD
mkdir AMD_Kexts
mv System/Library/Extensions/AMD*.* AMD_Kexts/
reboot
 
  • Like
Reactions: AppleMacFinder
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.