macOS High Sierra (10.13) Unsupported Macs Thread

[dosdude1]

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).

But it's erroring out in the portion where the numerical fsX are being checked. It shouldn't even reach the alphabetical portion if it finds the file in a numerical volume. Besides, the exact same comparison works on my machine without an issue, which has the APFS volume on fs1:.

 

[jhowarth]

Also, I think you may want to implement the use of a efi-boot-<UUID> peacekeeper on the EFI partition as I originally suggested. Currently you are using the very first apfs.efi you find irregardless of whether it resides on the same physical drive as the APFS partition you are trying to mount. This might cause weirdness when you have more than one physical drive with an APFS partition.
[doublepost=1504066471][/doublepost]

But it's erroring out in the portion where the numerical fsX are being checked. It shouldn't even reach the alphabetical portion if it finds the file in a numerical volume. Besides, the exact same comparison works on my machine without an issue, which has the APFS volume on fs1:.

My mistake. I assume it may not like two variable substitutions on the same line. Why not try getting rid of the targetUUID variable and just hard coding the UUID value throughout the script.

 

[dosdude1]

Also, I think you may want to implement the use of a efi-boot-<UUID> peacekeeper on the EFI partition as I originally suggested. Currently you are using the very first apfs.efi you find irregardless of whether it resides on the same physical drive as the APFS partition you are trying to mount. This might cause weirdness when you have more than one physical drive with an APFS partition.
[doublepost=1504066471][/doublepost]

My mistake.

I don't think it'll matter which "apfs.efi" file it loads, as they will be exactly the same. (It's the APFS EFI driver found in a macOS install). Could you try adding "echo %m" right after the line "for %m run (0 9)", run the script, and take a picture of the output? That should pinpoint the issue.

 

[jhowarth]

It is also possible that the EFI shell doesn't like the '-' separators in the UUID string. Perhaps have the APFS patch that creates start.nsh parse those out. All you really want here is a unique identifier that will always be assigned to the same physical drive. So the UUID with the dashes stripped out works just as well for that purpose.

 

[dosdude1]

It is also possible that the EFI shell doesn't like the '-' separators in the UUID string. Perhaps have the APBS patch that creates start.nsh parse those out. All you really want here is a unique identifier that will always be assigned to the same physical drive. So the UUID with the dashes stripped out works just as well for that purpose.

But the thing is, comparing the UUIDs as they are, whilst using multiple variables, works perfectly fine on my machine... It's something with your configuration that's causing the issue, more than likely. Just add that "echo" line I mentioned earlier and send me the output of that.

 

[jhowarth]

I think a see a second issue here. The startup script has...

set apfsBootUUIDdir "apfsbootuuid"

but this is installed as a file containing the UUID string rather than a directory with a file named as the UUID string...

$ ls -l /apfsbootuuid
-rw-r--r--@ 1 root wheel 36 Aug 27 09:19 /apfsbootuuid
Mac-Pro:/ howarth$ cat /apfsbootuuid
EE73D24B-E1DF-3978-8AD6-66CBAB5ABAC2Mac-Pro:/ howarth$
[doublepost=1504068471][/doublepost]

But the thing is, comparing the UUIDs as they are, whilst using multiple variables, works perfectly fine on my machine... It's something with your configuration that's causing the issue, more than likely. Just add that "echo" line I mentioned earlier and send me the output of that.

On my machine, the startup.nsh has...

set targetUUID "A43465F6-5134-3A38-A3D1-9171AAFB3C02"

while the /apfsbootuuid file that was created has 'EE73D24B-E1DF-3978-8AD6-66CBAB5ABAC2'
[doublepost=1504069116][/doublepost]Okay. I see the problem now.

set targetUUID "A43465F6-5134-3A38-A3D1-9171AAFB3C02"

in startup.nsh was set correctly...

Mac-Pro:~ howarth$ diskutil info "/Volumes/High Sierra APFS HD" | grep UUID
Volume UUID: A43465F6-5134-3A38-A3D1-9171AAFB3C02
Disk / Partition UUID: A43465F6-5134-3A38-A3D1-9171AAFB3C02

but the /apfsbootuuid file created incorrectly had a bad UUID as well. So the bug is entirely in the code which should be creating a /apfsbootuuid directory and a file name after the contents of targetUUID.
[doublepost=1504070044][/doublepost]One other minor glitch. You also seem to have created an empty file name /apfsboot as well as the incorrect /
apfsbootuuid file (which should be a directory) than contained the string with the wrong UUID.

FYI, I have no idea where you got the bad UUID in the incorrect apfsbootuuid file as it doesn't match any volume on my machine according to 'diskutil info' (including the USB High Sierra Patch installer key).

 

[mnsiw]

Just finished implementing APFS support in High Sierra Patcher!

Thank you Dosdude1, just installed High Sierra on MacBook 5,1 APFS, working perfect.

 

[jhowarth]

Thank you Dosdude1, just installed High Sierra on MacBook 5,1 APFS, working perfect.

What do you have in your root partition? I'm not sure at which revision of APFS patch these were created but on my machine I ended up with both an empty file named 'apfsboot' and a file named 'apfsbootuuid' containing an incorrect UUID string. I assume these were installed prior to the 2.1.8 patching and that the current APFS patch in 2.1.8 isn't savvy enough to delete them so the correct 'apfsbootuuid' directory with file named as the UUID string to be created. So we do need a 2.1.9 release to clean up those issues (and make sure that when users clone over a APFS volume and reapply the APFS patch, the old UUID file in apfsbootuuid gets purged out to keep things tidy).

 

[honeycombz]

Hey, I'm running a Mac Pro 3,1 with a GTX 680 and an SSD as my boot volume connected to an Apricorn Velocity Solo X1 pointing to my home directory on an HDD. Wondering if this High Sierra patcher would work with this setup at this time or if I should wait a bit more for some of the issues to be worked out.

 

[tarasis]

Unable to convert my existing install into APFS. Option is greyed out both when booted via USB stick or via the recovery partition.

MBP 13” Mid 2009 (MBP5,5)



Seems others have the issue :/

https://forums.developer.apple.com/thread/84692

 

[roziek]

@dosdude1 Still nothing for me on my Mac Pro 3,1.

Just tried it again, this time with v2.1.8 and the latest beta (btw, the tool still downloads the previous beta, had to download it on a supported MacBook Pro).

And again, startup.nsh is not even run in my case. Both EFI and startup.nsh are in place. The apfsbootuuid folder with the correctly named UUID file inside is also in place in the root of my High Sierra volume. And nothing.

Actually, nothing has worked for me since the switch from the helper boot partition to the new method starting in v2.1.3.

Is anyone else having the same problem? I would "love" it to have a problem of it not being able to find the correct volume and boot, but right now I don't even get that far (like I mentioned: startup.nsh doesn't even get run).

