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@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
