Description of problem: I've standard encrypted setup (luks+LVM). I'm creating new LV volume on which I'd like to install new fedora system. The /boot partition is common and is the first unencrypted partition on the disk. I start the livecd and run anaconda (icon on the desktop), go through the install procedure and unlock the existing luks setup. Then I assign / to the previously created partition and /boot to current /boot partition. Everything seems to be correct, but in the end anaconda misteriously decides to regenerate ALL initramfs disks that are present in /boot, which does not really work well. It should not touch them at all! It also rewrites grub.cfg with wrong variables, rendering the previous system unbootable, as the root= no longer matches what it was. The same issue is with latest centos7.1 live. FC22 beta does not even get to that point. With Centos it's even worse, as the last available kernel was older that one in my fedora and it completely messed up the boot entries. Version-Release number of selected component (if applicable): Fedora-Live-KDE-x86_64-21-5.iso How reproducible: always Steps to Reproduce: 1. run default fedora encrypted install of F19 (leave some space in the VG). I run it from livecd 2. (I'm always fully updating the system here) 3. create a LV with sufficient space available to hold new F21 installation (I'm using 10G) 3. Get Fedora-Live-KDE-x86_64-21-5.iso and try installing fedora onto that new partition 4. reboot and boot to previous F19 installation Actual results: the previous installation is not bootable (you end up in F21) Expected results: * no initramfs rewritten for kernels that have not been newly installed * no grub entries changed, just new ones added for new installation * older installations bootable as if the installation of new fedora never happened (this was the case with F19) Additional info:
*** This bug has been marked as a duplicate of bug 1074358 ***