Hiya, so it looks as though there's been a recent change in the last alpha of baselayout, such that dm-crypt's plugin starts dm-crypt-execute-${myservice} (as found on lines 203 and 226 of /lib/rcscripts/addons/dm-crypt-start.sh). It appears there's already a dm-crypt-execute-checkfs and dm-crypt-execute-localmount, but there isn't one defined for dm-crypt-execute-volumes, which also seems to call the addon. As such encrypted swap doesn't seem to be starting properly, and on shut down appears to call exit somewhere, which causes baselayout to mention that init scripts shouldn't call exit. If there's any more information I can provide, or patches to test, please let me know, or collar me on IRC... 5;)
For anyone who hasn't been following the previous bug I filed, the warnings describing the fact that dm-crypt-execute-volumes wasn't found are no longer presented to the user in alpha8-r1 (they seem to have been masked by the patch for the previous bug), however cryptfs swap still fails to mount (as an example).
volumes init script starts the RC_VOLUME_ORDER stuff now so users can specify where in the list (before/after modules for example) it starts. I think the crypt stuff will have to take that into account now.
Ok, a couple of interesting little bits I just discovered. It turns out that volumes isn't starting because it's only used by checkfs, rather than needed by it. Once you add that and run sed -i -e 's/checkfs/volumes/' /lib/rcscripts/addons/dm-crypt-start.sh then everything seems to go back to normal. It also shows the "do not use exit in initscript" error, right at the start of the volumes initscript (so whilst during testing I ran /etc/init.d/volumes start, and it gave me the error). Gimmie a shout if you need more info... 5:)
Created attachment 104084 [details, diff] Patch for cryptsetup-luks's dm-crypt-start addon script Ok, so here's a patch that hopefully will allow both baselayout >= 1.13.0 and < 1.13.0 use for cryptsetup. It only needs to be applied to a file in ${FILESDIR}, so no epatching or modification of the ebuild required. I would however like someone to check that it works for < 1.13.0 please, since I don't have any encrypted boxes that now use that version of baselayout...
I took a look into patching baselayout to correct its part of the problem, but it appears that whilst checkfs is in /init.d, volumes is in /init.d.Linux, so I think that adding "need volumes" to /init.d/checkfs won't be possible by a patch. Would it be best to have it amended when portage installs the scripts, or should it just be an ewarn at the end of the ebuild? Is there a default set of services that should always be in your boot runlevel, which we can then add volumes to?
(In reply to comment #5) > I took a look into patching baselayout to correct its part of the problem, but > it appears that whilst checkfs is in /init.d, volumes is in /init.d.Linux, so I > think that adding "need volumes" to /init.d/checkfs won't be possible by a > patch. No. However, volumes is added to the boot runlevel by the ebuild now, so it should be ok.
Cool, thanks very much Roy! 5:)
Sorry about the delay on this, i've been busy and don't run the alpha baselayout. I tried the script on <1.13 and it was fine, but after emerging 1.13 and applying your patch, i'm getting the errors that you mention your patch solves. Is there something else I need to be doing before I look at this in more detail? Some functionality changed between now and then in baselayout?
Hiya, no you're quite right, it's been broken for the past couple of days. I updated to baselayout-1.13.0_alpha12 on the 17th and something broke again. From what I can tell dm-crypt-start.sh is getting sourced, but isn't being passed ${myservice}, and hence when it tries to execute dm-crypt-execute-${myservice} it fails, because it can't find the right function. As far as I'm aware, this always used to be passed the right variables, and worked for me up to and including baselayout-1.13.0_alpah11-r2. After a bit of digging, it turns out that $myservice got deprecated on March 2nd 2006 (http://sources.gentoo.org/viewcvs.py/baselayout?rev=1935&view=rev) and $SVCNAME should be used instead. It looks like it got fully turned off a few days ago. A "sed -i -e 's:myservice:SVCNAME' <patch file>" should make it all work again. I'll post a new patch after I've gone shopping... 5:) I still don't know what's causing the "use of exit in an init.d script" warning so if you've got any ideas where to look for that it'd help a lot. Thanks! 5:)
Created attachment 107780 [details, diff] dm-crypt-start.sh.diff Please, test this one. :)
Thanks Jakub! 5:) Sorry, I was ill on Thursday and I've been kind of out of it since (back to normal food on Sunday) and I completely forgot to post the corrected patch. Sorry! 5:(
I had installed cryptsetup-luks but hadn't yet created an encrypted volume, so the only error I was getting at startup was: /lib64/rcscripts/addons/dm-crypt-start.sh: line 226: dm-crypt-execute-: command not found Jakub's patch eliminated that error for me.
*** Bug 167549 has been marked as a duplicate of this bug. ***
Created attachment 115970 [details, diff] Updated patch which works with >=baselayout-2 as well I attached an updated patch which * works for baselayout-2 as well (replaced all dashes in function names with underscores) * no longer prints 'command not found' because `splash` is not installed (simply redirected stdout/stderr to /dev/null) The patched script should still work with baselayout-1.12 and 1.13, but I only tested 2.0.0_alpha1.
Wow, you're fast, I only just found out about the underscore thing! 5:P I'll give it a try out, and look through it, and then (since this has been open with a patch since December) if it's all good, I'll commit it...
Ok, I've now patched this in the tree, but only for the new ebuild (1.0.4-r2). Please give the servers a couple of hours to sync up and then try the new version. If there are any problems, please reopen this bug and we'll try to get the fixed up. Thanks... 5:)
