macOS High Sierra (10.13) Unsupported Macs Thread

[roziek]

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.

Sure, and I agree that’s a priority.

When that is fully worked out, I hope we’ll get booting from encrypted volumes too, though .
[doublepost=1504207040][/doublepost]Ok, encrypting via FileVault 2 is taking place as we speak. We’ll see what will come out of that.

One interesting note here: previously when you turned FileVault on while booted into OS (as opposed to turning it on during post-installation setup), the machine immediately rebooted and you were presented with that EFI passcode screen. After you typed it in, the OS booted and the encryption continued.

But now it seems like it’s encrypting right away. It didn’t reboot, just started encrypting. Now I wonder: is that because of how APFS is handling whole-disk encryption, or it’s just a change in FileVault under High Sierra, regardless of the filesystem used.

Will report whether I can boot into it when it’s done encrypting.

 

[Stratus Fear]

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.

Interestingly, it looks like HS maintains the Preboot partition even if you don't have your HS volume encrypted, so pointing the startup.nsh script over there should probably work regardless of whether someone is using FileVault. I was poking around in there on an install on a supported machine that hasn't had FileVault enabled, and it does appear to maintain all the boot files in there regardless (with the notable exception of apfs.efi, which is absent from Preboot), in a subfolder named with the UUID of the main APFS volume where HS is installed. Looks like multiple HS installs on multiple APFS volumes inside the same APFS container can use the same Preboot and Recovery volumes, too; I had more than one UUID-named subfolder in both partitions from a couple different HS installs.

 

[shaocaholica]

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.

Thanks. So apfs.efi is copied from /usr/standalone/i386 (APFS volume) to the EFI partition as part of the APFS patch process?

 

[nekton1]

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.

Has anyone confirmed that moving startup.nsh to /EFI/BOOT enables the coexistence and booting of multiple bootable APFS disks that can be selected at the efi.boot screen?

 

[roziek]

It finished encrypting. Unsurprisingly, it won’t boot, startup.nsh can’t find the boot file.

FileVault 2 works fine on an HFS installation of High Sierra, though, so that’s something.

Has anyone confirmed that moving startup.nsh to /EFI/BOOT enables the coexistence and booting of multiple bootable APFS disks that can be selected at the efi.boot screen?

I only have one install of HS, so can’t test it.

 

[dosdude1]

Has anyone confirmed that moving startup.nsh to /EFI/BOOT enables the coexistence and booting of multiple bootable APFS disks that can be selected at the efi.boot screen?

Yes, I just tested it, and it does allow me to boot different APFS volumes from the boot menu.

 

[nekton1]

OK, I will move the startup.nsh on my two test SSDs Disk A and Disk B and try again in MP3,1.

Will a new patch implement this too?

 

[dosdude1]

OK, I will move the startup.nsh on my two test SSDs Disk A and Disk B and try again in MP3,1.

Will a new patch implement this too?

Yes, already updated to implement that change.

 

[roziek]

Yes, already updated to implement that change.

Still seeing v2.2.0 on the site.

 

[dosdude1]

Still seeing v2.2.0 on the site.

Ah, forgot to edit the webpage. Check now.

 

[roziek]

Ah, forgot to edit the webpage. Check now.

Thanks .

 

[nekton1]

Thanks .

I can confirm that the new location of startup.nsh in /EFI/BOOT does support disk selection and booting from both Disk A and Disk B APFS-formatted with HS beta 8 and using dosdude's patcher 2.1.9 (I moved startup.nsh manually this time instead of using the 2.2.0 patcher.)

Two things I wonder: 1. Do Apple macOS updates touch the EFI partition? and 2. Will this affect cloning using CCC5?

However, the Volume UUIDs for the two disks are still identical—which must cause trouble in the future!

/dev/disk0 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *120.0 GB disk0

1: EFI EFI 209.7 MB disk0s1

2: Apple_APFS Container disk1 119.8 GB disk0s2


/dev/disk1 (synthesized):

#: TYPE NAME SIZE IDENTIFIER

0: APFS Container Scheme - +119.8 GB disk1

Physical Store disk0s2

1: APFS Volume Disk B 11.7 GB disk1s1

2: APFS Volume Preboot 20.4 MB disk1s2