Any ideas, anyone?
[doublepost=1504099293][/doublepost]

Unable to convert my existing install into APFS. Option is greyed out both when booted via USB stick or via the recovery partition.

MBP 13” Mid 2009 (MBP5,5)

View attachment 715106

Seems others have the issue :/

https://forums.developer.apple.com/thread/84692

That's strange, but why don't you do a clean APFS install of High Sierra? Would be easier.

 

[jhowarth]

@dosdude1 Still nothing for me on my Mac Pro 3,1.

Just tried it again, this time with v2.1.8 and the latest beta (btw, the tool still downloads the previous beta, had to download it on a supported MacBook Pro).

And again, startup.nsh is not even run in my case. Both EFI and startup.nsh are in place. The apfsbootuuid folder with the correctly named UUID file inside is also in place in the root of my High Sierra volume. And nothing.

Actually, nothing has worked for me since the switch from the helper boot partition to the new method starting in v2.1.3.

Is anyone else having the same problem? I would "love" it to have a problem of it not being able to find the correct volume and boot, but right now I don't even get that far (like I mentioned: startup.nsh doesn't even get run).

Any ideas, anyone?
[doublepost=1504099293][/doublepost]

That's strange, but why don't you do a clean APFS install of High Sierra? Would be easier.

How did you create your APFS partition? I ask because every time that I have tried to use 'diskutil apfs coovert' to convert a JHFS patched High Sierra volume to APFS, diskutil exited with an error code instead of 0. The only way I have been able to get the JHFS to APFS conversion to work is to start with an freshly formatted JHFS volume, convert it with 'diskutil apfs convert' and then use Carbon Copy Cloner 5.0 to clone my working JHFS patched High Sierra volume onto it.
[doublepost=1504101793][/doublepost]

Unable to convert my existing install into APFS. Option is greyed out both when booted via USB stick or via the recovery partition.

MBP 13” Mid 2009 (MBP5,5)

View attachment 715106

Seems others have the issue :/

https://forums.developer.apple.com/thread/84692

