Hi. I just tried to get my system booting from a luks encrypted root partition and found that the information at http://gentoo-wiki.com/SECURITY_System_Encryption_DM-Crypt_with_LUKS regarding creating the init rd is extremely complicated and that the custum ebuild provided by the luks author (http://luks.endorphin.org/gentoo) is very outdated, not supporting udev for instance. I have thus made a patch for genkernel based on the ebuild provided by the luks author. you can find it attached. The only non automated point is building the static version of cryptsetup. For now I suppose it's under /bin/cryptsetup-static. Maybe cryptsetup-luks could have a static use flag The patch is for the 3.3.10 version Do what you want with it. Maybe someone will find it usefull. TIA
Created attachment 79476 [details, diff] patch for genkernel to allow initrd to use luks encrypted devices
Turns out cryptsetup-luks allready has "dynamic" flag wich by default is set to false resulting in a static binary. I have updated my patch accordingly, solved other bugs (LUKS="yes/no" on /etc/genkernel now works) and added a little explanation in the comandline help
Created attachment 79580 [details, diff] new improved patch other things that could be done. * Load copy some necessary modules to the initrd and load them at boot (not essential) * blue-sky scenario: use luksDump to check what modules the partition needs and load them automatically
I'd imagine your patch changes something in generic/, right? Want to rerun diff with -ur so the changes in there get diffed as well? Thanks.
Created attachment 79704 [details, diff] recursive Sorry about forgetting to recurse. Yes it changes files is generic (linuxrc for sure) I also added the author information regarding this file because it is copy paste from the luks' creator ebuild. Other files should be independent work by me. This is pretty simple stuff but I think it would be a nice addition to genkernel and with a small effort. New patch created
*** Bug 123305 has been marked as a duplicate of this bug. ***
Sorry for dup. I checked few days ago and there was no such request. I didn't bother to check again after I found a time slice to diff it. Sorry for noise. Although I wonder why Claudio didn't mail me about that. However, go ahead with his patch. He seemed to have spent more effort on that patch than me.
(In reply to comment #7) ... > However, go ahead with his patch. He seemed to have spent more effort on > that patch than me. > I don't think thats very accurate. Like I wrote on my first comment, this is mainly an adaptation of your patch and by no way do I wish to claim authorship of work that isn't my own. By the way, thanks for LUKS! I also have a preliminary version that uses luksDump to see the ciphers it needs to mount the device and loads them on the fly from the initrd (if not statically compiled). I run away from bash as much as I can so I probably have something very wrong, because while trying it on a running system it seems to work but when I boot, apparently ciphers don't get detected. This is probably some stupid mistake I made or some feature I use that behaves differently on busybox. This is not very important, but if anyone is interested I can push it harder or give the code I have written. The only great advantage would be not having to compile the crypto-stuff and dm-stuff statically into the kernel. I guess for novices that may turn out to be unnecessarily complex. A check to see if cryptsetup is static would be nice at initrd build time.
You will find a static check in my patch. You might want to put it into a helper file that is sourced by gen_initrd.sh and gen_initram.sh. Today I migrated to LUKS on raid and noticed that there is a kernel problem that is worked around in genkernel successfully. The workaround must be enabled for LUKS too though. Just add setup_md_device ${LUKSdev} after the LUKSdev is set in linuxrc. This works fine for me.
One month of no activity. Maintainers, any difficulties?
Well, we are currently busy fixing bugs, rather than working on new support. Honestly actual problem reports always take precedence over feature requests, so this might not even be considered for a little while as we try to work out some of the issues we have with genkernel 3.3.11 that actually affect the release. After those bugs are worked out, then we will revisit this. The simple answer is "when we get to it". Asking doesn't speed up the process. ;]
Created attachment 82798 [details, diff] md fix Patch looks good, and the demand for it seems to be there so I see no problem with putting it into 3.3. However, the patch needs to be able to deal with setup_md_devices correctly -- can you test this works without having to manually run setup_md_device please? Thanks.
Any news on this? It's been another month :-)
(In reply to comment #13) > Any news on this? It's been another month :-) Yes, can somebody check the patch in comment #12 works please?
I've added a modified version of the patch above, plus the md fix, plus the is_static function from the other bug to CVS. If it doesn't work, I'm sure we'll find out soon enough... ;]
(In reply to comment #15) > If it doesn't work, I'm sure > we'll find out soon enough... ;] Post problems here. Maybe we can be of some assistance if that happens...
*** Bug 135924 has been marked as a duplicate of this bug. ***
Fixed in 3.4.0_pre1, thanks. Let us know if things break :)
*** Bug 142365 has been marked as a duplicate of this bug. ***
