[-69624] APFS volume creation fails during macOS 26 Tahoe install

## Description
Model: MacBookAir8,2 Patcher version: 4.0.0.17002 Target OS: macOS 26 Tahoe

Steps to reproduce

Boot OpenCore Legacy Patcher T2 installer USB with SMBIOS Spoofing

Open Disk Utility in Recovery

Select internal NVMe (disk0)

Erase → APFS → GUID Partition Map

Container creates successfully (disk5)

Prepare to add APFS volume to container disk5 ← FAILS HERE

Error: An internal error has ocurred: (-69624)

Full diskutil sequence (Terminal)

This works:

diskutil apfs createContainer disk0s2 "Macintosh HD"

Creates container disk5 successfully

This FAILS with -69624:

diskutil apfs addVolume disk5 APFS "Macintosh HD" -passphrase

Error: -69624

Have the same issue and the results of SEP booted via OpenCorePkg are these:
-bash-3.2# sw_vers
ProductName: macOS
ProductVersion: 26.6.2
BuildVersion: 25G83
-bash-3.2# ioreg -p IODeviceTree -n chosen -r -l | grep -Ei 'sep|sepfw'
-bash-3.2# ioreg -r -n AppleSEPManager -l | grep -Ei 'sep|boot'
+-o AppleSEPManager <class AppleSEPManager, id 0x1000002e1, registered, matched, active, busy 0 (1 ms), retain 10>
| "CFBundleIdentifier" = "com.apple.driver.AppleSEPManager"
| "IOProviderClass" = "AppleSEPIntelIOPNub"
| "IOClass" = "AppleSEPManager"
| "CFBundleIdentifierKernel" = "com.apple.driver.AppleSEPManager"
| "IOMatchedAtBoot" = Yes
| "IONameMatch" = "iop-nub,sep"
| "IOUserClientClass" = "AppleSEPUserClient"
| "IONameMatched" = "iop-nub,sep"
"IOProviderClass" = "AppleSEPManager"
"IOMatchedAtBoot" = Yes
-bash-3.2# sw_vers
ProductName: macOS
ProductVersion: 26.6.2
BuildVersion: 25G83
-bash-3.2# ioreg -p IODeviceTree -n chosen -r -l | grep -Ei 'sep|sepfw'
-bash-3.2# ioreg -r -n AppleSEPManager -l | grep -Ei 'sep|boot'
+-o AppleSEPManager <class AppleSEPManager, id 0x1000002e1, registered, matched, active, busy 0 (1 ms), retain 10>
| "CFBundleIdentifier" = "com.apple.driver.AppleSEPManager"
| "IOProviderClass" = "AppleSEPIntelIOPNub"
| "IOClass" = "AppleSEPManager"
| "CFBundleIdentifierKernel" = "com.apple.driver.AppleSEPManager"
| "IOMatchedAtBoot" = Yes
| "IONameMatch" = "iop-nub,sep"
| "IOUserClientClass" = "AppleSEPUserClient"
| "IONameMatched" = "iop-nub,sep"
"IOProviderClass" = "AppleSEPManager"
"IOMatchedAtBoot" = Yes
-bash-3.2# sw_vers
ProductName: macOS
ProductVersion: 26.6.2
BuildVersion: 25G83
-bash-3.2# ioreg -p IODeviceTree -n chosen -r -l | grep -Ei 'sep|sepfw'
-bash-3.2# ioreg -r -n AppleSEPManager -l | grep -Ei 'sep|boot'
+-o AppleSEPManager <class AppleSEPManager, id 0x1000002e1, registered, matched, active, busy 0 (1 ms), retain 10>
| "CFBundleIdentifier" = "com.apple.driver.AppleSEPManager"
| "IOProviderClass" = "AppleSEPIntelIOPNub"
| "IOClass" = "AppleSEPManager"
| "CFBundleIdentifierKernel" = "com.apple.driver.AppleSEPManager"
| "IOMatchedAtBoot" = Yes
| "IONameMatch" = "iop-nub,sep"
| "IOUserClientClass" = "AppleSEPUserClient"
| "IONameMatched" = "iop-nub,sep"
"IOProviderClass" = "AppleSEPManager"
"IOMatchedAtBoot" = Yes
-bash-3.2#
This is on MacBookPro16,2 spoofed as 16,1.
But despite this, formatting a partition as APFS even falls short. Will post later with the next set of diagnostics.
@DrDonk @rizosprime

