I have on a MacPro 3,1 a HD7770 which was not originally in it but brought later from Apple as an upgrade to be able to run FinalCut Pro.
Has somebody yet tested this card to work in High Sierra ???????????? Many thanks in advance for the info.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS High Sierra (10.13) Unsupported Macs Thread
- Thread starter foxlet
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
Has somebody yet tested this card to work in High Sierra ???????????? Many thanks in advance for the info.
Apple never sell officially The 7950 Mac edition.
It was possible to buy it at Amazon, OWC, and every good Apple Reseller ....
All you can do is try. Other people on other fora have reported the 5770 and 5780 as not currently working with HS in the early betas. But I would think Apple should support those cards. If you have one and it does not work, please send feedback to Apple using FA, assuming the MacPro is a supported model like the 5,1. They are not interested in feedback from the unsupported 3,1. My 5870 does not work in HS but is fine in Sierra and El Capitan.
Just patched beta 7 with dosdudes HS patcher 2.1.5. Tried to install onto a 2009 MBP 17" and got to error "..could not be installed on your computer. No packages were eligible for install"
Did I do something wrong? Everything worked up until that point.
Did I do something wrong? Everything worked up until that point.
Did you make a USB installer using a FULL download version of High Sierra beta 7 from Apple (about a 5 GB download) and dosdude1's patcher? Did you then boot successfully from that USB installer? Did you then attempt the install and got that message? If so, try going back to an earlier dosdude1 patch in the 1.x series because the latest patches are trying to fix APFS booting and may be buggy.
Yes to all of that. I take it the 1.x versions don't support APFS at all? I might wait a bit then.
Check your date and time. Sometimes, the wrong date and time can cause this to happen.
My two cents on the whole 'foxlet' vs. 'dosdude1' kerfuffle....
First, I also agree that this was better to be solved privately. That being said...
To foxlet, your work has played a large part in keeping useful but "obsolete" hardware in production for many of us who either didn't want to retire a useful machine or just didn't have the budget to get a new machine. And for that you have our collective thanks. But the right solution isn't to "take your marbles and go home". Some of us are wracking our old brains for how you accomplished all this which is great for me to keep sharp on my old Unix skills. Sometimes you may not know exactly how your efforts are affecting others. And I know you haven't earned a dime on this. If you want, start a tip jar somewhere and I'm sure that more than a few of us will contribute. I have two Mac Pro 3,1s still in production in my house happily running Sierra thanks to your work.
To dosdude1, you've also contributed mightily to this effort, not only solving key problems but making the utilities accessible to those of us who don't want to go through a byzantine series of steps to get this to work. And for that you also have the gratitude of the community. My only advice is to openly publish your work and make sure to acknowledge others in advance, even if it was a clue rather than code. That way when you participate in a collective effort like this, there are no misunderstandings.
I'm sure that if both of you actually lived and worked in the same place and saw each other face to face, this whole incident wouldn't have happened. But the Internet tends to depersonalize us (I've seen this since the 1980s) leading to misunderstandings. The older I get, the more I value interpersonal communication. I can't tell you how many times it's defused situations at my job that could have gotten ugly quickly if people weren't speaking regularly.
Thanks guys.
First, I also agree that this was better to be solved privately. That being said...
To foxlet, your work has played a large part in keeping useful but "obsolete" hardware in production for many of us who either didn't want to retire a useful machine or just didn't have the budget to get a new machine. And for that you have our collective thanks. But the right solution isn't to "take your marbles and go home". Some of us are wracking our old brains for how you accomplished all this which is great for me to keep sharp on my old Unix skills. Sometimes you may not know exactly how your efforts are affecting others. And I know you haven't earned a dime on this. If you want, start a tip jar somewhere and I'm sure that more than a few of us will contribute. I have two Mac Pro 3,1s still in production in my house happily running Sierra thanks to your work.
To dosdude1, you've also contributed mightily to this effort, not only solving key problems but making the utilities accessible to those of us who don't want to go through a byzantine series of steps to get this to work. And for that you also have the gratitude of the community. My only advice is to openly publish your work and make sure to acknowledge others in advance, even if it was a clue rather than code. That way when you participate in a collective effort like this, there are no misunderstandings.
I'm sure that if both of you actually lived and worked in the same place and saw each other face to face, this whole incident wouldn't have happened. But the Internet tends to depersonalize us (I've seen this since the 1980s) leading to misunderstandings. The older I get, the more I value interpersonal communication. I can't tell you how many times it's defused situations at my job that could have gotten ugly quickly if people weren't speaking regularly.
Thanks guys.
lol I'm dumb. I do this every time. It was the stupid date because I pulled the battery to clean the internals.
Thanks, I'm glad you see the situation from a much more reasonable perspective. What I don't like is the way way Foxlet brought this whole thing up, with essentially a long post making false accusations against me, without even so much as a private message to me first, claiming I've done things such as stealing code from his programs, some of which were never even released and I never even had access to. Heck, I didn't even know what he did to get APFS volumes to boot on unsupported Macs before doing hours worth of late-night research about the EFI shell, EFI drivers, and EFI shell scripting. All in all, I'd just like to ensure people in this thread understand that I'm not the type of person to steal somebody's work/code and pass it off as my own. Any program, code, or resource that I did not write or create, but use in my program, is credited to the author in the About window.
[doublepost=1504054286][/doublepost]I've just finished doing some work on the APFS booting method of High Sierra Patcher, and I think I've managed to get the issue of booting with multiple hard disks installed resolved. The changes have been added to the latest version of High Sierra Patcher, which is available here. @jhowarth, unfortunately the EFI shell is so limited, that it cannot even read from files into a variable. This prevented me from using a volume's UUID to determine the boot volume, so what I've done instead is placed an empty file, called "apfsboot", in the root of the APFS volume that should be booted. The EFI shell script will look for this file, which, when found, allows it to determine the device to boot from. I'm currently in the process of creating a PreferencePane for System Preferences to allow selection of the desired boot volume, which should help users who have more than one APFS volume with a macOS installation on a single drive. I've almost finished this, so I should be able to get it out in the next day or so.
Last edited:
Actually, I wasn't thinking of reading from the place keeper file on the EFI and / partitions but just have their filenames contain the embedded UUID. This file would be created at the APFS patching level so that shouldn't be an issue. So for my particular hardware configuration....
/dev/disk2 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *250.1 GB disk2
1: EFI EFI 209.7 MB disk2s1
2: Apple_APFS Container disk4 249.8 GB disk2s2
which resulted in a fs# entry of...
fs4 :HardDisk - Alias hd45c0a1 blk4
Acpi(PNP0A03,0)/Pci(1FI2)/Sata(2,0,0)/HD(Part1,Sig3B46F49B-BC50-4B9B-97FF-2A20E6472AF1)
for the EFI, the place keeper filename would be efi-boot-3B46F49B-BC50-4B9B-97FF-2A20E6472AF1 and the startup.nsh would search for it with code like...
for %m run (1 50)
if exist "fs%m:\EFI\efi-boot-3B46F49B-BC50-4B9B-97FF-2A20E6472AF1" then
if exist "fs%m:\EFI\apfs.efi" then
load fs%m:\EFI\apfs.efi
exit
else
if %m == 50 then
echo "apfs.efi file not found, exiting..."
endif
endif
endif
endfor
Likewise for the boot.efi, startup.nsh would use code like...
for %m run (1 50)
if exist "fs%m:\System\Library\CoreServices\system-boot-3B46F49B-BC50-4B9B-97FF-2A20E6472AF1" then
if exist "fs%m:\%apfsBootFile%" then
echo "Starting macOS..."
fs%m:\%macOSBootFile%
exit
else
if %m == 50 then
echo "Boot file not found, exiting..."
endif
endif
endif
endfor
This avoids any need of reading the UUID from files as it is hardcoded into the place keeper filenames themselves.
Of course, when APFS is re-applied, it should first purge any files at the proposed locations with the wildcard \EFI\efi-boot-* and \System\Library\CoreServices\system-boot-* to remove any stale place keepers files that might have been transferred when an existing APFS partition was cloned from one drive to another on an unsupported Mac.
Last edited:
Yeah, that's what I was trying to do. But, how does the EFI shell KNOW what the UUID it needs to look for is? I tried to do this by creating the same file in the EFI partition, but the issue is it is impossible to read the contents of a directory into a variable to see what the UUID it needs to look for is. This command: "if exist "fs%m:\System\Library\CoreServices\system-boot-3B46F49B-BC50-4B9B-97FF-2A20E6472AF1"" can't work without using a variable to store "3B46F49B-BC50-4B9B-97FF-2A20E6472AF1", after locating it and reading it from somewhere, which can't be done with the EFI shell.
[doublepost=1504056789][/doublepost]Oh! I see what you mean now. I should actually edit the SCRIPT based on the desired volume. That should actually work!
Yes. The UUID would become hardcoded into the filenames used and the installed startup.nsh script that looks for them when the APFS patching is applied to the particular drive.
Alright, just got the implementation done and uploaded! Give it a try and let me know how it works!
The first section of startup.nsh works correctly as apfs.efi is loaded and the mapping for the APFS volume is displayed but there is an error message immediately following...
Executing...
fs5:\System\Library\CoreServices\boot.efi
...boots the APFS HS volume as expected.
I was just building a new USB installer but will stop until this glitch is fixed. I'm planning to start over fresh with three SSDs with beta 8 and formatted APFS and the new post install patch and will then load them in MP 3,1 and see what happens.
The startup.nsh installed has...
echo -off
set StartupDelay 1
set -v efishellmode 1.1.2
set apfsBootUUIDdir "apfsbootuuid"
set macOSBootFile "System\Library\CoreServices\boot.efi"
set targetUUID "A43465F6-5134-3A38-A3D1-9171AAFB3C02"
for %i run (0 9)
if exist fs%i:\EFI\apfs.efi then
load fs%i:\EFI\apfs.efi
connect -r
map -u
endif
endfor
for %m run (0 9)
if exist "fs%m:\%apfsBootUUIDdir%\%targetUUID%" then
echo "Starting macOS..."
fs%m:\%macOSBootFile%
exit
endif
endfor
for %l in A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
if exist "fs%l:\%apfsBootUUIDdir%\%targetUUID%" then
echo "Starting macOS..."
fs%l:\%macOSBootFile%
exit
else
if %l == Z then
echo "Boot file not found, exiting..."
endif
endif
endfor
So it is barfing on...
if exist "fs%m:\%apfsBootUUIDdir%\%targetUUID%" then
Perhaps just drop trying to use so many variable substitutions and just repeat an explicit hard coding of the UUID
echo -off
set StartupDelay 1
set -v efishellmode 1.1.2
set apfsBootUUIDdir "apfsbootuuid"
set macOSBootFile "System\Library\CoreServices\boot.efi"
set targetUUID "A43465F6-5134-3A38-A3D1-9171AAFB3C02"
for %i run (0 9)
if exist fs%i:\EFI\apfs.efi then
load fs%i:\EFI\apfs.efi
connect -r
map -u
endif
endfor
for %m run (0 9)
if exist "fs%m:\%apfsBootUUIDdir%\%targetUUID%" then
echo "Starting macOS..."
fs%m:\%macOSBootFile%
exit
endif
endfor
for %l in A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
if exist "fs%l:\%apfsBootUUIDdir%\%targetUUID%" then
echo "Starting macOS..."
fs%l:\%macOSBootFile%
exit
else
if %l == Z then
echo "Boot file not found, exiting..."
endif
endif
endfor
So it is barfing on...
if exist "fs%m:\%apfsBootUUIDdir%\%targetUUID%" then
Perhaps just drop trying to use so many variable substitutions and just repeat an explicit hard coding of the UUID
Last edited:
Hmm, it says the error is in the if statement on line 15... Maybe try removing the quotes around "fs%m:\%apfsBootUUIDdir%\%targetUUID%" and see if that works?
I see the error now. You are erroneously assuming that the / partitions reside on fs# A-Z. That isn't the case here. While they might extend out to the alphabetical letters if you had enough drives and partitions, they start from where the EFI boot partitions left off. So on my machine, each AppleRAID-1 slice drive has both an EFI partition and an Apple_Boot partition while the third drive with the APFS volume only has the single EFI partition. This maps out to fs0 through fs4. After loading afps.efi, the mapping continues from fs5 through fs8 (where the boot.efi for the APFS / partition actually resides on fs5).