Bug 202703 - geom_eli_passphrase_prompt doesn't work with (at least) various USB keyboards
Summary: geom_eli_passphrase_prompt doesn't work with (at least) various USB keyboards
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 10.2-RELEASE
Hardware: amd64 Any
: --- Affects Many People
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-08-28 02:57 UTC by Mason Loring Bliss
Modified: 2017-08-14 00:51 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mason Loring Bliss 2015-08-28 02:57:42 UTC
geom_eli_passphrase_prompt isn't working on a Dell Precision WorkStation T5400 I've got here, which uses an identical set-up to another system I have - two SATA disks, ZFS maintaining a bootpool across them, GELI across the rest and ZFS maintaining a pool on that.

I note the GELI password prompt on boot, enter the passphrase, and then get the normal mid-boot passphrase when the kernel tries to mount the root filesystem, which requires a frantic whacking of the enter key until I see a linefeed, after which I'm told my passphrase was incorrect but I'm given a chance to authenticate, which succeeds and continues into the boot.

$ uname -a
FreeBSD lethe 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r286666: Wed Aug 12 15:26:37 UTC 2015     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
$ cat /boot/loader.conf 
geom_eli_passphrase_prompt="YES"
geli_ada0p4_keyfile0_load="YES"
geli_ada0p4_keyfile0_type="ada0p4:geli_keyfile0"
geli_ada0p4_keyfile0_name="/boot/encryption.key"
geli_ada1p4_keyfile0_load="YES"
geli_ada1p4_keyfile0_type="ada1p4:geli_keyfile0"
geli_ada1p4_keyfile0_name="/boot/encryption.key"
aesni_load="YES"
geom_eli_load="YES"
geom_mirror_load="YES"
vfs.root.mountfrom="zfs:zroot/ROOT/default"
zfs_load="YES"
kern.geom.label.gptid.enable="0"
zpool_cache_load="YES"
zpool_cache_type="/boot/zfs/zpool.cache"
zpool_cache_name="/boot/zfs/zpool.cache"

(the mirror_load is unnecessary, FWIW)
Comment 1 Mason Loring Bliss 2015-11-21 00:14:48 UTC
I've now seen this on another system running 10.2-RELEASE as well. It seems that the USB keyboard is not properly initialized or is otherwise consistently in a strange state when the prompt is presented.

As a workaround, whacking backspace once before entering a passphrase seems to get the keyboard into a better state. That said, it's not a matter of simply eating a key, as whacking something *other* than backspace evidently puts something into the queue and results in a bad passphrase.
Comment 2 Mason Loring Bliss 2015-12-02 09:45:47 UTC
Is this going to be triaged at some point? It's a fairly annoying issue. Is there some process in place to ensure that bugs don't sit forever without even a tentative poke?
Comment 3 Mason Loring Bliss 2017-08-10 19:24:32 UTC
FreeBSD is better off this way. Sorry for the bother.
Comment 4 Ed Maste freebsd_committer 2017-08-13 17:27:56 UTC
Allan, any ideas?
Comment 5 Allan Jude freebsd_committer 2017-08-13 17:44:23 UTC
(In reply to Ed Maste from comment #4)
This is not my feature, it is dteske@'s.

The loader is a very limited environment, and it depends on BIOS support for the USB keyboard, and does not support any kind of alternative keyboard layout.

EFI might be the only hope users have of getting something slightly better.
Comment 6 Devin Teske freebsd_committer 2017-08-14 00:51:22 UTC
Try this in /boot/loader.conf

hint.atkbdc.0.disabled="1"