Description of problem: Bug 553411 added xts support into RHEL5.7. But anaconda treat xts encrypted disk as un-initialized disk. If will cause data loss if user/customer choose to initializ that disk. Version-Release number of selected component (if applicable): RHEL5.7-Server-20110628.1.n repo How reproducible: 100% Steps to Reproduce: 1. Created a xts disk in RHEL5.7 (cryptsetup-luks-1.0.3-6.el5 and kernel-2.6.18-259.el5) by this disk: cryptsetup -c aes-xts-plain64 -s 512 luksFormat /dev/sda 2. Install RHEL 5.7 with that disk. Actual results: Anaconda treat the encrypted disk as un-initialized disk. Expected results: Anaconda prompt for password. Additional info:
anaconda in RHEL-5 has never supported whole disk encryption. You can either have encrypted partitions (e.g., /dev/sda1) or encrypted LVM volume groups and probably encrypted LVM logival volumes, but you cannot encrypt a whole disk and have anaconda use that. The behavior you are seeing is expected and has been there since 5.0. If you create a valid disk label on the device (e.g., a DOS disklabel), then create a single partition and encrypt that, anaconda will find it and prompt you for the password. The key thing here is that anaconda must have disks with valid disk labels in order to do anything. Without a valid disk label, it will assume the disk is uninitialized and offer to relabel it and let you make partitions on it.
David, Thanks for the update. I tried on /dev/sdb1 which is fdisk and encrypted by RHEL6, still got some issue for xts encrypted disk. == VNC/KVM anaconda mode == I got the these error after I input the passwd for xts encrypted disk: (Confirmed in anaconda shell Ctrl+Alt+F2, dmsetup table show luks partition has successfully opened and /dev/mapper/luks-<UUID> also ready for I/O) =========== Traceback (most recent call first): File "/usr/lib/anaconda/partedUtils.py", line 904, in findExistingRootPartitions if fstype == "ext3": File "/usr/lib/anaconda/upgrade.py", line 151, in findExistingRoots rootparts = anaconda.id.diskset.findExistingRootPartitions(upgradeany = upgradeany) File "/usr/lib/anaconda/upgrade.py", line 108, in findRootParts anaconda.id.rootParts = findExistingRoots(anaconda) File "/usr/lib/anaconda/dispatch.py", line 207, in moveStep rc = stepFunc(self.anaconda) File "/usr/lib/anaconda/dispatch.py", line 130, in gotoNext self.moveStep() File "/usr/lib/anaconda/gui.py", line 1156, in nextClicked self.anaconda.dispatch.gotoNext() UnboundLocalError: local variable 'fstype' referenced before assignment =========== == Text anaconda mode == === for complex password: 'redhat redhat ' === It keep querying for passwd even I am surely inputed the correct passwd. Console complain about incorrect passwd. === for simple password: 'redhat' === It will got same python error as vnc/kvm mode do. I reopen this bug for above issue. If you think it should in a new bug, let me know. As enable xts support is kind of important for RHEL5, please reply ASAP. Thanks.
Created attachment 511096 [details] Anaconda crash log for xts in RHEL5.7-Server-20110630.0
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: anaconda does not support xts encryption for storage volumes. If you have existing xts encrypted volumes, anaconda will detect them as unpartitioned storage space and ask you if you wish to initialize them. Be sure to have anaconda ignore any volumes you have with xts encryption and then configure them for use after installation. If you wish to set up new xts volumes, you will need to do so after installation. Be sure to leave available storage space that you can allocate for the xts encrypted volumes after installation.
Just want to clarify,which feature we are going to fix in this bug? 1. Enable xts __volume__ support for open and mount operation in anaconda. 2. Enable xts __disk__ support for open and mount operation in anaconda. or both of them? The subject of this bug need to be updated just in case someone got confused about Comment #1. Comment #2 should be bug description in stead of comment #0
Deleted Technical Notes Contents. Old Contents: anaconda does not support xts encryption for storage volumes. If you have existing xts encrypted volumes, anaconda will detect them as unpartitioned storage space and ask you if you wish to initialize them. Be sure to have anaconda ignore any volumes you have with xts encryption and then configure them for use after installation. If you wish to set up new xts volumes, you will need to do so after installation. Be sure to leave available storage space that you can allocate for the xts encrypted volumes after installation.
To reproduce: 1) In RHEL 6.2 create an encrypted partition taking all disk space: # cryptsetup luksDump /dev/vdb1 | grep Cipher Cipher name: aes Cipher mode: xts-plain64 2) In 5.6 anaconda keeps asking for the pass phrase for vdb1 even if it is entered correctly. In 5.8 snapshot #1: 1) In GUI mode - enter vdb1 pass phrase - device is unlocked. Create other partitions, assign mount point for vdb1 (do not format) - partition is mounted and writeable after the install. 2) In TUI mode - enter vdb1 pass phrase - device is unlocked. Format other partions, assign mount point for vdb1 (do not format) - all works as expected
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0197.html