Partitioning disk “APPLE SSD AP2048N Media” (disk2)

Running operation 1 of 1: Add “Sanga” 115.55 GB by shrinking container disk3 “Container disk3” (disk2s3) from 237.64 GB to 122.09 GB…
Aligning shrink delta to 115,546,902,528 bytes and targeting a new container size of 122,089,701,376 bytes
Determined the minimum size for the APFS Container to be 452,984,832 bytes
Resizing APFS Container designated by APFS Container Reference disk3
The specific APFS Physical Store being resized is disk2s3
Verifying storage system
Performing fsck_apfs -n -x /dev/disk2s3
Checking the container superblock.
Checking the checkpoint with transaction ID 37.
Checking the space manager.
Checking the space manager free queue trees.
Checking the object map.
Checking the encryption key structures.
error: container keybag (4096000+1): failed to get keybag data: Operation not permitted
Encryption key structures are invalid.
The container /dev/disk2s3 could not be verified completely.
Storage system check exit code is 8.
Storage system verify or repair failed. : (-69716)

Operation failed…

So what I know for sure a keybag operation is failing. I’ll get more info soon what is exactly failing.

Strangely enough, deleting an entire container succeeds, but deleting an APFS formatted partition does not:
-bash-3.2# diskutil apfs deleteContainer disk3
Started APFS operation on disk3
Deleting APFS Container with all of its APFS Volumes
Unmounting Volumes
Deleting Volumes
Deleting Container
Wiping former APFS disks
Switching content types
1 new disk created or changed due to APFS operation
Disk from APFS operation: disk2s3
Finished APFS operation on disk3
Removing disk2s3 from partition map
-bash-3.2#
@rizosprime @DrDonk

log show --path "/Volumes//private/var/db/diagnostics" --last 30m --info --debug

log show --directory "/Volumes/Macintosh HD - Data/private/var/db/diagnostics" --last 30m --info --debug

log stream --predicate 'sender == "AppleKeyStore" OR eventMessage CONTAINS[c] "VEK" OR eventMessage CONTAINS[c] "keybag"' --info --debug --style compact

-bash-3.2# log stream --predicate 'sender == "AppleKeyStore" OR eventMessage CONTAINS[c] "VEK" OR eventMessage CONTAINS[c] "keybag"' --info --debug --style compact
Filtering the log data using "sender == "AppleKeyStore" OR composedMessage CONTAINS[c] "VEK" OR composedMessage CONTAINS[c] "keybag""
Timestamp Ty Process[PID:TID]
2026-08-29 19:20:32.788 Db Terminal[355:2388] [com.apple.CFBundle:loading] dlfcn check load bundle CFBundle 0x600003440fc0 </System/Library/PrivateFrameworks/MobileKeyBag.framework> (not loaded), dlopen of /System/Library/PrivateFrameworks/MobileKeyBag.framework/MobileKeyBag mode 0x115 getting handle 0x183550ce1

Exactly the keybag operation is causing an issue here.

When booting my 2020 MacBook Pro 4 thunderbolt 3 ports natively, this is without deleting or doing anything with the APFS partition.
@DrDonk
I'm showing this on my 2020 MacBook Pro due to not being able to show logs as detailed inside Recovery.

