Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.bugs.dist > #907408 > unrolled thread

Bug#903641: Preserve numlock state during cryptdisk boot password prompt in plymouth

Started byPascal Vibet - ADACIS <pvibet@gmail.com>
First post2018-07-12 15:10 +0200
Last post2018-07-27 16:00 +0200
Articles 6 — 3 participants

Back to article view | Back to linux.debian.bugs.dist


Contents

  Bug#903641: Preserve numlock state during cryptdisk boot password prompt in plymouth Pascal Vibet - ADACIS <pvibet@gmail.com> - 2018-07-12 15:10 +0200
    Bug#903641: Preserve numlock state during cryptdisk boot password prompt in plymouth Guilhem Moulin <guilhem@debian.org> - 2018-07-12 16:00 +0200
      Bug#903641: Preserve numlock state during cryptdisk boot password prompt in plymouth Pascal Vibet - ADACIS <pvibet@gmail.com> - 2018-07-12 20:00 +0200
        Bug#903641: initramfs-tools-core: 'keymap' scripts don't preserve numlock state Guilhem Moulin <guilhem@debian.org> - 2018-07-12 20:40 +0200
    Bug#903641: Preserve numlock state during cryptdisk boot password prompt in plymouth Ben Hutchings <ben@decadent.org.uk> - 2018-07-27 15:20 +0200
      Bug#903641: Preserve numlock state during cryptdisk boot password prompt in plymouth Pascal Vibet - ADACIS <pvibet@gmail.com> - 2018-07-27 16:00 +0200

#907408 — Bug#903641: Preserve numlock state during cryptdisk boot password prompt in plymouth

FromPascal Vibet - ADACIS <pvibet@gmail.com>
Date2018-07-12 15:10 +0200
SubjectBug#903641: Preserve numlock state during cryptdisk boot password prompt in plymouth
Message-ID<waJw6-fD-21@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

Package: cryptsetup-initramfs
Version: 2:2.0.2-1ubuntu1

Dear Maintainers, i propose you my fix to this problem.

I'm using smartcard to decrypt luks disk, i'm using decrypt_opensc 
script in /etc/crypttab. I want to preserve numlock state during 
cryptdisk boot password prompt.

I found this article: 
https://superuser.com/questions/1062979/preserve-numlock-state-during-cryptdisk-boot-password-prompt-in-plymouth

So, i apply modifications like this:
in /usr/share/initramfs-tools/hooks/cryptopensc:
65a66
 > copy_exec /usr/bin/setleds

in /usr/share/initramfs-tools/scripts/local-top/cryptopensc:
36a37,45
 >
 > if [ ! -x /usr/bin/setleds ] ; then
 >     exit 0
 > fi
 >
 > INITTY=/dev/tty[1-8]
 > for tty in $INITTY ; do
 >    setleds -D +num < $tty
 > done

I apply modifications:
update-initramfs -u -k all

So i can use my numlock in boot password prompt for my smartcard.

Cheers,

[toc] | [next] | [standalone]


#907415

FromGuilhem Moulin <guilhem@debian.org>
Date2018-07-12 16:00 +0200
Message-ID<waKit-v1-7@gated-at.bofh.it>
In reply to#907408

[Multipart message — attachments visible in raw view] — view raw

Control: severity -1 minor

Hi,

On Thu, 12 Jul 2018 at 15:02:20 +0200, Pascal Vibet - ADACIS wrote:
> So, i apply modifications like this:
> in /usr/share/initramfs-tools/hooks/cryptopensc:
> […]
> in /usr/share/initramfs-tools/scripts/local-top/cryptopensc:

