Boot process hangs with FV enabled on 10.11.x?

Valued Contributor II

I noticed my freshly imaged 10.11.4 computers were hanging on boot when FV was enabled.

To troubleshoot, if I do an erase and install of 10.11.5 and enable FV through system prefs - machine boots normally.

If I do an erase and install of 10.11.5 and run quickadd to get machine talking to JSS and then run our enable FV policy, FV enables fine, but on boot up after I enter the local admin password, the progress bar hangs about 55% of the way through.

If I let it sit there for 15 minutes and it never boots. If I tap the return key, booting happens as normal.

It happens on every boot. I assumed it was a networking issue, so I disabled all network interfaces & same result. Nothing jumps out at me in the system.log, not sure what other logging to look at.

Anyone seen this, or have any ideas? We are using institutional and individual recovery keys.


Esteemed Contributor
Esteemed Contributor

@CasperSally I updated my FV2 Mac from 10.11.4 to 10.11.5 this AM.

It went through fine.

I'll await others to chime in though.

Valued Contributor

Do you have any log in hook policies?

Valued Contributor II

This is on new machines, nothing to do with latest update.

I notice in 'all messages' log after I tap return button to get machine to boot, 'mcxalr{x}' mentions. Maybe it has something to do with machine getting managed/profiles. Will retest with JAMF with a machine that doesn't get profiles.

Valued Contributor II

I think I tracked the issue down to custom plist config login window profile preference (AdminMayDisableMCX=true) to allow our technicians to disable profiles, on login they usually get attached pop up box but it's hanging the FV2 boot3cea0d81c077480b8138703eb931f581.

at least I know the cause of it - almost none of our users are admins.

New Contributor

Hey CasperSally,

I registered just for this thread! I also had this problem. I thought it was our A/V installing unsigned extensions causing SIP to act up but after tonnes of testing it came down to one profile that had that key in it.

As soon as I removed AdminMayDisableMCX, our build and deploy process worked fine.

I don't know why it breaks FileVault but at least wanted to chime in.

New Contributor II

Is AdminMayDisableMCX the only key you were managing on Maybe you are also locking automatic login into a false state which was conflicting with FV's automatic login mechanism?

Look into the DisableFDEAutoLogin key in