Preserve numlock state during cryptdisk boot password prompt in plymouth

Question

Each time my computer boots, there is prompt for password to decrypt hard drive (ubuntu is using plymouth). I'd like to use numeric keypad, but unfortunately plymouth changes numlock status to off ignoring my bios settings to enable numlock on boot (which is a bit irritating). Is there any "trick" to preserve numlock settings instead of being forced to change numlock to "on state" manually?

Answer 1

Plymouth starts from the initrd, long before your config files in /etc directory are accessible and read. Only files within initrd can be accessed when plymouth prompts for the passphrase to decrypt your root partition.

None of the classical solutions to activate numlock with the mdm, lightdm, etc. config files will work. Because these greeters starts after Plymouth. When I tried solutions based on "numlockx", none of them works. So I presume plymouth, at least in recent versions, starts before serverX.

After reading some man pages and many tries I finally succeed to activate numlock when Plymouth prompts for the passphrase. Please, note that I'm a Mint 17.3 user and my solution may need some adaptations depending on the Linux Distribution (refer to "initramfs-tools" and "setleds" man pages). Mint and Ubuntu are very close so actually the procedure described below may be identical or, at least, very similar.

I'm not a linux newbie but nevertheless I'm not an expert of the "initramfs" phase... so I would be happy of any improvement suggested that could make my method safer.

CAUTION : Be sure you exactly know how to start your OS from an alternative or backuped initrd in order to avoid to get stuck if the initrd generated by the following instructions refuse to boot !

We will use the setleds binary to activate numlock. So we must be sure it's available from inside the initrd image. Create a file "numlock" in your "/etc/initramfs-tools/hooks" directory (or its equivalent, according to your Linux Distrib.) with the following lines :

#! /bin/sh -e

PREREQ=""

prereqs () {
    echo "$PREREQ"
}

case $1 in
prereqs)
    prereqs
    exit 0
    ;;
esac

. /usr/share/initramfs-tools/hook-functions

# Add setleds to initrd
if test -x /usr/bin/setleds ; then
   copy_exec /usr/bin/setleds /usr/bin/setleds
fi

exit 0

Mark this file as executable :

# chmod 0755 numlock

The setleds binary will be accessible from inside the initrd the next times we will reconstruct "initramfs".

Now, we just need to write a little script to use setleds to activate the numlock... The main problem is to chose the right time to execute the script. If it is executed to soon, I guess the tty where Plymouth prompts will not yet be available or the keyboard configuration risks to override the numlock status. If the script is executed after the Plymouth's prompt, numlock will be activated too late...

According to my own experiments, everything is alright if the script is placed in the "/etc/initramfs-tools/scripts/init-top" directory with "console_setup" and "brltty" as prerequisites (not totally sure these prerequisites are necessary, but it works for me. Possibly, correct it according to the keyboard configuration scripts you have in your "/usr/share/initramfs-tools/scripts/init-top" directory).

Simply create in your "/etc/initramfs-tools/scripts/init-top" a script "numlock" with the following lines :

#!/bin/sh

PREREQ="console_setup brltty"
prereqs()
{
    echo "$PREREQ"
}
case $1 in
# get pre-requisites
prereqs)
    prereqs
    exit 0
    ;;
esac

if [ -x /usr/bin/setleds ] ; then
   INITTY=/dev/tty[1-8]
   for tty in $INITTY ; do 
       setleds -D +num < $tty 
       done 
fi

exit 0

Of course, mark this file as executable :

# chmod 0755 numlock

Re-construct your initrd :

# update-initramfs -u

If you're lucky, numlock should be automatically active on plymouth prompt the next time you boot. Note : I successfully reproduces this method on few production computers. Only one of them was a little slowly on first reboot... but I suspect that was due to another minor bug in the initramfs config files.