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