I do not use dmcrypt in the init scripts and do not have devices set in fstab. Rather, I manually mount encrypted filesystems as follows in my home directory: #!/bin/sh sudo losetup /dev/loop0 ~/stuff sudo cryptsetup -c aes -s 256 -h plain create stuff /dev/loop0 sudo mount -t ext2 /dev/mapper/stuff ~/mnt/stuff I also have a corresponding unmount script: sudo umount ~/mnt/stuff sudo cryptsetup remove stuff sudo losetup -d /dev/loop0 All of works fine. However, at shutdown time, if my dmcrypt drive is mounted, halt.sh fails and drops me to a prompt for root maintenance. (Enter Root Password or press Control-D to continue): Either it is trying to unmount /home before trying to unmount the dmcrypt drive or it is not reading /proc/mounts properly or is trying to run losetup -d before unmounting the loopback device? On reboot, a check is done on my home partition because it was not unmounted cleanly. The encrypted fs is fine and no data appears to be lost or corrupted. Perhaps the logic of halt.sh needs to be adjusted to account for this situation where dmcrypt is used, but NOT set up through init. Some additional information: mars bin # losetup -a /dev/loop/0: [0307]:577565 (/home/peter/stuff) peter@mars $ cat /proc/mounts rootfs / rootfs rw 0 0 /dev/root / reiserfs rw,noatime 0 0 proc /proc proc rw,nodiratime 0 0 sysfs /sys sysfs rw 0 0 udev /dev tmpfs rw,nosuid 0 0 devpts /dev/pts devpts rw 0 0 snip.... /dev/hda7 /home ext3 rw,noatime,data=ordered 0 0 /dev/mapper/stuff /home/peter/mnt/stuff ext2 rw,nogrpid 0 0 could the problem be the order of unmount? Trying to unmount /home before ...stuff? halt.sh should pick up the fact that /dev/mapper is a loop device, don't you think? sys-apps/baselayout-1.11.14 mars peter # emerge info Portage 2.0.53 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r2, 2.6.14-gentoo-r5 i686) ================================================================= System uname: 2.6.14-gentoo-r5 i686 AMD Athlon(tm) XP 2800+ Gentoo Base System version 1.6.14 dev-lang/python: 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r3
you're probably going to have to track this down yourself ... look in the halt.sh script, there is already logic in there for unmounting dm-crypt loop devices regardless of how they were actually mounted
remaining=$(awk '!/^#/ && $1 ~ /^\/dev\/loop/ && $2 != "/" {print $2}' proc/mounts | \... When dmcrypt is used, the device in /proc/mounts is /dev/mapper, not /dev/loop. This is why no loopbacks get removed. Check out this fragment: peter@mars ~ $ grep "^\/dev\/loop\|^\/dev\/mapper" /proc/mounts /dev/mapper/stuff /home/peter/mnt/stuff ext2 rw,nogrpid 0 0 As opposed to: peter@mars ~ $ grep "^\/dev\/loop" /proc/mounts peter@mars ~ $ I believe the addition of the simple conditional for /dev/mapper in halt.sh will fix the problem. Will report.
Well, that was fun. Unfortunately, while the loopback test _DID_ find the /dev/mapper device and removed it, the dmcrypt addon never ran since I don't have a /etc/cryptfs file set up. So, shutdown still hangs because halt.sh doesn't disconnect the dmcrypt device. That's why /home/peter never can unmount. I want to keep these files completely in userspace, so I suppose I will have to remember to unmount it by hand, or add it to local.stop or suffer with the error. Marking cantfix unless you can think of a better way. I'll play around with fuse too. This really is a user-level problem, not system.
