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