Created attachment 320540 [details] /tmp/anaconda.log from the 2nd install (right after showing partitioning screen) Description of problem: Anaconda fails to unlock all previously encrypted partitions in subsequent install. See steps to reproduce for details. Version-Release number of selected component (if applicable): anaconda-11.1.2.136-2 How reproducible: Steps to Reproduce: 1. Install a system with 2 disks such as: /dev/sda1 vfat /boot/efi /dev/sda2 software RAID /dev/sda3 software RAID /dev/sda4 ext3 /home, encrypted /dev/sdb1 software RAID /dev/sdb2 software RAID /dev/sdb3 vfat /data, encrypted /dev/md0, ext3, RAID5 (all partitions), /, encrypted 2. System installs and boots without problems (see https://bugzilla.redhat.com/show_bug.cgi?id=456283#c28) 3. Reboot and initiate second install 4. A prompt appears asking you to enter the pass phrase for /dev/md0. Enter it without selecting "global pass phrase" 5. Although there are 2 other encrypted devices no other prompts appear. 6. Select custom partitioning Actual results: No prompt for /home and /data partitions. In disk druid they appear as type Foreign Expected results: anaconda will ask for pass phrases or other 2 encrypted partitions. Additional info: Data after 1st install: [root@roentgen ~]# cat /etc/fstab /dev/mapper/luks-7aa8c29d-c2fc-447d-a7d3-d937037f1795 / ext3 defaults 1 1 /dev/mapper/luks-e9e0b642-a14c-4c16-9e24-801170499b41 /home ext3 defaults 1 2 /dev/mapper/luks-592f0948-3794-4f2f-ba8a-e52634fd0355 /data vfat defaults 0 0 /dev/sda1 /boot/efi vfat defaults 0 0 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 [root@roentgen ~]# cat /etc/crypttab luks-7aa8c29d-c2fc-447d-a7d3-d937037f1795 UUID=7aa8c29d-c2fc-447d-a7d3-d937037f1795 none luks-e9e0b642-a14c-4c16-9e24-801170499b41 UUID=e9e0b642-a14c-4c16-9e24-801170499b41 none luks-592f0948-3794-4f2f-ba8a-e52634fd0355 UUID=592f0948-3794-4f2f-ba8a-e52634fd0355 none [root@roentgen ~]# cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md0 : active raid5 sdb2[3] sdb1[2] sda3[1] sda2[0] 31456512 blocks level 5, 256k chunk, algorithm 2 [4/4] [UUUU] unused devices: <none> [root@roentgen ~]# blkid /dev/mapper/luks-592f0948-3794-4f2f-ba8a-e52634fd0355: UUID="48F6-E97D" TYPE="vfat" /dev/mapper/luks-e9e0b642-a14c-4c16-9e24-801170499b41: LABEL="/home" UUID="e0207af4-7e89-4682-b4ab-f9df1dd5f40d" TYPE="ext3" /dev/mapper/luks-7aa8c29d-c2fc-447d-a7d3-d937037f1795: UUID="0ab6c8f9-95b1-490a-9fb8-96ce74f1bd9e" TYPE="ext3" /dev/sda1: SEC_TYPE="msdos" LABEL="/boot/efi" UUID="48F6-E97F" TYPE="vfat" /dev/sda2: UUID="7aa8c29d-c2fc-447d-a7d3-d937037f1795" TYPE="crypt_LUKS" /dev/sdb1: UUID="5e0a52ff-ff8a-4f5c-b425-3bc3e48c4f40" TYPE="crypt_LUKS" /dev/md0: UUID="7aa8c29d-c2fc-447d-a7d3-d937037f1795" TYPE="crypt_LUKS" /dev/sdb3: UUID="592f0948-3794-4f2f-ba8a-e52634fd0355" TYPE="crypt_LUKS" /dev/sda4: UUID="e9e0b642-a14c-4c16-9e24-801170499b41" TYPE="crypt_LUKS"
What do you see on tty5? And what happens if you run 'cryptsetup isLuks /dev/sdb3' and 'cryptsetup isLuks /dev/sda4' on tty2? This is on ia64 again, right?
(In reply to comment #1) > This is on ia64 again, right? Yes, ia64. Strange enough this time I was asked for the pass phrase for all 3 block devices in this order: sda4, sdb3, md0. Only sdb3 which is encrypted vfat seems to have problems. The UI shows it as foreign and the logs says: sh-3.2# grep sdb3 /tmp/anaconda.log 07:33:23 INFO : going to get passphrase for encrypted device sdb3 07:33:28 INFO : mapping LUKS device sdb3 to luks-53f794eb-6cf5-44ad-8095-b15555bf3e46 07:33:36 INFO : mapping LUKS device sdb3 to luks-53f794eb-6cf5-44ad-8095-b15555bf3e46 07:33:45 INFO : mapping LUKS device sdb3 to luks-53f794eb-6cf5-44ad-8095-b15555bf3e46 07:33:45 DEBUG : sdb3 is encrypted; filesystem is 'None'
Still seeing this issue with all PVs encrypted and only lv_swap encrypted. Entering pass phrase & selecting "global pass phrase" shows all LVs as foreign.
So you have seen two different behaviors (comment #2 being the second). Any ideas what the differentiating factor is? I was able to reproduce the behavior in comment #2. All LVM devices appear as they should, but the vfat device shows as foreign. The vfat is on sda2. sda3 is an encrypted PV containing an encrypted swap LV and two unencrypted ext3 LVs. I will investigate the vfat showing as foreign since that's the only part I can reproduce.
I am still working on a solution, but here's a quick update: the problem is that in RHEL5 we have only one way to detect a vfat filesystem, and that is via parted. The problem is that you cannot pass an arbitrary device to these parted methods and since the device that parted knows about is encrypted it cannot detect the vfat fs. I am looking now for potential solutions.
It looks like a fix for this is going to take more effort than is justifiable for encrypted vfat. A potential release note blurb could read something like: Pre-existing encrypted block devices containing vfat filesystems will appear as type 'foreign' in the partitioning interface. If you want the device to be mounted automatically during system boot, you will have to manually add an entry to /etc/fstab." There is a section describing this in the installation guide that might be worth referencing. I don't know what the final URL will be, but here is a link to the content: http://documentation-stage.bne.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Installation_Guide/ch28s04s07.html
Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Pre-existing encrypted block devices containing vfat filesystems will appear as type 'foreign' in the partitioning interface and will not be mounted automatically during system boot. To causes such devices to be mounted automatically, manually add an entry to /etc/fstab." Note to Ryan: There is a section describing this in the installation guide that might be worth referencing. I don't know what the final URL will be, but here is a link to the content: http://documentation-stage.bne.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Installation_Guide/ch28s04s07.html
thanks Denise. added to RHEL5.3 release notes.
Release note updated. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,8 +1 @@ -Pre-existing encrypted block devices containing vfat filesystems will appear as type 'foreign' in the partitioning interface and will not be mounted automatically during system boot. To causes such devices to be mounted automatically, manually add an entry to /etc/fstab." +Existing encrypted block devices that contain vfat file systems will appear as type 'foreign' in the partitioning interface; as such, these devices will not be mounted automatically during system boot. To ensure that such devices are mounted automatically, add an appropriate entry for them to /etc/fstab. For details on how to do so, refer to man fstab.- -Note to Ryan: -There is a section describing this in the installation guide that might be -worth referencing. I don't know what the final URL will be, but here is a link -to the content: - -http://documentation-stage.bne.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Installation_Guide/ch28s04s07.html