Bug 154968

Summary:	FC4 grub hangs on stage2
Product:	[Fedora] Fedora	Reporter:	Warren Togami <wtogami>
Component:	grub	Assignee:	Peter Jones <pjones>
Status:	CLOSED RAWHIDE	QA Contact:	Mike McLean <mikem>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	fedora, gajownik, gczarcinski, rnichols42
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-05-18 19:44:46 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	136450

Description Warren Togami 2005-04-15 05:50:44 UTC

While the vast majority of "grub hands at stage2" problems from FC3 were fixed
in FC4, it seems that a few machines still experience this problem.  This bug is
split from Bug 139140 which is a confusing mess of different hardware and
FC3/FC4 mixed reports.

Please describe your hardware here ONLY if FC4's grub fails exactly in one of
these two ways:
1) hangs on stage2
2) spontaneous reboot when it reaches stage2

http://forums.fedoraforum.org/forum/showthread.php?t=49276
DO NOT REPORT HERE IF YOU ARE USING FC3.  Instead follow the procedure that I
wrote here.  Chances are it will fix your FC3.

Comment 1 Gene Czarcinski 2005-04-15 14:31:48 UTC

Please also see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154548
which appears (to me) as an anaconda bug (on FC4T2).  When this occurs, grub is
not installed in the partition (i386).

This also occurred in a similar but different situation doing an x86_64 (fresh)
install on the same system except that it appears more like the problem
described here in that the install was all screwed up.  To recover, I had to run
rescueCD to set the MBR in my "system boot controller partition
(grub/root/setup).  I then rebooted the x86_64 rescueCD and had to run
grub-install becuase nothing had been installed.

The system is an opteron on an ASUS SK8V motherboard with two disks PATA on hda
and a SATA which comes up as sda.  Booting is off the hda drive with hda1 being
a small system (boot controller) pointed to by MBR, hda9 being the i386
partition and hda10 being the x86_64 partition.

fdisk -l /dev/hda:


Disk /dev/hda: 122.9 GB, 122942324736 bytes
255 heads, 63 sectors/track, 14946 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1   *           1         123      987966   83  Linux
/dev/hda2             124         489     2939895   82  Linux swap / Solaris
/dev/hda4             490       14946   116125852+   5  Extended
/dev/hda5             490        2314    14659281   83  Linux
/dev/hda6            2315        4139    14659281   83  Linux
/dev/hda7            4140        5964    14659281   83  Linux
/dev/hda8            5965        7789    14659281   83  Linux
/dev/hda9            7790        9614    14659281   83  Linux
/dev/hda10           9615       11439    14659281   83  Linux
/dev/hda11          11440       13264    14659281   83  Linux
/dev/hda12          13265       14946    13510633+  83  Linux

I have another partition (hda11) which I can do another test install if there is
something you want me to test.  Once the install is complete and I fix
everything up, it works fine.

Comment 2 Jeremy Katz 2005-05-18 19:44:46 UTC

Gene's problem should be fixed with Peter's change from last week... not seeing
other reports here, I'm going to close this due to lack of information.

Comment 3 Robert Nichols 2006-02-03 01:34:04 UTC

I ran into this problem with FC4 installed on a Compaq Evo D510 CMT I just
acquired.  GRUB would display:

    GRUB Loading stage 1.5


    GRUB loading, please wait...

and then hang.  GRUB version is 0.95-13.i386.  I discovered that if I
substitute the /boot/grub/*stage* files from FC3 (grub-0.95-3.i386) and
rerun "setup (hd0)" from the GRUB shell, then booting works properly.