Last login: Sat Aug 29 23:05:34 on console
boyan2@MacBook-Pro ~ % log stream --predicate 'sender == "AppleKeyStore" OR eventMessage CONTAINS[c] "VEK" OR eventMessage CONTAINS[c] "keybag"' --info --debug --style compact
Filtering the log data using "sender == "AppleKeyStore" OR composedMessage CONTAINS[c] "VEK" OR composedMessage CONTAINS[c] "keybag""
Timestamp Ty Process[PID:TID]
2026-08-29 23:07:09.742 Df kernel[0:2531] (AppleKeyStore) "AppleKeyStore":pid:139,:13297: operation failed (sel: 17 ret: e00002f0, -1)
2026-08-29 23:07:09.744 Df kernel[0:2531] (AppleKeyStore) "AppleKeyStore":pid:139,:13297: operation failed (sel: 17 ret: e00002f0, -1)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
2026-08-29 23:07:10.478 Df kernel[0:17cf] (AppleKeyStore) "AppleKeyStore":pid:139,:13297: operation failed (sel: 17 ret: e00002f0, -1)
2026-08-29 23:07:10.480 Df kernel[0:17cf] (AppleKeyStore) "AppleKeyStore":pid:139,:13297: operation failed (sel: 17 ret: e00002f0, -1)
2026-08-29 23:07:10.481 Df kernel[0:17cf] (AppleKeyStore) "AppleKeyStore":pid:139,:13297: operation failed (sel: 17 ret: e00002f0, -1)
2026-08-29 23:07:10.482 Df kernel[0:17cf] (AppleKeyStore) "AppleKeyStore":pid:139,:13297: operation failed (sel: 17 ret: e00002f0, -1)
2026-08-29 23:07:10.869 Df kernel[0:277f] (AppleKeyStore) "AppleKeyStore":pid:753,:13297: operation failed (sel: 17 ret: e00002f0, -1)
2026-08-29 23:07:11.070 Df kernel[0:277f] (AppleKeyStore) "AppleKeyStore":pid:753,:13297: operation failed (sel: 17 ret: e00002f0, -1)
2026-08-29 23:07:13.374 Df dasd[157:89a] [com.apple.duetactivityscheduler:scoring] 0:com.apple.mobile.keybagd.space_repetition:2164A4:[
{name: Battery Level Policy, policyWeight: 1.000, response: {33, 0.00, [{batteryLevel == 17 AND pluggedIn == 0}]}}
], Decision: MNP}
2026-08-29 23:07:13.395 Df dasd[157:89a] [com.apple.duetactivityscheduler:scoring] 0:com.apple.mobile.keybagd.data-analytics:8F877A:[
{name: Battery Level Policy, policyWeight: 1.000, response: {33, 0.00, [{batteryLevel == 17 AND pluggedIn == 0}]}}
], Decision: MNP}
2026-08-29 23:07:18.622 Df kernel[0:2b0e] (AppleKeyStore) "AppleKeyStore":pid:157,:13297: operation failed (sel: 17 ret: e00002f0, -1)
2026-08-29 23:07:18.813 Df kernel[0:2b0e] (AppleKeyStore) "AppleKeyStore":pid:157,:13297: operation failed (sel: 17 ret: e00002f0, -1)
2026-08-29 23:07:22.631 Df kernel[0:20df] (AppleKeyStore) "AppleKeyStore":pid:139,:13297: operation failed (sel: 17 ret: e00002f0, -1)
2026-08-29 23:07:22.632 Df kernel[0:20df] (AppleKeyStore) "AppleKeyStore":pid:139,:13297: operation failed (sel: 17 ret: e00002f0, -1)
2026-08-29 23:07:22.633 Df kernel[0:20df] (AppleKeyStore) "AppleKeyStore":pid:139,:13297: operation failed (sel: 17 ret: e00002f0, -1)
2026-08-29 23:07:22.634 Df kernel[0:20df] (AppleKeyStore) "AppleKeyStore":pid:139,:13297: operation failed (sel: 17 ret: e00002f0, -1)
2026-08-29 23:07:28.719 Db siriinferenced[807:2be6] [com.apple.CFBundle:loading] dlfcn check load bundle CFBundle 0x7f77d2b2d800 </System/Library/PrivateFrameworks/MobileKeyBag.framework> (not loaded), dlopen of /System/Library/PrivateFrameworks/MobileKeyBag.framework/MobileKeyBag mode 0x115 getting handle 0x685162a59
2026-08-29 23:07:30.492 Df dasd[157:89a] [com.apple.duetactivityscheduler:scoring] 0:com.apple.mobile.keybagd.space_repetition:2164A4:[
{name: Battery Level Policy, policyWeight: 1.000, response: {33, 0.00, [{batteryLevel == 16 AND pluggedIn == 0}]}}
], Decision: MNP}
2026-08-29 23:07:30.556 Df dasd[157:2b0f] [com.apple.duetactivityscheduler:scoring] 0:com.apple.mobile.keybagd.space_repetition:2164A4:[
{name: Battery Level Policy, policyWeight: 1.000, response: {33, 0.00, [{batteryLevel == 16 AND pluggedIn == 0}]}}
], Decision: MNP}
2026-08-29 23:07:37.473 Df remotemanagementd[929:2c4c] [com.apple.xpc:connection] [0x7fbb2b71a6a0] activating connection: mach=true listener=false peer=false name=com.apple.mobile.keybagd.UserManager.xpc
2026-08-29 23:07:37.473 E kernel[0:bad] (Sandbox) Sandbox: remotemanagementd(929) deny(1) mach-lookup com.apple.mobile.keybagd.UserManager.xpc
2026-08-29 23:07:47.072 Df dasd[157:2c3e] [com.apple.duetactivityscheduler:scoring] 0:com.apple.mobile.keybagd.space_repetition:2164A4:[
{name: Battery Level Policy, policyWeight: 1.000, response: {33, 0.00, [{batteryLevel == 16 AND pluggedIn == 0}]}}
], Decision: MNP}
2026-08-29 23:07:58.417 Db authd[270:2e30] [com.apple.securityd:staticCode] 0x7fc65b1097b8 done serializing com.apple.MobileAsset.SoftwareUpdatecom.apple.apfs.wvekcom.apple.bluetooth.systemcom.apple.fileprovider.import-cookiecom.apple.keystore.filevaultcom.apple.private.AuthorizationServicessystem.preferencescom.apple.SoftwareUpdate.modify-settingscom.apple.private.CoreAnalytics.ManagementCommands.allowcom.apple.private.CoreAnalytics.RolloverEvents.allowcom.apple.private.LocalAuthentication.Storagecom.apple.private.LocalAuthentication.Storage.SetLockdownModecom.apple.private.admin.writeconfigcom.apple.private.assets.change-daemon-configcom.apple.private.backupd.session</key<…>
2026-08-29 23:07:58.426 Db authd[270:2aeb] [com.apple.securityd:staticCode] 0x7fc65b20ed38 done serializing com.apple.MobileAsset.SoftwareUpdatecom.apple.apfs.wvekcom.apple.bluetooth.systemcom.apple.fileprovider.import-cookiecom.apple.keystore.filevaultcom.apple.private.AuthorizationServicessystem.preferencescom.apple.SoftwareUpdate.modify-settingscom.apple.private.CoreAnalytics.ManagementCommands.allowcom.apple.private.CoreAnalytics.RolloverEvents.allowcom.apple.private.LocalAuthentication.Storagecom.apple.private.LocalAuthentication.Storage.SetLockdownModecom.apple.private.admin.writeconfigcom.apple.private.assets.change-daemon-configcom.apple.private.backupd.session</key<…>
2026-08-29 23:07:58.435 Db airportd[252:2c52] [com.apple.securityd:staticCode] 0x7fb9b821bc78 done serializing com.apple.MobileAsset.SoftwareUpdatecom.apple.apfs.wvekcom.apple.bluetooth.systemcom.apple.fileprovider.import-cookiecom.apple.keystore.filevaultcom.apple.private.AuthorizationServicessystem.preferencescom.apple.SoftwareUpdate.modify-settingscom.apple.private.CoreAnalytics.ManagementCommands.allowcom.apple.private.CoreAnalytics.RolloverEvents.allowcom.apple.private.LocalAuthentication.Storagecom.apple.private.LocalAuthentication.Storage.SetLockdownModecom.apple.private.admin.writeconfigcom.apple.private.assets.change-daemon-configcom.apple.private.backupd.session</key<…>
2026-08-29 23:07:58.466 Db authd[270:2aeb] [com.apple.securityd:staticCode] 0x7fc65b0057e8 done serializing com.apple.MobileAsset.SoftwareUpdatecom.apple.apfs.wvekcom.apple.bluetooth.systemcom.apple.fileprovider.import-cookiecom.apple.keystore.filevaultcom.apple.private.AuthorizationServicessystem.preferencescom.apple.SoftwareUpdate.modify-settingscom.apple.private.CoreAnalytics.ManagementCommands.allowcom.apple.private.CoreAnalytics.RolloverEvents.allowcom.apple.private.LocalAuthentication.Storagecom.apple.private.LocalAuthentication.Storage.SetLockdownModecom.apple.private.admin.writeconfigcom.apple.private.assets.change-daemon-configcom.apple.private.backupd.session</key<…>
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
=== Messages dropped during live streaming (use log show to see what they were)
2026-08-29 23:09:11.111 Df dasd[157:3362] [com.apple.duetactivityscheduler:scoring] 0:com.apple.mobile.keybagd.space_repetition:2164A4:[
{name: Battery Level Policy, policyWeight: 1.000, response: {33, 0.00, [{batteryLevel == 16 AND pluggedIn == 0}]}}
], Decision: MNP}
2026-08-29 23:09:15.362 Df tipsd[968:33f3] [com.apple.xpc:connection] [0x7fc7bd908060] activating connection: mach=true listener=false peer=false name=com.apple.mobile.keybagd.UserManager.xpc
2026-08-29 23:09:15.363 E kernel[0:3168] (Sandbox) Sandbox: tipsd(968) deny(1) mach-lookup com.apple.mobile.keybagd.UserManager.xpc
2026-08-29 23:09:19.575 Df kernel[0:2b8c] (AppleKeyStore) "AppleKeyStore":pid:139,:13297: operation failed (sel: 17 ret: e00002f0, -1)
2026-08-29 23:09:19.578 Df kernel[0:2b8c] (AppleKeyStore) "AppleKeyStore":pid:139,:13297: operation failed (sel: 17 ret: e00002f0, -1)
2026-08-29 23:09:20.977 Df kernel[0:3431] (AppleKeyStore) "AppleKeyStore":pid:139,:13297: operation failed (sel: 17 ret: e00002f0, -1)
2026-08-29 23:09:20.979 Df kernel[0:3431] (AppleKeyStore) "AppleKeyStore":pid:139,:13297: operation failed (sel: 17 ret: e00002f0, -1)
2026-08-29 23:09:20.981 Df kernel[0:3431] (AppleKeyStore) "AppleKeyStore":pid:139,:13297: operation failed (sel: 17 ret: e00002f0, -1)
2026-08-29 23:09:20.982 Df kernel[0:3431] (AppleKeyStore) "AppleKeyStore":pid:139,:13297: operation failed (sel: 17 ret: e00002f0, -1)
2026-08-29 23:09:26.237 Df dasd[157:899] [com.apple.duetactivityscheduler:scoring] 0:com.apple.mobile.keybagd.space_repetition:2164A4:[
{name: Battery Level Policy, policyWeight: 1.000, response: {33, 0.00, [{batteryLevel == 15 AND pluggedIn == 0}]}}
], Decision: MNP}
2026-08-29 23:09:29.634 Df kernel[0:3433] (AppleKeyStore) "AppleKeyStore":pid:139,:13297: operation failed (sel: 17 ret: e00002f0, -1)
2026-08-29 23:09:29.636 Df kernel[0:3433] (AppleKeyStore) "AppleKeyStore":pid:139,:13297: operation failed (sel: 17 ret: e00002f0, -1)
2026-08-29 23:09:29.638 Df kernel[0:3433] (AppleKeyStore) "AppleKeyStore":pid:139,:13297: operation failed (sel: 17 ret: e00002f0, -1)
2026-08-29 23:09:29.640 Df kernel[0:3433] (AppleKeyStore) "AppleKeyStore":pid:139,:13297: operation failed (sel: 17 ret: e00002f0, -1)
2026-08-29 23:09:42.483 Df dasd[157:35a3] [com.apple.duetactivityscheduler:scoring] 0:com.apple.mobile.keybagd.space_repetition:2164A4:[
{name: Battery Level Policy, policyWeight: 1.000, response: {33, 0.00, [{batteryLevel == 15 AND pluggedIn == 0}]}}
], Decision: MNP}
2026-08-29 23:09:52.157 Df kernel[0:35a4] (AppleKeyStore) "AppleKeyStore":pid:157,:13297: operation failed (sel: 17 ret: e00002f0, -1)
2026-08-29 23:09:52.162 Df kernel[0:35a4] (AppleKeyStore) "AppleKeyStore":pid:157,:13297: operation failed (sel: 17 ret: e00002f0, -1)
2026-08-29 23:09:54.625 Df dasd[157:35a3] [com.apple.duetactivityscheduler:scoring] 0:com.apple.mobile.keybagd.space_repetition:2164A4:[
{name: Battery Level Policy, policyWeight: 1.000, response: {33, 0.00, [{batteryLevel == 15 AND pluggedIn == 0}]}}
], Decision: MNP}
2026-08-29 23:09:57.486 Df dasd[157:3614] [com.apple.duetactivityscheduler:scoring] 0:com.apple.mobile.keybagd.space_repetition:2164A4:[
{name: Battery Level Policy, policyWeight: 1.000, response: {33, 0.00, [{batteryLevel == 15 AND pluggedIn == 0}]}}
], Decision: MNP}
2026-08-29 23:10:25.253 Df kernel[0:2f62] (AppleKeyStore) "AppleKeyStore":pid:753,:13297: operation failed (sel: 17 ret: e00002f0, -1)
2026-08-29 23:10:25.264 Df kernel[0:2f62] (AppleKeyStore) "AppleKeyStore":pid:753,:13297: operation failed (sel: 17 ret: e00002f0, -1)