3: APFS Volume Recovery 517.0 MB disk1s3

4: APFS Volume VM 20.5 KB disk1s4


/dev/disk2 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *50.0 GB disk2

1: EFI EFI 209.7 MB disk2s1

2: Apple_APFS Container disk3 49.8 GB disk2s2


/dev/disk3 (synthesized):

#: TYPE NAME SIZE IDENTIFIER

0: APFS Container Scheme - +49.8 GB disk3

Physical Store disk2s2

1: APFS Volume DiskA 12.2 GB disk3s1

2: APFS Volume Preboot 20.4 MB disk3s2

3: APFS Volume Recovery 517.0 MB disk3s3

4: APFS Volume VM 20.5 KB disk3s4


ROBERTs-Mac-Pro:~ robert$ sudo diskutil info disk0s1 | grep UUID

Volume UUID: 0E239BC6-F960-3107-89CF-1C97F78BB46B

Disk / Partition UUID: 45862D59-85B4-461B-A27C-DCC2B7922290

ROBERTs-Mac-Pro:~ robert$ sudo diskutil info disk2s1 | grep UUID

Volume UUID: 0E239BC6-F960-3107-89CF-1C97F78BB46B

Disk / Partition UUID: 04EC9B3F-5D47-4A27-AB58-FC934034F2C5

Anyhow, great work everybody.

 

[dosdude1]

I can confirm that the new location of startup.nsh in /EFI/BOOT does support disk selection and booting from both Disk A and Disk B APFS-formatted with HS beta 8 and using dosdude's patcher 2.1.9 (I moved startup.nsh manually this time instead of using the 2.2.0 patcher.)

Two things I wonder: 1. Do Apple macOS updates touch the EFI partition? and 2. Will this affect cloning using CCC5?

However, the Volume UUIDs for the two disks are still identical—which must cause trouble in the future!

/dev/disk0 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *120.0 GB disk0

1: EFI EFI 209.7 MB disk0s1

2: Apple_APFS Container disk1 119.8 GB disk0s2


/dev/disk1 (synthesized):

#: TYPE NAME SIZE IDENTIFIER

0: APFS Container Scheme - +119.8 GB disk1

Physical Store disk0s2

1: APFS Volume Disk B 11.7 GB disk1s1

2: APFS Volume Preboot 20.4 MB disk1s2

3: APFS Volume Recovery 517.0 MB disk1s3

4: APFS Volume VM 20.5 KB disk1s4


/dev/disk2 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *50.0 GB disk2

1: EFI EFI 209.7 MB disk2s1

2: Apple_APFS Container disk3 49.8 GB disk2s2


/dev/disk3 (synthesized):

#: TYPE NAME SIZE IDENTIFIER

0: APFS Container Scheme - +49.8 GB disk3

Physical Store disk2s2

1: APFS Volume DiskA 12.2 GB disk3s1

2: APFS Volume Preboot 20.4 MB disk3s2

3: APFS Volume Recovery 517.0 MB disk3s3

4: APFS Volume VM 20.5 KB disk3s4


ROBERTs-Mac-Pro:~ robert$ sudo diskutil info disk0s1 | grep UUID

Volume UUID: 0E239BC6-F960-3107-89CF-1C97F78BB46B

Disk / Partition UUID: 45862D59-85B4-461B-A27C-DCC2B7922290

ROBERTs-Mac-Pro:~ robert$ sudo diskutil info disk2s1 | grep UUID

Volume UUID: 0E239BC6-F960-3107-89CF-1C97F78BB46B

Disk / Partition UUID: 04EC9B3F-5D47-4A27-AB58-FC934034F2C5

Anyhow, great work everybody.

