Bug 79379 - boot fails with grub on linux RAID1 md device
boot fails with grub on linux RAID1 md device
Status: CLOSED DUPLICATE of bug 55484
Product: Red Hat Linux
Classification: Retired
Component: grub (Show other bugs)
7.3
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Jeremy Katz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-12-10 18:28 EST by Tim Mooney
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 13:50:17 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)
ks.cfg that leaves a grub system unbootable, but a lilo system works (3.27 KB, text/plain)
2002-12-10 18:34 EST, Tim Mooney
no flags Details
/boot/grub/grub.conf from the unbootable system. (1.37 KB, text/plain)
2002-12-10 18:35 EST, Tim Mooney
no flags Details

  None (edit)
Description Tim Mooney 2002-12-10 18:28:49 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:1.2) Gecko/20021204

Description of problem:
System: Intel SBT2 motherboard with all the latest BIOS components
available from:

  http://support.intel.com/support/motherboards/server/sbt2/latest_bios.htm

Dual Pentium III Xeon processors, 1536 MB RAM.
On-board AIC-7899 with latest HBA firmware (2.57S7), also from Intel.
2 x ST318437LC (18 G) SCSI disks, channel A, ids 0 & 1 (sda & sdb)
2 x ST336706LC (36 G) SCSI disks, channel A, ids 2 & 3 (sdc & sdd)

RedHat 7.3, installed using Kickstart (same thing happens when installed
manually, though).

Problem:  with the OS installed on RAID1 devices on sda & sdb, trying
to boot the box with grub as the bootloader fails.  Booting hangs with

  GRUB Loading stage2...

If I boot the system off of the RH 7.3 CDs and use the rescue option
to make a linux boot floppy (I have to use the uniprocessor kernel
for the boot floppy, because the 2.4.18 smp kernel won't fit on the
floppy -- mkbootdisk fails to detect the error when creating the
boot floppy, BTW), I can use the boot floppy to boot the system,
and everything I've tested works.  It just won't boot using grub as
the bootloader from the internal hard disks.

If I modify our Kickstart file to use lilo as the bootloader, the
system *will* boot correctly.

Thinking it might be something pooched with the initial grub install,
I initially tried

  grub-install /dev/md0

Which didn't work, because the grub-install script doesn't support
meta devices (that's a problem, and should be fixed).

If I instead try

  grub-install /dev/sda

or

  grub-install /dev/sdb

Grub gives me the same error as when I tried /dev/md0:

[root@backup1 root]# grub-install /dev/sda
/dev/md0 does not have any corresponding BIOS drive.

The /boot/grub/device.map file looks like:

(fd0)   /dev/fd0
(hd0)   /dev/sda
(hd1)   /dev/sdb
(hd2)   /dev/sdc
(hd3)   /dev/sdd

Looking at the grub-install script, no matter what I pass in as
the device to operate on, it figures out that /boot == /dev/md0 and
/ == /dev/md1, and then it fails to operate because the sed commands
it uses to normalize the device names aren't expecting `md'.

Clearly grub was installed on at least one of the two disks that
make up /dev/md0 (and /dev/md1 - /dev/md6), since grub tries to load
the stage2 bootloader and then hangs.  In fact, if run grub manually
after booting the system (either from the floppy boot diskette, or
after re-Kickstarting the system to use lilo as the bootloader), I
see:

grub> root (hd0,0)
 Filesystem type is ext2fs, partition type 0xfd

grub> find /grub/stage1
 (hd0,0)
 (hd1,0)

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)"...  22 sectors are embedded.
succeeded
 Running "install /grub/stage1 d (hd0) (hd0)1+22 p (hd0,0)/grub/stage2
/grub/grub.conf"... succeeded
Done.

grub> setup (hd1)
 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 (hd1)"...  22 sectors are embedded.
succeeded
 Running "install /grub/stage1 d (hd1) (hd1)1+22 p (hd0,0)/grub/stage2
/grub/grub.conf"... succeeded
Done.



If I modify /boot/grub/grub.conf to include "debug", and then do the
above procedure again, instead of hanging at the "GRUB Loading stage2..."
message I get a message (which I don't have exact, sorry)
that says "GRUB Loading stage1.5..." and then a message that was
something like

  starting GRUB, please wait...

or

  GRUB loading, please wait...

and then a hang.

Version-Release number of selected component (if applicable):
grub-0.91-4

How reproducible:
Always

Steps to Reproduce:
Install RedHat 7.3 using Kickstart (or manually), using the attached
ks.cfg.

Actual Results:  System will hang at "GRUB Loading stage2..." if grub is the
bootloader.
If you modify the ks.cfg to use Lilo as the bootloader instead, lilo
will load successfully when you reboot the system, and you can boot the Linux
kernel.

Expected Results:  Using grub as the bootloader should work.

Using grub on top of Linux RAID1 /dev/md style devices should work.

grub-install should accept and understand /dev/md style devices, and
it should install the necessary bits on *both* sides of the mirror.
Alternately, if you have /boot=/dev/md0 and /=/dev/md1, and you try

  grub-install /dev/sda

or

  grub-install /dev/sdb
it *ought* to allow you to proceed.

Additional info:
Comment 1 Tim Mooney 2002-12-10 18:34:16 EST
Created attachment 88310 [details]
ks.cfg that leaves a grub system unbootable, but a lilo system works
Comment 2 Tim Mooney 2002-12-10 18:35:57 EST
Created attachment 88311 [details]
/boot/grub/grub.conf from the unbootable system.
Comment 3 Jeremy Katz 2002-12-29 01:37:44 EST

*** This bug has been marked as a duplicate of 55484 ***
Comment 4 Red Hat Bugzilla 2006-02-21 13:50:17 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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