Show keyboard input menu on FileVault encrypted Mac

m_entholzner
Contributor III

Hi everyone,

acutally I got the problem, that on FileVault encrypted Macs the input menu for keyboard layouts won't show up in the boot screen.

The setting for the keyboard input menu is located in /Library/Preferences/com.apple.loginwindow with the key showInputMenu and a boolean value.

If I try to set the value via defaults write, the checkbox in System Preferences is active and the input menu is shown in login window. BUT if the computer is FileVault encrypted, the input menu won't show up in the boot screen.

Only if I set the checkbox manually in System Preferences, the input menu shows up in loginwindow and in boot screen.

I tried Composer to evaluate which files are changed during clicking in System Preferences. The only valuable file is /Library/Preferences/com.apple.loginwindow.

Does anyone have the same problems?

Thanks in advice,
Michael

1 ACCEPTED SOLUTION

Josh_S
Contributor III

I think I got this figured out. When you update a setting via the GUI, it updates the associated "efires" cache files and then writes those to the Recovery HD. In order to update the efires files without going through the GUI, you have to 1) Update the settings file, 2) Clear the efires cache files to force the system to rebuild them directly from the plist files the next time the Recovery HD is updated, and 3) Tell the system to update the Recovery HD.

defaults write /Library/Preferences/com.apple.loginwindow showInputMenu -bool TRUE
rm /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations/*.efires

Edit: Thanks Rich. It appears that you are right and that you do not need to run "fdesetup sync" to force an update. The system seems to automatically update the Recovery HD after erasing those files. I've updated the code block to remove that.

Technically the "sync" verb of fdesetup is not meant for this, and it might have unintended consequences if there is an OD/AD user account enabled for FileVault that has been deleted, but it does force an update of the preference files. Hopefully Apple realizes the need/desire for this functionality and includes it in a future update.

View solution in original post

17 REPLIES 17

Josh_S
Contributor III

When you check the box in the GUI it makes some modifications to files on the recovery partition, which makes sense because the main drive is not decrypted at that stage of login on a FV2 encrypted Mac. What is currently eluding me is how to push settings changes to the recovery partition. I'll play a bit more and see if I can figure it out.

Josh_S
Contributor III

I think I got this figured out. When you update a setting via the GUI, it updates the associated "efires" cache files and then writes those to the Recovery HD. In order to update the efires files without going through the GUI, you have to 1) Update the settings file, 2) Clear the efires cache files to force the system to rebuild them directly from the plist files the next time the Recovery HD is updated, and 3) Tell the system to update the Recovery HD.

defaults write /Library/Preferences/com.apple.loginwindow showInputMenu -bool TRUE
rm /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations/*.efires

Edit: Thanks Rich. It appears that you are right and that you do not need to run "fdesetup sync" to force an update. The system seems to automatically update the Recovery HD after erasing those files. I've updated the code block to remove that.

Technically the "sync" verb of fdesetup is not meant for this, and it might have unintended consequences if there is an OD/AD user account enabled for FileVault that has been deleted, but it does force an update of the preference files. Hopefully Apple realizes the need/desire for this functionality and includes it in a future update.

m_entholzner
Contributor III

Perfect, this works! Many thanks for figuring this out, you made my day :)

rtrouton
Release Candidate Programs Tester

The fdesetup sync part may not be needed. I was able to do this:

sudo defaults write /Library/Preferences/com.apple.loginwindow LoginwindowText "My Login Window Text Goes Here"
sudo defaults write /Library/Preferences/com.apple.loginwindow showInputMenu -bool TRUE
sudo rm /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations/*.efires

On restart, the FileVault pre-boot login screen looked like this, with keyboard input and login text now showing.

external image link

mm2270
Legendary Contributor III

All good information. Thanks Josh_S and Rich for figuring this stuff out. Though we don't currently have a need to enable this, its nice to know its possible.

rtrouton
Release Candidate Programs Tester

mboylan
New Contributor

Rather than manually removing those caches, the Apple recommended way to synchronize the EFI loginwindow is via the following command:

sudo touch /System/Library/PrivateFrameworks/EFILogin.framework/Resources/EFIResourceBuilder.bundle/Contents/Resources

You'll see log entries like the following afterwards:

Jun 24 13:22:49 mbp-boylan.local com.apple.kextcache[29396]: rebuilding /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations
Jun 24 13:22:49 mbp-boylan.local efilogin-helper[29397]: targetVolume: /
Jun 24 13:22:49 mbp-boylan.local efilogin-helper[29397]: **** WARNING: cannot find showInputMenu key assumining NO
Jun 24 13:22:53 mbp-boylan.local com.apple.kextcache[29396]: /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations not cached.
Jun 24 13:22:53 mbp-boylan.local fseventsd[64]: Logging disabled completely for device:1: /Volumes/Recovery HD
Jun 24 13:22:54 mbp-boylan.local com.apple.kextcache[29396]: Successfully updated disk0s3.

maiksanftenberg
Contributor II

I used this till now as well to fix my problem with "out of sync" FileVault passwords (in most cases Users forgotten there passwords).
But it seems to be not longer working since 10.9.4 for mobile AD accounts.

Did anybody have an idea why?

Thanks

m_entholzner
Contributor III

FileVault passwords have to be synced with an "fdesetup sync".

maiksanftenberg
Contributor II

@entholzner thanks.
I will give it a try.

Cheers,
Maik

gabester
Contributor III

So in 2019, does fdesetup sync now work to sync user passwords to FileVault? Stumbling across these words suggests otherwise, but it's also my first time encountering this discussion, as I'd previously thought fdesetup sync was the answer and am now seeking to find something else for cases where it fails to sync the password occasionally.

bearzooka
Contributor

I know this is an old post, but in 2019, with Mojave and Catalina, the recommended commands were not working, so I created a script that gets the keyboard layout from the user settings and inserts it into the PLIST that will set the layout on the FileVault screen.

I recommend deploying through SelfService or automated after enabling FileVault.

opus-nbo
New Contributor

@bearzooka The script does run correctly under macOS Montery 12.1 (FileVault enabled) but has no effect. Keyboard layout as well as interface language on login screen stay US.

bearzooka
Contributor

@opus-nbo Yeah, we're noticing that recently. I'll try to figure out if it's still possible and update the script.

bearzooka
Contributor

@opus-nboI just figured out that now we need to delete the dictionary first; I've updated the script accordingly. Let me know how it goes.

somnico
New Contributor III

I tested the script with Monterey 12.2.1 in a Self Service policy. Script output in the log looks good. "Will set to Swiss German - 19."

 

But after a shutdown/startup my FV loginwindow still shows first "US" and then switches to "ABC".

Sven_S
New Contributor III

Look no further. I've found another thread with a working solution: https://community.jamf.com/t5/jamf-nation/login-screen-with-wrong-language/m-p/274313#M796