A couple years ago, I installed 10.2-RELEASE amd64 on an Acer Aspire One Z (model ZC-700g, Intel Celeron J3160 CPU, 4GB RAM). During installation, I followed the instructions in the FreeBSD Handbook: In section 2.6, I chose Automatic Root-on-ZFS and changed the "Encrypt Disks?" option to yes, and followed the instructions in section 2.6.4. Since then, I updated and upgraded following the handbook, release notes, and errata documents. Yesterday, I upgraded from 11.2-RELEASE to 12.0-RELEASE. After shutting down to boot into the new kernel, I entered my passphrase at the GELI prompt which appears before the boot menu. However, the boot process stalled after the kernel booted, as if I entered a bad passphrase. Double-checking and slowing down my typing had no effect: I was entering the correct passphrase, consistent with all previous startups, but it wasn't being recognized. My current passphrase consists of runs where the letters are uppercase, long enough that it's easier to type with caps lock on. While trying to figure out what I was doing wrong, I noticed the GELI keypress spinner advance a step when I turned caps lock on and again when I turned it off; this is new. My passphrase wasn't recognized until I typed it in without the benefit of caps lock. Steps to reproduce: Install (or upgrade to) FreeBSD 11.2-RELEASE amd64 with "Automatic Root-on-ZFS," change "Encrypt Disks?" from NO to YES, set a passphrase including uppercase letters. Then, upgrade to 12.0-RELEASE. Expected behavior: The passphrase typed at the boot-time GELI prompt is recognized whether capitals are typed with Shift pressed or capitals are typed with caps lock on. Actual behavior: The passphrase is recognized if capitals are typed with Shift pressed, but it is not recognized if the caps lock key is used during passphrase entry.
Hi, Follow up questions: - Is this a separate, unencrypted bootpool setup? - geom_eli_passphrase_prompt="YES" in /boot/loader.conf?
I have a separate pool called bootpool, and I assume it's unencrypted. I'm too ignorant of ZFS management to be 100% confident. According to `zpool status`, it's also ada0p3 (no .eli), and according to `zfs list`, it mounts on /bootpool. The root pool, zroot, is ada0p5.eli, and zroot/ROOT/default mounts on /. When booting with what the system thought was a bad passphrase, it was only ada0p5 it asked me for. My /boot/loader.conf file wasn't changed during the upgrade, and it has a `geom_eli_passphrase_prompt="YES"` line.
New information: The caps lock key can be used, but backspace must be pressed once right after pressing caps lock.
Created attachment 207941 [details] git(1) diff against /boot/lua/password.lua Hi, Please try this patch against /boot/lua/password.lua.
The patch had no effect on passphrase input, both at the boot-time prompt and when asked for ada0p5's passphrase while the kernel booted up. The patch also had no effect on the boot-time display: The keypress spinner advanced with each press of caps lock.
Recently SHIFT also became (at least) a character: whenever I try to insert a capital letter by pressing the SHIFT key I see the bar indicating character insertion rotating full speed and of course the password is inserted wrong. The problem is present in 12.1-STABLE r354066 but was not there in 12.1-STABLE r353430.
(In reply to Lorenzo Salvadore from comment #6) Is this defect on BIOS or UEFI system? If it is UEFI, please run from loader OK prompt: chain /boot/loader_4th.efi - does it still have the defect? If this is BIOS system, does the defect appear with boot1 or loader? That is, if you enter the password and press the space when there is spinner, does boot: prompt appear? On boot: prompt, enter /boot/loader_4th and does the defect appear there? It would be helpful to know exactly where the issue does appear.
(In reply to Toomas Soome from comment #7) I'm on a UEFI system. I was unable to run the test you suggested: SHIFT is broken in the ok prompt too, so that I cannot insert the needed underscore. Whenever I press SHIFT I cannot add any character to the line I'm writing and only terminating it by pressing ENTER gets the prompt working again. CAPSLOCK works as expected on the ok prompt but does not for the GELI password insertion: it inserts a dummy character as described in comment #3.
(In reply to Lorenzo Salvadore from comment #8) please try this patch and please report me back the output: Index: stand/efi/libefi/efi_console.c =================================================================== --- stand/efi/libefi/efi_console.c (revision 355225) +++ stand/efi/libefi/efi_console.c (working copy) @@ -1112,6 +1112,9 @@ if (status == EFI_SUCCESS) { kss = key_data.KeyState.KeyShiftState; kp = &key_data.Key; + printf("kts: %x kss: %x scan: %x unicode: %x\n", + key_data.KeyState.KeyToggleState, kss, + kp->ScanCode, kp->UnicodeChar); if (kss & EFI_SHIFT_STATE_VALID) { /* @@ -1126,10 +1129,11 @@ kp->UnicodeChar++; } } + if (kp->ScanCode == 0 && kp->UnicodeChar == 0) + return (false); + keybuf_inschar(kp); + return (true); } - - keybuf_inschar(kp); - return (true); } return (false); }
(In reply to Toomas Soome from comment #9) I tested your patch on 12.1-STABLE r355326. Here are some outputs. Feel free to ask for more. - pressing SHIFT with CAPSLOCK off: kts: c0 kss:80000001 scan: 0 unicode: 0 - pressing SHIFT with CAPSLOCK on: kts: c4 kss:80000001 scan: 0 unicode: 0 - switching CAPSLOCK from off to on: kts: 80 kss:80000000 scan: 0 unicode: 0 - switching CAPSLOCK from on to off: kts: 84 kss:80000000 scan: 0 unicode: 0
(In reply to Lorenzo Salvadore from comment #10) ok, This output is expected, but is the input working now?
(In reply to Toomas Soome from comment #11) Sorry, I had forgotten to test the input itself. Yes, it works now. Thank you very much.
A commit references this bug: Author: tsoome Date: Tue Dec 3 18:36:39 UTC 2019 New revision: 355347 URL: https://svnweb.freebsd.org/changeset/base/355347 Log: loader: ReadKeyStrokeEx may return partial keystrokes In some systems we can receive no scancode nor unicodechar values. PR: 240760 Reported by: Ariel Millennium Thornton MFC after: 1 week Changes: head/stand/efi/libefi/efi_console.c
A commit references this bug: Author: tsoome Date: Mon Dec 9 21:10:18 UTC 2019 New revision: 355571 URL: https://svnweb.freebsd.org/changeset/base/355571 Log: MFC r355347: loader: ReadKeyStrokeEx may return partial keystrokes In some systems we can receive no scancode nor unicodechar values. PR: 240760 Reported by: Ariel Millennium Thornton Changes: _U stable/12/ stable/12/stand/efi/libefi/efi_console.c
(In reply to Ariel Millennium Thornton from comment #0) Ariel, is this issue fixed for you?
(In reply to Toomas Soome from comment #15) I'm afraid not. I just upgraded to 12.0-RELEASE-p12, and the issue is still present.
(In reply to Ariel Millennium Thornton from comment #16) I wonder if you could test stable/12, I am not sure about what patch is included in p12...
I have not been vigilant with this bug. Sorry about that. I am currently on the same PC and upgraded to FreeBSD version 12.2-RELEASE-p2, and this bug appears no longer present. I can enter the capital letters in my GELI passphrase with caps lock on again. I don't know which version or patch level the bugfix is in, but I was never able to test on STABLE, only on RELEASE. It's between these versions: 12.0-RELEASE-p12: bug was present 12.2-RELEASE-p2: bug is not present
^Triage: Assign to committer resolving and close the bug report