+++ This bug was initially created as a clone of Bug #571577 +++ Description of problem: I've been attempting to install F12 x86_64 on a new T410 laptop. I've enabled disk encryption in the Anaconda UI, with a default partitioning scheme. This is a new laptop, with no previous OS installed. Manual installation appears to succeed, provided I pass "nomodeset vnc" at installation boot line. However, on attempting to boot, I get various error messages. Unable to get a direct screenshot, so manually typing the following: alg: No test for __aes-aesni (__driver-aes-aesni) alg: No test for __ecb-aes-aesni (__driver-ecb-aes-aesni) alg: No test for __cbc-aes-aesni (__driver-cbc-aes-aesni) alg: No test for __ecb-aes-aesni (cryptd(__driver-ecb-aes-aesni)) padlock: VIA PadLock not detected. alg: skcipher: Failed to load transform for xts-aes-aesni: -2 device-mapper: table: 253:0: crypt: Error allocating crypto tfm device-mapper: ioctl: error adding target to table device-mapper: reload ioctl failed: Invalid argument Failed to setup dm-crypt key mapping for device /dev/sda2 Check that kernel supports aes-xts-plain-cipher (check syslog for more info). Failed to read from key storage Ray Strode told me this is an issue with hardware crypto support: the hardware apparently has hardware crypt support, but a buggy module means that the crypto doesn't work, and thus the encrypted OS can't be booted. The workaround of adding: rdblacklist=aesni-intel to the kernel boot line fixed it for me. (Documenting it here in Bugzilla) Version-Release number of selected component (if applicable): kernel-2.6.31.5-127.fc12.x86_64 --- Additional comment from dmalcolm on 2010-03-08 16:33:19 EST --- Created an attachment (id=398629) Photo of the boot failure --- Additional comment from dmalcolm on 2010-03-09 15:01:19 EST --- The problem is still present with the latest F12 kernel update; on this hardware I still need to use "rdblacklist=aesni-intel" to boot successfully (with encrypted partitions as per defaults), or the boot fails with (apparently) the same errors as in comment #0. This is with: kernel-2.6.32.9-67.fc12.x86_64 --- Additional comment from cebbert on 2010-03-16 05:15:15 EDT --- Can you get to a shell after boot fails and see what is in /proc/crypto? --- Additional comment from kmcmartin on 2010-04-28 12:59:12 EDT --- Dave, So this error occurs regardless of install or not? (IE: blacklisted on install, then unblacklist and it will fail) I'm looking into it now, it's a very strange error in a mess of code... If it happens outside of the installer it will be easier for me to test it. regards, Kyle --- Additional comment from updates on 2010-05-03 21:38:45 EDT --- kernel-2.6.33.3-79.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/kernel-2.6.33.3-79.fc13 --- Additional comment from updates on 2010-05-04 19:53:16 EDT --- kernel-2.6.33.3-79.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. --- Additional comment from evan on 2010-05-05 13:30:19 EDT --- I had my wireless AP set to use AES for encryption, and after upgrading to kernel-2.6.33.3-79.fc13 I have no longer been able to connect to my wireless network. Now that I see this change I can probably just change the encryption settings on my AP (once I get home later today), but this might have broken things for other users who aren't able to control the cipher used by access points they use. --- Additional comment from kmcmartin on 2010-05-05 22:54:07 EDT --- No. That's a different bug and unrelated to this. You still have AES support, this just removes the ability to use the Core i7 AES instructions to accelerate it. --Kyle
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This bug will be fixed when these two commits make their way upstream: http://git.kernel.org/?p=linux/kernel/git/herbert/crypto-2.6.git;a=commit;h=9bed4aca296fdf9c1b85a8f093e92018dc9864f3 http://git.kernel.org/?p=linux/kernel/git/herbert/crypto-2.6.git;a=commit;h=b23b64516500df6b70fcafb820970f18538252cf Any kernel config workarounds can go away then. --Andy
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=b23b64516500df6b70fcafb820970f18538252cf http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=9bed4aca296fdf9c1b85a8f093e92018dc9864f3