As I described in the Gentoo Forums, it might be a good idea to make dm-crypt part of the start_volumes and stop_volumes scheme so it will play nicely with for example lvm. Basically this involves small changes in /etc/conf.d/rc, /etc/init.d/checkfs and /etc/init.d/halt.sh. Ref: http://forums.gentoo.org/viewtopic-t-294345.html
integrated in baselayout-1.12.x and trunk i guess if it breaks someone will let us know ;)
*** Bug 129643 has been marked as a duplicate of this bug. ***
not so simple after all
dm-crypt addon code needs to be rewritten to allow for this
After upgrading to baselayout-1.12.0_pre17-r1 (where this change is committed according to changelog) my dm-crypt broke. I have *really* simple configuration, ie. at boot time I only encrypt my swap, my /etc/conf.d/cryptfs has only swap=crypt-swap source='/dev/sda2' (And fstab is set up correctly - it worked in pre17). But for some reason the cryptsetup is not ran anymore => swap device is not set up any more, and I get an error at boot (Ctrl-d to continue or root passwd for maintenance). I'm using cryptsetup-luks-1.0.1-r1. Nothing wrong with cryptsetup though, when I mount my encrypted loopbacks they still work ok. /sbin/losetup /dev/loop0 /var/loop/crypt.img /bin/cryptsetup luksOpen /dev/loop0 crypt works fine. Just the boot-time setting up of swap fails..
I booted up this morning to the same issue so I decided to investigate further... Looks like the baselayout-1.12.0_pre17-1975.patch is what caused the problem. It moved the "start_addon dm-crypt" line from the checkfs script to the localmount script. For some reason this causes the dm-crypt-start.sh to break in a way that I do not yet understand. As far as I can tell, the ${myservice} variable will work if dm-crypt-start.sh is run from checkfs, but not from localmount. I haven't checked yet whether this has is unique to cryptsetup-luks (which is where the dm-crypt-start.sh script is from). I'm going to play around and see if I can figure it out. -Riskable http://www.riskable.com "I have a license to kill -9"
Sorry, the baselayout-1.12.0_pre17-1975.patch removed the "start_addon dm-crypt" line from both checkfs *and* localmount. I need caffeine. ...still investigating.
there's nothing to investigate ive already reverted the changes in svn that caused your bug and were suggested by this bug
pre17-r2 has the change reverted
Funny to hear all these problems. The way I set it up works fine for me. Although my system might be a month behind the current portage status. Is dm-crypt in the RC_VOLUME_ORDER variable in /etc/conf.d/rc ? If it isn't there, it will not be run. I have to admit I haven't tried the new baselayout yet (i.e. the one that seems to be wrong).
Ok, I have it working now with baselayout 1.12.5-r2 which is the current stable. What I noticed is that the start_volumes and stop_volumes functions have been removed from /etc/init.d/functions.sh. The function of start_volumes is now part of /sbin/rc, which starts the volumes in the order as given in the RC_VOLUME_ORDER parameter of /etc/conf.d/rc. So the first thing is to rework this parameter to read "dm dm-crypt lvm". OF course, this order depends on the way your system is set up. If you would have dm-crypt on top of lvm, then you need to put lvm before dm-crypt. So, I stripped the start_addon dm-crypt from /etc/conf.d/checkf and /etc/conf.d/halt.sh. It is no longer needed here as dm-crypt is now part of RC_VOLUME_ORDER in /etc/conf.d/rc. I also suggest adding dm-crypt to the default setting in /etc/init.d/functions.sh, e.g. RC_VOLUME_ORDER=${RC_VOLUME_ORDER:-raid evms lvm dm dm-crypt} This should have done the trick. However, there is a little snag. When you now boot up, the dm-crypt action fails complaining about a missig "dm-crypt-execute-". This is due to the fact that the variable ${myservice} is empty when the dm-crypt start script /lib/rcscripts/addons/dm-crypt-start.sh is invoked. I fixed this hackishly (is this a word?) by including the following line in /lib/rcscripts/addons/dm-crypt-start.sh at the start of the main body (line 112): myservice=${myservice:-checkfs} Now, if no service is given, this script assumes it is run as part of the checkfs service. Not really the proper way to do it, but it works. Basically what I did is move the start of the dm-crypt addon to an earlier part of the boot sequence. Where checkfs is normally started right after the Logical Volume Manager (and dm-crypt as first action of checkfs as well), it is now run just before the Logical Volumen Manager and treated as any other volume manager like raid, lvm and evms. Looking at how dm-crypt is also invoked from localmount, I think my solution is right, although abusing the checkfs name might be a bit hackish. I hope this helps in tackling this issue.
I arrived at the same conclusion, but from a different direction - for various reasons, I have dm-crypt under my LVM, and the shortcoming in the rcscript is even more painfully obvious. During the RC_VOLUME_ORDER mount, ${myservice} (which, BTW, is deprecated according to /etc/init.d/runscript.sh) is unset and the mount fails, whereas post-LVM 'checkfs' kicks off and stuff magically works the second time around. I'll hack around on it a bit more and try to work out a better method. The above works, but there should be a better way.
There is a new version of dm-crypt-start.sh in, check it out.
I'm happy with how this is functioning now, open a new bug with any specific problems with the latest ebuild.
