croaker
Jul 6, 2017 7:15 AM
(in response to trekkie)
I had the same problem on my 15" MacBook Pro early 2011 with a FV2 encrypted homemade fusion drive after it slept during install. To make matters worse it wouldn't even boot into the recovery partion (although it would boot into the password recovery utility). I ended up creating a bootable USB drive so I could get to an OS 10.13 terminal window.
After some research and a lot of trial and error I came up with a solution that worked for me:
1. Boot into the OS installer/recovery drive.
2. Open a terminal window. Run diskutil apfs list and find your boot volume
$ diskutil apfs list
APFS Container (1 found)
|
+-- Container disk2 87F8E3F6-28B8-4A98-847A-28C4370E1133
====================================================
APFS Container Reference: disk2 (Fusion)
Capacity Ceiling (Size): 754964643840 B (755.0 GB)
Capacity In Use By Volumes: 480886849536 B (480.9 GB) (63.7% used)
Capacity Available: 274077794304 B (274.1 GB) (36.3% free)
|
+-< Physical Store disk0s2 A070CF3A-AFA8-4AFF-81E3-E77D75FD4685
| -----------------------------------------------------------
| APFS Physical Store Disk: disk0s2
| Size: 255716540416 B (255.7 GB)
|
+-< Physical Store disk1s2 46B2EB23-79BA-43A0-A99F-D50AAC6C66BF
| -----------------------------------------------------------
| APFS Physical Store Disk: disk1s2
| Size: 499248103424 B (499.2 GB)
|
+-> Volume disk2s1 6AAC9D56-EC44-38B3-9C50-1D6DA3020377
| ---------------------------------------------------
| APFS Volume Disk (Role): disk2s1 (No specific role)
| Name: Macintosh HD
| Mount Point: /
| Capacity Consumed: 461711589376 B (461.7 GB)
| Capacity Reserve: None
| Capacity Quota: None
| Encrypted: Yes (Unlocked)
|
+-> Volume disk2s2 FA366E2A-B9CD-4822-AC93-3133635BAFD60
| ---------------------------------------------------
| APFS Volume Disk (Role): disk2s2 (Preboot)
| Name: Preboot
| Mount Point: Not Mounted
| Capacity Consumed: 18444288 B (18.4 MB)
| Capacity Reserve: None
| Capacity Quota: None
| Encrypted: No
|
+-> Volume disk2s3 0E4E73B-B55D-4DEC-94A1-0A3DD20E73EC
| ---------------------------------------------------
| APFS Volume Disk (Role): disk2s3 (Recovery)
| Name: Recovery
| Mount Point: Not Mounted
| Capacity Consumed: 518926336 B (518.9 MB)
| Capacity Reserve: None
| Capacity Quota: None
| Encrypted: No
|
+-> Volume disk2s4 38451C7D-33AA-42AE-A951-09CB95D25D2C
---------------------------------------------------
APFS Volume Disk (Role): disk2s4 (VM)
Name: VM
Mount Point: /private/var/vm
Capacity Consumed: 9842118656 B (9.8 GB)
Capacity Reserve: None
Capacity Quota: None
Encrypted: No
2. Now run diskutil apfs unlockvolume on your boot volume. Authenticate with your usual password
$ diskutil apfs unlockvolume disk2s1
...
3. Finally, run diskutil apfs updatePreboot on your now unlocked boot volume
$ diskutil apfs updatePreboot disk2s1
Started APFS operation
UpdatePreboot: Commencing operation to update the Preboot Volume for Target Volume disk2s1 Macintosh HD
UpdatePreboot: The Target Volume's OpenDirectory (non-special kind) user count is 1 and the Recovery (any of 3 kinds) user count is 2
UpdatePreboot: No custom Open Directory path given
UpdatePreboot: Using GivenVolumeMountPointOrNilIfNotMounted as MacOSSearchPath
UpdatePreboot: Using MacOSSearchPath's child dslocal path as OpenDirectorySearchPath
UpdatePreboot: MacOS Search Path = (nil=NotMounted) = /
UpdatePreboot: Open Directory Database Search Path = (nil=MacOSSearchPathNotMounted) = /var/db/dslocal/nodes/Default
UpdatePreboot: Successfully opened Open Directory database; setting AuthODNodeOrNil accordingly
UpdatePreboot: Mounting and ensuring as mounted the related Preboot Volume
UpdatePreboot: Preboot Volume = disk2s2 Preboot
UpdatePreboot: Preboot Volume Target Directory = /Volumes/Preboot/6AAC9D56-EC44-38B3-9C50-1D6DA3020377
UpdatePreboot: Considering APFS Crypto User EBC6C064-0000-11AA-AA11-00306543ECAC
UpdatePreboot: This is the Personal Recovery Key for this Volume
UpdatePreboot: Treating this APFS Crypto User as a Personal Recovery Key User
UpdatePreboot: Before rendering EFILoginUserGraphics user resources for type = EFI Login Personal Recovery Key User
UpdatePreboot: After rendering EFILoginUserGraphics Data=(0=Error)=0x7fb910f24b00=0
UpdatePreboot: Successfully added a Personal Recovery Key User to the building dictionary
UpdatePreboot: Successfully processed APFS Volume Crypto User EBC6C064-0000-11AA-AA11-00306543ECAC
...
UpdatePreboot: Considering APFS Crypto User 57A79AC6-ED71-4DE5-82BE-6B0ECFC5E2C
UpdatePreboot: Defaulting and requiring that this be an Open Directory User
UpdatePreboot: Treating this APFS Crypto User to be, and requiring to match, an Open Directory User
UpdatePreboot: Correlated APFS Volume Crypto User with Open Directory User 57A79AC6-ED71-4DE5-82BE-6B0ECFC5E2C aka "admin"
UpdatePreboot: All required data for this Open Directory user has been obtained
...
datePreboot: Writing Admin User Info File to path /Volumes/Preboot/6AAC9D56-EC44-38B3-9C50-1D6DA3020377/var/db/AdminUserRecoveryInfo.plist
UpdatePreboot: Successfully wrote Admin User Info File
UpdatePreboot: Checking for existence of Secure Access Token file /var/db/dslocal/nodes/Default/secureaccesstoken.plist
UpdatePreboot: Before copying Secure Access Token file /var/db/dslocal/nodes/Default/secureaccesstoken.plist into directory /Volumes/Preboot/6AAC9D56-EC44-38B3-9C50-1D6DA3020377/var/db
UpdatePreboot: After copying error=(0=success)=0
UpdatePreboot: Unmounting Preboot Volume
UpdatePreboot: Exiting Update Preboot operation with overall error=(0=success)=0
If it ends with an overall error of 0 then that's it. Done! Reboot and be prepared to wait. The first boot took an an inordinate amount of time for me. I was patient and let it do it's thing and it paid off. Finder finally loaded and everything opened up to it's pre-upgrade status.
If you see errors while updatePreboot is considering the Open Directory User ensure your unlocked APFS volume is mounted and readable. It must have access to the local Open Directory search path (/var/db/dslocal/nodes/Default) to build a list of authorized users (AdminUserRecoveryInfo.plist) and an access token (secureaccesstoken.plist) and copy them onto the Preboot volume (/Volumes/Preboot/6AAC9D56-EC44-38B3-9C50-1D6DA3020377/var/db/).
I suspect it is updatePreboot that causes this problem during install. I have a working theory on why it is happening: The OS Installer reboots the system. After restart the CoreStorage volume is unlocked and converted to APFS after which the OS install process begins. When the install is complete, just before the final reboot, updatePreboot is applied to the FV2 boot volume. We have already shown that updatePreboot will fail if the FV2 volume is locked and I'm fairly sure FV2 volumes lock (or have the encryption keys destroyed) at sleep. Following this logic: if the machine sleeps during (or at the end of) the install process but before updatePreboot runs, the Preboot volume will fail to get updated. The machine then reboots: EFI sees the FV2 boot volume so it looks to the (improperly updated) Preboot volume for authorized users. EFI fails to find any admin users since updatePreboot could not read them from Open Directory on the locked boot volume so it displays the generic "disk password" prompt. This is also why neither the recovery key nor an icloud account will unlock the drive.
I hope this helps anyone with this issue. Also, please feel free to correct any glaring mistakes I may have made.
Scot
This helped me Show 13 Likes (13)
