Bug#495509: cryptsetup: timeout option does not work anymore

[Alexander Heinlein]

Package: cryptsetup
Version: 2:1.0.6-6
Severity: normal

Hi.

cryptsetup ignores the timout option specified in /etc/crypttab, and also
the one from /etc/default/cryptdisks.

My /etc/crypttab:
sda6 /dev/sda6 none luks,timeout=6,tries=2,checkargs=xfs

Also calling cryptsetup directly with the -t option ignores the timeout.
cryptsetup from stable takes care of this option.

Regards,
Alex

-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (950, 'unstable'), (850, 'testing'), (750, 'stable'), (600, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.25.10
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages cryptsetup depends on:
ii dmsetup 2:1.02.27-3 The Linux Kernel Device Mapper use
ii libc6 2.7-13 GNU C Library: Shared libraries
ii libdevmapper1.02.1 2:1.02.27-3 The Linux Kernel Device Mapper use
ii libpopt0 1.14-4 lib for parsing cmdline parameters
ii libuuid1 1.41.0-3 universally unique id library

cryptsetup recommends no packages.

Versions of packages cryptsetup suggests:
ii dosfstools 2.11-6 utilities for making and checking
ii initramfs-tools [linux-initra 0.92f tools for generating an initramfs
ii udev 0.125-5 /dev/ and hotplug management daemo

-- debconf-show failed

--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[David Härdeman]

On Sun, August 17, 2008 11:23, Alexander Heinlein wrote:
> cryptsetup ignores the timout option specified in /etc/crypttab, and also
> the one from /etc/default/cryptdisks.
>
> My /etc/crypttab:
> sda6 /dev/sda6 none luks,timeout=6,tries=2,checkargs=xfs

Right,

the problem is that some of the changes we've committed during the last
couple of weeks in order to support usplash/splashy/remote shells/etc make
it very hard to support timeouts. I'm not sure if we'll be able to readd
support for it... :(

--
David Härdeman

[Alexander Heinlein]

On Mon, Aug 18, 2008 at 10:11:54AM +0200, David Härdeman wrote:
> the problem is that some of the changes we've committed during the last
> couple of weeks in order to support usplash/splashy/remote shells/etc make
> it very hard to support timeouts. I'm not sure if we'll be able to readd
> support for it... :(

Oh, too bad :(

Disabling timeouts per default through config and placing a hint about
occuring issues when reenabling it isn't an option?

Would be nice if my system will boot even if there is nobody who enters the
password for auto mounted, non essential partitions.

Regards,
Alex

[David Härdeman]

On Mon, August 18, 2008 11:10, Alexander Heinlein wrote:
> On Mon, Aug 18, 2008 at 10:11:54AM +0200, David Härdeman wrote:
>> the problem is that some of the changes we've committed during the last
>> couple of weeks in order to support usplash/splashy/remote shells/etc
>> make
>> it very hard to support timeouts. I'm not sure if we'll be able to readd
>> support for it... :(
>
> Oh, too bad :(
>
> Disabling timeouts per default through config and placing a hint about
> occuring issues when reenabling it isn't an option?

Well, the problem is that the "issue" is most of the time that there is no
timeout at all...

> Would be nice if my system will boot even if there is nobody who enters
> the password for auto mounted, non essential partitions.

If they aren't essential, then a workaround for now would be to mark them
"noauto" and use the opposite approach compared to what you're used to
doing (i.e. when someone is present, he/she can manually mount the extra
volumes).

--
David Härdeman