Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.bugs.dist > #907408 > unrolled thread
| Started by | Pascal Vibet - ADACIS <pvibet@gmail.com> |
|---|---|
| First post | 2018-07-12 15:10 +0200 |
| Last post | 2018-07-27 16:00 +0200 |
| Articles | 6 — 3 participants |
Back to article view | Back to linux.debian.bugs.dist
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
| From | Pascal Vibet - ADACIS <pvibet@gmail.com> |
|---|---|
| Date | 2018-07-12 15:10 +0200 |
| Subject | Bug#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]
| From | Guilhem Moulin <guilhem@debian.org> |
|---|---|
| Date | 2018-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]
| From | Pascal Vibet - ADACIS <pvibet@gmail.com> |
|---|---|
| Date | 2018-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]
| From | Guilhem Moulin <guilhem@debian.org> |
|---|---|
| Date | 2018-07-12 20:40 +0200 |
| Subject | Bug#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]
| From | Ben Hutchings <ben@decadent.org.uk> |
|---|---|
| Date | 2018-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]
| From | Pascal Vibet - ADACIS <pvibet@gmail.com> |
|---|---|
| Date | 2018-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