Can't Enter the Nitrokey-Pin after boot to unencrypt the luks partition

[madbehaviorus]

The script took my key without any warnings to the LuksKeySlot.
So far so good.
After the reboot, it shows the exactly little question from here, but I can only enter one or sometimes up to five characters and then nothing else. I can't go to "OK", "Cancel" or enter any character. I can switch between the cmdl and the "waiting linux spashscreen" with the up and down keys. The keyboard is active and registered every insert. It is not broken. I used it with much live distributions every day. With an external USB-keyboard it is the same, with one difference: If I reinsert the usb-cable, I can enter one character more. So I repeat this one to insert all characters from my Nitrokey phrase, switch to the "OK" button and....nothing....

The testdistribution is a new fresh debian bullseye netinstall with xfce.
The partitions are all manually created with the following layout:

• /boot
• /sda5 # luks device
  • sda5_crypt # lvm group volume with two volumes
    • root # lvm root
    • swap # lvm swap

Before I run the script, the 10m old fresh debian bullseye (debian-11.0.0-amd64-netinst.iso) installation are reboot without any problems. And I can confirm, my downloaded Image have the exactly same 512 hash from the debian site. The gpg sig is also correct. I run two machines without problems with this image.

So, where is the problem here?

madbehaviorus

[daringer]

The tests where made on an Ubuntu system, but I would bet that this makes no difference at all.

For me this looks like USB is somehow behaving in an undefined way, especially the fact that you can enter one more character after plugging in a usb keyboard is indicating this in my eyes.

Did you try the Nitrokey in another USB-port, in particular a usb2 port, or even maybe a usb2-hub, sometimes usb3+ ports behave weird with plain usb2 devices.

Further something suspicious is this:

I can switch between the cmdl and the "waiting linux spashscreen" with the up and down keys.

I would expect a behavior like this if you would hold the ctrl/alt key while pressing up/down, this further indicates that something is wrong with the actual usb-input. Maybe there even could be something weird during this stage of the system, could maybe nevertheless try another keyboard. Or is there maybe any other (hid) usb-device that could interfere here?

[madbehaviorus]

Thank you for your reply.

I think I must explain my device a bit more.

My test device is a Thinkpad r400. The onboard keyboard works without any issues on every live and installed distribution I've tested. Furthermore, it works in the BIOS, coreboot, libreboot and grub menu / cmdl also.

The external keyboard works also great (I've used and use it in many cases, on the same laptop and other laptops and workstations).

So, USB ports, onboard keyboard and external keyboard can't be the problem.

Today, I've tested on the same device with a actually xubuntu 20.04 installation on it, and it works like a charm. But first, I had to install pinentry-curses and pinentry-tty before the script can run update-grub.

In the next days, I hope I can find the time for testing Debian bullseye and look at the same issue...

EDIT: the the ubuntu installation was light different to the debian one. I use the same partitions without lvm.

[madbehaviorus]

Today I've tested the same debian installation method from above with the same result. I've tested an other keyboard also. I've put the ssd in another working (used as daily driver) t500 device with the same result.
Can you test this script with a fresh debian bullseye installation and report it?

I dont't know what 's the problem here...

edit: I followed this instructions.

[daringer]

ok, yeah if written a good part of that guide, but the -oem images have pending updates, means I'll surely see a fresh debian machine sooner or later