IMHO, the 'diskutil apfs convert' option is too buggy to use, at least on HDD but I don't see why that would be different from SSD in this regard. I would suiggest, assuming that you have an existing JHFS patched High Sierra volume to clone...

1) Format a drive as extended HFS with journaling.
2) From the macOS patched High Sierra installer key, execute 'sudo apfs convert' on that empty JHFS volume.
3) Use Carbon Copy Cloner 5.0 to clone your current JHFS High Sierra volume onto the newly converted empty APFS one and then apply the patches from the macOS High Sierra Patcher installer.

 

[roziek]

How did you create your APFS partition? I ask because every time that I have tried to use 'diskutil apfs coovert' to convert a JHFS patched High Sierra volume to APFS, diskutil exited with an error code instead of 0. The only way I have been able to get the JHFS to APFS conversion to work is to start with an freshly formatted JHFS volume, convert it with 'diskutil apfs convert' and then use Carbon Copy Cloner 5.0 to clone my working JHFS patched High Sierra volume onto it.
[doublepost=1504101793][/doublepost]

IMHO, the 'diskutil apfs convert' option is too buggy to use, at least on HDD but I don't see why that would be different from SSD in this regard. I would suiggest, assuming that you have an existing JHFS patched High Sierra volume to clone...

1) Format a drive as extended HFS with journaling.
2) From the macOS patched High Sierra installer key, execute 'sudo apfs convert' on that empty JHFS volume.
3) Use Carbon Copy Cloner 5.0 to clone your current JHFS High Sierra volume onto the newly converted empty APFS one and then apply the patches from the macOS High Sierra Patcher installer.

I've been doing a clean APFS installation of High Sierra from the very beginning, apart from just a one-time test of converting from HFS to APFS so I could report the results here on the forums.

So, in short: I format the disk as APFS (straight from the USB installer, either in terminal or Disk Utility) > install High Sierra > apply post install patches. Has been working fine all this time, and the installation itself also goes smooth. No luck with the new APFS boot method though. And like I mentioned several times, the problem doesn't even lie in finding the correct volume to boot, but in the fact that the startup.nsh doesn't even get run, at all.

Still works fine if I use v2.1.2 which uses the helper boot partition.

 

[tarasis]

How did you create your APFS partition? I ask because every time that I have tried to use 'diskutil apfs coovert' to convert a JHFS patched High Sierra volume to APFS, diskutil exited with an error code instead of 0. The only way I have been able to get the JHFS to APFS conversion to work is to start with an freshly formatted JHFS volume, convert it with 'diskutil apfs convert' and then use Carbon Copy Cloner 5.0 to clone my working JHFS patched High Sierra volume onto it.
[doublepost=1504101793][/doublepost]

IMHO, the 'diskutil apfs convert' option is too buggy to use, at least on HDD but I don't see why that would be different from SSD in this regard. I would suiggest, assuming that you have an existing JHFS patched High Sierra volume to clone...

1) Format a drive as extended HFS with journaling.
2) From the macOS patched High Sierra installer key, execute 'sudo apfs convert' on that empty JHFS volume.
3) Use Carbon Copy Cloner 5.0 to clone your current JHFS High Sierra volume onto the newly converted empty APFS one and then apply the patches from the macOS High Sierra Patcher installer.

That’s what I probably should have done. I just executed the convert from the command line which worked …

However the disk/partition does not appear as a bootable disk when booting the comp while holding Alt. MBP Judy boots into recovery partition.

I did run the post install patch from dosdude1’s installer.

 

[dosdude1]

I've been doing a clean APFS installation of High Sierra from the very beginning, apart from just a one-time test of converting from HFS to APFS so I could report the results here on the forums.

So, in short: I format the disk as APFS (straight from the USB installer, either in terminal or Disk Utility) > install High Sierra > apply post install patches. Has been working fine all this time, and the installation itself also goes smooth. No luck with the new APFS boot method though. And like I mentioned several times, the problem doesn't even lie in finding the correct volume to boot, but in the fact that the startup.nsh doesn't even get run, at all.

Still works fine if I use v2.1.2 which uses the helper boot partition.

What's your configuration? If you have multiple drives installed, try removing all except the one containing High Sierra, and see if that makes a difference.

 

[roziek]

What's your configuration? If you have multiple drives installed, try removing all except the one containing High Sierra, and see if that makes a difference.

I do, I have disks in 3 out of 4 bays. Will do just that and report back. That would be a shame though, I need those disks in there .

 

