For me (MacBook5,1 with SSD, patcher 2.1.5), first clicking "Unmount" for the primary drive
in Disk Utility when booted from a USB stick allowed for APFS conversion.
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
For me (MacBook5,1 with SSD, patcher 2.1.5), first clicking "Unmount" for the primary drive
in Disk Utility when booted from a USB stick allowed for APFS conversion.
Can anyone with this new apfs boot method working correctly tell me - what files and folders do you have on the EFI partition of that disk?
I’m interested only in what the patcher tool put there; please skip anything you’ve added manually, if you did.
I’m interested only in what the patcher tool put there; please skip anything you’ve added manually, if you did.
1) make sure you are only using a single APFS patched drive on your machine as multiple ones don't co-exist yet.
2) for a removable drive, you will have to use 'sudo diskutil mount disk#s1' to mount the EFI partition on the removable drive (replacing the # with the correct disk id number for that drive).
3) in the mounted EFI at /Volumes/EFI, delete apfs.efi file that is erroneously renamed EFI and use 'mkdir EFI' to make the required directory.
4) Reapply the APFS patches to the removable drive with the APFS partition.
This will produce a usable APFS boot on the removable drive but it is fragile in that if you ever attach any other drives with patched APFS partitions, the wrong startup.nsh may be used causing the removable drive to no longer boot but the first alternative APFS drive it finds startup,nsh on.
[doublepost=1504179762][/doublepost]Here you are roziek.
[doublepost=1504180001][/doublepost]Before you install macOS to the SSD, REMOVE all other disks from the system.
Then use DU in the USB installer to partition the target SSD to HFS+. Then partition it again to APFS. Then run DU First Aid on it and check its health. If it passes, run the macOS install. Then reboot from the USB installer and run the post-install. Good luck.
It looks like...
https://community.hpe.com/hpeb/attachments/hpeb/hpsc.../efi_shell_cmnd_1_1.pdf
might be the best reference guide to use as it matches the Apple EFI version. I have been using 'dmpstore -b' in the startup.nsh in an attempt to discover what UUID the startup.nsh thinks it has been booted from. So far I haven't made much headway as their are entries named ':efi-boot-device' and ':efi-boot-device-date' which appear to be prefixed with the same UUID number but that UUID doesn't seem to exist for any partition on my drives.
I think we should focus on trying to see if there resides in the EFI shell environmental a fingerprint for which UUID the boot selector thought it was using. If the proper UUID survives from the boot selector in any EFI environmental, we should be able to use that to check for the appropriate EFI and / partitions using the UUID named placekeeper file approach.
https://community.hpe.com/hpeb/attachments/hpeb/hpsc.../efi_shell_cmnd_1_1.pdf
might be the best reference guide to use as it matches the Apple EFI version. I have been using 'dmpstore -b' in the startup.nsh in an attempt to discover what UUID the startup.nsh thinks it has been booted from. So far I haven't made much headway as their are entries named ':efi-boot-device' and ':efi-boot-device-date' which appear to be prefixed with the same UUID number but that UUID doesn't seem to exist for any partition on my drives.
I think we should focus on trying to see if there resides in the EFI shell environmental a fingerprint for which UUID the boot selector thought it was using. If the proper UUID survives from the boot selector in any EFI environmental, we should be able to use that to check for the appropriate EFI and / partitions using the UUID named placekeeper file approach.
jhowarth,
Did you see the results of the testing with two internal SSDs you requested. Any ideas?
R
Did you see the results of the testing with two internal SSDs you requested. Any ideas?
R
As I posted earlier, I think the most obvious path forward is to try to find an EFI environmental that contains the actual UUID of the partition that EFI boot selector thought it was using. If we can find an EFI environmental that remains correctly set for the desired drive, then we should be able to use that UUID value within a universal startup.nsh shell script that relies on reading the EFI environment for the UUID rather than hard-coding it.
@jhowarth @nekton1 Thanks guys! Not my first rodeo, though 
.
So: all disks unplugged, aside from the one I’m actually installing and testing HS on, obviously.
Also, I’m always doing a fresh install, and I’m always partitioning the disk beforehand, to start clean and without any leftovers that could cause some conflicts.
What the patcher tool puts in my EFI partition does not match what you have in there. I only have the EFI executable and the startup.nsh in there, like so:
In the root of my High Sierra install I have the required apfsbootuuid folder with a file in it named after the Volume UUID of that High Sierra volume (they match), like so:
So clearly, at some point, something goes wrong for some reason and the patcher does not save all the required stuff on my EFI partition.
And hence, the startup.nsh is never run on boot, nor does the EFI Boot appear on the boot selection screen. Been like that through v2.1.3 and PB6 to v2.1.9 and PB7.
.So: all disks unplugged, aside from the one I’m actually installing and testing HS on, obviously.
Also, I’m always doing a fresh install, and I’m always partitioning the disk beforehand, to start clean and without any leftovers that could cause some conflicts.
What the patcher tool puts in my EFI partition does not match what you have in there. I only have the EFI executable and the startup.nsh in there, like so:
In the root of my High Sierra install I have the required apfsbootuuid folder with a file in it named after the Volume UUID of that High Sierra volume (they match), like so:
So clearly, at some point, something goes wrong for some reason and the patcher does not save all the required stuff on my EFI partition.
And hence, the startup.nsh is never run on boot, nor does the EFI Boot appear on the boot selection screen. Been like that through v2.1.3 and PB6 to v2.1.9 and PB7.
Alright, I see what the issue is now with multiple volumes... The EFI shell is just loading the first startup.nsh it sees, NOT the one on the device booted from. To work around this, I'm going to use that system preferences PrefPane I posted earlier. I'm going to make it edit ALL startup.nsh files on ANY drive to point to the desired UUID, preventing the chance it starts up from the wrong UUID. I know this is somewhat of a hackjob solution, but due to the extremely limited nature of the EFI shell, it's about all that can be done. At some point I may try to see if I can write my own EFI program instead of using a shell script, but for now I'm going to try to get this to work.
That is the glitch I previously described in how the current 2.1.9 High Sierra Patcher handles APFS patching removable media. It currently isn't savvy to the fact that Apple only installs an EFI sub-directory on the EFI partitions of non-removable media. So when the APFS patch attempts to copy files to the missing sub-directory, it erroneously ends up renaming apfs.efi as EFI instead. The work-around is to mount the problematic EFI partition on the removable media, delete the EFI file (which actually a misnamed apfs.efi) and create the missing EFI directory with mkdir in its place. Now when you reapply the APFS patches from 2.1.9, the ABFS partition on the removable media will be bootable (as long as it is the only APFS volume on your system).
[doublepost=1504187481][/doublepost]
Are we absolutely sure yet that none of the variables returned by 'dmpstore -b' has the original UUID from the 'EFI boot' selected originally in the boot selector? I know we will see the nvram values for the boot UUID set by the Startup Disk preference panel but I am still hoping that somewhere in that mess there is a copy of the UUID that was originally invoked in the boot selector. If we can get our hands on that UUID from within the script via that environmental, I think we have an entry point into getting onto the correct boot drive.
Last edited:
I must have missed that, but fortunately I figured this out minutes ago
.Although, I do not use any removable media. All those disks are internal SATA disks, so, strange.
Just updated the tool to resolve that issue.I must have missed that, but fortunately I figured this out minutes ago
Although, I do not use any removable media. All those disks are internal SATA disks, so, strange.
[doublepost=1504188913][/doublepost]
That's actually what I was originally going to do, but the issue arises due to the limitations of the EFI shell itself. It is impossible (at least, based on all the Googling and research I've done) to store the output of a command into a variable. Because of that, even if dmpstore was able to return the values needed, it would be impossible to do anything with them.
I must have missed that, but fortunately I figured this out minutes ago
Although, I do not use any removable media. All those disks are internal SATA disks, so, strange.
From what I could glean from the available documentation, Apple normally uses the EFI directory to contain an APPLE/EXTENSIONS subdirectory for holding Firmware.scap to apply firmware patches. I did find that whole idea curious as it seemed like it would be fragile moving drives between machines with wildly differnet EFI firmware revisions.
[doublepost=1504190420][/doublepost]
I have been using...
https://community.hpe.com/hpeb/attachments/hpeb/hpsc-46/2667/1/efi_shell_cmnd_1_1.pdf
as my reference and from that documentation, it would seem that anything you can see from 'dmpstore -b; should be capable of being used just like any variables you set yourself like...
set apfsBootFile "apfsboot"
by referencing the environmental variable sandwiched between percentage symbols. IMHO, the real question is whether the boot process leaves behind any environmental with the UUID selected in the boot selector at all.
I deliberately got 2x 2009 17" MBPs because I was told that the 2010+2011 MBPs all have a serious hardware flaw that will kill the GPU in a few years and no one is really offering a repair solution for them. You see repair shops offering re-balling for the 2010/2011s but again I've been told this is band aid and they'll keep failing because some components are not the right spec on the main board. If someone were to offer a long term fix for them I'd jump on a 2011 17".
Well I would expect we just don't have the syntax quite right as it seems really illogical for the EFI shell to not allow those to be accessed in some form. There is a UEFI-boot IRC channel. It might be useful for one of us to pop over there and see if they have any insights on the details of accessing EFI environmental s within the EFI shell. Who knows... they might even have some insights on the startuo,nsh problem.
Ah, I think I just figured out the problem! startup.nsh needs to be located in the /EFI/BOOT directory of the ESP, NOT in the root. Try moving it to that located on both disks, and see if it then loads the correct file.
Happy to report that it's finally working on my Mac Pro 3,1. APFS installation, all disks plugged in, High Sierra 17A352a, patcher v2.2.0.
TRIM via sudo trimforce enable works too.
Will now try installation on APFS Encrypted.
TRIM via sudo trimforce enable works too.
Will now try installation on APFS Encrypted.
Can someone explain in semi laymans terms how APFS booting/bootstrapping works on unsupported Macs as opposed to natively supported Macs?
On supported machines, Apple issued a firmware update to allow the system's EFI firmware to detect and boot from APFS volumes. Unsupported machine, of course, did not get that firmware update. Because of this, in order to boot from an APFS partition, an APFS driver must be loaded through different means. Luckily, Apple provides this APFS driver in the form of "apfs.efi", located in the /usr/standalone/i386 folder on every High Sierra install. Using an EFI shell, this driver can be loaded, allowing the EFI shell to map and load APFS volumes, then from there the necessary volume can be located. Then, all that needs to be done from that point is the /System/Library/CoreServices/boot.efi file needs to be called from the EFI shell, which begins the macOS booting process.
Just an update on the iCloud login and iMessage/Facetime in virtualization (i.e., a non-standard Mac environment). This had the same problems as unsupported Macs in Developer Release 7 and before. In Developer Release 8, it works now. in VMWare Fusion 8.58. So as I surmised earlier, it was a bug and likely not an intentional situation. Perhaps the workaround dosdude1 came up with is no longer necessary.
Nah dude, it was really necessary... I tried it with several betas developer and public, and they all went stupid on APFS with that first helper partition with iMessage FaceTime...
So it’s a relief to see that we have everything working nice and smooth✌
So, the results.
Installation on APFS Encrypted went fine. After the reboot, before you can apply the post install patches, you need to unlock the volume first in terminal via diskutil apfs unlockVolume /dev/diskXsY. After that, the patcher can see the volume and apply the patches. It did it without complaining. I checked afterwards and it worked properly: everything needed on the EFI partition was there, same for the apfsbootuuid folder in the root of my High Sierra disk.
But as probably could be expected, startup.nsh was unforunately not able to boot it, because it can't find the boot file, and it can't because the volume at that point is locked/encrypted.
@dosdude1 Do you think a solution here is possible? Can you unlock the volume from the EFI shell? Ask the user for the passphrase? Or is the EFI shell too limited for that.
That was all done by formatting the disk as APFS Encrypted first and then installing High Sierra on it.
Now I'm going to try installing on a normal, not encrypted APFS, and then turning on the FileVault 2. We'll see what happens.
This workaround is a better solution to the APFS boot problem, though, as it avoids creating unnecessary helper boot partitions for every bootable APFS High Sierra volume you have. So we have working FaceTime/iMessage and a better APFS boot method. We should stick to it.
Installation on APFS Encrypted went fine. After the reboot, before you can apply the post install patches, you need to unlock the volume first in terminal via diskutil apfs unlockVolume /dev/diskXsY. After that, the patcher can see the volume and apply the patches. It did it without complaining. I checked afterwards and it worked properly: everything needed on the EFI partition was there, same for the apfsbootuuid folder in the root of my High Sierra disk.
But as probably could be expected, startup.nsh was unforunately not able to boot it, because it can't find the boot file, and it can't because the volume at that point is locked/encrypted.
@dosdude1 Do you think a solution here is possible? Can you unlock the volume from the EFI shell? Ask the user for the passphrase? Or is the EFI shell too limited for that.
That was all done by formatting the disk as APFS Encrypted first and then installing High Sierra on it.
Now I'm going to try installing on a normal, not encrypted APFS, and then turning on the FileVault 2. We'll see what happens.
This workaround is a better solution to the APFS boot problem, though, as it avoids creating unnecessary helper boot partitions for every bootable APFS High Sierra volume you have. So we have working FaceTime/iMessage and a better APFS boot method. We should stick to it
.
I don't think the current implementation will be able to boot from an encrypted volume. I may have an idea of a solution that may work, but it'll take a bit to implement. See, I believe when you encrypt the APFS volume, the system will resort to loading boot.efi from the "Preboot" partition. If I just edit the script to look for that if the volume is encrypted, it should work, but would also add more complications that I don't want to deal with until we ensure the current method boots non-encrypted APFS volumes reliably.So, the results.
Installation on APFS Encrypted went fine. After the reboot, before you can apply the post install patches, you need to unlock the volume first in terminal via diskutil apfs unlockVolume /dev/diskXsY. After that, the patcher can see the volume and apply the patches. It did it without complaining. I checked afterwards and it worked properly: everything needed on the EFI partition was there, same for the apfsbootuuid folder in the root of my High Sierra disk.
But as probably could be expected, startup.nsh was unforunately not able to boot it, because it can't find the boot file, and it can't because the volume at that point is locked/encrypted.
@dosdude1 Do you think a solution here is possible? Can you unlock the volume from the EFI shell? Ask the user for the passphrase? Or is the EFI shell too limited for that.
That was all done by formatting the disk as APFS Encrypted first and then installing High Sierra on it.
Now I'm going to try installing on a normal, not encrypted APFS, and then turning on the FileVault 2. We'll see what happens.
This workaround is a better solution to the APFS boot problem, though, as it avoids creating unnecessary helper boot partitions for every bootable APFS High Sierra volume you have. So we have working FaceTime/iMessage and a better APFS boot method. We should stick to it