Bug#507722: cryptsetup: unable to enter passphrase at boot time with bootlogd enabled
package cryptsetup retitle 507722 passphrase prompt not displayed in boot process with insserv, CONCURRENCY=shell and bootlogd enabled thanks -- hello Jochen, On 21/02/2009 Jochen Schulz wrote: Jochen Schulz: As you can see, there's (unfortunately) no luks. I don't know whether that makes any difference. I just changed my /home to luks, but that didn't solve the issue. So, to summarize insserv with CONCURRENCY=shell and bootlodg with BOOTLOGD_ENABLE=Yes make it hard to enter the cryptdisks-early passphrase at boot because the prompt is invisible. Ok, that one finally made it possible for me to reproduce the bug. After installing insserv and setting CONCURRENCY=shell in the kvm test installation, the cryptsetup passphrase prompt is not displayed in boot process any longer. And I think I understand why I observed that my keypresses have been echoed to the screen sometimes. /var/log/boot reveals a pause of almost thirty seconds when setting up encrypted swap (I used 'set -x' in /etc/init.d/cryptdisks-early): Sat Feb 21 19:32:03 2009: + cryptsetup -c aes-cbc-essiv:sha256 -s 256 -h sha256 --key-file=/dev/random create cswap0 /dev/sda6 Sat Feb 21 19:32:29 2009: + '[' -z '' ']' Sat Feb 21 19:32:29 2009: + break Sat Feb 21 19:32:29 2009: + return 0 Sat Feb 21 19:32:29 2009: + '[' ok '!=' ok ']' Probably my machine lacks entropy during that time. Any keys pressed while cryptsetup is waiting for the entropy pool to fill up end up on the screen. Ironically, pressing keys appears to speed up this process. Yes, lack of entropy is exactly the problem here. You could use /dev/urandom instead of /dev/random. Otherwise you'll have to cope with the situation and input random characters over your keyboard until enough entropy was available from /dev/random. But there are no messages at all from cryptdisks-early on screen. Not even a success message about cswap0. I can only recognize that cryptsetup is done setting up cswap0 and waiting for /home's passphrase by pressing keys und wait for them to *not* appear on the screen. One idea I had when investigating this issue: bootlogd appears to prevent stderr from being printed to the screen. I can only see the 'set -x' output from cryptdisks-early when shutting down (and, of course, in the boot log file). Are all of cryptdisks-early's messages printed to stderr instead of stdout? At least /lib/cryptsetup/askpass only prints to stderr, as fas as I can see. askpass writes to stderr, but the cryptdisks script itself uses lsb logging functions, and as far as I can see from /lib/lsb/init-functions, that one doesn't write to stderr. And with CONCURRENCY=No set, cryptsetup passphrase prompt is displayed, so bootlogd itself cannot be the problem. Additionally, the combination of CONCURRENCY=Yes and bootlogd seems to suppress a lot of boot messages, not only cryptdisks. greetings, jonas signature.asc Description: Digital signature
Bug#507722: cryptsetup: unable to enter passphrase at boot time with bootlogd enabled
Jonas Meurer: Here, the passphrase prompt is displayed in the same way with bootlogd enabled and disabled. Could you try whether the bug still applies on your system, and if yes, give me more details about your setup? Yes, I can still reproduce it. I am really out of ideas what might be causing this. My current configuration: - self-compiled vanilla 2.6.29-rc5 linux kernel. I tried vanilla 2.6.28.7 and 2.6.27-1-amd64 (from experimental) as well with the same results. - encrypted filesystems in /etc/crypttab: cswap0 /dev/sda6 /dev/random swap,cipher=aes-cbc-essiv:sha256,size=256,hash=sha256 home /dev/sda7 nonecipher=aes As you can see, there's (unfortunately) no luks. I don't know whether that makes any difference. - cryptsetup version 2:1.0.6-7 (unstable) - sysvinit version 2.86.ds1-61 (unstable) - insserv version 1.12.0-4 (unstable), CONCURRENCY=shell in /etc/default/rcS. Disabling this setting resolves the problem, just like disabling bootlogd. J. -- In the west we kill people like chickens. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Bug#507722: cryptsetup: unable to enter passphrase at boot time with bootlogd enabled
Jochen Schulz: As you can see, there's (unfortunately) no luks. I don't know whether that makes any difference. I just changed my /home to luks, but that didn't solve the issue. So, to summarize insserv with CONCURRENCY=shell and bootlodg with BOOTLOGD_ENABLE=Yes make it hard to enter the cryptdisks-early passphrase at boot because the prompt is invisible. And I think I understand why I observed that my keypresses have been echoed to the screen sometimes. /var/log/boot reveals a pause of almost thirty seconds when setting up encrypted swap (I used 'set -x' in /etc/init.d/cryptdisks-early): Sat Feb 21 19:32:03 2009: + cryptsetup -c aes-cbc-essiv:sha256 -s 256 -h sha256 --key-file=/dev/random create cswap0 /dev/sda6 Sat Feb 21 19:32:29 2009: + '[' -z '' ']' Sat Feb 21 19:32:29 2009: + break Sat Feb 21 19:32:29 2009: + return 0 Sat Feb 21 19:32:29 2009: + '[' ok '!=' ok ']' Probably my machine lacks entropy during that time. Any keys pressed while cryptsetup is waiting for the entropy pool to fill up end up on the screen. Ironically, pressing keys appears to speed up this process. But there are no messages at all from cryptdisks-early on screen. Not even a success message about cswap0. I can only recognize that cryptsetup is done setting up cswap0 and waiting for /home's passphrase by pressing keys und wait for them to *not* appear on the screen. One idea I had when investigating this issue: bootlogd appears to prevent stderr from being printed to the screen. I can only see the 'set -x' output from cryptdisks-early when shutting down (and, of course, in the boot log file). Are all of cryptdisks-early's messages printed to stderr instead of stdout? At least /lib/cryptsetup/askpass only prints to stderr, as fas as I can see. J. -- If I was Mark Chapman I would have shot John Lennon with a water pistol. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Bug#507722: cryptsetup: unable to enter passphrase at boot time with bootlogd enabled
Hey Jochen, On 04/01/2009 Jochen Schulz wrote: What I can see when booting: ... kernel messages ... INIT: version 2.86 booting Using shell-style concurrent boot in runlevel S. Starting hotplug events dispatcher: udevd. Synthesizing the initial hotplug events...done. Waiting for /dev to be fully populated... ... kernel messages ... done. Starting boot logger: bootlogdSetting the system clock. _ At the last line, the cursor is blinking and cryptsetup is waiting for me to enter the passphrase. Did you already try to remove bootlogd and see whether that fixes your boot process? Yes, I didn't expect it to change anything but disabling bootlogd in /etc/default/bootlogd makes the passphrase promopt visible again. I wish I could. What is strange is that on another new installation (different hardware) with the same setup I don't have the problem at all. I can reproduce the problem on this system as well by enabling bootlogd. I just tried to reproduce the bug on a recent debian/sid kvm installation with luks-encrypted /home, unencrypted rootfs and bootlogd enabled. I wasn't able to reproduce it. Here, the passphrase prompt is displayed in the same way with bootlogd enabled and disabled. Could you try whether the bug still applies on your system, and if yes, give me more details about your setup? greetings, jonas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507722: [pkg-cryptsetup-devel] Bug#507722: cryptsetup: unable to enter passphrase at boot time
Jonas Meurer: So your boot process hangs after bootlogd is started, correct? Can you force the boot process to continue with ctrl+c? It doesn't really hang, it's just that cryptsetup waits for me to enter the passphrase without showing the prompt. If I enter the passphrase and press Enter, booting continues normally. What I can see when booting: ... kernel messages ... INIT: version 2.86 booting Using shell-style concurrent boot in runlevel S. Starting hotplug events dispatcher: udevd. Synthesizing the initial hotplug events...done. Waiting for /dev to be fully populated... ... kernel messages ... done. Starting boot logger: bootlogdSetting the system clock. _ At the last line, the cursor is blinking and cryptsetup is waiting for me to enter the passphrase. Did you already try to remove bootlogd and see whether that fixes your boot process? Yes, I didn't expect it to change anything but disabling bootlogd in /etc/default/bootlogd makes the passphrase promopt visible again. I wish I could. What is strange is that on another new installation (different hardware) with the same setup I don't have the problem at all. I can reproduce the problem on this system as well by enabling bootlogd. J. -- A passionate argument means more to me than a blockbuster movie. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Bug#507722: [pkg-cryptsetup-devel] Bug#507722: cryptsetup: unable to enter passphrase at boot time
severity 507722 normal thanks --- Hey Jochen, On 21/12/2008 Jochen Schulz wrote: What exactly do you see on the boot screen? Are you asked for a passphrase input at all? If yes, how exactly does it look like? The last lines just say something about bootlogd being started and some other service. I can scroll back up to init starting, but I cannot find the passphrase prompt. So your boot process hangs after bootlogd is started, correct? Can you force the boot process to continue with ctrl+c? Did you already try to remove bootlogd and see whether that fixes your boot process? please try to describe more detailed what exactly happens, and what doesn't happen despite you expecting it to happen. Please provide more information so that we're able to track down the actual bug. I wish I could. What is strange is that on another new installation (different hardware) with the same setup I don't have the problem at all. Ok, but you still have the system where the issues did occur. And on this system, you're still able to reproduce the bug? greetings, jonas signature.asc Description: Digital signature
Bug#507722: [pkg-cryptsetup-devel] Bug#507722: cryptsetup: unable to enter passphrase at boot time
Hi Jonas, thanks for getting back on this. Jonas Meurer: Do you use any kind of bootsplash implementation, like splashy or usplash? No. how does your exact setup look like? is /home directly on top of the dm-crypt device, or do you use LVM? It is directly on the device. No LVM involved. What exactly do you see on the boot screen? Are you asked for a passphrase input at all? If yes, how exactly does it look like? The last lines just say something about bootlogd being started and some other service. I can scroll back up to init starting, but I cannot find the passphrase prompt. Please provide more information so that we're able to track down the actual bug. I wish I could. What is strange is that on another new installation (different hardware) with the same setup I don't have the problem at all. What makes things worse (and this report Severity: important, at least in my opinion) is that, more often than not, my keypresses are echoed to the screen and don't get read by cryptseup at all. I cannot confirm this anymore (not even with the package from unstable). IMO this bug can be downgraded to 'normal' or even 'minor'. Maybe I was just too impatient. I prepared a new upload of cryptsetup which fixes several bugs. Could you give that a try and report whether it fixes your bug as well? Thanks for that. I tried that package, but it doesn't change the behaviour. J. -- Fashion is more important to me than war, famine, disease or art. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Bug#507722: [pkg-cryptsetup-devel] Bug#507722: cryptsetup: unable to enter passphrase at boot time
Hey Jochen, On 03/12/2008 Jochen Schulz wrote: Hi, I am trying to use an encrypted /home filesystem on a system whose boot process is managed by insserv. Unfortunately, the prompt from /etc/init.d/cryptdisks isn't visible on screen at the time I am supposed to enter the passphrase. The system just sits idle waiting for me to enter it. Above the cursor are kernel messages about detected devices and information about a boot log being created. Do you use any kind of bootsplash implementation, like splashy or usplash? how does your exact setup look like? is /home directly on top of the dm-crypt device, or do you use LVM? What exactly do you see on the boot screen? Are you asked for a passphrase input at all? If yes, how exactly does it look like? Please provide more information so that we're able to track down the actual bug. What makes things worse (and this report Severity: important, at least in my opinion) is that, more often than not, my keypresses are echoed to the screen and don't get read by cryptseup at all. Since cryptsetup is the only software needing user interaction at boot time (and both situations look exactly equally on screen), I strongly suspect it to be the culprit. It looks like it closes stdin even before I have the chance to enter my passphrase. I prepared a new upload of cryptsetup which fixes several bugs. Could you give that a try and report whether it fixes your bug as well? You can find the new packages at http://people.debian.org/~mejo/cryptsetup/ greetings, jonas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507722: cryptsetup: unable to enter passphrase at boot time
Package: cryptsetup Version: 2:1.0.6-6 Severity: important Hi, I am trying to use an encrypted /home filesystem on a system whose boot process is managed by insserv. Unfortunately, the prompt from /etc/init.d/cryptdisks isn't visible on screen at the time I am supposed to enter the passphrase. The system just sits idle waiting for me to enter it. Above the cursor are kernel messages about detected devices and information about a boot log being created. What makes things worse (and this report Severity: important, at least in my opinion) is that, more often than not, my keypresses are echoed to the screen and don't get read by cryptseup at all. Since cryptsetup is the only software needing user interaction at boot time (and both situations look exactly equally on screen), I strongly suspect it to be the culprit. It looks like it closes stdin even before I have the chance to enter my passphrase. Thanks, Jochen. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages cryptsetup depends on: ii dmsetup 2:1.02.27-4 The Linux Kernel Device Mapper use ii libc62.7-16 GNU C Library: Shared libraries ii libdevmapper1.02.1 2:1.02.27-4 The Linux Kernel Device Mapper use ii libpopt0 1.14-4 lib for parsing cmdline parameters ii libuuid1 1.41.3-1universally unique id library cryptsetup recommends no packages. Versions of packages cryptsetup suggests: ii dosfstools3.0.1-1utilities for making and checking ii initramfs-tools [linux-initra 0.92l tools for generating an initramfs ii udev 0.125-7/dev/ and hotplug management daemo -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
