Summary: | cryptsetup-luks 1.0.3-r3 unable to create swap mapping, keyfile not a regular file, thus function never returns | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Andreas Ntaflos <daff> |
Component: | New packages | Assignee: | Benjamin Smee (strerror) (RETIRED) <strerror> |
Status: | RESOLVED INVALID | ||
Severity: | major | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Andreas Ntaflos
2006-10-28 18:42:21 UTC
Not a security bug. I assume that /dev/hda3 correctly points to the right partition for your environment? If so then try manually executing: cryptsetup -c aes -h sha256 -d /dev/urandom create crypt-swap /dev/hda3 mkswap /dev/mapper/crypt-swap swapon /dev/mapper/crypt-swap If that executes correctly then try a reboot and let me know how it goes. Thanks for the reply! Those commands executed successfully, however, upon rebooting the exact same error occured. Could it be that instead of `create' the init scripts call `luksOpen', as it is LUKS which cannot read the keyfile from a non-terminating stream directly? I had the same problem, and took a look at: /lib/rcscripts/addons/dm-crypt-start.sh The script does luksOpen if `cryptsetup isLuks ${source}` succeeds. IMHO it should not check for a luks-header when opening swap. However, my problem was that I had a luks header at the start of the swap volume by accident after repartitioning. cryptsetup does an exhausting read with luksOpen, but not with create. Probably this is the same problem in your case, too. Overwrite the header with: dd if=/dev/zero of=/dev/swap count=666 Thanks Johannes, I did what you suggested, but while experimenting on how to solve or reproduce the bug I have recreated the swap partition numerous times (mkswap), with and without applying dm-crypt settings. Shouldn't this overwrite any previous partition header? Anyway, I upgraded to cryptsetup 1.0.4 and applied Johannes' suggested fix and after a reboot everything seems to work again. I suppose this bug should be marked as WORKSFORME of some such. Sounds like there was just something incorrectly setup with your env. Not to be flamebait or offensive or anything, but from my POV all I really did was (as described) an emerge -u cryptsetup-luks && etc-update, which effectively broke broke swap encryption. Apparently the fault has to be on my side since noone else (except Johannes) experienced this problem in this context. But what did I do wrong? |