This is with running First Aid on a partition

@DrDonk · August 31, 2026

I think that this will never work with T2 due to how security modes and sepOS work. I am going to write what I think is happening in a new post where I have been looking at the T2 papers and videos from Apple and various security researchers.

@Medelcartelinc I think this error doesn't have to do with sepOS or the T2, otherwise the kernel wouldn't even be able to start.

@rizosprime, this is a known limitation with T1/T2 Macs when using SMBIOS spoofing.
The error -69624 happens because you are trying to create an encrypted APFS volume (FileVault) directly from the Recovery Environment. Because OCLP is actively spoofing your SMBIOS to a newer model to allow the Tahoe installation, the T2's Secure Enclave Processor (SEP) detects the hardware mismatch and refuses to generate the cryptographic keybags for the volume, causing diskutil to fail.

Open Disk Utility and erase the drive as standard APFS (Unencrypted). Do not set a password or passphrase.
Proceed with the macOS Tahoe installation normally.
Once macOS is installed and you are booted into your user account, go to System Settings > Privacy & Security > FileVault and turn it on from there.
Enabling FileVault from within the booted OS works perfectly fine because the SEP handles the encryption keys differently at that stage.

@albert-mueller You are confusing Secure Boot with the Secure Enclave (SEP) Data Protection. They are two completely different subsystems of the T2 chip.
The kernel is able to start because OpenCore successfully bypasses the early Secure Boot checks (usually by overriding the SecureBootModel or injecting VMM flags).
However, FileVault encryption does not rely on Secure Boot t relies on the SEP to securely wrap the Volume Encryption Key (VEK). When Disk Utility attempts to format the drive as Encrypted APFS in Recovery, macOS asks the SEP to generate the cryptographic keys. Because we are spoofing the SMBIOS, the SEP detects that the injected board-id doesn't match its internal bridgeOS firmware and immediately rejects the key generation request (which results in the -69624 error).
This is why the kernel can boot perfectly fine, but hardware-backed encryption fails when generated from the installer under a spoofed SMBIOS. Doing it from the booted OS usually succeeds because the SEP handles user-space key generation differently once the OS is fully initialized.

