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
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.
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.
/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
er, /boot/boot/grub/* rather than /boot/grub/grub/* in the second stanza of comment 4
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.
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.
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.
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)
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?
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.
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
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
(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.
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.
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.
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.
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.
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.
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.)
Created attachment 310383 [details] MBR of computer that had booting problem
Created attachment 310384 [details] MBR of computer still running Fedora 8
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.
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.
I'm just experiencing the same problem after a recent yum update; grub just hangs with a non-functional command prompt, raising severity
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.
Perhaps I wasn't clear enough, the only word "GRUB" is exactly what I'm seeing (however, comment #19 helped me fix the problem)
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)
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.
Created attachment 311200 [details] Output from fdisk -l This is the output from fdisk -l for the computer mentioned in comment 24.
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.
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.
I saw this too on an x86_64 machine (F9 upgraded from F8), though it was not the first kernel update afterwards.
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.
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.
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.
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.
*** Bug 447188 has been marked as a duplicate of this bug. ***
*** Bug 472829 has been marked as a duplicate of this bug. ***
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.
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.
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.
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?
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.
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
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.
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.
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
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.
*** Bug 488259 has been marked as a duplicate of this bug. ***
*** Bug 470594 has been marked as a duplicate of this bug. ***
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.
Updating F10 to F11. Still the same. Had to use the Rescue DVD and grub-install /dev/sda.
[... 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.]
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.
(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.
Created attachment 350524 [details] Broken stage2 file This is my broken stage2 file.
Created attachment 350525 [details] Repaired stage2 file This is the repaired version of my stage2 file.
(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.
I have systems with /boot separate and on the root partition and it happens both ways.
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.)
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.
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
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.-
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.
Per comment 65, it looks like this should be re-opened and the Fedora version incremented to F12.
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.-
(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.
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.-
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.