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 7Qn_w7ME82l8 for ; Wed, 21 Sep 2011 14:57:26 +0200 (CEST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by mail.saout.de (Postfix) with ESMTP for ; Wed, 21 Sep 2011 14:57:26 +0200 (CEST) Message-ID: <4E79DF31.10709@mousecar.com> Date: Wed, 21 Sep 2011 08:57:21 -0400 From: ken MIME-Version: 1.0 References: <1316570636.4663.3@mofo> <4E79548F.8080206@redhat.com> In-Reply-To: <4E79548F.8080206@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] Password is not accepted Reply-To: gebser@mousecar.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt On 09/20/2011 11:05 PM Milan Broz wrote: > 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 Is there a way to determine if the USB connection to the encrypted disk is good... so that it won't drop any characters in the passphrase? E.g., how about running an "fdisk -l" on the drive first, then running the "cryptsetup" command? Better: Is there perhaps an option to cryptsetup (just for testing of course) which would make it echo back the passphrase it received...? just to ensure that it received what I intended?