This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 586916 - Unable to decrypt disk on F-12 x86_64 install on T410: required "rdblacklist=aesni-intel"
Unable to decrypt disk on F-12 x86_64 install on T410: required "rdblacklist=...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
13
All Linux
low Severity high
: ---
: ---
Assigned To: Tom "spot" Callaway
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F13Blocker/F13FinalBlocker
  Show dependency treegraph
 
Reported: 2010-04-28 10:04 EDT by Chuck Ebbert
Modified: 2010-05-06 09:53 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 571577
Environment:
Last Closed: 2010-05-06 09:53:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Chuck Ebbert 2010-04-28 10:04:28 EDT
+++ 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@redhat.com on 2010-03-08 16:33:19 EST ---

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

--- Additional comment from dmalcolm@redhat.com 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@redhat.com on 2010-03-16 05:15:15 EDT ---

Can you get to a shell after boot fails and see what is in /proc/crypto?
Comment 1 Adam Williamson 2010-04-30 15:01:57 EDT
This bug was discussed at the 2010/04/30 blocker review meeting. 

It is accepted as a direct blocker as it hits the criterion "The installer must be able to complete an installation using the entire disk, existing free space, or existing Linux partitions methods, with or without encryption enabled" - https://fedoraproject.org/wiki/Fedora_13_Alpha_Release_Criteria - for a reasonably wide range of systems.

Proposed approach here is to ship with the module disabled in the kernel config, then ship a kernel update that enables the module once we're confident it's behaving correctly.

Please try as hard as possible to have the changes ready for Tuesday 2010/05/04, when the Fedora 13 RC stage will be starting up. Thank you.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 2 Adam Williamson 2010-05-03 20:06:24 EDT
assigning to spot for action, kyle is aware of this issue but says he doesn't 'want to' push the workaround.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 3 Adam Williamson 2010-05-03 22:02:11 EDT
kyle has pushed a kernel with the workaround (thanks kyle):

https://admin.fedoraproject.org/updates/kernel-2.6.33.3-79.fc13

I can test kernel for regressions but can't confirm the encryption actually works on the affected hardware (though it really ought to, as it should now behave precisely like any other hardware); can someone who has it please test? Thanks.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 4 Dave Malcolm 2010-05-04 14:34:25 EDT
I've done some verification of this issue, testing with and without the "rdblacklist=aesni-intel" option on various kernels.

kernel-2.6.32.9-67.fc12.x86_64:
  - booting without special options: FAILS: reaches the plymouth crypto "ask for a key" UI, but upon entering correct key, it fails with the "Failed to load transform for xts-aes-aesni: -2" error message
  - booting with "rdblacklist=aesni-intel": WORKS: am able to proceed through to gnome desktop

kernel-2.6.32.9-70.fc12.x86_64:
  - as above: needs "rdblacklist=aesni-intel" at kernel command line, or it can't decrypt the disk

Testing the new kernel required me to update to f13, so I did a yum update from f12 to f13.

kernel-2.6.33.3-72.fc13.x86_64:
  - as above: needs "rdblacklist=aesni-intel" at kernel command line, or it can't decrypt the disk


kernel-2.6.33.3-79.fc13.x86_64:
  - works both with _and_ without the "rdblacklist=aesni-intel" at kernel command line

So 2.6.33.3-79 does indeed seem to fix the crypto issue.

I'm running with 2.6.33.3-79 now, and it mostly seems to work.

I do see a graphical glitch when starting X (which appears to also have been present with -72, and may be related to the upgrade from F-12 to F-13): when starting X with an external monitor connected, I need to switch to a tty then back to X before I get any output on either the external or builtin display, other than a flickering vertical lines in the left-most few columns of the external monitor.   (I'm in the RH Westford office, with this machine, and can show the ehavior there if that will help).   Should I file a separate bug about this video issue?
Comment 5 Adam Williamson 2010-05-04 17:21:53 EDT
Thanks Dave, that's great. Yes, please file a new bug on the graphical issue. Do you have access to any older F13 kernels to check that with, perhaps figure out roughly when it came in? You could check the Beta, perhaps.
Comment 6 Adam Williamson 2010-05-06 09:53:09 EDT
-79 has gone to stable, so let's close this. Dave, did you file a separate bug for your graphics issue (just so I can look at it)? Thanks.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

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