Created attachment 897792 [details] From attempted anaconda install involving an encrypted partition. Description of problem: Kickstart directed install fails with No preexisting VG with the name "vg_thyrsuslaptop" was found ...yet the logs are full of mentions of the volume group and its logical volumes, the directory /dev/vg_thyrsuslaptop contains the logical volume names, the device mapper mapper components are all present, "vgdisplay" shows the volume available. The physical volume is LUKS. Version-Release number of selected component (if applicable): Fedora 20 x86_64 install version How reproducible: always Steps to Reproduce: 1. sda1 - /boot partition (to be overwritten) 2. sda2 - LUKS partition 3. decrypted LUKS as physical volume for lvm2 Actual results: After prompting for the LUKS password, activates VG and makes LV available to shell, but anaconda doesn't recognize it. Expected results: Install onto lv_root and lv_swap, configure lv_home to be mounted. Additional info: Will attach log files from /tmp. Results are from a virtual machine closely emulating my production laptop; configs managed by cobbler. The virtual machine would allow shenanigans to get this to work, but which wouldn't address the actual object, which is the hardware laptop I'd like to update.
Created attachment 897793 [details] Kickstart %pre script which make LUKS partition available
Created attachment 897794 [details] Storage log showing presense of VG
Created attachment 897795 [details] gzip'd storage.state file
Created attachment 897796 [details] Kickstart file
The only way to make this work currently is to specify the passphrase in the kickstart config as part of the partition command for the encrypted PV(s). I will take a look at adding the ability to associate an active luks device with its backing device.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.