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