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) |
| | |
| + |
| ==================================================== |
| 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