Bug 450143 - grub doesn't boot and prints GRUB_ after dist upgrade (or a later kernel update)
grub doesn't boot and prints GRUB_ after dist upgrade (or a later kernel update)
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
12
All Linux
high Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
: Reopened
: 447188 470594 472829 488259 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-05 11:22 EDT by Brian Brock
Modified: 2010-06-29 03:32 EDT (History)
35 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-29 03:32:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
grub-bug-mbr.diff (769 bytes, text/plain)
2008-06-12 10:55 EDT, Will Woods
no flags Details
MBR of computer that had booting problem (1.67 KB, text/plain)
2008-06-26 17:12 EDT, Bruce Orchard
no flags Details
MBR of computer still running Fedora 8 (1.67 KB, text/plain)
2008-06-26 17:12 EDT, Bruce Orchard
no flags Details
MBR of computer that could not boot after kernle upgrade (1.73 KB, application/octet-stream)
2008-06-27 15:52 EDT, Bruce Orchard
no flags Details
Output from fdisk -l (567 bytes, text/plain)
2008-07-07 14:35 EDT, Bruce Orchard
no flags Details
Broken stage2 file (108.40 KB, application/octet-stream)
2009-07-05 01:30 EDT, John Guthrie
no flags Details
Repaired stage2 file (108.40 KB, application/octet-stream)
2009-07-05 01:32 EDT, John Guthrie
no flags Details

  None (edit)
Description Brian Brock 2008-06-05 11:22:25 EDT
Description of problem: 
System does not boot after latest grub update.  After cold start, system will 
hang at the boot prompt, printing "GRUB _"  (underscore is a blinking cursor).  
No input is echoed. 
 
 
After upgrading a system from F8 to F9, I ran `yum -y update` on the first 
boot.  Update progressed normally, including installation of grub-0.97-33.fc9.  
No errors messages seen in /var/log/yum.log /root/upgrade.log 
/root/upgrade.log.syslog 
 
Note that the system did boot properly immediately after installation, before 
applying updates.  I did not change the configuration of any components 
manually. 
 
Version-Release number of selected component (if applicable): 
grub-0.97-33.fc9.i386 
 
How reproducible: 
Have not tried to re-install to reproduce, this system is my desktop with data 
I'm using for work on the local disk. 
 
Additional info: 
boot partition is sda1, ext3. 
root partition is ext3 on lvm, residing in disk partition /dev/sda2 
 
