Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 589390 - aesni-intel module breaks booting off encrypted root
Summary: aesni-intel module breaks booting off encrypted root
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 14
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Kyle McMartin
QA Contact: Fedora Extras Quality Assurance
Depends On: 571577
TreeView+ depends on / blocked
Reported: 2010-05-06 02:55 UTC by Kyle McMartin
Modified: 2015-09-01 03:53 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 571577
Last Closed: 2011-06-15 13:33:17 UTC

Attachments (Terms of Use)

Description Kyle McMartin 2010-05-06 02:55:17 UTC
+++ 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:
to the kernel boot line fixed it for me.  (Documenting it here in Bugzilla)

Version-Release number of selected component (if applicable):

--- Additional comment from on 2010-03-08 16:33:19 EST ---

Created an attachment (id=398629)
Photo of the boot failure

--- Additional comment from 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:

--- Additional comment from 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 on 2010-04-28 12:59:12 EDT ---


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 on 2010-05-03 21:38:45 EDT ---

kernel- has been submitted as an update for Fedora 13.

--- Additional comment from on 2010-05-04 19:53:16 EDT ---

kernel- 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 on 2010-05-05 13:30:19 EDT ---

I had my wireless AP set to use AES for encryption, and after upgrading to kernel- 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 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.


Comment 1 Bug Zapper 2010-07-30 11:33:30 UTC
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:

Comment 2 Andy Lutomirski 2011-05-25 13:19:46 UTC
This bug will be fixed when these two commits make their way upstream:;a=commit;h=9bed4aca296fdf9c1b85a8f093e92018dc9864f3;a=commit;h=b23b64516500df6b70fcafb820970f18538252cf

Any kernel config workarounds can go away then.


Note You need to log in before you can comment on or make changes to this bug.