Hide Forgot
Description of problem: There's no grub2 menu displayed; after a time a random kernel is booted that cannot work Version-Release number of selected component (if applicable): grub2-2.0-0.25.beta4.fc17.x86_64 How reproducible: Perfectly. Steps to Reproduce: 1. Install fresh F17 2. At first boot no grub2 menu appears; an incorrect kernel eventually boots 3. Actual results: Unbootable system Expected results: Correct grub2 setup Additional info: There are so many major faults with grub2 it's hard to see where to begin. The most egregious are these: 1 - Instead of presenting a menu, my 64 bit machine displays an error message box "Input not supported" which steps diagonally up the screen. After about 30 sec the machine boots into some randomly chosen kernel. 2 - Most of the menuitems in /boot/grub2/grub.cfg are constructed incorrectly; only a few of them can possibly start a properly functioning system. Taken together, it is nearly impossible to boot a new Fedora 17 system. Item 1 means there's no way to choose among the various kernels and item 2 means the chance of hitting a working menuitem is slim to none. My standard procedure over many Fedora generations is to freshly install into alternating root partitions, keeping all the others intact. On this target machine I have /dev/sda1 /boot /dev/sda5 /f16 /dev/sda6 / /dev/sda7 /home /dev/sda8 /b1 /dev/sda9 swap /dev/sdb1 /h1 After completing installation of F17, /boot contained four kernels: vmlinuz-3.3.4-5.fc17.x86_64 vmlinuz-3.3.6-3.fc16.x86_64 vmlinuz-3.3.7-1.fc16.x86_64 vmlinuz-3.4.2-1.fc16.x86_64 Commonsense dictates that grub2 would present exactly four choices. Instead it constructs 14! These consist of all combinations of the four kernels with the two root partitions, with a couple of useless "Recovery" items for good measure. This is utter nonsense. If I can figure out which kernel is associated with which root partition, so can grub2. At "first boot", the machine booted an old F16 kernel combined with the new root partition. Unsurprisingly, nothing worked - no network, a very short list of modules - no way to continue with the installation, eg, yum update and yum install <others>. After much head-scratching and knashing of teeth I discovered the problem, and hand-edited /boot/grub2/grub.cfg (despite the injunction) and commented out all the garbage, leaving only the intended menuitem as the first. I also set default=0. With fingers crossed, I typed reboot which, as F17 is prone to do, froze the machine. After the necessary Reset, again there was no visible grub2 menu, but it correctly booted the new vmlinuz-3.3.4-5.fc17.x86_64. Networking worked and I was able to continue with yum update and the rest of the installation. This gave a new kernel - vmlinuz-3.4.4-3.fc17.x86_64 - and I was pleasantly surprised to see the new grub.cfg had a new entry inserted before all the rest, with all my edits retained, including set default=0, so I expected it to boot the new first menuitem correctly. Wrong! It booted the old vmlinuz-3.3.4-5.fc17.x86_64. Evidently, setting default=0 is no longer effective. This was fixed by more editing of grub.cfg, removing the old first menuitem for vmlinuz-3.3.4-5.fc17.x86_64*. Now I have a system that can only boot vmlinuz-3.4.4-3.fc17.x86_64 because there's no way to choose anything else. But at least it boots something!!! Some possibly relevant machine info: /proc/cpuinfo: model name : AMD Phenom(tm) II X4 840 Processor lspci: 00:0d.0 VGA compatible controller: nVidia Corporation C61 [GeForce 7025 / nForce 630a] (rev a2) Although it has an nvidia video card, I haven't yet gotten around to installing kmod-nvidia. Clearly, something is hosed up with grub2's use of font, but I can't see how it works or how to fix it. On another x86_64 machine, and two i386 machines F17 grub2 displays its menu correctly, except for its brain-dead contruction of menuitems that cannot possibly work.
I have just discovered BZ 817187 which supplies a solution to my missing grub2 menu during boot. Either the solution of Comment 15 or 16 restores my menu. Apparently, the gfxterm is seriously broken, but the console terminal works fine. Of course, this offers no solution to the brain-dead construction of menuitems that combine kernels and root partitions that are incompatible. I am happy to have a working menu that at least allows me to choose which kernel to boot, even if many of the choices simply cannot work.
You should not share the same /boot across distros. In most cases you shouldn't need separate /boot at all. If you do need you can have a partition with /fX directories and make the /boot symlinks to them. As for video problem can you try an explicit GFXMODE? What does videoinfo say? It's similar to 827003.
> You should not share the same /boot across distros. In most cases you shouldn't > need separate /boot at all. I have 'always' used a single boot partition with multiple root partitions specifically so that the boot menu could allow me to choose which kernel, old or new, to boot. That, after all, is the explicit purpose of grub. Lilo did this; grub did this. Only the new "improved" grub2 seems unable. If I have separate, different /boot directories within each of several root partitions, please explain to me how the Master Boot Record will be able to transfer control to a single menu that will permit me to choose one of the several kernels housed within the multiple root partitions. > If you do need you can have a partition with /fX directories and make the > /boot symlinks to them. I don't understand this sentence at all. Sorry to be dense. Please elucidate in detail. > As for video problem can you try an explicit GFXMODE? What does videoinfo > say? It's similar to 827003. My current grub.cfg is heavily edited to remove the many non-functional entries. This took hours of work because I dared not make a mistake, and grub.cfg is very hard to read. It also contains in the header section terminal_output console set timeout=15 ### END /etc/grub.d/00_header ### because I set new non-standard values in /etc/default/grub and reran grub2-mkconfig. I am reluctant to repeat that because it will destroy all my work. Is your request that I change the line in grub.cfg to this: ? terminal_output gfxmode If so, based on prior experience, I think it will render my system unbootable again, and I'll be unable to repair the damage. Even if I do this experiment, where do I see this "videoinfo"? $ videoinfo bash: videoinfo: command not found Please tell me your request more precisely.
Sorry for the multiple comments. Bugzilla gave me this error message and there was no obvious way to overcome it. An error occurred during a connection to bugzilla.redhat.com. SSL received a record with an incorrect Message Authentication Code. (Error code: ssl_error_bad_mac_read) The page you are trying to view cannot be shown because the authenticity of the received data could not be verified. Please contact the website owners to inform them of this problem. Alternatively, use the command found in the help menu to report this broken site.
(In reply to comment #2) > You should not share the same /boot across distros. In most cases you > shouldn't need separate /boot at all. If you do need you can have a > partition with /fX directories and make the /boot symlinks to them. As for > video problem can you try an explicit GFXMODE? What does videoinfo say? It's > similar to 827003. So Vladimir, if you wanted to install F17 alongside of F16, (two root file systems) sharing /home, how would YOU do it? Where, exactly, would YOU put the boot information for the multiple roots other than in a shared boot partition? Since the info for the two systems needs to be shared, commonly available to the boot mechanism, how do you do it without sharing it? Telling me "I shouldn't do it" is not helpful, but is condescending. It really would be nice if the Fedora developers realized that they're making so many huge changes to the system (grub2, systemd, now F18's messed up Ubuntu-wanna-be attention-deficit-disorder installer, and gnome3) that it would be nice if their "improvements" didn't wreak havoc on pre-existing installations. Since there is a significant chance that the new system won work well, it's nice to be able to boot back into the old system. This whole "we don't care about what was/is on your system" mentality is juvenile. Fedora used to show the user a modicum of respect. In 3 or 4 iterations of grub2, Fedora STILL can't made it so that multiple FEDORA versions can EASILY coexist? WHY NOT?!?!? My father's comments about grub2 being a mess are absolutely correct.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. 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 '17'. 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 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 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 17'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.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 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. Thank you for reporting this bug and we are sorry it could not be fixed.