Red Hat Bugzilla – Bug 505836
F11 unbootable, incorrect grub install
Last modified: 2010-06-28 08:59:19 EDT
After installing Fedora 11 on a multi-boot laptop, the system gave
black screen on reboot. No error messages or beeps, just black
screen. I had to re-install GRUB by hand to make it usable again.
The installation (netinst.iso) was run from a USB stick. The system
is a Lenovo Thinkpad x200s, at the time of installation it was
attached to a docking bay that had a DVD drive. (The latter was
empty, I think.)
Fedora 11 was installed into existing /dev/sda6, which was
reformatted. The machine had /boot (/dev/sda2) used by Fedora 10
(/dev/sda5) and had GRUB installed on /dev/sda.
During the Fedora 11 installation I chose to update bootloader and
edited the boot menu, adding F10 and Other. Everything seemed to
work, and after package installation was complete and anaconda
prompted to reboot, I removed the USB stick and rebooted. The black
It seems that anaconda did not get the device map right:
[agt@x200s ~]$ cat /boot/grub/device.map.f11-install
# this device map was generated by anaconda
On this system /dev/sdb does not normally exist; it was the USB stick
from which the installation was performed. The correct map for this
system is just
[agt@x200s ~]$ cat /boot/grub/device.map
The generated /boot/grub/grub.conf referenced (hd1,n) instead of
[root@x200s ~]# cat /boot/grub/grub.conf.f11-install-20090612
# grub.conf generated by anaconda
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd1,1)
# kernel /vmlinuz-version ro root=/dev/sda6
# initrd /initrd-version.img
title Fedora (126.96.36.199-167.fc11.x86_64)
kernel /vmlinuz-188.8.131.52-167.fc11.x86_64 ro root=UUID=e764ac73-2aef-4dce-a6ab-8c81dceaafc3 rhgb quiet
Can you list the exact steps you took on the bootloader screen, and tell us exactly what your partition layout looks like, so we can attempt to reproduce this?
Here is the information you requested:
There is only one hard drive on this laptop, no raid or LVM is used.
The partition layout is
[root@localhost ~]# sfdisk -d /dev/sda
# partition table of /dev/sda
/dev/sda1 : start= 63, size= 41254857, Id= 7, bootable
/dev/sda2 : start= 41254920, size= 401625, Id=83
/dev/sda3 : start= 41656545, size= 81915435, Id= 5
/dev/sda4 : start=123571980, size=189004725, Id=83
/dev/sda5 : start= 41656608, size= 30716217, Id=83
/dev/sda6 : start= 72372888, size= 30716217, Id=83
/dev/sda7 : start=103089168, size= 10233342, Id=82
/dev/sda8 : start=113322573, size= 10249407, Id=82
All the partitions existed before the F11 installation and were not
resized. sda2 is /boot (and was entered as such in the custom
partition editor screen during the installation), sda5 was reformatted
as ext4 to install F11.
I did not write down my exact steps at the bootloader configuration
screen, but the whole process seemed straightforward and unambiguous.
I did not have a chance to edit or even view grub configuration. The
GUI interface initially had an entry for Fedora 11, and a button to
"Add" other systems, which IIRC only allowed to specify partition and
corresponding boot menu label.
More info: I did some tests tonight and I think I found a way to
reproduce the problem. Compare these two situations:
1) Plug a USB stick into a laptop port. Power the system up and
boot from the built-in hard drive. On the grub menu screen press
"c" to get the grub shell. Now
grub> geometry (hd0)
drive 0x80 ...(printout of built in HD follows)
grub> geometry (hd1)
drive 0x81 ...(printout of the USB stick pars)
2) Plug a USB stick with systemrescuecd-x86-1.1.7.iso live image into
a laptop port. Power the system up and boot from the USB stick.
Among the boot options (I think on the "F2" screen) are "boot from
the first hard disk" and "boot from the second hard disk".
Selecting "boot from the first" boots the same systemrescuecd
again. Selecting "boot from the second hard disk" brings up
the GRUB menu from the hard drive installation. Pressing "c"
we get a grub shell again, but this time we can observe
grub> geometry (hd0)
drive 0x80 ...(printout of the USB stick pars)
grub> geometry (hd1)
drive 0x81 ...(printout of built in HD follows)
It seems that "hd0" is the initial boot device. Because I installed
F11 from a USB stick, like the case (2) above, anaconda saw the "real"
hard drive as hd1.
While this problem is tricky to solve, it ought to be addressed. An
unbootable system is a *bad* screw up for many users. My suggestion
is to compare, at the time of installation, the drive number from
which anaconda is run with the drive number where GRUB is going to be
installed. If the installer's media drive number is smaller than the
GRUB target hard drive number, this is clearly suspicious. Once the
installation media is removed, the number of the remaining hard drive
is likely to change upon reboot. Are there any real life use cases
when this check would give a false positive? I don't see any at the
moment. An it would catch the case that I had.
What to do once the "possible drive renumbering" situation is
detected is the next question. At the minimum the user should be
warned, and may be given an option of editing the actual grub
configuration file. In a text editor, not via the simplistic GUI.
One would also want to double check onto what drive GRUB is going to
In simple cases, like most laptop installs, it would be sufficient for
a user to assert to the installer that the system has only one hard
drive. Then the installer can just write out and use the hardcoded
device.map "(hd0) /dev/sda".
Bug #450143 might be related. I ran into this problem during prior upgrades 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.
Or not. I just upgraded from F10 to F11 from a DVD on a desktop machine with no external drive plugged in, and somehow grub didn't get installed properly. It was easy enough to do it manually because I've been through this before, but seriously, this needs to get fixed. grub.conf was updated fine. There are no errors in /root/upgrade.log or /root/upgrade.log.syslog.
I just upgraded my other workstation from F10 to F11 from a DVD.
My general setup is:
sda (hd0) : first hard drive, grub installed on MBR
sdb1 (hd1,0) : second hard drive, 1st partition, /boot where grub's later stages and conf file live
built-in card reader with slots for SD, CF, etc.
USB hard drive with a couple of partitions
The rest of sdb is my linux installation.
On one of the logging consoles, right at the end of the upgrade, I caught an error message. It showed that grub was run with the command
install --stage2=/boot/grub/stage2 /grub/stage1 d (hd0) /grub/stage2 p (hd1,0)/grub/grub.conf
and gave an error about an invalid device.
I went to one of the other consoles that has a command line. I ran grub and typed the same command and got the same error.
I then tried the commands
and it told me it was running
install /grub/stage1 d (hd0) (hd0)1+28 p (hd1,0)/grub/stage2 /grub/grub.conf
And this worked. My system booted. I don't know enough about grub to know what makes the difference.
I'm confused because according to grub's built-in help, the install syntax should be p /grub/grub.conf and the stage2 file ought to be in some other order, probably after the (hd0)1+28.
Similar problem here, reproduced twice.
1. Fresh F11 AMDx64 install,multiple (EIDE & SATA) disks present.
During installation chose use fedora and fedora-updates repositories.
the resulting installation is unbootable.
The way to fix - boot from rescue DVD, run grub and execute
2. A laptop with Intel x86 F11 install, single disk.
Windows is booted via grub "Other" operating system menu option.
In September I turned on the computer and run
yum -y update command.
The update (hundreds packages) finished successfully.
Then the laptop became unbootable.
To make it booting again -
boot from installation DVD, choose "rescue"
run grub and execute grub command listen in item 1.
By the way, when using just DVD install
(without network repositories with updates during install)
the resulting installation boots OK. No problem then.
This is just something from updates, what breaks booting.
I don't know if this is relevant:
I used a DVD to upgrade my workstation from F11 to F12. I happened to have a USB hard drive plugged in (it has a linux partition by the way), and when the install program got to the part about the bootloader, it disabled the option to upgrade the bootloader configuration. It seems that the USB drive was being mapped to /dev/sda, and my two internal hard drives were mapped to /dev/sdb and /dev/sdc and the install program was very confused. Normally, the two internal hard drives are mapped to /dev/sda and /dev/sdb, it boots initially from /dev/sda and the /boot partition is on /dev/sdb. I canceled the upgrade, unplugged the USB hard drive, rebooted, and tried again. This time, the internal hard drives were sda and sdb like normal, and the installer enabled the option to upgrade the bootloader configuration. I used that option and proceeded with the upgrade. The system booted correctly after the upgrade. So I suspect there's some problem with drive identification confusing the part of the upgrade process dealing with grub. I know grub has some uncertainty about how the BIOS identifies hard drives vs. how the linux kernel does it, so maybe that's part of the problem? This was on a Dell Precision 690 with their A05 BIOS.
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:
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.