[Khashoggi]

Dosdude1 - Great job with your tool and evolving it, and also for being very responsive to users questions throughout the thread.

Foxlet - Don’t take your ball and go home. Instead stay and contribute, answer questions not just ignore them and hint at tools for weeks that never are released to the community as a whole. It’s the mature thing to do. Also, it’s best to wash your dirty laundry in private because it just makes you look petulant.

 

[jhowarth]

I do, I have disks in 3 out of 4 bays. Will do just that and report back. That would be a shame though, I need those disks in there .

Is it possible that you have \EFI\apfs.efi on more than one attached drive? I am still nervous about the approach currently used in startup.nsh as it will load the apfs.efi from the first EFI partition that it finds it on. My suggestion had been to also use a UUID file on the EFI partitions are well to insure that the afps.efi loaded was from the same physical drive as the APFS partition, but that part wasn't implemented.

IMHO, it just doesn't seem like a good idea to use the apfs.efi from a different drive, especially as it may be mixing APBS patch changes from two entirely different High Sierra Patcher releases.

 

[dosdude1]

Is it possible that you have \EFI\apfs.efi on more than one attached drive? I am still nervous about the approach currently used in startup.nsh as it will load the apfs.efi from the first EFI partition that it finds it on. My suggestion had been to also use a UUID file on the EFI partitions are well to insure that the afps.efi loaded was from the same physical drive as the APFS partition, but that part wasn't implemented.

IMHO, it just doesn't seem like a good idea to use the apfs.efi from a different drive, especially as it may be mixing APBS patch changes from two entirely different High Sierra Patcher releases.

APFS.efi is the same, regardless of what drive it's on (it's just taken from the /usr/standalone/i386 folder of a High Sierra install). All it is is a driver, so as long as it's loaded from somewhere it will work just fine... Doesn't matter what drive or partition it's on or loaded from. And, it's loaded when running the script, and if the script isn't running in the first place, the APFS.efi file isn't even part of the process at that point.

 

[jhowarth]

APFS.efi is the same, regardless of what drive it's on (it's just taken from the /usr/standalone/i386 folder of a High Sierra install). All it is is a driver, so as long as it's loaded from somewhere it will work just fine... Doesn't matter what drive or partition it's on or loaded from. And, it's loaded when running the script, and if the script isn't running in the first place, the APFS.efi file isn't even part of the process at that point.

IMHO, it still would be cleaner to make sure that the apfs.efi was always loaded from the same physical drive as the desired APFS partition to make sure we never mix components installed by different versions of the High Sierra Patcher program.

 

[shaocaholica]

Not having any luck with 2.1.9 patcher and beta 7 on a 2009 MBP 17 with an APFS formatted SSD.

How do I bring up the verbose boot output?

 

[dosdude1]

Not having any luck with 2.1.9 patcher and beta 7 on a 2009 MBP 17 with an APFS formatted SSD.

How do I bring up the verbose boot output?

Do you have an option labeled "EFI Boot" when booting while holding the Option key?

 

[roziek]

Not having any luck with 2.1.9 patcher and beta 7 on a 2009 MBP 17 with an APFS formatted SSD.

How do I bring up the verbose boot output?

Add -v flag to your boot-args using nvram (as sudo).

sudo nvram boot-args="-v"

Or if you want to do a one-time verbose boot, press and hold CMD + V when you power on your Mac.

 

[jhowarth]

I've been doing a clean APFS installation of High Sierra from the very beginning, apart from just a one-time test of converting from HFS to APFS so I could report the results here on the forums.

So, in short: I format the disk as APFS (straight from the USB installer, either in terminal or Disk Utility) > install High Sierra > apply post install patches. Has been working fine all this time, and the installation itself also goes smooth. No luck with the new APFS boot method though. And like I mentioned several times, the problem doesn't even lie in finding the correct volume to boot, but in the fact that the startup.nsh doesn't even get run, at all.

Still works fine if I use v2.1.2 which uses the helper boot partition.

I'll try a clean install of High Sierra on an APFS partition using my USB external drive to see how that works out. It is unclear at the moment how many hurdles Apple will place in front of HDD users who want to install on APFS. Hopefully they won't go to the extreme of checking if the destination drive is non-SSD but APFS and refusing to install in that case.

 

[tarasis]

Recreating patcher stick with 2.1.9 (I had apparently used 2.1.2), and reapplying the APFS patch has made it possible for me to boot with APFS.