If you're using cryptsetup-luks-1.0.3-r2 with a kernel newer than 2.6.20, you're not prompted for the root filesystem's passphrase by cryptsetup which is run from a genkernel created initrd. I guess this is related to the old version of luks using the deprecated "getpass" method, while the new versions use a completely different routine, to retrieve the passphrase. Reproducible: Always Steps to Reproduce: 1. Install a crypted root setup, where you use luks 2. Boot the system Actual Results: See luks trying to decrypt your hd without password and without prompting you for one. Expected Results: Well... being prompted for a passphrase instead of getting an error message only, that there's no key with an empty passphrase ;) see http://forums.gentoo.org/viewtopic-p-4053155.html
*** Bug 182386 has been marked as a duplicate of this bug. ***
Adding arches to make the decision because the maintainer has not responded in a month.
i say sparc stable.
x86 stable
mips doesn't use gentoo-sources, and I'm not aware of any users trying encrypted hard drives on our arch (nor is mips-sources rigged for any crypto-setup like that).
Ehh, cryptsetup doesn't require any patches to the kernel, so mips-sources has full support for it. It just uses the device-mapper functionality from vanilla. If you still don't want this on mips, feel free to remove yourselves again.
Stable for HPPA.
ppc64 stable
amd64 done
stable on mips. Can't test it, but we'll play the waiting game for any unknown unknown bugs out there.
ppc stable
alpha/ia64 stable, closing, thanks Tobias for testing