Bug 1240802

Proposed as a Blocker for 23-alpha by Fedora user juliuxpigface using the blocker tracking app because:

 Well, it might be a corner case related to qemu-kvm, but if anybody confirms it on bare metal, as it stands, it seems to violate release criteria "2.4.1 Expected installed system boot behavior - Encrypted partitions".

"In all of the above cases, if any system partitions were encrypted as part of the installation, the boot process must prompt for the passphrase(s) and correctly unlock the partition(s) when provided with the correct passphrase(s)."

Reference:
https://fedoraproject.org/wiki/Fedora_23_Alpha_Release_Criteria#Expected_installed_system_boot_behavior

just to be clear, with the example passphrase, you would hit these keys:

capslock
k
capslock
@
t
h
e
r
i
n
e
1
2
3

expecting it to produce K@therine123, but it fails? Is that the scenario?

(In reply to Adam Williamson from comment #2)
> just to be clear, with the example passphrase, you would hit these keys:
> 
> capslock
> k
> capslock
> @
> t
> h
> e
> r
> i
> n
> e
> 1
> 2
> 3
> 
> expecting it to produce K@therine123, but it fails? Is that the scenario?

Well, the scenario you described is correct. After some boots of my kvm-qemu guest, I can add some details :

1) If caps lock is enabled at 'grub stage', then it seems that I'll always hit the issue.

2) If caps lock is disabled at 'grub stage', then sometimes I won't hit the issue, but I can't really understand why.

3) Then, in any case, I'm pretty sure I always hit it if I type the "@" with the caps lock enabled, with this sequence:

shift + k
capslock
@
capslock
t
h
e
r
i
n
e
1
2
3

I can confirm that I can reproduce this against Fedora 22 too.

Discussed at today's blocker review meeting [1].

We decided to delay the decision and repropose this as final blocker - This bug could use some more testing of different keyboard layouts on bare metal.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2015-07-20/

Discussed at 2015-07-27 blocker review meeting: http://meetbot-raw.fedoraproject.org/fedora-blocker-review/2015-07-27/f23-blocker-review.2015-07-27-16.00.log.txt . We didn't get around to looking into this further last week, so the note from last week stands.

I tested this with virt-manager. On installed system when I boot to grub with Caps-lock on and I couldn't unlock the disk.

It behaves really strangely. If I have caps-lock on during boot I can unlock the disk by using Shift in reverse (use it to write lower case).

E. g.: I used password FedoraFTW. I let caps-lock on during boot. Then I have to type (with c-l still on, if I turn it off it doesn't work neither way) - f Shift+e Shift+d Shift+o Shift+r Shift+a FTW.


I think that handling of Caps-lock in terminal is broken in libvirt. Try to open tty3 and log in. Then turn on Caps lock and write something. It will produce mix of both upper and lower case chars. I filled another bug for this: bug 1249016

I'm still -1 for blocker. +1 FE. As it is sufficient just to turn off Cups Lock before booting.

I tried this on bare metal. I turned caps lock on just before grub appeared. Then when it booted to the prompt for decryption the input from keyboard seemed to not work. No key I pressed was processed (no points appeared in field for password and Esc didn't work too for switching to text mode).

After a while it will start to work again. Than I could write my password. But Cups Lock couldn't be turn on. Once I wasn't able to write password correctly at all. I'm not sure why. But it usually works after I wait a while (it's about 10 seconds).

Discussed at today's blocker review meeting [1].

It was decided to delay the decision again - This bug still needs some more digging done before we can determine it's status.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2015-08-03/

Discussed at 2015-08-20 blocker review meeting: http://meetbot-raw.fedoraproject.org/fedora-blocker-review/2015-08-20/f23-blocker-review.2015-08-20-16.05.log.txt . Rejected as a blocker: there's clearly weirdness here, multiple folks have reproduced it, but overall we figured it's not severe enough to block on. If you have weirdness with caps lock, turn off caps lock.

we don't handle caps lock in the luks password handling. We receive the keypresses directly from the kernel tty layer. If caps lock is broken there, it needs to be fixed in the kernel.

*********** MASS BUG UPDATE **************
 
We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 23 kernel bugs.
 
Fedora 23 has now been rebased to 4.7.4-100.fc23.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you have moved on to Fedora 24 or 25, and are still experiencing this issue, please change the version to Fedora 24 or 25.
 
If you experience different issues, please open a new bug report for those.

*********** MASS BUG UPDATE **************
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.