Bug 137789 - Grub does not boot and it hangs after a successful installation
Grub does not boot and it hangs after a successful installation
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: grub (Show other bugs)
3
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Jeremy Katz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-01 07:33 EST by Srihari Vijayaraghavan
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-11-16 12:08:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Srihari Vijayaraghavan 2004-11-01 07:33:28 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; rv:1.7.3)
Gecko/20041020 Firefox/0.10.1

Description of problem:
It hangs while trying to load second stage loader.


Version-Release number of selected component (if applicable):
FC3 RC5

How reproducible:
Sometimes

Steps to Reproduce:
1. Install FC3 RC5
2. Instruct Installer to install grub in a boot record rather than MBR
by selecting "advance boot loader configuration" option.
3. Complete the installation.
    

Actual Results:  Observe that the newly installed FC does not boot.


Expected Results:  System to boot after a successful installation.

Additional info:

This I have observed on FC3 RC5.

I have seen this problem on 3 different computers (two P4 and one
Athlon) across 2 different boot loaders (two through FC2 Grub and one
through Windows 2000 boot loader).

Two things that were common in all these configurations:
1. I instructed the installer to install the grub in a boot sector of
a partition rather than MBR.
2. Upon booting through rescue mode (from Install CD4) and
reinstalling grub (/sbin/grub-install <device_name>) solved the
problem and made the system to boot fine.

It is as if Installer forgot to run the above command in case of a
non-MBR based installation. (Maybe this problem is present in MBR
configuration too; however, I did not check it on an MBR
configuration. Sorry.)

Thank you.
Comment 1 Jeremy Katz 2004-11-01 10:14:38 EST
Did you already have an active partition on the box?  What does fdisk
-l show?
Comment 2 Srihari Vijayaraghavan 2004-11-01 17:51:08 EST
Yes, there were active partitions in all those machines. (In both the
P4 machines there were Windows 2000 active partitions, while on the
Athlon an FC2.)

Fdisk -l, I did not take that. Neither did I copy the entire
/boot/grub directory structure nor did I compare that directory
structure before and after fixing the problem manually. Sorry. (The
first and second time I thought I was doing something stupid and
wrong, but then when it repeated itself on the third computer I knew
the installer was doing something wrong.)

I will try to simulate and see if I can reproduce the problem.

Thank you.

(My bad I had to discover these problems in the final RCs :(; I should
have done the testing during earlier test stages. But then I was busy
at the Uni.)
Comment 3 Jeremy Katz 2004-11-02 09:40:36 EST
If there's already an active partition set, then we leave it active. 
Otherwise, we break the use of third-party boot managers.

Installing to the partition instead of the MBR is really only useful
for cases where you have a third-party boot manager.  In all other
cases, you probably want to install to the MBR.
Comment 4 Srihari Vijayaraghavan 2004-11-02 15:46:14 EST
I am afraid I do not understand you completely.

Are you saying that if you ask the installer to install the grub
bootloader at the first sector of a partition (rather that at MBR)
then it may not install grub there? (or only install it partially)

This is my setup:
1. Windows on /dev/hda1
2. FC2's /boot on /dev/hda2 (and there are other partitions for FC2
for /, /usr, /tmp, /var etc..)
3. FC2's grub on MBR
4. Grub is the very first boot loader to be loaded by the BIOS (to
load both FC2's kernel, to chain load Windows boot loader and to load
any other boot loaders)
5. FC3 (RC5) is in /dev/hda12 (there is only one parition ie, /;
everything else such as /boot, /usr, /tmp, /var etc. are just directories)
6. FC3 installer was instructed to install grub on /dev/hda12 (so that
it could be chain loaded from FC2's grub (pls refer to point 3)
7. FC2's grub, when instructed to load FC3's grub, loaded the first
stage, but while loading second stage completely hangs.

Are you saying this is an unsupported arragement?

Thank you.
Hari.

PS: I appreciate your help. And I am unable to reproduce this problem
on my laptop, but I shall try and reproduce this problem on other
machines today.
Comment 5 Srihari Vijayaraghavan 2004-11-15 04:37:01 EST
(I have used the vanilla FC3 x86_64 DVD installation media.)

I have reproduced this bug on my AMD64. In this computer FC2's grub on
MBR (/dev/hda) is the primary boot loader for the entire system.

I selected "Advanced boot loader" option during installation, and
chose to install the boot loader on the first sector of one and only
partition (root) of the FC3 (/dev/hda17).

Then I added the following section in my primary grub:
title FC3
    rootnoverify hd(0,16)
    chainloader +1

When I select that it just hangs. (Though ctrl+alt+del works fine.)

I have not tried to fix anything up this time around, although I know
I can fix this by using the Rescue mode and using /sbin/grub-install.
Upon request I can provide files/directories etc..

(It is as if Anaconda installer 'forgot' to install the boot loader.)

Thank you
Hari
Comment 6 Srihari Vijayaraghavan 2004-11-16 03:26:59 EST
I think I understand the problem: I observe that the FC3 - Anaconda -
Disk Druid created partitions are not visible when I use "fdisk -l
/dev/hda". But OTOH they are there and accounted for when I use
"parted /dev/hda print". (I tried this upon completion of the
installation and just before rebooting.)

What are the odds Anaconda (grub installation procedure) was upset
about that?

(Even after a reboot it is still the case, ie, parted shows the Disk
Druid created partitions while fdisk does not.)

Thank you.
Hari.
Comment 7 Srihari Vijayaraghavan 2004-11-16 04:56:33 EST
And Oh BTW, kernel accounts for those 'hidden' (partially :) partitions:

hda: max request size: 1024KiB
hda: Host Protected Area detected.
        current capacity is 234435439 sectors (120030 MB)
        native  capacity is 234441648 sectors (120034 MB)
hda: 234435439 sectors (120030 MB) w/8192KiB Cache, CHS=16383/255/63,
UDMA(100)
hda: cache flushes supported
 hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 hda12
hda13 hda14 hda15 hda16 hda17 hda18 >

And so does /proc/partitions file.

Yes; hda17 and hda18 are the two FC3 installation created partitions.
And both are the one and only partitions for two FC3 installations
obviously. Yes; I have installed FC3 multiple times on this computer :).

Interestingly when I installed the second FC3 (on /dev/hda18), the
previously installed FC's partition (/dev/hda17) was visible in the
Disk Druid screen. IOW, Anaconda does the right thing while "reading"
the partitions, but not while "writing". Maybe it uses two kinds of
procedures/tools: one for partition "reading", which obviously does
the right thing, but not the partition "writing", which might be at
fault. Just a guess.

Summary: fdisk does not display Anaconda - Disk Druid created
partitions (/dev/hda17 and hda18) in my case (before and after the
reboot); OTOH, parted, kernel and /proc/partitions are just fine with
those partitions. And that just might be the root cause of my problem.

Thank you.
Hari.
Comment 8 Jeremy Katz 2004-11-16 12:08:41 EST
fdisk won't display any partitions over /dev/hdaX16.

As for your original question, we install GRUB, but changing the
active partition is usually the exact opposite of what the user
expects.  If they expected GRUB to be activated by default, then you
install to the MBR.

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