Skip to main content
Solved

Show keyboard input menu on FileVault encrypted Mac

M
Forum|alt.badge.img+16

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

Best answer by Josh_S

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 original
    Did this topic help you find an answer to your question?

    J
    Forum|alt.badge.img+11
    • Josh_S
    • Contributor
    • June 15, 2013

    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.

    J
    Forum|alt.badge.img+11
    • Josh_S
    • Contributor
    • June 17, 2013

    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.

    F
    1 person likes this
    • F
      flampel
    M
    Forum|alt.badge.img+16

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

    R
    Forum|alt.badge.img+31

    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
    Forum|alt.badge.img+16
    • mm2270
    • Legendary Contributor
    • June 18, 2013

    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.

    R
    Forum|alt.badge.img+31

    I've written a post on this, available from here:

    http://derflounder.wordpress.com/2013/06/19/enabling-filevault-2-pre-boot-login-screen-functions-from-the-command-line/

    M
    Forum|alt.badge.img
    • mboylan
    • New Contributor
    • June 24, 2013

    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.
    M
    Forum|alt.badge.img+9

    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
    Forum|alt.badge.img+16
    • m_entholzner
    • Honored Contributor
    • October 2, 2014

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

    M
    Forum|alt.badge.img+9

    @entholzner thanks.
    I will give it a try.

    Cheers,
    Maik

    G
    Forum|alt.badge.img+10
    • gabester
    • Valued Contributor
    • May 7, 2019

    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.

    B
    Forum|alt.badge.img+8
    • bearzooka
    • Valued Contributor
    • July 26, 2019

    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.

    O
    Forum|alt.badge.img+3
    • opus-nbo
    • New Contributor
    • February 9, 2022

    @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.

    B
    Forum|alt.badge.img+8
    • bearzooka
    • Valued Contributor
    • February 9, 2022

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

    B
    Forum|alt.badge.img+8
    • bearzooka
    • Valued Contributor
    • February 9, 2022

    @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
    Forum|alt.badge.img+5
    • somnico
    • New Contributor
    • February 22, 2022
    bearzooka wrote:

    @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.


    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".

    S
    Forum|alt.badge.img+2
    • Sven_S
    • New Contributor
    • February 14, 2023
    somnico wrote:

    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".


    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

    Reply


    Most helpful members this week

    Terms & ConditionsCookie settingsAccessibility statement

    Cookie policy

    We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

     
    Cookie settings