Bug 837430
Summary: | No grub2 menu; can't boot new F17 installation | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | David A. De Graaf <dad> |
Component: | grub2 | Assignee: | Peter Jones <pjones> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | urgent | Docs Contact: | |
Priority: | unspecified | ||
Version: | 17 | CC: | bcl, collura, dennis, mads, pjones, srdegraaf |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-08-01 08:57:21 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
David A. De Graaf
2012-07-03 20:38:10 UTC
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. > 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. > 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. |