@albert-mueller You are confusing Secure Boot with the Secure Enclave (SEP) Data Protection. They are two completely different subsystems of the T2 chip.
The kernel is able to start because OpenCore successfully bypasses the early Secure Boot checks (usually by overriding the SecureBootModel or injecting VMM flags).
However, FileVault encryption does not rely on Secure Boot t relies on the SEP to securely wrap the Volume Encryption Key (VEK). When Disk Utility attempts to format the drive as Encrypted APFS in Recovery, macOS asks the SEP to generate the cryptographic keys. Because we are spoofing the SMBIOS, the SEP detects that the injected board-id doesn't match its internal bridgeOS firmware and immediately rejects the key generation request (which results in the -69624 error).
This is why the kernel can boot perfectly fine, but hardware-backed encryption fails when generated from the installer under a spoofed SMBIOS. Doing it from the booted OS usually succeeds because the SEP handles user-space key generation differently once the OS is fully initialized.

@Medelcartelinc On a 2020 4 thunderbolt 3 ports MacBook Pro, with spoofed SMBIOS I managed to get Tahoe booting, however no external APFS partitions could be mounted.

@Medelcartelinc However, on Mac mini 2018 it panics, and haven't made progress without SMBIOS spoofing… will test again.

@albert-mueller The kernel panic on the Mac mini 2018 without SMBIOS spoofing is entirely expected: Tahoe officially drops support for that board-id, so the kernel triggers an early "Unsupported platform" panic before WindowServer even starts. You must spoof the SMBIOS to boot.nRegarding the 2020 MacBook Pro not being able to mount external APFS partitions: this is actually another side-effect of the exact same SEP/SMBIOS mismatch! In macOS Tahoe, apfs.kext is much stricter and often communicates with the SEP to validate volume signatures or metadata (especially for APFS volumes that might contain sealed snapshots or specific APFS features). Because the SEP is in a partial lockdown state due to the spoofed board-id, it refuses to validate the mount requests.
To fix the external APFS mounting issue on T2 Macs, we will likely need a dedicated kernel patch (probably integrated into RestrictEvents.kext) to bypass the new Tahoe APFS/SEP validation checks, similar to how revpatch=sbvmm bypasses the firmware checks.
For the time being, the user in this issue should still proceed with installing on an unencrypted standard APFS drive and enabling FileVault later.

