[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


From: Uwe Zeisberger
Subject: GRUB + HPT370
Date: Thu, 29 Jul 2004 15:58:33 +0200
User-agent: Mutt/1.5.6+20040523i


here is my successful story of using Grub (Debian package version
0.95+cvs20040624-3) with an HPT370 Raid Controller (BIOS 1.11.0402):

My mainboard (an Abit KT7-Raid) has two onboard IDE Controllers, a VIA
chipset and an HPT370 Raid Controller.

Booting Linux with lilo worked fine. Booting with Grub only worked, if
the hard disk to boot was attached to the VIA controller.

Whenever I plugged the hd with a Grub in the mbr into the HPT
controller, the computer entered an endless boot loop. Then only
installing lilo or attaching the hd to the VIA controller and
reinstalling Grub helped.

After some hard testing I detected, that four bytes - namely the bytes
0x1220+3 - of /dev/hde are overwritten with zeros at booting time.

Unfortunately this is in the area, where Grub places stage1_5, and these
four bytes are obviously important.

Then I spend some time to understand the documentation of Grub, and
tested much.

In the end I did:

  grub> root (hd0,0)
   Filesystem type is xfs, partition type 0x83

  grub> setup (hd0)
  .... embed /boot/grub/xfs_stage1_5 (hd0) ... 19 ...
  .... install /boot/grub/stage1 (hd0) (hd0)1+19 p /boot/grub/stage2 

  the setup command dumps (via embed) (a slightly modified version of)
  /boot/grub/xfs_stage1_5 directly behind the mbr (to the blocks 1 to
  19). Then it installs stage1 in the mbr and tells it, where to find

Now in a root shell:

- get the modified xfs_stage1_5 back:

  # dd if=/dev/hde of=stage1_5 skip=1 count=19
  19+0 records in
  19+0 records out
  9728 bytes transferred in 0.001225 seconds (7941754 bytes/sec)

- clean this area:

  # dd if=/dev/zero of=/dev/hde seek=1 count=19
  19+0 records in
  19+0 records out
  9728 bytes transferred in 0.001333 seconds (7298110 bytes/sec)

  I think, this is save, because the raid chip writes zeros, too. If
  you want a hardware raid, there may be sensitive information to backup
  before the first installation of Grub.

- dump stage1_5 to a higher address:

  # dd if=stage1_5 of=/dev/hde seek=16
  19+0 records in

and now in a Grub shell (if you closed the shell from above, reset the
root to (hd0,0) or whatever you use):

  grub> install /boot/grub/stage1 (hd0) (hd0)16+19 p /boot/grub/stage2 

The only difference to the above command executed by setup is the third
argument specifying the new address of stage1_5.

Then I rebooted and was happy.

Maybe it would be nice, if the setup command would take an additional
argument, which specifies the offset of stage1_5 (and defaults to 1).
Then the commands for me were:

  grub> root (hd0,0)
  grub> setup (hd0) 16

(I didn't looked in the source code of Grub - maybe I am able to provide
a patch, if you are interested. I imagine, thats not too difficult.)

To sum up, I can say that I learned much in the last few hours, I didn't
lost any data (though it looked like it, more than once) and hopefully
this mail is helpful to anybody, who is in a situation similar to mine.


Uwe Zeisberger


Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]