Bug 505836 - F11 unbootable, incorrect grub install
F11 unbootable, incorrect grub install
Product: Fedora
Classification: Fedora
Component: grub (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-06-14 04:12 EDT by Andrei Gaponenko
Modified: 2010-06-28 08:59 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-06-28 08:59:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Andrei Gaponenko 2009-06-14 04:12:26 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
screen followed.  

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
(hd1)     /dev/sda
(hd0)     /dev/sdb

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
(hd0)     /dev/sda

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 (
	root (hd1,1)
	kernel /vmlinuz- ro root=UUID=e764ac73-2aef-4dce-a6ab-8c81dceaafc3 rhgb quiet
	initrd /initrd-
title F10
	rootnoverify (hd1,4)
	chainloader +1
title Other
	rootnoverify (hd1,0)
	chainloader +1


Thank you,
Comment 1 Andy Lindeberg 2009-06-15 14:59:00 EDT
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?
Comment 2 Andrei Gaponenko 2009-06-16 04:07:42 EDT

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
unit: sectors

/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
be installed.

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".

Comment 3 Garrett Mitchener 2009-06-26 14:58:15 EDT
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.
Comment 4 Garrett Mitchener 2009-06-26 22:21:36 EDT
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.
Comment 5 Garrett Mitchener 2009-06-29 12:02:53 EDT
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

root (hd1,0)
setup (hd0)

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.
Comment 6 Need Real Name 2009-09-27 04:33:31 EDT
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

find /grub/stage1
root (hd1,0)
setup (hd0)

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.
Comment 7 Need Real Name 2009-09-27 04:38:30 EDT
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.
Comment 8 Garrett Mitchener 2009-12-10 09:56:57 EST
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.
Comment 9 Bug Zapper 2010-04-27 10:53:57 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: 
Comment 10 Bug Zapper 2010-06-28 08:59:19 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.

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