How reproducible: Steps to Reproduce: 1. Create and encrypt a filesystem and make sure that your passphrase include a space character. 2. Try to install RHEL5 (a dialog will appear asking the password) Actual results: - Passphrase dialog keep asking the password Expected results: - Anaconda should understand any character.
Please attach /tmp/anaconda.log to this bug report. Thanks.
Created attachment 382570 [details] anaconda.log sda3 = passphrase without spaces (worked) sda6 = passphare which contain spaces Provided 4 times the right password to dialog but without success.
Hi, Sorry, I've noticed that spaces in passphrase are not the issue here. However, RHEL5 installer seems not read the password created by Fedora 12 Installer. Both partitions are: ext3 /dev/sda3 was created by RHEL5 installer /dev/sda6 was created by Fedora 12 installer
We started using a different cipher in Fedora 11 or 12 (aes-xts-plain). RHEL5 installer runtime environment does not include the kernel modules needed to use this cipher.
This one has come in a bit too late to make it in to RHEL 5.5, putting it on the 5.6 proposed list. Based on discussion with dlehman, we just need to copy in the additional kernel modules (scripts/mk-images) to the initrd.img used by anaconda.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Hello, support for which cipher is requested here? Note that RHEL6 started using aes-xts-plain64 instead of aes-xts-plain (bug #600295).
This should be fixed in anaconda-11.1.2.213.
Upon closer investigation, the RHEL5 kernel lacks the XTS cipher that we use in RHEL6 and Fedora 12 and later. Unless the kernel team backports the XTS module to RHEL5, we will not be able to do anything for this bug in anaconda. We assumed the XTS cipher was available in RHEL5 kernels, but it is not. anaconda has the necessary support in its code, so if the xts.ko module shows up in the RHEL5 kernel, everything will fall in to place. Reassigning to the kernel team for them to consider for a future release. The largest use case seems to be users of RHEL6 with encrypted filesystems who want to mount those volumes in RHEL5. We use aes-xts-plain[64] in F-12/RHEL-6 and beyond. Certainly too late for 5.6. Flagging for 5.7 consideration.
I've finished (In reply to comment #14) > Upon closer investigation, the RHEL5 kernel lacks the XTS cipher that we use in > RHEL6 and Fedora 12 and later. Unless the kernel team backports the XTS module > to RHEL5, we will not be able to do anything for this bug in anaconda. We > assumed the XTS cipher was available in RHEL5 kernels, but it is not. > > anaconda has the necessary support in its code, so if the xts.ko module shows > up in the RHEL5 kernel, everything will fall in to place. > > Reassigning to the kernel team for them to consider for a future release. The > largest use case seems to be users of RHEL6 with encrypted filesystems who want > to mount those volumes in RHEL5. We use aes-xts-plain[64] in F-12/RHEL-6 and > beyond. > > Certainly too late for 5.6. Flagging for 5.7 consideration. I've finished the backport work, but didn't have an environment for testing. with following brew built kernel, the xts.ko should appear, can you help me test the xts module?
*** Bug 636208 has been marked as a duplicate of this bug. ***
Patch(es) available in kernel-2.6.18-252.el5 You can download this test kernel (or newer) from http://people.redhat.com/jwilson/el5 Detailed testing feedback is always welcomed.
Patch reverted in kernel-2.6.18-253.el5, due to concerns over possible issues with existing crypto export certification (or something along those lines).
Patch(es) available in kernel-2.6.18-259.el5 You can download this test kernel (or newer) from http://people.redhat.com/jwilson/el5 Detailed testing feedback is always welcomed.
Jarod, For kernel -268. The anaconda still don't have xts module. After installtion, we can open luks partition created by RHEL6, got these warning: === key slot 0 unlocked. *** stack smashing detected ***: cryptsetup terminated Aborted === I noticed that you reverted some patch, but xts, gf128mul modules are still in kernel -268. I am kind of confusing about xts in RHEL5, can you clarify its status and what does this bug suppoes to fix?
Sorry, needinfo incorrect people. Danny Feng, Please kindly reply the comments #34. Thanks.
(In reply to comment #35) > Sorry, needinfo incorrect people. > > Danny Feng, > > Please kindly reply the comments #34. Thanks. Well, this bz was tracked for xts module, the dm-crypt support for the new xts module was tracked by bz660368. As the bug you mentioned: === key slot 0 unlocked. *** stack smashing detected ***: cryptsetup terminated Aborted === This looks identical to bz678011, which confirms to be fixed in cryptsetup-luks-1.0.3-6.el5, so I need you to provide your crptsetup-luks info. If it is a lower version, please upgrade your cryptsetup-luks and try it again. Thanks.
For install time, xts module still cannot loaded even it's already in modules.cgz.
(In reply to comment #37) > For install time, xts module still cannot loaded even it's already in > modules.cgz. Is there any detailed info? What's the meaning for cannot loaded? modprobe error?
For install time, I guess it is just bug #703782 (some other crypto modules were missing from anaconda image.) (Change to support xts had side effect to require more modules from cryptoapi.)
(In reply to comment #38) > Is there any detailed info? What's the meaning for cannot loaded? > modprobe error? In anaconda shell (Alt+F2), lsmod show nothing about xts. modporbe in this shell will not work for any module ( not sure it's a bug or not, as all module has been compressed into modules.cgz). insmod will not work neither. As comment #39 spot out, tried new repo: RHEL5.7-Server-20110628.1.n xts module loaded sucessfully. luksOpen againt aes-xts-plai64 work well in anaconda shell. The only problem we left is: Anaconda cannot recognize the xts encrypted disk and refer it as un-initialize disk. Does any other bug for tracing this issue?
Bug 718123 created for anaconda issue. VERIFY this bug.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-1065.html