Description of problem: Fedora 20 is installed leaving some free space. Then Fedora Rawhide is installed which renders Fedora 20 unbootable because there's no menu entry for it at all. The reason why is because os-prober doesn't find Fedora 20, because the LV its root is on is not active at the time anaconda calls grub2-mkconfig. Assumption is that anaconda needs to make all LV's active so that os-prober can probe them and produce any necessary menu entries. Also assuming this problem doesn't happen if the prior/existing system is a non-LVM install. Version-Release number of selected component (if applicable): anaconda-21.37.1.fc21 os-prober-1.58-6.fc21.x86_64 How reproducible: Always if the previous installation root is on an LV. Steps to Reproduce: 1. Install Fedora 20 using default ext4+LVM2 layout leaving some free space. 2. Install Fedora 21 using default ext4+LV2 layout into free space. Actual results: Fedora 20 is not a boot menu option in GRUB. Only Rawhide is a boot option. Expected results: Fedora 20 and 21 should be boot options. Additional info: While booted in the live environment... [root@localhost fedora]# os-prober /dev/mapper/fedora00-root:Fedora release 21 (Rawhide):Fedora:linux [root@localhost fedora]# lvs LV VG Attr LSize Pool Origin Data% Move Log Cpy%Sync Convert home fedora -wi------- 11.72g root fedora -wi------- 14.65g swap fedora -wi-ao---- 2.52g root fedora00 -wi-ao---- 47.43g swap fedora00 -wi-ao---- 2.50g os-prober in the live environment isn't finding Fedora 20 because fedora-root is not active. Question is whether anaconda is supposed to make it active so os-prober can find it, or if os-prober should make all LV's active before it probes? [root@localhost fedora]# lvchange -a y /dev/fedora [root@localhost fedora]# lvs LV VG Attr LSize Pool Origin Data% Move Log Cpy%Sync Convert home fedora -wi-a----- 11.72g root fedora -wi-a----- 14.65g swap fedora -wi-ao---- 2.52g root fedora00 -wi-ao---- 47.43g swap fedora00 -wi-ao---- 2.50g [root@localhost fedora]# os-prober /dev/mapper/fedora-root:Fedora release 20 (Heisenbug):Fedora:linux /dev/mapper/fedora00-root:Fedora release 21 (Rawhide):Fedora1:linux
Created attachment 910124 [details] program.log
See also bug 964828, which is similar but is a grub2-mkconfig bug creating the properly formed entry for the prior Fedora system.
OK so this is probably a duplicate of bug 825236. Hence it's also not EFI specific. Until we sort out how this is going to work, I think anaconda needs to warn the user that their prior install will become unbootable and require manual post install work. Borking their previously working system without notice and expecting them to figure it all out is the work of a user hostile installer.
Actually this behavior is worse on UEFI because Anaconda obliterates the /boot/efi/EFI/fedora contents in favor of all new contents. So the previous systems's grub.cfg is lost. So it's a data loss bug on UEFI. On BIOS it's slightly less bad because the old grub.cfg still exists, merely requiring esoteric knowledge on the part of the user to fix the problem correctly.
*** This bug has been marked as a duplicate of bug 825236 ***