From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZizNpif3dnJ for ; Wed, 21 Sep 2011 05:06:01 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mail.saout.de (Postfix) with ESMTP for ; Wed, 21 Sep 2011 05:06:00 +0200 (CEST) Message-ID: <4E79548F.8080206@redhat.com> Date: Wed, 21 Sep 2011 05:05:51 +0200 From: Milan Broz MIME-Version: 1.0 References: <1316570636.4663.3@mofo> In-Reply-To: <1316570636.4663.3@mofo> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] Password is not accepted List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Karl O. Pinc" Cc: dm-crypt@saout.de On 09/21/2011 04:03 AM, Karl O. Pinc wrote: > This is all driven by the initramfs. What happens is that, > sometimes, the screen goes black for perhaps 15 or more > seconds starting about 3 or 4 seconds after the luks > password prompt. Attempts to enter the password or portion > thereof during this time always result in failure. > I believe I've seen the same problem without the screen > going black as well. If I wait a long time to enter the > password all is well. I had problems with late reset of usb devices (with connected usb keyboard). When I start to enter passphrase (in initramfs), usb kernel module resets usb devices (perhaps just initialization) and usually it cause lost of some entered characters. Waiting few seconds helps - maybe this is the similar case or just problem with another hw interfering (like gpu). To debug such issues - boot kernel, intramfs (dracut or whatever it is) with full debug to console, check what is logged immediately before it happens. (If it is too quick, just use some camera and record screen or log it to serial console.) With passphrase entered in late init where things run in parallel (like systemd these days) even more magic can happen;-) Milan