Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[Bug 202703] geom_eli_passphrase_prompt doesn't work on Dell Precision WorkStation T5400

0 views
Skip to first unread message

bugzilla...@freebsd.org

unread,
Aug 27, 2015, 10:57:57 PM8/27/15
to freebs...@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202703

Bug ID: 202703
Summary: geom_eli_passphrase_prompt doesn't work on Dell
Precision WorkStation T5400
Product: Base System
Version: 10.2-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: freebs...@FreeBSD.org
Reporter: ma...@blisses.org

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 ro...@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)

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebs...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs...@freebsd.org"

bugzilla...@freebsd.org

unread,
Nov 20, 2015, 7:14:58 PM11/20/15
to freebs...@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202703

--- Comment #1 from Mason Loring Bliss <ma...@blisses.org> ---
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.

bugzilla...@freebsd.org

unread,
Nov 20, 2015, 7:15:58 PM11/20/15
to freebs...@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202703

Mason Loring Bliss <ma...@blisses.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Severity|Affects Only Me |Affects Many People

bugzilla...@freebsd.org

unread,
Nov 20, 2015, 7:16:21 PM11/20/15
to freebs...@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202703

Mason Loring Bliss <ma...@blisses.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Summary|geom_eli_passphrase_prompt |geom_eli_passphrase_prompt
|doesn't work on Dell |doesn't work with (at
|Precision WorkStation T5400 |least) various USB
| |keyboards

bugzilla...@freebsd.org

unread,
Dec 2, 2015, 4:46:01 AM12/2/15
to freebs...@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202703

--- Comment #2 from Mason Loring Bliss <ma...@blisses.org> ---
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?
0 new messages