Red Hat Bugzilla – Bug 826866
New installation won't boot, damaged existing F16 installation (grub2-mkconfig bug)
Last modified: 2012-05-31 07:03:32 EDT
Description of problem: I keep having 2 fedora installations ("old" and "new") as well as a windoze partition in my machine. The Linux installations share the same /boot partition, and I keep reusing the Linux partitions (for instance, when F17 was released, I keep my F16 installation, and install the F17 in the partition where I previously had F14 installed). After installing F17 to disk (using KDE spin), I ended up with a system where * F17 boots in "crippled" state (no ethernet port detected, etc) * I cannnot boot my F16 on another partition any longer using the new grub2 installed into /dev/sda The problem is due to the fact that the auto-generated grub.conf specified improper kernel versions. This happens for both: the F17 (grub2-mkconfig picked the kernel from F16 for it), and my F16 installation (it picked an old kernel from the previous F14 installation, which was still present on the /boot partition). You may want to look at the attachment 587954 [details] (for another grub2-related problem, #826612), where I put my grub.cfg that has the problem. After booting to Linux I edited the /boot/grub2/grub.cfg file so that to specify the proper version of the kernel and initrd images for subsequent entries, I was able to get a functioning F17, and also boot into my F16 installation. Version-Release number of selected component (if applicable): rpm -q grub2 grub2-2.0-0.25.beta4.fc17.x86_64 I believe that this issue may also be related (be at the origin of) the bugs #820351 and #826612.
(please write bug numbers as 'bug 820351' so they get linked automatically) How did you install/upgrad f17? The initial bad f17 kernel is probably bug 820351. A shared /boot is not a good idea and will not work. It is better to use separate /boot and chain the boot loaders somehow. The futureproof way is to put a configfile entry in /boot/grub2/custom.cfg. The working but less recommended way is to use 'chainload', either directly to core.img or to the partition where it has been installed (probably with a fragile blocklist). The entries generated from os-prober is currently broken. They might change to use the configfile method in the future. This is a messy bug report where several issues are mentioned. It is thus impossible to follow up on and no single fix can fix it ... and parts of it is probably duplicates of issues that is discussed elsewhere. Please file issues separately. Please clarify and rephrase what _the_ bug you want to report here is. Especially "grub2-mkconfig picked the kernel from F16 for it" indicates "something" but is very unclear.
Hi there, Sorry for not having given a clear report. The actual bug that I wanted to report is with the grub2-mkconfig and likely with the os-prober, which did not match the kernels to my installations correctly. As you explained, the os-prober seems to be broken, hence I understand that the bug has already been reported and it is being looked at. I wonder if there is any workaround that would make my further installations of F17 smooth (ie. so that I won't have to correct the grub.cfg manually). Now a couple of explanations about my installation of F17. What I did to install F17 was the following. I have a machine with two installations: F16 (which I use daily to work) and a F14 (which was my previous "production" version, before I got F16 configured/tailored for all my needs). I prefer having these parallel installations, rather than upgrades of my system simply for productivity reasons (If something does not work, I could still boot to the previous version). I apply this "cyclic" model and it works pretty well for 15+ years of my use of RedHat and then Fedora. I decided that I will install the F17 into the partition that was occupied by (now unused for long time) F14 installation. I booted the F17 KDE Spin, and chose "Install to HD". Then I chose "custom partitioning" method, and told it to install to /dev/sda5, which was previously used by F14. I also told it to use /dev/sda2 as /boot (shared boot). So far, sharing the /boot has always worked "out of the box". I understand that with LILO then GRUB, each having the config files in its separate /etc, there was no conflict between the installations. Now with the grub2 config being on the /boot, indeed there may be issues that would need to be looked at. Still I believe, there must be a way out of this, that would not require me re-partitioning the disks completely... And that there are people who, like me, use similar multi-boot setups. hope this helps, Piotr