Re: [dm-crypt] boot timeout and fsck.ext3

[Rainer Maier <RaMaier@gmx.de>]

Hi,
on my Debian installation I attached the noauto in /etc/crypttab:
tresor  /dev/sda2       none    luks,check=ext2,retry=5,timeout=5,noauto

and in fstab I only left:
/dev/mapper/tresor  /tresor         auto    defaults                   0       0
# /dev/sda2           /tresor         ext3    defaults,errors=remount-ro 0

Since only the /dev/sdb system is encrypted and not the /dev/hda or /dev/sda 
everything starts ok.

When I then use cryptdisks_start is seems equal to:
cryptsetup luksOpen /dev/sda2 tresor
but I have to mount the system manually:
mount /dev/mapper/tresor /tresor

Is that behaviour normal or do I have to change some settings to make
cryptdisks_start even mount the disks ?

Best regards
Rainer

Jonas Meurer schrieb:
> hello,
> 
> On 13/08/2009 Rainer Maier wrote:
>> since my system is now working again, I have 2 more problems.
>>
>> 1. When Linux starts it requires a password for the encrypted
>> partitions. How do I set the timeout value ?
>> I know there is an easy way to do it, but I did not find it any more.
> 
> no, unfortunately there's no easy way to do it any longer. the timeout
> option always had major drawbacks, such as fsck on boot failing in case
> the dm-crypt device wasn't setup due to timeout. thus we completely
> kicked the timeout option from cryptdisks in debian.
> 
> the way to go if you don't have physical access to your machine, is
> adding the 'noauto' option in /etc/cryptdisks and decrypting the device
> manually later with 'cryptdisks_start <device>'.
> 
> another option would be to use dropbear (small ssh server) within
> initramfs to ssh into the machine while booting, and enter the
> passphrase there. see debian bug #465902 [1] for more information.
> 
>> 2. When the system starts, it requests a fsck.ext3 check.
>> How is that done on luks ?
> 
> fsck is run for the devices in /etc/fstab. you don't have the source
> device of your encrypted partition in /etc/fstab, but rather the
> decrypted target device. and that one contains the filesystem (i.e.
> ext3). thus fsck runs a filesystem check on your decrypted filesystem,
> just like it does for unencrypted partitions.
> if the device doesn't exist (i.e. because cryptdisks init script failed)
> then fsck fails on boot and an emergency shell is started. that's the
> reason why we kicked timeout support from cryptdisks initscript in
> debian (see above).
> 
> greetings,
>  jonas
> 
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465902
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt