macOS Tahoe beta enables FV2 by default and it seems like the mechanism was altered in some ways, that might end up locking out of booting FV2 encrypted macOS volumes in the same container.
After installing macOS Tahoe on separate APFS volume, every FV2 volume in this container becomes unbootable with OpenCore - the prebooter loads, but doesn't accept password. To make macOS bootable again, encryption needs to be turned off from macOS Tahoe recovery - password still works and volumes can be decrypted succesfully, but prebooter never accepts it, just acts like invalid password has been entered, no special OC errors or even attempt to boot.
A few things I discovered while troubleshooting:
- main installation of macOS Sequoia couldn't be booted with FV2 enabled
- change password within Recovery, both with current password and iCloud - password not accepted
- installed Monterey on second volume, worked great until FV2 was enabled - password not accepted
- clearing NVRAM didn't help
- booting from older backup of EFI folder that was used with Monterey, still didn't allow encrypted Monterey to boot
- took out the drive and booted in other OC-based hackintosh - password not accepted; main drive of this hackintosh is also FV2 which works correctly, but couldn't boot the Tahoe-infected drive
- deleting Preboot volume and recreating it with new macOS installation didn't help, tested with Sonoma and Monterey
Now, after deleting Tahoe volume, I am still unable to sucesfully login into FV2 volumes in this very same container, even after decrypting and encrypting it again or enabling FileVault on a fresh installation of macOS.
I am able to boot unecrypted volumes tho.
I have seen other users reporting being unable to boot other volumes after Tahoe installation
UPDATE: workaround
It is suspected that Apple APFS driver is either buggy or not compatible with FV2 software decryption, since all officially supported models are T2 equipped. FV2 in some cases gets automatically enabled during Tahoe upgrade.
Partition embedded APFS driver is also updated during the process, so it may affect all encrypted volumes in the same container.
To restore your ability to boot use macOS Recovery to disable FV2 encryption on selected volume.
To use FV2, temporary workaround is to add apfs_aligned.efi to your OC Drivers and disable APFS Jumpstart to disallow loading the partition embedded driver (thanks @vit9696 @mhaeuser )
macOS Tahoe beta enables FV2 by default and it seems like the mechanism was altered in some ways, that might end up locking out of booting FV2 encrypted macOS volumes in the same container.
After installing macOS Tahoe on separate APFS volume, every FV2 volume in this container becomes unbootable with OpenCore - the prebooter loads, but doesn't accept password. To make macOS bootable again, encryption needs to be turned off from macOS Tahoe recovery - password still works and volumes can be decrypted succesfully, but prebooter never accepts it, just acts like invalid password has been entered, no special OC errors or even attempt to boot.
A few things I discovered while troubleshooting:
Now, after deleting Tahoe volume, I am still unable to sucesfully login into FV2 volumes in this very same container, even after decrypting and encrypting it again or enabling FileVault on a fresh installation of macOS.
I am able to boot unecrypted volumes tho.
I have seen other users reporting being unable to boot other volumes after Tahoe installation
UPDATE: workaround
It is suspected that Apple APFS driver is either buggy or not compatible with FV2 software decryption, since all officially supported models are T2 equipped. FV2 in some cases gets automatically enabled during Tahoe upgrade.
Partition embedded APFS driver is also updated during the process, so it may affect all encrypted volumes in the same container.
To restore your ability to boot use macOS Recovery to disable FV2 encryption on selected volume.
To use FV2, temporary workaround is to add apfs_aligned.efi to your OC Drivers and disable APFS Jumpstart to disallow loading the partition embedded driver (thanks @vit9696 @mhaeuser )