Why only in cryptopensc and not in cryptroot?  Also /usr/bin/setleds
comes from the ‘kbd’ package which cryptsetup-initramfs doesn't depend
on (it's only a Recommends, not a hard Depends), so `copy_exec` needs to
wrapped to check for the program's existence.

>> INITTY=/dev/tty[1-8]
>> for tty in $INITTY ; do
>>    setleds -D +num < $tty
>> done

Does that really *preserve* the numlock state?  I'm not familiar with
setleds(1), but according to the manpage it *sets* numlock and changes
the default settings.

Cheers,
-- 
Guilhem.

[toc] | [prev] | [next] | [standalone]


#907448

FromPascal Vibet - ADACIS <pvibet@gmail.com>
Date2018-07-12 20:00 +0200
Message-ID<waO2J-2GP-9@gated-at.bofh.it>
In reply to#907415

[Multipart message — attachments visible in raw view] — view raw

Hi,

Le 12/07/2018 à 15:48, Guilhem Moulin a écrit :
> Why only in cryptopensc and not in cryptroot?  Also /usr/bin/setleds
> comes from the ‘kbd’ package which cryptsetup-initramfs doesn't depend
> on (it's only a Recommends, not a hard Depends), so `copy_exec` needs to
> wrapped to check for the program's existence.
Because i don't test with cryptroot. For package depends or Recommends, 
the /usr/share/initramfs-tools/hooks/cryptopensc script need 
'dpkg-architecture' program to work and it is in 'dpkg-dev' package||.

But you are right, 'setleds'  is not the goods choice to keep numlock state.
I will search a better program.

Regards

Le 12/07/2018 à 15:48, Guilhem Moulin a écrit :
> Control: severity -1 minor
>
> Hi,
>
> On Thu, 12 Jul 2018 at 15:02:20 +0200, Pascal Vibet - ADACIS wrote:
>> So, i apply modifications like this:
>> in /usr/share/initramfs-tools/hooks/cryptopensc:
>> […]
>> in /usr/share/initramfs-tools/scripts/local-top/cryptopensc:
> Why only in cryptopensc and not in cryptroot?  Also /usr/bin/setleds
> comes from the ‘kbd’ package which cryptsetup-initramfs doesn't depend
> on (it's only a Recommends, not a hard Depends), so `copy_exec` needs to
> wrapped to check for the program's existence.
>
>>> INITTY=/dev/tty[1-8]
>>> for tty in $INITTY ; do
>>>      setleds -D +num < $tty
>>> done
> Does that really *preserve* the numlock state?  I'm not familiar with
> setleds(1), but according to the manpage it *sets* numlock and changes
> the default settings.
>
> Cheers,

[toc] | [prev] | [next] | [standalone]


#907453 — Bug#903641: initramfs-tools-core: 'keymap' scripts don't preserve numlock state

FromGuilhem Moulin <guilhem@debian.org>
Date2018-07-12 20:40 +0200
SubjectBug#903641: initramfs-tools-core: 'keymap' scripts don't preserve numlock state
Message-ID<waOFs-37Z-5@gated-at.bofh.it>
In reply to#907448

[Multipart message — attachments visible in raw view] — view raw

Control: severity -1 wishlist
Control: reassign -1 initramfs-tools-core
Control: retitle -1 initramfs-tools-core: 'keymap' scripts don't preserve numlock state

On Thu, 12 Jul 2018 at 19:46:02 +0200, Pascal Vibet - ADACIS wrote:
> Le 12/07/2018 à 15:48, Guilhem Moulin a écrit :
>> Why only in cryptopensc and not in cryptroot?  Also /usr/bin/setleds
>> comes from the ‘kbd’ package which cryptsetup-initramfs doesn't depend
>> on (it's only a Recommends, not a hard Depends), so `copy_exec` needs to
>> wrapped to check for the program's existence.
>
> Because i don't test with cryptroot.

You are, it's the hook that copies the cryptsetup binaries to the
initramfs…  And /scripts/local-top/cryptroot is run whenever you have
encrypted devices that need to be unlocked at initramfs stage (whether
or not some of these devices are using ‘keyscript=decrypt_opensct’).

> For package depends or Recommends, the
> /usr/share/initramfs-tools/hooks/cryptopensc script need
> 'dpkg-architecture' program to work and it is in 'dpkg-dev' package||.

No need, it's enough to check whether ‘/usr/bin/setleds’ exists, like
we're doing for ‘/usr/bin/gpg’ and some other binaries.

That being said I don't think restoring the numlock state is the job of
cryptsetup's initramfs hook & boot scripts, just like it's not its job
to install the right keyboard layout.

I'm therefore reassigning this to ‘initramfs-tools-core’, which is the
package shipping the keymap hook.

> But you are right, 'setleds' is not the goods choice to keep numlock state.
> I will search a better program.

An option would be to store the state when generating the initramfs
image, but that doesn't seem to be exactly what you want.  With full
disk encryption I don't know where else to store the state at shutdown
stage.

-- 
Guilhem.

[toc] | [prev] | [next] | [standalone]


#909710

FromBen Hutchings <ben@decadent.org.uk>
Date2018-07-27 15:20 +0200
Message-ID<wgaOZ-9y-3@gated-at.bofh.it>
In reply to#907408

[Multipart message — attachments visible in raw view] — view raw

Control: tag -1 moreinfo

On Thu, 12 Jul 2018 15:02:20 +0200 Pascal Vibet - ADACIS <pvibet@gmail.com> wrote:
> Package: cryptsetup-initramfs
> Version: 2:2.0.2-1ubuntu1
> 
> Dear Maintainers, i propose you my fix to this problem.
> 
> I'm using smartcard to decrypt luks disk, i'm using decrypt_opensc 
> script in /etc/crypttab. I want to preserve numlock state during 
> cryptdisk boot password prompt.
> 
> I found this article: 
> https://superuser.com/questions/1062979/preserve-numlock-state-during-cryptdisk-boot-password-prompt-in-plymouth
[...]

If plymouth specifically changes Num Lock state, this may be a bug in
plymouth.  However, I don't think it does.

I have a theory as to what might be happening:

* Each Linux virtual terminal (VT) has an independent keyboard
  lock/LED state.  When a different VT is activated, the driver will
  apply the lock/LED state for that VT.
* If you boot Linux in BIOS mode, the default state of Num Lock is set
  acccording to what the BIOS says it should be.
* If you boot Linux some other way, like UEFI, the default state is
  unknown and assumed to be off.
* plymouth opens and activates a new VT.  This applies the default
 
state.

Does this system boot using the BIOS or UEFI?

If it boots using UEFI, you can test this theory by doing:

1. In the boot menu, edit the kernel command line to remove "splash"
   and add "break=premount".
2. At the initramfs shell prompt, enter "openvt" to create a new VT.
3. Press Alt-F2 to activate the new VT.  Does Num Lock turn off?
4. Press Alt-F1 to activate the first VT.  Does Num Lock turn on or
   off?

Ben.

-- 
Ben Hutchings
Power corrupts.  Absolute power is kind of neat. - John Lehman

[toc] | [prev] | [next] | [standalone]


#909721

FromPascal Vibet - ADACIS <pvibet@gmail.com>
Date2018-07-27 16:00 +0200
Message-ID<wgbrH-na-5@gated-at.bofh.it>
In reply to#909710

[Multipart message — attachments visible in raw view] — view raw

Hi,

i will test your solutions.

Regards

2018-07-27 15:13 GMT+02:00 Ben Hutchings <ben@decadent.org.uk>:

> Control: tag -1 moreinfo
>
> On Thu, 12 Jul 2018 15:02:20 +0200 Pascal Vibet - ADACIS <pvibet@gmail.com>
> wrote:
> > Package: cryptsetup-initramfs
> > Version: 2:2.0.2-1ubuntu1
> >
> > Dear Maintainers, i propose you my fix to this problem.
> >
> > I'm using smartcard to decrypt luks disk, i'm using decrypt_opensc
> > script in /etc/crypttab. I want to preserve numlock state during
> > cryptdisk boot password prompt.
> >
> > I found this article:
> > https://superuser.com/questions/1062979/preserve-numlock-state-during-
> cryptdisk-boot-password-prompt-in-plymouth
> [...]
>
> If plymouth specifically changes Num Lock state, this may be a bug in
> plymouth.  However, I don't think it does.
>
> I have a theory as to what might be happening:
>
> * Each Linux virtual terminal (VT) has an independent keyboard
>   lock/LED state.  When a different VT is activated, the driver will
>   apply the lock/LED state for that VT.
> * If you boot Linux in BIOS mode, the default state of Num Lock is set
>   acccording to what the BIOS says it should be.
> * If you boot Linux some other way, like UEFI, the default state is
>   unknown and assumed to be off.
> * plymouth opens and activates a new VT.  This applies the default
>
> state.
>
> Does this system boot using the BIOS or UEFI?
>
> If it boots using UEFI, you can test this theory by doing:
>
> 1. In the boot menu, edit the kernel command line to remove "splash"
>    and add "break=premount".
> 2. At the initramfs shell prompt, enter "openvt" to create a new VT.
> 3. Press Alt-F2 to activate the new VT.  Does Num Lock turn off?
> 4. Press Alt-F1 to activate the first VT.  Does Num Lock turn on or
>    off?
>
> Ben.
>
> --
> Ben Hutchings
> Power corrupts.  Absolute power is kind of neat. - John Lehman
>
>

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.bugs.dist


csiph-web