+++ 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