Bug 837430

Summary: No grub2 menu; can't boot new F17 installation
Product: [Fedora] Fedora Reporter: David A. De Graaf <dad>
Component: grub2Assignee: Peter Jones <pjones>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 17CC: 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
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.

Comment 1 David A. De Graaf 2012-07-04 00:43:42 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.

Comment 2 Vladimir Serbinenko 2012-07-07 12:16:13 UTC
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.

Comment 3 David A. De Graaf 2012-07-07 21:45:05 UTC
> 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.

Comment 4 David A. De Graaf 2012-07-07 21:46:00 UTC
> 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.

Comment 5 David A. De Graaf 2012-07-07 21:48:58 UTC
> 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.

Comment 6 David A. De Graaf 2012-07-07 21:52:36 UTC
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.

Comment 7 Stuart R. DeGraaf 2013-01-20 12:39:55 UTC
(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.

Comment 8 Fedora End Of Life 2013-07-04 02:38:42 UTC
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.

Comment 9 Fedora End Of Life 2013-08-01 08:57:47 UTC
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.