@albert-mueller The kernel panic on the Mac mini 2018 without SMBIOS spoofing is entirely expected: Tahoe officially drops support for that board-id, so the kernel triggers an early "Unsupported platform" panic before WindowServer even starts. You must spoof the SMBIOS to boot.nRegarding the 2020 MacBook Pro not being able to mount external APFS partitions: this is actually another side-effect of the exact same SEP/SMBIOS mismatch! In macOS Tahoe, apfs.kext is much stricter and often communicates with the SEP to validate volume signatures or metadata (especially for APFS volumes that might contain sealed snapshots or specific APFS features). Because the SEP is in a partial lockdown state due to the spoofed board-id, it refuses to validate the mount requests.
To fix the external APFS mounting issue on T2 Macs, we will likely need a dedicated kernel patch (probably integrated into RestrictEvents.kext) to bypass the new Tahoe APFS/SEP validation checks, similar to how revpatch=sbvmm bypasses the firmware checks.
For the time being, the user in this issue should still proceed with installing on an unencrypted standard APFS drive and enabling FileVault later.

This happens without FileVault on my end, I tried deleting a non-encrypted partition even on my end and failed to do so.

@albert-mueller · September 1, 2026 · edited

@albert-mueller The kernel panic on the Mac mini 2018 without SMBIOS spoofing is entirely expected: Tahoe officially drops support for that board-id, so the kernel triggers an early "Unsupported platform" panic before WindowServer even starts. You must spoof the SMBIOS to boot.nRegarding the 2020 MacBook Pro not being able to mount external APFS partitions: this is actually another side-effect of the exact same SEP/SMBIOS mismatch! In macOS Tahoe, apfs.kext is much stricter and often communicates with the SEP to validate volume signatures or metadata (especially for APFS volumes that might contain sealed snapshots or specific APFS features). Because the SEP is in a partial lockdown state due to the spoofed board-id, it refuses to validate the mount requests.
To fix the external APFS mounting issue on T2 Macs, we will likely need a dedicated kernel patch (probably integrated into RestrictEvents.kext) to bypass the new Tahoe APFS/SEP validation checks, similar to how revpatch=sbvmm bypasses the firmware checks.
For the time being, the user in this issue should still proceed with installing on an unencrypted standard APFS drive and enabling FileVault later.