Also can't seem to make grub work when run manually.  I booted into rescue 
mode using the F9 dvd, ran `chroot /mnt/sysimage`.  There was a complaint by 
anaconda saying that an error occured (and to re-run selecting the 'read-only' 
option if I'm unable to see the disk), but I haven't been able to track down 
its source yet (looking more deeply after filing). 
 
grub> install --stage2=/boot/grub/stage2 /grub/stage1 d /grub/stage2 p 
(hd0,0)/grub/grub.conf 
 
Error 12: invalid device requested 
 
grub> cat (hd0,0)/grub/grub.conf 
 
Error 15: File not found 
 
system mainboard chipset is intel 82865G 
disk controller is ICH5 
hard disk is SATA, identified as sda in dmesg
Comment 2 Brian Brock 2008-06-05 11:34:03 EDT
I'm mistaken above about `cat (hd0,0)/grub/grub.conf`.  That command works 
properly, I had temporarily removed the file to check for different effects. 
 
All other info above is correct after re-checking. 
Comment 3 Brian Brock 2008-06-05 12:01:02 EDT
also interesting on that system are: 
file named ' ' (no quotes) in / apparently created during upgrade to F9 
directory in / named ... (hex number with many digits enclused in { }, doesn't 
match anything in /etc/fstab), apparently created/altered during post-reboot 
update of packages. 
 
I don't think they're neccessarily related, seems they're more likely related 
to other broken package upgrades. 
Comment 4 Brian Brock 2008-06-05 15:10:13 EDT
/boot (sda0) has a sub-dir /boot 
this means that the new, useful grub files for grub are in /boot/boot/grub 
rather than /boot/grub.   
 
timestamps indicate that /boot/grub/* was created during install, and that 
/boot/grub/grub/* was created during the yum update I ran post-install. 
 
running `grub-install --root-directory=/ /dev/sda` created a bootable 
installation 
Comment 5 Brian Brock 2008-06-05 15:11:12 EDT
er, /boot/boot/grub/* rather than /boot/grub/grub/* in the second stanza of 
comment 4 
Comment 6 Wesley Haines 2008-06-09 12:34:56 EDT
I had a similar issue also on an i386 system when upgrading the original F9
kernel to the latest version:

(from yum.log)
Jun 06 19:27:02 Installed: kernel-PAE-2.6.25.4-30.fc9.i686
Jun 06 19:27:02 Installed: kernel-2.6.25.4-30.fc9.i686

I had to use the Rescue mode and run "grub-install /dev/sda". 

The system booted normally after I completed the F8->F9 upgrade process. Only
after upgrading the kernel (from updates repository) later that evening did it
cause problems. I booted the system today and found the "GRUB_" message. Doing
the rescue mode operation fixed the issue.

Grub was not updated (it's still the version that is on the install DVD), so it
appears to have been caused by a problem in the latest kernel package.
Comment 7 Todd J Martin 2008-06-12 00:14:41 EDT
I can confirm that I saw this behaviour when doing a yum update that updated the
kernel:

Jun 11 23:21:55 Installed: kernel-2.6.25.4-30.fc9.i686

I was able to fix the issue by booting off a rescue disk and running grub-install.
Comment 8 Will Woods 2008-06-12 10:29:12 EDT
I see this fairly frequently after preupgrades to F9. It only seems to manifest
after the first kernel update following the initial installation.

Maybe this has something to do with the switch from LABEL=xxx to UUID=xxx, or
anaconda's rewriting of grub.conf? 

I've checked the GRUB files on /boot and they appear to be intact. grub-install
/dev/sda definitely changes *something*, but I'm not sure what.
Comment 9 Will Woods 2008-06-12 10:55:12 EDT
Created attachment 309075 [details]
grub-bug-mbr.diff

I took images of the MBR before and after running grub-install /dev/sda in
rescue mode; this is the diff of the hexdumps of those images.

Offsets 0x40 - 0x49 seem to have been changed.

http://mirror.href.com/thestarman/asm/mbr/GRUB.htm has some info about those
offsets:

   [7C40] -> 80 ("Boot Drive") NOTE: For those of you with multi-OS
	     booting systems, if your Linux installation with GRUB's
	     remaining software (stage2, menu file, etc.) is located
	     somewhere other than on the Primary Master drive, this
	     value will be 81, 82, etc. depending upon which drive
	     that Linux OS's /boot/grub directory is located.
(etc. see the referenced page for details)
Comment 10 Will Woods 2008-06-12 11:08:47 EDT
The important details from that diff are:

(broken)  00000040  80 | 00 | 00 80 | 41 64 01 00 | 00 08 

(working) 00000040  ff | 00 | 00 20 | 01 00 00 00 | 00 02

Maybe preupgrade's use of GRUB's 'savedefault --once' messed that part up?
Comment 11 Will Woods 2008-06-12 15:24:36 EDT
pjones points out that I haven't seen the "/boot/grub/grub/..." behavior, so
this may be a different root cause with the same result.

In my case, something about the post-f9 update(s) appears to change
/boot/grub/stage2, and that seems to make GRUB fail.

I'm working on reproducing the problem and comparing the output of:
 blocklist (hd0,0)/grub/stage2 | /sbin/grub --batch --no-floppy
--device-map=/boot/grub/device.map
before, during, and after the problem happens.
Comment 12 Maurizio Marini 2008-06-15 08:11:32 EDT
i noticed that grub was damaged after 
device-mapper-multipath-0.4.7-15.fc9.i386
friday upgrade
i was unable to chroot /mnt/sysimage as (i suppose) device-mapper-multipath had
changed /etc/fstab & /boot/grub/grub.conf

here it is /etc/fstab after davasting upgrade
UUID=cf7cd8e9-13c6-4997-88cf-2b2e917736fb /                       ext3   
defaults        1 1
UUID=22309ffe-0180-41bd-a868-9d5b15660781 /home                   ext3   
defaults        1 2
UUID=c46f0b8e-ea34-47f5-8c7f-57a7f3a5d531 /boot                   ext3   
defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
UUID=817d341a-8daa-43dd-8c97-2eea4c1f418f swap                    swap   
defaults        0 0

and daasted grub.conf:
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.25.6-55.fc9.i686)
        root (hd0,0)
        kernel /vmlinuz-2.6.25.6-55.fc9.i686 ro
root=UUID=cf7cd8e9-13c6-4997-88cf-2b2e917736fb rhgb quiet
        initrd /initrd-2.6.25.6-55.fc9.i686.img
title Fedora (2.6.25.4-30.fc9.i686)
        root (hd0,0)

i fixed fstab and grub.conf mounting disk on usb box and then i was able to
chroot /mnt/sysimage

it seems that device-mapper-multipath (as documented into:
/usr/share/doc/device-mapper-multipath-0.4.7/FAQ ) has changed (devasted)
/etc/fstab and grub.conf, damaging mbr
Comment 13 Maurizio Marini 2008-06-15 08:25:47 EDT
i upgraded my f8 -> f9 on 13^ of may.
After then, i upgraded kernel 2 times:
May 15 12:27:58 Installed: kernel-2.6.25.3-18.fc9.i686
Jun 09 09:56:44 Installed: kernel-2.6.25.4-30.fc9.i686

without any issue. i got grub damaged only after friday 13 jun. upgrade

here is the packages list i upgraded:
Jun 13 13:54:46 Updated: selinux-policy-3.3.1-64.fc9.noarch
Jun 13 13:55:08 Updated: selinux-policy-targeted-3.3.1-64.fc9.noarch
Jun 13 13:55:35 Updated: selinux-policy-devel-3.3.1-64.fc9.noarch
Jun 13 13:55:40 Updated: logwatch-7.3.6-22.fc9.noarch
Jun 13 13:55:47 Updated: kernel-headers-2.6.25.6-55.fc9.i386
Jun 13 13:57:04 Updated: 1:java-1.6.0-openjdk-javadoc-1.6.0.0-0.15.b09.fc9.i386
Jun 13 13:57:14 Installed: kernel-devel-2.6.25.6-55.fc9.i686
Jun 13 13:57:23 Updated: nspr-4.7.1-0.9.1.fc9.i386
Jun 13 13:57:28 Updated: nss-3.12.0.3-0.9.1.fc9.i386
Jun 13 13:57:55 Updated: 1:java-1.6.0-openjdk-1.6.0.0-0.15.b09.fc9.i386
Jun 13 13:57:57 Updated: postgresql-libs-8.3.3-1.fc9.i386
Jun 13 13:57:58 Updated: kpartx-0.4.7-15.fc9.i386
Jun 13 13:57:59 Updated: device-mapper-multipath-0.4.7-15.fc9.i386
Jun 13 13:58:00 Updated: 1:java-1.6.0-openjdk-plugin-1.6.0.0-0.15.b09.fc9.i386
Jun 13 13:58:02 Updated: nss-tools-3.12.0.3-0.9.1.fc9.i386
Jun 13 13:58:31 Installed: kernel-2.6.25.6-55.fc9.i686
Jun 13 13:58:32 Updated: gstreamer-plugins-farsight-0.12.7-2.fc9.i386
Jun 13 13:58:34 Updated: gdb-6.8-10.fc9.i386
Jun 13 13:58:35 Updated: nspr-devel-4.7.1-0.9.1.fc9.i386
Jun 13 13:58:36 Updated: nss-devel-3.12.0.3-0.9.1.fc9.i386
Jun 13 13:59:09 Installed: kernel-2.6.25.6-55.fc9.i686
Comment 14 Maurizio Marini 2008-06-15 08:40:00 EDT
(In reply to comment #8)
> I see this fairly frequently after preupgrades to F9. It only seems to
manifest
> after the first kernel update following the initial installation.
> 
> Maybe this has something to do with the switch from LABEL=xxx to UUID=xxx, or
> anaconda's rewriting of grub.conf? 
> 
> I've checked the GRUB files on /boot and they appear to be intact. grub-
> /dev/sda definitely changes *something*, but I'm not sure what.

i have not noticed that f8->f9 upgrade has swtched LABEL=xxx to UUID=xxx, so i
suppose that device-mapper-multipath did it on 13 Jun. upgrade.
maybe i am wrong to think that device-mapper-multipath is the "guilt".
idid not have with me  f9 dvd to rescue, i have only a Centos5 dvd, and maybe
the old kernel was not able to recgnize UUID=xxx format.
Comment 15 Waqas Bhatti 2008-06-16 21:25:49 EDT
I see the same thing as Maurizio, on a preupgraded F8->F9 box. The previous
kernel update worked just fine, but this one (kernel-PAE-2.6.25.6-55.fc9) which
came with device-mapper-multipath-0.4.7-15.fc9 gives the same GRUB> message upon
boot.

In my case, I was able to use the F9 netinst CD to get to rescue mode, and look
around in the /boot/grub directory. Trying a grub-install /dev/sdc (where Fedora
lives) didn't work because of a 'device could not be found in the BIOS' error. I
looked at device.map which indeed did not list /dev/sdc. After adding the line:

(hd2)    /dev/sdc

I redid the grub-install, and it worked fine. My /etc/fstab does have UUIDs in
it, and was presumably converted by anaconda during the preupgrade, but it had
no issues with the previous two kernel updates until this one. I think Maurizio
is right in pointing to device-mapper-multipath as the source of the problem.
Comment 16 Victor Lorenz 2008-06-17 13:01:49 EDT
Had the same problem with a system that had been upgraded F8->F9 using
preupgrade. Problem only with the latests kernel upgrade. I have two hard
drives. One with XP and FC 8 (i386) and the second with the upgraded FC 9
(x64_86). I had converted to booting using the grub from the second hard drive. 

I used the FC 8 rescue to restore the grub that ran from first hard drive and
was able to boot into the FC 8 system. This Grub also now gave me the option to
boot to the FC 9 system. Started to load but failed half through the startup
dialog with different error msg. I could however scan the FC 9 file system from
the FC 8 system. While I could not open the grub.conf file on the FC9 system I
could see it was of 0 length and now dated to prior to the upgrade.

Ended up downloading FC9 iso and re-doing upgrade which only took a few minutes.
Didn't add any modules but fixed problem causing areas.

Hope this helps.
Comment 17 Bruce Orchard 2008-06-17 14:01:51 EDT
I have seen this on 2 computers.  On one computer I did not have any trouble
reinstalling grub from the rescue CD.  The other computer has the system disk on
a dmraid, /dev/mapper/isw_ccebidbcgj_sda_sdb.  Grub returned a partition not
found error when I tried to reinstall grub.  I finally got grub installed by
doing a grub DEVICE command to tell it where the device was.  I forget if I had
the partition suffix on the device name.
Comment 18 barry gould 2008-06-20 14:07:08 EDT
This happened to me last night, after doing yum update.
I had upgraded to Fedora 9 from 8 a month or so ago.

Suggest raising severity here. Dead computers are no fun.
Comment 19 barry gould 2008-06-20 14:23:44 EDT
Tried fixing with Knoppix 5.03; got a slight improvement (grub has a menu
instead of hanging).

Used 'rescue mode' on Fedora9 DVD;
mounted local disks in RW mode (in menu)
chroot'd the hard disk
grub-install --root-directory=/ /dev/sda

Grub's now working again.
Comment 20 Michael DeHaan 2008-06-24 11:04:21 EDT
Also saw this happen to me, IBM Thinkpad T42, upgrading from F8 to F9 via DVD,
grub-install fails, just shows "GRUB" at the prompt after rebooting. 

Running grub-install /dev/sda in rescue mode did not fix the problem, as I
didn't realize I needed the --root-directory parameter.  Finally just did a
fresh install preserving /home to fix it.

(I also can provide physical/SSH access to this machine to RH folks if it would
prove useful.)

Comment 21 Bruce Orchard 2008-06-26 17:12:02 EDT
Created attachment 310383 [details]
MBR of computer that had booting problem
Comment 22 Bruce Orchard 2008-06-26 17:12:21 EDT
Created attachment 310384 [details]
MBR of computer still running Fedora 8
Comment 23 Bruce Orchard 2008-06-26 17:23:15 EDT
I attached dumps of MBR's from 2 identical computers, one (comment 21) running
Fedora 9 and one (comment 22) running Fedora 8.  The comment in comment 21 is
not correct.  This computer did not have the booting problem--that was 2 other
computers.  The computer in comment 21 was upgraded to Fedora 9 with yum rather
than the upgrade option on the install disk.

The computers in comments 21 and 22 are identical.  They both have 2 SCSI disk
drives.  Windows is on the first drive and Fedora is on the second drive.  The
MBR is on the first drive.  I noticed that the MBR in comment 21 goes to grub
stage 1.5  on the first drive and the MBR in comment 22 goes directly to stage 2
on the second drive.  

The earlier attachment, grub_bug_mbr.diff, shows the same difference.

Comment 24 Bruce Orchard 2008-06-27 15:52:37 EDT
Created attachment 310473 [details]
MBR of computer that could not boot after kernle upgrade

Here is the MBR of a computer that could not boot after a kernel upgrade.  This
is a laptop.  This dump of the MBR was done after the grub boot was
reinstalled.  Note that it goes to stage1.5.
Comment 25 Lukáš Tinkl 2008-07-03 13:17:53 EDT
I'm just experiencing the same problem after a recent yum update; grub just
hangs with a non-functional command prompt, raising severity
Comment 26 Will Woods 2008-07-03 13:51:58 EDT
If there's a command prompt (i.e. "grub>"), that's a different bug. This bug is
for GRUB hanging with no command prompt, just "GRUB" onscreen.
Comment 27 Lukáš Tinkl 2008-07-03 17:38:43 EDT
Perhaps I wasn't clear enough, the only word "GRUB" is exactly what I'm seeing
(however, comment #19 helped me fix the problem)
Comment 28 david 2008-07-07 05:48:22 EDT
I have had the same / similar problem.
I upgraded from fc8 to fc9 with DVD - new installation worked fine.
Then I upgraded the kernel from 2.6.25.6-55 to 2.6.25.9-76. When I rebooted, the
PC-model splash screen showed, then the screen showed immediately showed 'GRUB_'
at the top and the system beep rang continuously.

Problem was solved by:
- going into rescue mode from DVD
- changing root directory to /mnt/sysimage
- running 'grub-install --root-directory=/ /dev/sdb

My /boot partition is on sdb rather than sda - having some time ago added a new
harddrive to rebuild a busted system without wiping my data.

I am running x64_86.

I also had some problems with anaconda during the install. It wouldn't work when
rebooting to the install DVD. It did work when I shut down and started from
cold.  I haven't logged these as I didn't have the backtrace etc - but have seen
similar bugs reported.  I will try to relocate the numbers and post.

The common issue through these seems to be with people who are running their
/boot off the secondary hard-drive.  I suspect that when the updated kernel
installed it reset the /boot location to the primary hard-drive. (There is still
an empty /boot partition on it.)  It could have something to do with the move to
labels - but I am using LVM, which is supposed to be OK.

Does make me wonder if there are enough test cases being used before release?

Anyway - not sure this is a GRUB bug - suspect it is a more fundamental
architecture issue.  But don't know enough to suggest what or where.

(btw - other than this - fc9 has some great improvements to the x86_64
architecture, which means some things that didn't work well under fc8 are now
working fine)
Comment 29 david 2008-07-07 05:52:02 EDT
Also - recommend that this bug (whatever category it is in) be upgraded to
URGENT - since it creates a total system failure that ordinary users cannot be
expected to correct or diagnose.  Also, that suggested solution be added to
common bugs on fc9 documentation page until corrected.
Comment 30 Bruce Orchard 2008-07-07 14:35:14 EDT
Created attachment 311200 [details]
Output from fdisk -l

This is the output from fdisk -l for the computer mentioned in comment 24.
Comment 31 david 2008-07-08 02:01:20 EDT
The similar bug in the Anaconda list that I was referring to is 443451.
Particularly the comment about difficulty finding the correct hard-drive for GRUB.
Comment 32 Aaron Thomas 2008-07-14 21:01:28 EDT
Was running Fedora 7 and could not upgrade via preupgrade. Took the time to
download and burn the Fedora 9 DVD. Upgraded my system and rebooted. Everything
was fine. I did notice that package management ran and then my wife logged on.
When we she rebooted for some reason it came up with Grub and the blinking
cursor Much like comment #19:

Used 'rescue mode' on Fedora9 DVD;
mounted local disks in RW mode (in menu)
chroot'd the hard disk
grub-install --root-directory=/ /dev/sda

Grub's now working again.

Comment 33 Oli Wade 2008-07-20 05:19:14 EDT
I saw this too on an x86_64 machine (F9 upgraded from F8), though it was not the
first kernel update afterwards.
Comment 34 peter 2008-09-08 16:22:18 EDT
If using preupdate to go from fc8 to fc9 rather than an fc9 dvd, you need to edit /etc/fstab, changing the UUID... to the old format of /dev/sdxn and then reboot, chroot and run grub-install.
Comment 35 CEBrinkman 2008-09-12 23:17:14 EDT
I have an alienware laptop with two hard drives. When I did the original install I had the two drives configured as one. I used a fc9 dvd to perform an upgrade. The original boot after upgrade was successful but after that it hangs with GRUB displayed. I can get access using the rescue mode.  From other posts here it seems that 'grub-install --root-directory=/ /dev/sda' or something like it may give me back a working system. My problem is that I have data on this machine I don't want to lose. So does anyone know if 'grub-install --root-directory=/ /dev/sda' is the correct command or not. Does my two disks configured as one make this command slightly different? If I get it wrong will I be able to use rescue mode again?

I don't really have external storage that will hold the data or I would create a backup. I guess the safest route would be to go buy some.

Anyone know the answers to my questions listed here?

I'm new here so if this post is not appropriate for this forum just let me know.

Thanks for your help.
Comment 36 CEBrinkman 2008-09-12 23:23:22 EDT
I have an alienware laptop with two hard drives. When I did the original install I had the two drives configured as one. I used a fc9 dvd to perform an upgrade. The original boot after upgrade was successful but after that it hangs with GRUB displayed. I can get access using the rescue mode.  From other posts here it seems that 'grub-install --root-directory=/ /dev/sda' or something like it may give me back a working system. My problem is that I have data on this machine I don't want to lose. So does anyone know if 'grub-install --root-directory=/ /dev/sda' is the correct command or not. Does my two disks configured as one make this command slightly different? If I get it wrong will I be able to use rescue mode again?

I don't really have external storage that will hold the data or I would create a backup. I guess the safest route would be to go buy some.

Anyone know the answers to my questions listed here?

I'm new here so if this post is not appropriate for this forum just let me know.

Thanks for your help.
Comment 37 Eric Sandeen 2008-11-21 15:01:15 EST
wwoods (or anyone who can recreate) - can you strace the commands you've run to get a failing setup, and attach those?  And/or, compare hexdumps of good & bad stage2 files (if they differ between good & bad?)

I've seen an example in the past where grub was updating the stage2 by writing directly to the block device, and that's not coherent w/ the filesystem, so a later fs flush sometimes clobbers the blocklist written directly onto the bdev.  In some incarnations, grub does this; in others, it writes it through the filesystem (as it should, always.)

Several places call devwrite() if the stage2_os_file is not set, (i.e. if --stage2= is not specified) and this writing-directly-to-disk is fraught with danger.
Comment 38 John Guthrie 2008-12-08 17:11:33 EST
I can verify that this bug is still around in upgrading from F9 to F10.

Both of my f9 -> f10 upgrades have ended up with corrupted GRUB MBRs after the
upgrade.  One of them would print out "GRUB", and then reboot.  The other just
repeatedly printed out "GRUB" across the screen.  I was able to fix both of
them by using a rescue disk and re-installing the grub MBR from the grub
command-line shell.  Not much of a problem, but kind of annoying.  (Unfortunately, I fixed things before seeing comment #37 above.)

It is interesting to note that when I tried to fix the first GRUB failure using a rescue disk, the grub shell would exit on a floating point exception signal whenever I tried to use the "find" builtin command.

Also, both of these were installed over the network using an http URL.  I don't know if that makes any difference, but I do have some spare machines at home that I could use to try duplicating this again if someone can tell me what to log beforehand or what to look for.
Comment 39 Jerry Amundson 2008-12-10 13:06:16 EST
*** Bug 447188 has been marked as a duplicate of this bug. ***
Comment 40 Jerry Amundson 2008-12-10 16:27:34 EST
*** Bug 472829 has been marked as a duplicate of this bug. ***
Comment 41 Bruce Orchard 2008-12-10 16:37:23 EST
A few weeks ago I upgraded the computer mentioned in comment 22 to Fedora 9. 
It has 2 SCSI disks, sda and sdb.  When I started Windows XP and the MBR were
on sda and Fedora 8 on sdb.  I wiped out the Fedora 8 install on sdb and did a
new install of Fedora 9 on sdb.  There were no problems during the install. 
When I tried to boot the resulting system, it stopped with just the word GRUB
on the display.  I played around trying to repair it, but ultimately gave up,
wiped out Windows XP (I never used it), and did a new install on sda.  I did
not have any trouble booting the system that resulted.  My suspicion is that
the fact the the MBR was on sda and the Linux system was on sdb lead to the
problem.

This is the only case I have seen the problem in where a new install was done
rather than an upgrade install.
Comment 42 Glen Turner 2008-12-14 02:32:14 EST
I also can confirm this issue exists F9-->F10, at least on a iMac Mini using BootCamp (ie: BIOS emulation, not EFI). Used preupgrade to do the upgrade, machine booted fine after upgrade, ran 'dhclient eth0 && yum upgrade' from single user mode with enforcing SELinux, on next boot machine printed "GRUB" and hung.
Comment 43 David Hull 2008-12-17 00:25:08 EST
I believe that I may have a fix for one of the causes of this bug.

I recently updated from Fedora 9 to Fedora 10 from the installation DVD.  I let the installer (anaconda?) reinstall grub.  After the installation was complete and the system attempted to reboot, booting stopped at the "grub>" prompt.  Various attempts to reinstall grub did not work, including

  root (hd0,0)
  setup (hd0)

My system is set up with separate /boot and / partitions.

What finally worked for me was

  root (hd0,0)
  setup --prefix=/grub (hd0)

I believe that grub's setup command was using the wrong path (/boot/grub) for a system with a separate /boot partition.
Comment 44 Garrett Mitchener 2009-01-07 12:44:59 EST
I ran into something like this upgrading a couple of my machines from f8 to f10.  In my cases, grub's first stage got put on the MBR but the other stages weren't visible to it somehow.  I caught part of the problem (I think) on my x86_64 workstation.  It has two hard drives, and my linux installation (including the /boot partition) is on the second one, sdb, but I install grub on sda.

At the end of the installation, I saw on one of the logging consoles where the installation process ran grub, gave it an install commend, and got some sort of error about a device not existing.  I went to a console running a shell and tried the same command and got the same error, even after doing chroot to the installed system's root directory.  Then I tried running grub's setup command rather than install.  The setup command seems to check for a few files then run an install command and this time the install command worked with no error.  I noticed that the install command displayed by the setup command had the arguments in a different order.  Unfortunately, I didn't write any of this down and the command that failed doesn't seem to be in the upgrade log file in /root.

Anyway. Is it possible that something changed in some new version of grub concerning the order of arguments to its install command and anaconda needs to be updated to compensate?
Comment 45 John Guthrie 2009-01-12 23:59:32 EST
This may be a slightly more general issue than just OS upgrades.  I have a third machine that I updated from F8 to F10.  The OS upgrade went fine.  I just did a kernel upgrade from 2.6.27.5-117.fc10 to 2.6.27.9-159.fc10.  Upon rebooting after installing the new kernel, I got the GRUB prompt followed by never-ending beeping and a hung machine.

I have not finished rescuing it if there is any info that someone would like me to retrieve before I re-run grub.

This machine has a separate /boot partition, if that matters.
Comment 46 Jerry Amundson 2009-01-17 23:30:32 EST
Another Fedora 9 to Fedora 10 upgrade, and another "grub>" prompt. Well done. Pats on the back all around. Here's the smolt profile, in case someone cares.
http://www.smolts.org/client/show/pub_3594ebeb-f1bc-4341-9e05-0f31320c81a2
Comment 47 CEBrinkman 2009-01-27 15:23:40 EST
I have two systems running fc9 both with two disks that fc configured as one.  One of the systems has a raid controller (laptop) and the other does not(desktop).  I 'upgraded' the one with the raid controller some time ago and ended up with the famous GRUB prompt.  I foolish thought this was a problem with doing a upgrade from one fc version to another.  Today I learned it can happen with a simple 'update'.  I know almost nothing about grub, raid, etc.  On the laptop my /boot/grub/device.map file contains
(hd0)	/dev/mapper/pdc_bcijbagdb
When I look in the /dev/mapper directory I see control, VolGroup01-LogVol00, VolGroup01-LogVol01, pdc_bcijbagdb, pdc_bcijbagdbp1, and pdc_bcijbagdbp2.  On my decktop, that now has the GRUB problem, I only have the VolGroup00-LogVol00, VolGroup00-LogVol01 and control.

I don't know if this helps any but it sure would be nice to get this GRUB issue fixed.
Comment 48 Lloyd Matthews 2009-01-28 18:10:07 EST
I just encountered this problem in F10.

I have a Nvidia based motherboard, two SATA drives running with NVRaid 1. 
I upgraded to F10 from F8 and used the scsi_mod.scan=sync kernel option to
get around the RAID problem, then did the mkinitrd update, then updates
including kernel 2.6.27.9-159.  All was well, and I have been using and
updating since Jan 12 until today.

With today's update, I finished the updates and rebooted and got the GRUB
prompt.  OK, no problem, I booted from the F10 DVD, entered rescue mode,
and ran:

chroot /mnt/sysimage

grub
grub> find /grub/grub.conf
(hd0,2)
(hd1,2)   [note that it is NVRaid1, so found both drives]
grub> root (hd0,2)
Filesystem type is ext2fs, partition type 0x83
grub> setup (hd0)
checking if "/boot/grub/stage1" exists... no
checking if "/grub/stage1" exists... yes
checking if "/grub/stage2" exists... yes
checking if "/grub/e2fs_stage1_5"exists... yes
running "embed /grub/e2fs_stage1_5 (hd0)... 23 sectors are embedded
succeeded
running "install /grub/stage1 (hd0) (hd0)1+23 p (hd0,2)/grub/stage2 /grub/grub.conf"... failed

error 22t: no such partition


OK, I also tried (hd1,2), and got the same exact messages except for the substitution of (hd1)

I exited grub shell and tried grub-install /dev/sda
got: /dev/sda does not have any corresponding BIOS drive

my device.map file is:
(hd0)  /dev/mapper/nvidia_adgbjghc

The device.map file is the same as it has always been, no change.

This is a Linux only machine, no dual boot.  Partitions are:
/dev/mapper/nvidia_adgbjghcp1 vfat
/dev/mapper/nvidia_adgbjghcp2 ext3
/dev/mapper/nvidia_adgbjghcp3 ext3 /boot
/dev/mapper/nvidia_adgbjghcp4 extended
/dev/mapper/nvidia_adgbjghcp5 ext3 /
/dev/mapper/nvidia_adgbjghcp6 swap

I also tried booting the rescue with and without the scsi_mod.scan=sync
with no difference in the outcome.  I have done this grub reinsall on
many different systems and never had this problem.  Although they were not
RAID systems of any kind.  I have never had to do a grub install on this
system until today.  I don't know if it is related to NVRaid, RAID in
general, or something else.

After much research and a hint from comment #17 above, as well as an Ubuntu
howto, I found that I needed to enter two device definitions before setting 
root and running setup:

device (hd0,2) /dev/mapper/nvidia_adgbjghcp3
device (hd0) /dev/mapper/nvidia_adgbjghc
root (hd0,2)
setup (hd0)

This completed and I was able to boot into the new kernel.

One odd side effect of this is that I am now experiencing bug #473319, but I
have no problem booting.  I hope this helps to solve this problem.
Comment 49 Glen Turner 2009-02-20 01:27:25 EST
Just updated the F10 system that previously had this issue in #42 using "yum update". Upgrading lead to the return of the fault: the printing of "GRUB" and a hang. /var/log/yum.log lists these packages:

Feb 20 15:42:08 Updated: libgnome-2.24.1-9.fc10.x86_64
Feb 20 15:42:17 Updated: sqlite-3.5.9-4.fc10.x86_64
Feb 20 15:42:29 Updated: evolution-data-server-2.24.4-1.fc10.x86_64
Feb 20 15:42:32 Updated: 1:net-snmp-libs-5.4.2.1-3.fc10.x86_64
Feb 20 15:42:33 Updated: elfutils-libelf-0.140-1.fc10.x86_64
Feb 20 15:42:33 Updated: libattr-2.4.43-2.fc10.x86_64
Feb 20 15:42:36 Updated: elfutils-libs-0.140-1.fc10.x86_64
Feb 20 15:42:39 Updated: gtkhtml3-3.24.4-1.fc10.x86_64
Feb 20 15:42:43 Updated: ffmpeg-libs-0.4.9-0.54.20080908.fc10.x86_64
Feb 20 15:42:45 Updated: 1:pkgconfig-0.23-6.fc10.x86_64
Feb 20 15:43:58 Updated: evolution-2.24.4-1.fc10.x86_64
Feb 20 15:43:59 Updated: ptlib-2.4.4-2.fc10.x86_64
Feb 20 15:44:06 Updated: strigi-libs-0.6.3-1.fc10.x86_64
Feb 20 15:44:09 Updated: compiz-0.7.8-7.fc10.x86_64
Feb 20 15:44:10 Updated: qwt-5.1.1-2.fc10.x86_64
Feb 20 15:44:14 Updated: soprano-2.2.1-1.fc10.x86_64
Feb 20 15:44:38 Updated: policycoreutils-2.0.57-17.fc10.x86_64
Feb 20 15:44:40 Updated: opal-3.4.4-4.fc10.x86_64
Feb 20 15:44:41 Updated: ffmpeg-0.4.9-0.54.20080908.fc10.x86_64
Feb 20 15:44:47 Updated: compiz-fusion-extras-0.7.8-3.fc10.x86_64
Feb 20 15:44:57 Updated: scidavis-0.1.4-1.fc10.x86_64
Feb 20 15:45:00 Updated: ginac-1.4.4-1.fc10.x86_64
Feb 20 15:45:04 Updated: nss_ldap-264-1.fc10.x86_64
Feb 20 15:45:06 Updated: procps-3.2.7-23.fc10.x86_64
Feb 20 15:45:07 Installed: libspiro-20071029-1.fc10.x86_64
Feb 20 15:45:13 Updated: gegl-0.0.22-2.fc10.x86_64
Feb 20 15:45:14 Updated: gnome-scan-libs-0.6.1-1.fc10.x86_64
Feb 20 15:45:32 Updated: selinux-policy-3.5.13-45.fc10.noarch
Feb 20 15:45:33 Updated: elfutils-libelf-devel-0.140-1.fc10.x86_64
Feb 20 15:45:34 Updated: elfutils-devel-0.140-1.fc10.x86_64
Feb 20 15:45:35 Updated: sqlite-devel-3.5.9-4.fc10.x86_64
Feb 20 15:45:38 Updated: libgnome-devel-2.24.1-9.fc10.x86_64
Feb 20 15:45:42 Updated: 6:kdelibs-common-4.2.0-10.fc10.x86_64
Feb 20 15:46:30 Updated: oxygen-icon-theme-4.2.0-7.fc10.noarch
Feb 20 15:46:38 Updated: gnome-scan-0.6.1-1.fc10.x86_64
Feb 20 15:47:03 Updated: ekiga-3.0.2-2.fc10.x86_64
Feb 20 15:47:17 Updated: evolution-exchange-2.24.4-1.fc10.x86_64
Feb 20 15:47:18 Updated: elfutils-0.140-1.fc10.x86_64
Feb 20 15:47:19 Updated: attr-2.4.43-2.fc10.x86_64
Feb 20 15:47:24 Updated: 1:net-snmp-python-5.4.2.1-3.fc10.x86_64
Feb 20 15:47:26 Updated: 1:net-snmp-utils-5.4.2.1-3.fc10.x86_64
Feb 20 15:47:50 Updated: gnome-power-manager-2.24.4-1.fc10.x86_64
Feb 20 15:47:57 Updated: nautilus-sound-converter-1.0.1-1.fc10.x86_64
Feb 20 15:48:09 Updated: gnome-applet-music-2.5.1-1.fc10.x86_64
Feb 20 15:48:10 Updated: 2:ntfs-3g-2009.2.1-1.fc10.x86_64
Feb 20 15:48:29 Updated: dvipdfmx-0-0.26.20090115cvs.fc10.x86_64
Feb 20 15:48:31 Updated: python-crypto-2.0.1-14.fc10.x86_64
Feb 20 15:48:32 Updated: xsane-gimp-0.996-3.fc10.x86_64
Feb 20 15:48:33 Updated: zfs-fuse-0.5.0-7.20081221.fc10.x86_64
Feb 20 15:48:35 Updated: mldonkey-gui-2.9.7-2.fc10.x86_64
Feb 20 15:48:39 Updated: duplicity-0.5.06-1.fc10.x86_64
Feb 20 15:48:42 Updated: 1:nfs-utils-1.1.4-8.fc10.x86_64
Feb 20 15:48:45 Updated: xsane-0.996-3.fc10.x86_64
Feb 20 15:48:47 Updated: ethtool-6-2.20090115git.fc10.x86_64
Feb 20 15:48:49 Updated: kde-settings-4.1-6.20090206svn.fc10.noarch
Feb 20 15:48:51 Updated: kernel-firmware-2.6.27.15-170.2.24.fc10.noarch
Feb 20 15:48:52 Updated: 1:control-center-filesystem-2.24.0.1-12.fc10.x86_64
Feb 20 15:49:13 Updated: 1:control-center-2.24.0.1-12.fc10.x86_64
Feb 20 15:49:27 Updated: gnome-mplayer-common-0.9.4-1.fc10.x86_64
Feb 20 15:49:28 Updated: ufraw-common-0.15-1.fc10.x86_64
Feb 20 15:49:28 Installed: 1:anaconda-yum-plugins-1.0-3.fc10.noarch
Feb 20 15:49:29 Installed: preupgrade-1.0.1-1.fc10.noarch
Feb 20 15:49:30 Installed: fontpackages-filesystem-1.15-1.fc10.noarch
Feb 20 15:49:30 Installed: vlgothic-fonts-common-20090204-2.fc10.noarch
Feb 20 15:49:39 Updated: evolution-data-server-doc-2.24.4-1.fc10.x86_64
Feb 20 15:49:40 Updated: ufraw-0.15-1.fc10.x86_64
Feb 20 15:49:40 Updated: gnome-mplayer-0.9.4-1.fc10.x86_64
Feb 20 15:50:05 Updated: compiz-gnome-0.7.8-7.fc10.x86_64
Feb 20 15:50:12 Updated: evolution-data-server-devel-2.24.4-1.fc10.x86_64
Feb 20 15:50:16 Installed: vlgothic-fonts-20090204-2.fc10.noarch
Feb 20 15:50:19 Installed: vlgothic-p-fonts-20090204-2.fc10.noarch
Feb 20 15:50:25 Updated: 1:net-snmp-devel-5.4.2.1-3.fc10.x86_64
Feb 20 15:50:53 Updated: selinux-policy-targeted-3.5.13-45.fc10.noarch
Feb 20 15:50:55 Updated: policycoreutils-gui-2.0.57-17.fc10.x86_64
Feb 20 15:51:09 Updated: compiz-fusion-extras-gnome-0.7.8-3.fc10.x86_64
Feb 20 15:51:25 Updated: evolution-help-2.24.4-1.fc10.x86_64
Feb 20 15:51:26 Updated: gtkhtml3-devel-3.24.4-1.fc10.x86_64
Feb 20 15:51:27 Updated: libattr-devel-2.4.43-2.fc10.x86_64
Feb 20 15:52:03 Installed: kernel-devel-2.6.27.15-170.2.24.fc10.x86_64
Feb 20 15:52:07 Updated: hal-info-20090202-1.fc10.noarch
Feb 20 15:52:09 Updated: dot2tex-2.8.4-1.fc10.noarch
Feb 20 15:52:10 Updated: setup-2.7.4-3.fc10.noarch
Feb 20 15:52:15 Updated: kernel-headers-2.6.27.15-170.2.24.fc10.x86_64
Feb 20 15:52:15 Updated: rhino-1.7-0.1.r2pre.1.1.fc10.noarch
Feb 20 15:52:17 Updated: python-louie-1.1-4.fc10.noarch
Feb 20 15:52:24 Updated: scidavis-manual-0.1.4-1.fc10.x86_64
Feb 20 15:52:33 Updated: docbook-style-xsl-1.74.0-5.fc10.noarch
Feb 20 15:52:38 Updated: meld-1.2.1-1.fc10.noarch
Feb 20 15:52:55 Updated: wine-core-1.1.14-1.fc10.i386
Feb 20 15:52:56 Updated: wine-capi-1.1.14-1.fc10.i386
Feb 20 15:52:57 Updated: wine-esd-1.1.14-1.fc10.i386
Feb 20 15:52:58 Updated: wine-cms-1.1.14-1.fc10.i386
Feb 20 15:52:59 Updated: wine-jack-1.1.14-1.fc10.i386
Feb 20 15:52:59 Installed: wine-pulseaudio-1.1.14-1.fc10.i386
Feb 20 15:53:00 Updated: wine-twain-1.1.14-1.fc10.i386
Feb 20 15:53:01 Updated: wine-ldap-1.1.14-1.fc10.i386
Feb 20 15:53:01 Updated: wine-nas-1.1.14-1.fc10.i386
Feb 20 15:53:02 Updated: sqlite-3.5.9-4.fc10.i386
Feb 20 15:53:37 Installed: kernel-2.6.27.15-170.2.24.fc10.x86_64
Feb 20 15:53:38 Updated: xorg-x11-drv-ati-6.10.0-2.fc10.x86_64
Feb 20 15:53:39 Updated: 1:xorg-x11-drv-nouveau-0.0.11-1.20090106git133c1a5.fc10.x86_64
Feb 20 15:53:40 Updated: wine-desktop-1.1.14-1.fc10.i386
Feb 20 15:53:41 Updated: phonon-4.3.0-5.fc10.x86_64
Feb 20 15:53:42 Updated: PackageKit-glib-0.3.14-1.fc10.x86_64
Feb 20 15:53:44 Updated: 1:perl-Module-Pluggable-3.60-56.fc10.x86_64
Feb 20 15:53:45 Updated: phonon-backend-xine-4.3.0-5.fc10.x86_64
Feb 20 15:53:47 Updated: PackageKit-gstreamer-plugin-0.3.14-1.fc10.x86_64
Feb 20 15:53:49 Updated: phonon-backend-gstreamer-4.3.0-5.fc10.x86_64
Feb 20 15:53:50 Updated: 3:perl-version-0.74-56.fc10.x86_64
Feb 20 15:53:51 Updated: PackageKit-yum-plugin-0.3.14-1.fc10.x86_64
Feb 20 15:53:51 Updated: 1:perl-Pod-Escapes-1.04-56.fc10.x86_64
Feb 20 15:53:52 Updated: PackageKit-udev-helper-0.3.14-1.fc10.x86_64
Feb 20 15:53:57 Updated: PackageKit-0.3.14-1.fc10.x86_64
Feb 20 15:53:58 Updated: 4:perl-libs-5.10.0-56.fc10.x86_64
Feb 20 15:54:21 Updated: 4:perl-5.10.0-56.fc10.x86_64
Feb 20 15:54:22 Updated: perl-Compress-Raw-Zlib-2.008-56.fc10.x86_64
Feb 20 15:54:42 Updated: 6:kdelibs-4.2.0-10.fc10.x86_64
Feb 20 15:54:48 Updated: 1:net-snmp-perl-5.4.2.1-3.fc10.x86_64
Feb 20 15:55:11 Updated: 1:emacs-common-22.3-4.fc10.x86_64
Feb 20 15:55:12 Installed: perl-Sane-0.02-2.fc10.x86_64
Feb 20 15:55:14 Updated: numactl-2.0.2-3.fc10.x86_64
Feb 20 15:55:33 Updated: frozen-bubble-2.2.0-1.fc10.x86_64
Feb 20 15:55:35 Updated: PackageKit-yum-0.3.14-1.fc10.x86_64
Feb 20 15:55:37 Updated: 1:emacs-22.3-4.fc10.x86_64
Feb 20 15:55:37 Updated: 4:perl-suidperl-5.10.0-56.fc10.x86_64
Feb 20 15:55:39 Updated: perl-Net-LibIDN-0.11-1.fc10.x86_64
Feb 20 15:55:40 Updated: 1:perl-Digest-SHA-5.45-56.fc10.x86_64
Feb 20 15:55:42 Updated: patchutils-0.3.1-1.fc10.x86_64
Feb 20 15:55:44 Updated: 1:net-snmp-5.4.2.1-3.fc10.x86_64
Feb 20 15:55:55 Updated: kino-1.3.3-1.fc10.x86_64
Feb 20 15:55:59 Updated: mldonkey-2.9.7-2.fc10.x86_64
Feb 20 15:56:18 Updated: gnome-packagekit-0.3.14-1.fc10.x86_64
Feb 20 15:56:24 Updated: 4:perl-devel-5.10.0-56.fc10.x86_64
Feb 20 15:56:26 Updated: perl-ExtUtils-MakeMaker-6.36-56.fc10.x86_64
Feb 20 15:56:27 Updated: 1:perl-ExtUtils-ParseXS-2.18-56.fc10.x86_64
Feb 20 15:56:29 Updated: perl-IO-Compress-Base-2.008-56.fc10.x86_64
Feb 20 15:56:30 Updated: perl-IO-Compress-Zlib-2.008-56.fc10.x86_64
Feb 20 15:56:31 Updated: perl-Compress-Zlib-2.008-56.fc10.x86_64
Feb 20 15:56:33 Updated: 1:perl-ExtUtils-CBuilder-0.21-56.fc10.x86_64
Feb 20 15:56:39 Updated: 1:perl-Pod-Simple-3.07-56.fc10.x86_64
Feb 20 15:56:40 Updated: 1:perl-IO-Zlib-1.07-56.fc10.x86_64
Feb 20 15:56:41 Updated: perl-Test-Harness-3.12-56.fc10.x86_64
Feb 20 15:56:42 Updated: 1:perl-Package-Constants-0.01-56.fc10.x86_64
Feb 20 15:56:43 Updated: perl-Archive-Tar-1.40-56.fc10.x86_64
Feb 20 15:56:46 Updated: gscan2pdf-0.9.27-3.fc10.noarch
Feb 20 15:56:49 Updated: 1:perl-Module-Build-0.2808-56.fc10.x86_64
Feb 20 15:56:51 Updated: perl-CPAN-1.9205-56.fc10.x86_64
Feb 20 15:56:52 Updated: perl-Test-Simple-0.80-56.fc10.x86_64
Feb 20 15:56:55 Updated: perl-Image-ExifTool-7.67-1.fc10.noarch
Feb 20 15:56:57 Updated: perl-Module-CoreList-2.15-56.fc10.x86_64
Feb 20 15:56:57 Updated: 1:net-snmp-gui-5.4.2.1-3.fc10.x86_64
Feb 20 15:57:08 Updated: docbook5-style-xsl-1.74.0-2.fc10.noarch
Feb 20 15:57:14 Updated: wine-tools-1.1.14-1.fc10.i386
Feb 20 15:57:14 Updated: wine-1.1.14-1.fc10.i386
Feb 20 15:58:37 Erased: VLGothic-fonts
Feb 20 15:59:50 Erased: VLGothic-fonts-proportional
Feb 20 16:01:41 Installed: kernel-2.6.27.15-170.2.24.fc10.x86_64
Feb 20 16:01:41 Updated: 1:emacs-common-22.3-4.fc10.x86_64
Feb 20 16:01:41 Updated: 1:emacs-22.3-4.fc10.x86_64

Note that previous upgrades of the kernel have been successful
Comment 50 Joe Elliott 2009-03-04 10:51:57 EST
I experienced this problem on a very simple single boot system with one disk.
This system has been at Fedora 9 for several months.
The seed of the problem was planted on 2/19/2009 at 21:21 which is when an automated process runs YUM.
The time stamp on /boot/grub/grub.conf reflected that time stamp.
================YUM Listing============================
Feb 19 21:15:57 Updated: 6:kdebase-libs-4.2.0-6.fc9.i386
Feb 19 21:16:21 Updated: 6:kdebase-4.2.0-6.fc9.i386
Feb 19 21:17:57 Updated: kdebase-runtime-libs-4.2.0-7.fc9.i386
Feb 19 21:18:08 Updated: kdebase-runtime-4.2.0-7.fc9.i386
Feb 19 21:18:59 Updated: kdepimlibs-4.2.0-2.fc9.1.i386
Feb 19 21:21:17 Updated: kernel-firmware-2.6.27.15-78.2.23.fc9.noarch
Feb 19 21:21:44 Installed: kernel-2.6.27.15-78.2.23.fc9.i686
Feb 19 21:21:48 Installed: kernel-2.6.27.15-78.2.23.fc9.i686
Feb 19 21:23:09 Installed: kernel-devel-2.6.27.15-78.2.23.fc9.i686
Feb 19 21:23:39 Updated: kernel-headers-2.6.27.15-78.2.23.fc9.i386
Feb 19 21:25:48 Updated: oxygen-icon-theme-4.2.0-7.fc9.noarch 
======================== =============================
I suspect the kernel.i686    2.6.27.15-78.2.23.fc9  update.
          
The first reboot after the update, 3/3/2009 reveled the problem.  
When booting normally I got the word GRUB and a blinking cursor.  The terminal would accept no input.

When booting from the rescue shell, before making any changes, I got a message to this effect:
“grub could not find kernel image”  This message was broken and spread all over the screen.

In the recovery shell >grub shell> the find command did not work.

The “grub-install --root-directory=/ /dev/sda” command did work.

After successfully rebooting I compared the new grub.conf file to one I had saved and they were identical so I guess the MBR got hosed.

 Note that the previous update “Jan 27 21:18:23 Installed: kernel-2.6.27.12-78.2.8.fc9.i686” caused no problem.

I searched the web regarding this problem and got lots of hits and wasted lots of time.  This post was the only one that had the good stuff.  Thanks everyone.
Comment 51 Michael Schwendt 2009-05-29 11:31:39 EDT
*** Bug 488259 has been marked as a duplicate of this bug. ***
Comment 52 Michael Schwendt 2009-06-01 14:11:07 EDT
*** Bug 470594 has been marked as a duplicate of this bug. ***
Comment 53 Michael Schwendt 2009-06-02 04:54:56 EDT
To all those, who run into this from time to time (whereas it simply is not reproducible at all for other users), with bug 496093 an out-of-bounds memory corruption issue in GRUB's "setup" function has been found. Try out the patch that is attached there - it's safe to apply and doesn't make GRUB worse.
Comment 54 Rick Richardson 2009-06-24 16:21:49 EDT
Updating F10 to F11.  Still the same.  Had to use the Rescue DVD and grub-install /dev/sda.
Comment 55 Michael Schwendt 2009-06-24 18:00:31 EDT
[... Adjusting the summary, as a normal kernel update actually doesn't reinstall GRUB, and any suspicious hd/fd activity is related to scanning for blockdevs/ids. Some comments and duplicates read as if the problem has occurred after a normal yum update, e.g. comment 50 , but comments like comment 18 are contradictory and mention a dist upgrade done a month before.]
Comment 56 Garrett Mitchener 2009-06-26 14:56:13 EDT
Bug #505836 might be related.  I ran into this problem upgrading with the upgrade image on a USB hard drive or CD drive.  It looks like GRUB sometimes gets installed with its device numbers confused by the presence of the removable hard drive during installation.
Comment 57 John Guthrie 2009-07-05 01:28:19 EDT
(In reply to comment #45)
> This may be a slightly more general issue than just OS upgrades.  I have a
> third machine that I updated from F8 to F10.  The OS upgrade went fine.  I just
> did a kernel upgrade from 2.6.27.5-117.fc10 to 2.6.27.9-159.fc10.  Upon
> rebooting after installing the new kernel, I got the GRUB prompt followed by
> never-ending beeping and a hung machine.
> 
> I have not finished rescuing it if there is any info that someone would like me
> to retrieve before I re-run grub.
> 
> This machine has a separate /boot partition, if that matters.  

I did rescue this machine, but I grabbed some snapshots of several of the GRUB files as well as a snapshot of the MBR before completing the rescue by re-running GRUB from a rescue disk.  I found that the MBR changed.  This perhaps is not so shocking.

But also the stage2 file changed as well.  I will talk more about that in a moment.  But first, I would like to note that the device.map, e2fs_stage1_5, and the stage1 files did not change.

The change in the stage2 file is what I find to be the most interesting.  If I run the strings program on the broken stage2 file and the repaired stage2 file, then the *only* difference in the output between them is the following:

euler_1018# diff -u =(strings stage2.pre.fix) =(strings stage2) | more
--- /tmp/zshXq88oI      2009-07-05 01:15:08.000000000 -0400
+++ /tmp/zshp0dAjm      2009-07-05 01:15:08.000000000 -0400
@@ -4,7 +4,8 @@
 Read
  Error
 0.97
-/boot/grub/grub.conf
+/grub/grub.conf
+conf
 Ou=<
 ^_[]
 USWV

Note that the string "conf" gets added to the repaired stage2 file.  But more significantly, the string "/boot/grub/grub.conf" changes to "/grub/grub.conf".  The first path would make sense on my system if I had my /boot directory on my root partition.  But I don't.  I have my /boot directory on its own partition so that the second path make more sense on my system.  Hence, when the broken stage2 file was installed, it was trying to reference a /boot/grub directory that didn't exist on my /boot partition.  Hence, the boot hang.

What this is telling me is that on a non-regular basis, GRUB is perhaps running with an incorrect idea of which partition it should be using as a root partition.  (I say "non-regular", because thankfully, it doesn't happen all of the time.)

It is certainly possible that a memory corruption could be causing this behavior, but I wouldn't be able to say for certain.

I am attaching the broken and repaired versions of my stage2 file in case anyone is interested.
Comment 58 John Guthrie 2009-07-05 01:30:16 EDT
Created attachment 350524 [details]
Broken stage2 file

This is my broken stage2 file.
Comment 59 John Guthrie 2009-07-05 01:32:31 EDT
Created attachment 350525 [details]
Repaired stage2 file

This is the repaired version of my stage2 file.
Comment 60 John Guthrie 2009-07-05 01:35:40 EDT
(In reply to comment #57)
> Note that the string "conf" gets added to the repaired stage2 file.  But more
> significantly, the string "/boot/grub/grub.conf" changes to "/grub/grub.conf". 
> The first path would make sense on my system if I had my /boot directory on my
> root partition.  But I don't.  I have my /boot directory on its own partition
> so that the second path make more sense on my system.  Hence, when the broken
> stage2 file was installed, it was trying to reference a /boot/grub directory
> that didn't exist on my /boot partition.  Hence, the boot hang.

I think it might be interesting to know how this affects people who have /boot on their root partition versus on a separate partition.
Comment 61 Samuel Sieb 2009-07-25 01:34:52 EDT
I have systems with /boot separate and on the root partition and it happens both ways.
Comment 62 David Hull 2009-08-28 14:15:17 EDT
I just updated grub and the kernel and had this problem (grub stuck at "GRUB" prompt with flashing underscore cursor) when I attempted to reboot.  From /var/log/yum.log:

Aug 25 14:33:55 Updated: grub-0.97-51.fc11.x86_64
(I did not reboot after the grub update.)
Aug 27 09:00:24 Updated: kernel-firmware-2.6.29.6-217.2.16.fc11.noarch
Aug 27 09:01:02 Installed: kernel-2.6.29.6-217.2.16.fc11.x86_64
Aug 27 09:01:46 Installed: kernel-devel-2.6.29.6-217.2.16.fc11.x86_64
Aug 27 09:01:50 Updated: kernel-headers-2.6.29.6-217.2.16.fc11.x86_64

I was able to fix the problem as suggested above by booting from a rescue CD and reinstalling grub:

[root@dale log]# /sbin/grub
Probing devices to guess BIOS drives. This may take a long time.


    GNU GRUB  version 0.97  (640K lower / 3072K upper memory)

 [ Minimal BASH-like line editing is supported.  For the first word, TAB
   lists possible command completions.  Anywhere else TAB lists the possible
   completions of a device/filename.]
grub> root (hd0,0)
root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83
grub> setup (hd0)
setup (hd0)
 Checking if "/boot/grub/stage1" exists... no
 Checking if "/grub/stage1" exists... yes
 Checking if "/grub/stage2" exists... yes
 Checking if "/grub/e2fs_stage1_5" exists... yes
 Running "embed /grub/e2fs_stage1_5 (hd0)"...  28 sectors are embedded.
succeeded
 Running "install /grub/stage1 (hd0) (hd0)1+28 p (hd0,0)/grub/stage2 /grub/grub.conf"... succeeded
Done.

After this, I rebooted and the system and the system booted normally, although the splash image no longer shows correctly.  (It shows behind the text, but not in the blank areas of the screen.)
Comment 63 Alejandro Segovia 2010-04-07 15:55:13 EDT
This info might be useful (or not), but I just got stung by this and wanted to share my experience under Fedora 12 x86_64.

I had a rather standard Partition layout like so:

/dev/sda1 - 40 GB - type: NTFS
/dev/sda5 - 2 GB - type: SWAP
/dev/sda6 - 20 GB - type: ext3
/dev/sda7 - 90 GB - type: ext3

/dev/sdb1 - 20 GB - type: ext3
/dev/sdb2 - 40 GB - type: ext3

I set up Fedora 12, using /dev/sda6 as the root partition and /dev/sda7 as the home partition. Once the installer completed, I rebooted the system and ended up in front of a single prompt ( _ ), with no GRUB message.

I tried all the tips and tricks mentioned in other comments and even reinstalling from a Live CD and then again with a Fedora 10 DVD. The problem still persisted.

I could finally solve it by I) unplugging /dev/sdb II) installing Windows 7 on /dev/sda (which overwrites the MBR) and III) reinstalling Fedora 12, this time selecting the "Use Entire Disk" installation option. IV) plug /dev/sdb back in.

All this leads me to believe the problem might be related to the partition layout, which somehow might confuse the bootloader installer.

Notice that I did not had a dedicated boot partition in my original setup. And now I do. This might have something to do as well.

Hope this helps.
Comment 64 Bug Zapper 2010-04-27 08:05:55 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  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 '11'.

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 11'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 11 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 65 Alejandro Segovia 2010-04-27 10:53:46 EDT
IMHO, I would suggest updating the Fedora version affected by this bug to Fedora 12. I've been able to reproduce it every time on Constantine, even when installing in a VirtualBox VM.

Kind regards,
Alejandro.-
Comment 66 Bug Zapper 2010-06-28 06:39:02 EDT
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 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.
Comment 67 D. Wagner 2010-06-28 12:52:00 EDT
Per comment 65, it looks like this should be re-opened and the Fedora version incremented to F12.
Comment 68 Alejandro Segovia 2010-06-28 22:47:42 EDT
Hi, I'm the guy from comment 65.

I think this issue might be related to Anaconda, rather than GRUB.

In many cases, this problem is detected when upgrading from a previous version of Fedora or from trying to install on the partitioning scheme produced by other distros.

In my particular case, I was trying to setup Fedora on a custom scheme and it seemed as if GRUB could not be installed (even though Anaconda reported success on the installation procedure). The only way I could get my box booting again was to accept Anaconda's default partitioning scheme (which creates an LVM volume and deletes all previous partitions).

Let me know if I can provide any more information on this.

Best regards,
Alejandro.-
Comment 69 Jerry Amundson 2010-06-28 23:06:54 EDT
(In reply to comment #68)
> Hi, I'm the guy from comment 65.
> 
> I think this issue might be related to Anaconda, rather than GRUB.

Hi, I'm the guy from comment 39, comment 40, and comment 46. :-)

I'm only slightly more educated in grub than in anaconda, so I'll gladly trust in your experience to reassign accordingly. My hope is someone will actually find some time to troubleshoot it with you.
Comment 70 Alejandro Segovia 2010-06-29 01:08:04 EDT
Hi Jerry, thanks. I think we're on to something here.

I found this ticket that corresponds to bug 595951. It provides an Anaconda stack trace from a failed install (under Fedora 13 though) indicating that the GRUB install process failed because the installer function got an invalid device id.

From bug 595951:

anaconda 13.42 exception report
Traceback (most recent call first):
  File "/usr/lib/anaconda/booty/util.py", line 5, in getDiskPart
    path = storage.devicetree.getDeviceByName(dev).path[5:]
  File "/usr/lib/anaconda/booty/x86.py", line 450, in grubbyPartitionName
    (name, partNum) = getDiskPart(dev, self.storage)
  File "/usr/lib/anaconda/booty/x86.py", line 365, in writeGrubConf
    f.write('\trootnoverify %s\n' % self.grubbyPartitionName(device))
  File "/usr/lib/anaconda/booty/x86.py", line 219, in writeGrub
    chainList, grubTarget, grubPath, cfPath)
  File "/usr/lib/anaconda/booty/x86.py", line 510, in write
    not self.useGrubVal)
  File "/usr/lib/anaconda/bootloader.py", line 217, in writeBootloader
    kernelList, otherList, defaultDev)
  File "/usr/lib/anaconda/dispatch.py", line 205, in moveStep
    rc = stepFunc(self.anaconda)
  File "/usr/lib/anaconda/dispatch.py", line 126, in gotoNext
    self.moveStep()
  File "/usr/lib/anaconda/gui.py", line 1313, in nextClicked
    self.anaconda.dispatch.gotoNext()
  File "/usr/lib/anaconda/iw/progress_gui.py", line 79, in renderCallback
    self.intf.icw.nextClicked()
  File "/usr/lib/anaconda/gui.py", line 1334, in handleRenderCallback
    self.currentWindow.renderCallback()
AttributeError: 'NoneType' object has no attribute 'path' 

Alejandro.-
Comment 71 Hans de Goede 2010-06-29 03:32:49 EDT
Hi All,

Sorry for not getting around to looking into this bug sooner, 99.9% of all cases where the grub installation fails, this is due to anaconda's idea of the BIOS disk order when booting (iow which disk is BIOS dev 80, which disk is BIOS dev 81, etc) is not correct. This can happen when the BIOS does not export usable EDD information or when starting the installer from a usb stick as in this case the boot order during installation is different (the usb stick is BIOS dev 80) then after the installation.

When you do a custom partitioning install, or check the review disklayout checkbox you are also given a bootloader configuration screen after formatting the filesystems. There is button there to change the device anaconda has selected to install grub onto, and in the dialog that button pops up when you press that you can configure the BIOS drive order, if you change this to what it will be after then installation *and* select to install grub into the mbr, not into the partition holding /boot, your system should boot properly.

The EDD based BIOS drive order detection was re-written in F-13 to better detect the boot order of BIOS RAID devices and it now is as good as it is ever going to get. IOW there is very little we can do to improve the BIOS boot device order detection. Esp. when booting the installer from usb-sticks (iow the livecd) we are just going to get it wrong (more so as some BIOS's seem to completely shuffle the order then rather then just adding the USB stick at the top of the boot device list).

When doing automatic partitioning we allow the user to select which drive the system will boot from and put that at the top of our view of the BIOS's boot devicelist this works well for avoiding this issue for single disk installs with multiple disk installs it is up to the end user to ensure that the BIOS drive order as seen by anaconda is what it will actually be like after the installation.

Thus I'm going to close this as worksforme.

Regards,

Hans


p.s.

The backtrace mentioned in comment #70 is of course a real bug which is likely fixed by the large booty cleanup which I did recently, that will be tracked further in bug 595951.

Note You need to log in before you can comment on or make changes to this bug.