It looks like it's just the UUIDs for the ESPs that are the same, which shouldn't make a difference as the script doesn't look at that. I don't believe the system updates make any changes to the ESP (and if they do, they shouldn't overwrite any of the files added). If you do clone the drive, all you'd need to do is re-run the post-install patch on the cloned volume.

 

[jhowarth]

I also can confirm that moving startup.nsh into EFI/BOOT on both APFS patched HS volumes allows the external USB one to boot as expected. So is this movement of startup.nsh info EFI/BOOT present in High Sierra Patcher 2.1.1? Also, is there a way to suppress the EFI shell screen output analogous to the Linux kernel splash screen option?

 

[dosdude1]

I also can confirm that moving startup.nsh into EFI/BOOT on both APFS patched HS volumes allows the external USB one to boot as expected. So is this movement of startup.nsh info EFI/BOOT present in High Sierra Patcher 2.1.1? Also, is there a way to suppress the EFI shell screen output analogous to the Linux kernel splash screen option?

Yes, in v2.1.1, it is now placed into /EFI/BOOT, fixing that issue. And unfortunately, there is not any way to suppress the output of the shell.

 

[roziek]

Yes, in v2.1.1, it is now placed into /EFI/BOOT, fixing that issue. And unfortunately, there is not any way to suppress the output of the shell.

That would of course be the v2.2.1. Just a correction to avoid unnecessary confusion for newcomers.

 

[jhowarth]

It would be nice if we could get rid of the non-descript 'EFI Boot' icon names in the boot selector and replace them with the actual volume names being booted. An potential approach seems to be described here...

https://apple.stackexchange.com/questions/2350/how-can-i-change-the-title-of-a-boot-image

using

sudo bless --folder <mount_path> -label <desired_label>

However we would have to add a mechanism to resync the labels if the volumes got renamed.

 

[nekton1]

FYI, CCC5 was able to clone an entire HS beta 8 (patcher 2.2.1) APFS formatted boot disk with full range of applications and home folder with 4 users to a second HS beta 8 (patcher 2.2.1) APFS formatted disk with just macOS HS beta 8 installed without problems and both are bootable.
[doublepost=1504225245][/doublepost]Have to wait until next Monday to see whether Software Update still works!

 

[jhowarth]

FYI, CCC5 was able to clone an entire HS beta 8 (patcher 2.2.1) APFS formatted boot disk with full range of applications and home folder with 4 users to a second HS beta 8 (patcher 2.2.1) APFS formatted disk with just macOS HS beta 8 installed without problems and both are bootable.
[doublepost=1504225245][/doublepost]Have to wait until next Monday to see whether Software Update still works!

If you have installed APFS on a HDD, I would read the release notes before installing the upcoming updates as Apple apparently intends to automate a roll-back of the APFS on fusion and hard drives back to HFS+ prior to or at the GM release.

 

[ryxn]

If you have installed APFS on a HDD, I would read the release notes before installing the upcoming updates as Apple apparently intends to automate a roll-back of the APFS on fusion and hard drives back to HFS+ prior to or at the GM release.

Source for that information?

 

[jhowarth]

Apple itself...

http://appleinsider.com/articles/17...e-with-legacy-hdds-and-possibly-fusion-drives

https://support.apple.com/en-us/HT208018

While the GM will install all SSDs as APFS, they have decided to keep APFS off of hard drives and fusion drives for the initial release and won't support conversion from HFS to APFS. The promised support to roll back APFS to HFS is a good thing IMHO as there really should be a two way conversion available in Disk Utility to APFS and back again to HFS as well.

 

[nekton1]

If you have installed APFS on a HDD, I would read the release notes before installing the upcoming updates as Apple apparently intends to automate a roll-back of the APFS on fusion and hard drives back to HFS+ prior to or at the GM release.

I have no HDDs—only SSDs. I would not touch APFS on HDD with a barge pole after Apple's warnings.

 

[shaocaholica]

I have quite a few Macs with a boot SSD and a secondary large HDD. I'll play around with formatting the HDDs APFS and seeing how that handles. Of course with non critical data although if APFS causes data loss on HDDs then that's a huge blow for Apple for releasing a FS that doesn't support HDDs no matter how hard they try to caveat it.

 

[nekton1]

I have quite a few Macs with a boot SSD and a secondary large HDD. I'll play around with formatting the HDDs APFS and seeing how that handles. Of course with non critical data although if APFS causes data loss on HDDs then that's a huge blow for Apple for releasing a FS that doesn't support HDDs no matter how hard they try to caveat it.

[doublepost=1504250216][/doublepost]Apple HAS said it will support APFS on HDD just NOT at the 10.13 GM release. It is risky to use APFS on HDD so be careful.

 

[olad]

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.

Simple, clear explanation. Captured with Captur for reference purposes. My fears of switching to APFS allayed. Thanks