Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Anaconda should run grub2-mkconfig when LVM devices are active|
|Product:||[Fedora] Fedora||Reporter:||Hedayat Vatankhah <hedayatv>|
|Component:||anaconda||Assignee:||Anaconda Maintenance Team <anaconda-maint-list>|
|Status:||NEW ---||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||23||CC:||anaconda-maint-list, awilliam, bcl, bugzilla, collura, dcantrell, dennis, g.kaviyarasu, hedayatv, jonathan, mads, mcatanzaro, pjones, robatino, vanmeeuwen+fedora|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2014-02-05 06:58:37 EST||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Hedayat Vatankhah 2012-05-25 08:19:40 EDT
Description of problem: Apparently, currently Anaconda runs grub2-mkconfig when LVM devices are not active; since os-prober (and as a result, grub2-mkconfig) does not detect OSes (e.g. Another Fedora installation) installed on LVM partitions. However, if I run grub2-mkconfig after installation, it'll detect them too. Therefore, it seems that Anaconda should activate LVM devices before running grub2-mkconfig
Comment 1 Jesse Keating 2012-07-16 19:45:21 EDT
Anaconda isn't going to activate the lvms not used for install. If os-prober needs to look into them, it needs to activate (and then deactivate) them itself.
Comment 2 Hedayat Vatankhah 2012-12-03 03:05:47 EST
*** Bug 880491 has been marked as a duplicate of this bug. ***
Comment 3 Hedayat Vatankhah 2012-12-03 03:24:55 EST
os-prober can't do this because grub2 (in fact, 30_os-prober script) later uses the device to retrieve full boot parameters (it uses os-prober again for that, but that's a different script (linux-boot-prober) which is executed separately). Therefore, os-prober should not de-activate LVM partitions and linux-boot-prober doesn't know which partitions are activated and which ones where already active when os-prober was called. Therefore, activating/deactivating LVM partitions should be done either in Anaconda, or in grub2. It seems that anaconda team think that it is not their job (while it can be said that grub2-mkconfig is also part of install). On the other hand, doing it in grub2 has the advantage that it also works for already installed systems. I wonder if activating & deactivating LVM partitions on a running system is acceptable.
Comment 4 Mads Kiilerich 2012-12-03 15:51:24 EST
(In reply to comment #3) > I wonder if activating & > deactivating LVM partitions on a running system is acceptable. FWIW, I don't think so. I think it would be better to have a separate tool that could be run initially (or manually) and create a static /etc/grub.d file. That would make it much more acceptable to run grub2-mkconfig after installing new kernels and thus avoid using /sbin/grubby. - but that is OT ;-) But FWIW: I doubt it will be fixed in grub. A fix in anaconda is much more likely to happen.
Comment 5 Hedayat Vatankhah 2012-12-12 18:35:57 EST
*** Bug 886270 has been marked as a duplicate of this bug. ***
Comment 6 Leslie Satenstein 2013-01-10 15:35:24 EST
Since this bug fix will not make F18 (as of this comments' timestamp), it is perhaps a very good idea to indicate the problem and the work around in the Fedora 18 release notes. In the release notes I would indicate that if the system had multiple distributions or operating systems, and at boot time, if the grub presentation was missing some from the list, then perform the following after firstboot: log to root or sudo su and run grub2-mkconfig >/tmp/grub.cfg #check it out here cp /boot/grub2/grub.cfg /boot/grub2/grub.bak #make a backup and keep orig cp /tmp/grub.cfg /boot/grub2 #now delete original rm /tmp/grub.cfg #now clean up. I always retain a previous copy
Comment 7 Mads Kiilerich 2013-01-10 15:38:28 EST
(In reply to comment #6) You should use -o instead of >, as mentioned in readme.fedora.
Comment 8 Leslie Satenstein 2013-01-10 15:52:13 EST
Hi Mads Re using -o I am a cautious person and since there is no man page for grub2-mkconfig in "Fedora 17" to tell me if there are side effects of using -o I remained cautious and chose to use redirection, which worked just fine for me. Would -o create different ownership and permissions? (no man page to tell me) If the Fedora team fixes the bug before go-live, then what I wrote is a moot point. if F18 gets shipped with the bug, then as I pointed out, a good place to advise the admin or person doing the installation about the problem is with the release notes. In the notes, you may phrase the information and solution as you wish.
Comment 9 Mads Kiilerich 2013-01-10 18:36:47 EST
Doing something different from what the documentation says is not being cautious. -o will make sure you never get a incomplete file even if grub2-mkconfig crashes.
Comment 10 Hedayat Vatankhah 2013-02-23 00:50:52 EST
Mads, would you please see if such a change can make it do Grub2, and if not, why? If it can be done in grub2, it has some advantages (it would also work if it is run in an installed system in which LVM devices are not active), and if it really shouldn't be fixed in grub2, this bug should be reassigned to Anaconda. I wonder if Anaconda disables LVM devices when run in live mode. If it doesn't, enabling all LVM devices in anaconda in DVD should be OK, since it is what happens in Live disks.
Comment 11 Mads Kiilerich 2013-02-24 10:01:41 EST
(In reply to comment #10) Sorry, I don't have time for that at the moment. If anything I would suggest working with upstream grub. But FWIW, right know I think that considering that os-prober already do a lot of probing and mounting of file systems, then it would be a reasonable expectation (and not significantly worse) if os-prober also did whatever it takes to detect lVMs.
Comment 12 Hedayat Vatankhah 2013-02-25 14:52:20 EST
Yes, I've considered doing this in os-prober, but I explained above that os-prober is actually called more than once from grub2-mkconfig (os-prober and linux-boot-prober for each GNU/Linux OS found), it should either preserve the state (which LVM partitions are activated by os-prober) and deactivate them after last call (which it can't detect), or should activate and deactivate them each time which could make it very slow and doesn't look like a good solution. It is much better if it is done in 30_os-prober or by Anaconda.
Comment 13 Leslie Satenstein 2013-06-16 09:41:52 EDT
Before GO live, as a Beta tester who just wipes a spare physical disk clean and does a reinstall, I find that the grub.cfg after installation is far from complete. It is missing other distributions. (My config is 4 disks, with /dev/sdd used as a wipe-and-reinstall disk for Fedora testing. On the system are Windows, Mint14, Fedora 18, and Suse. Anaconda does not detect Mint14 or Suse as the final action before asking for the system to be rebooted. On reboot, I actually do an immediate grub2-mkconfig and it properly corrects for the omissions during the F19 installation. So, my question is, is the grub2-install in anaconda as currrent as the one in F19?
Comment 14 Leslie Satenstein 2013-06-16 09:52:27 EDT
Merge this with 835517
Comment 15 Hedayat Vatankhah 2013-06-16 14:26:40 EDT
More information is needed. Where does Mint14 and Suse installed? Are they on LVM or... ? If not LVM, it is probably some other requirement.
Comment 16 Hedayat Vatankhah 2013-09-22 07:53:59 EDT
It seems that the same problem needs to be addressed for BTRFS partitions too.
Comment 17 Fedora End Of Life 2013-12-21 03:36:50 EST
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Comment 18 Fedora End Of Life 2014-02-05 06:58:40 EST
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 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.
Comment 19 Adam Williamson 2014-06-18 18:38:52 EDT
I have to say I disagree with Jesse's original assertion here (c#1). It seems a much more desirable design for me that anaconda should ensure the environment in which grub2-mkconfig will run is optimal for OS discovery, than to expect grub2-mkconfig to go around poking things in order to try and find OSes. It just seems to me that it makes sense for grub2-mkconfig to run with the environment it's given; providing the correct environment should be the responsibility of the entity invoking it, which in this case is anaconda.
Comment 20 Chris Murphy 2014-06-19 15:05:05 EDT
Either this bug, or bug 1110920 is a duplicate. The argument in 1110920 is to either fix the problem or inform the user that their previously bootable system won't appear in the boot menu after installing Fedora. Either way something needs to be done, it isn't OK to silently break a previously bootable system.
Comment 21 Adam Williamson 2014-06-19 15:07:06 EDT
*** Bug 1110920 has been marked as a duplicate of this bug. ***
Comment 22 Adam Williamson 2014-06-19 15:10:19 EDT
pjones agrees with the contention that it's not appropriate for grub2-mkconfig / os-prober to go around poking inactive storage devices to try and find OSes, hence the re-assignment back to anaconda. This really does seem like a straight up anaconda bug, to me. anaconda really ought to make sure installed OSes are visible at the time it invokes bootloader configuration. At *least*, it must surely be anaconda's responsibility to ensure other Fedora / Red Hat instances are properly discoverable for bootloader purposes; it's hard to see how it can be anyone else's job to make sure that if you install two Fedora releases together, both are bootable.
Comment 23 Fedora Blocker Bugs Application 2014-08-16 14:56:37 EDT
Proposed as a Blocker for 21-final by Fedora user catanzaro using the blocker tracking app because: This bug does not appear to violate any current release criterion, which I find surprising. I propose a new blocker criterion: "The installer must be able to detect all preexisting Linux installations and create working boot menu entries for those installations." I'm sure that wording needs to be more precise, but the intent is that installing Fedora should not make previous Linux installations disappear. If that's too broad then we could restrict it to previous Fedora installations instead.
Comment 24 Brian Lane 2014-08-18 19:06:33 EDT
bz is not the place to propose new criteria. I also object to wording like 'must be able to detect ALL preexisting Linux installations', it seems like you are trying to add features via release criteria. If you want new features, open a RFE bug for it or discuss it on the anaconda-devel mailing list: https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Comment 25 Michael Catanzaro 2014-08-18 22:01:56 EDT
(In reply to email@example.com from comment #24) > bz is not the place to propose new criteria. I also object to wording like > 'must be able to detect ALL preexisting Linux installations' If there's a technical reason why this is infeasible, then we should certainly soften the wording. > If you want new features, open a RFE bug for it or discuss it on the > anaconda-devel mailing list: > https://www.redhat.com/mailman/listinfo/anaconda-devel-list I think what I want is "Anaconda should run grub2-mkconfig when LVM devices are active" so probably this bug is sufficient.
Comment 26 Adam Williamson 2014-08-22 14:47:53 EDT
please propose release criteria on the test@ list, thanks. bcl: is it planned to fix this at least for the Fedora case for F21? It does seem like a significant bug.
Comment 27 Michael Catanzaro 2014-08-23 11:13:55 EDT
(In reply to Adam Williamson (Red Hat) from comment #26) > please propose release criteria on the test@ list, thanks. OK!
Comment 28 Adam Williamson 2014-11-07 17:45:04 EST
Just to confirm, this is still valid in 21 Final TC1 (I was trying to test another UEFI multiboot bug, but couldn't even manage to hit that one when installing alongside an F20 install to LVM, because of this bug). We likely will not make this block F21 release - it's a bit late to add new multiboot requirements - but it'd certainly be nice if we could fix it in time.
Comment 29 Leslie Satenstein 2015-02-13 16:57:09 EST
I no longer have a concern
Comment 30 Jan Kurik 2015-07-15 11:08:18 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23