Bug 1110920 - LVM: Existing Fedora rendered unbootable after installing Fedora n+1, missing grub entry
Summary: LVM: Existing Fedora rendered unbootable after installing Fedora n+1, missing...
Keywords:
Status: CLOSED DUPLICATE of bug 825236
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-06-18 19:10 UTC by Chris Murphy
Modified: 2014-06-19 19:07 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-19 19:07:06 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
program.log (77.55 KB, text/plain)
2014-06-18 19:11 UTC, Chris Murphy
no flags Details

Description Chris Murphy 2014-06-18 19:10:19 UTC
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

Comment 1 Chris Murphy 2014-06-18 19:11:09 UTC
Created attachment 910124 [details]
program.log

Comment 2 Chris Murphy 2014-06-18 19:12:21 UTC
See also bug 964828, which is similar but is a grub2-mkconfig bug creating the properly formed entry for the prior Fedora system.

Comment 3 Chris Murphy 2014-06-18 19:22:22 UTC
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.

Comment 4 Chris Murphy 2014-06-18 19:26:45 UTC
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.

Comment 5 Adam Williamson 2014-06-19 19:07:06 UTC

*** This bug has been marked as a duplicate of bug 825236 ***


Note You need to log in before you can comment on or make changes to this bug.