Unfortunately, I don't know C++, only a little of C# just enough to write an app. And also, ask Claude for smth and understand a fraction of the code in C++. That's it.
Would you be able to do this instead?
I know Python, however and that's the only language at which I'm good at.
@Medelcartelinc

@albert-mueller Sure, I can definitely take a look into this!
Writing a Lilu-based kernel patch to bypass the APFS/SEP validations is going to require some deep reverse-engineering of Tahoe's apfs.kext and the T2 management drivers to find the exact symbols to hook (e.g., intercepting the keybag requests or spoofing the volume validation routines).
t will take me some time to analyze the kernel binaries and write the C++ implementation, but I'll start looking into the macOS 26 kernel dumps and see if I can draft a patch for RestrictEvents.kext (or a standalone Lilu plugin). I'll keep you updated on the progress!

@albert-mueller · September 1, 2026 · edited

@albert-mueller Sure, I can definitely take a look into this! Writing a Lilu-based kernel patch to bypass the APFS/SEP validations is going to require some deep reverse-engineering of Tahoe's apfs.kext and the T2 management drivers to find the exact symbols to hook (e.g., intercepting the keybag requests or spoofing the volume validation routines). t will take me some time to analyze the kernel binaries and write the C++ implementation, but I'll start looking into the macOS 26 kernel dumps and see if I can draft a patch for RestrictEvents.kext (or a standalone Lilu plugin). I'll keep you updated on the progress!

Until a month ago, when @DrDonk showed up and helped I used to reverse engineer using Ghidra combined with Claude, Gemini and Gemini Notebook. And were able to help to a point, but something like this requires a person who knows how to do this without AI tools, so your work will be valuable.
@Medelcartelinc