FC4t2 no good without LILO

[Paul Iadonisi]

On Thu, 2005-04-14 at 13:37 -0700, Mike Bird wrote:
> On Thu, 2005-04-14 at 13:12, Paul Iadonisi wrote:
> > One last try.
> 
> [Great test log showing grub-install writing to both MBR's on SCSI
> drives when boot loader portion of MBR's was first zeroed and when no
> partition on either SCSI was marked active.  Thank you for that datum.]

  Thanks.  It looks like I'm finally getting through.

> So what did you mean by "The characters 'LILO' still left
> behind (as a remnant) after doing the grub-install has no bearing
> whatsoever on whether or not grub was really installed."?  The letters
> are part of LILO's first stage boot loader and are not part of Grub's.

  Okay, then, let me clarify.  Without looking at code, my educated
guess (which I claim is as good as your claims), it appears quite clear
that the string 'LILO' *near* the beginning of the boot sector (i.e.:
NOT at the very beginning) is simply cruft.  It's not used.  I sure hope
your are not claiming that the string 'LILO' itself dictates that the
bootloader being used is LILO, are you?  I've got to believe, based on
what I'm witnessing, that it is only the first few bytes (apparently
three bytes) that has any significance.

> Here Grub doesn't write to either MBR:
> 
> # grub-install --recheck /dev/md0
> Probing devices to guess BIOS drives. This may take a long time.
> Installation finished. No error reported.
> This is the contents of the device map /boot/grub/device.map.
> Check if this is correct or not. If any of the lines is incorrect,
> fix it and re-run the script `grub-install'.
> 
> (fd0)   /dev/fd0
> (hd0)   /dev/hde
> (hd1)   /dev/hdg
> # od -c /dev/hde | head -1
> 0000000   ë   H 220   l   b   a   L   I   L   O 001  \0 025 004   Z  \0
> # od -c /dev/hdg | head -1
> 0000000   ë   H 220   l   b   a   L   I   L   O 001  \0 025 004   Z  \0
> #
> 
> (I get the same result with or without --recheck).
> 
> Maybe Grub only overwrites the MBR if it's zero.  Maybe Grub only
> overwrites the MBR when no partition is marked active.  Maybe Grub is
> broken on IDE, or on tertiary IDE.

  Or maybe you are not looking close enough at the results before and
after running grub-install.  Look closely at my post with the date 'Thu,
14 Apr 2005 15:34:42' in this thread.  I dumped the boot blocks after
running lilo and then ran grub-install.  Then I dumped the boot blocks
again.  They were, in fact, different.  All that seems to matter is the
first three bytes.

>   If Redhat would document what
> functionality is supposed to be working,

  Given that this (sub)topic is about grub previously not getting
installed properly with grub-install onto a software raid 1 boot device,
I think you know that answer.
  Frankly, why do you need it to be *documented* in any way other than
bugzilla?  It was a bug that was experienced, apparently, in a pretty
widespread manner.  It was a reported in bugzilla (apparently many
times).  It is finally fixed.  We are talking about it now in pretty
detailed terms.  What more should anyone need?

>  we'd know what sort of bug
> report to file, if any.

  Any *other* problems you find with the CURRENT grub (0.95-12).  Or re-
report this one, if you can document that it still exists.  If you do
that, though, you've got to a better job than you have in this sub-
thread.

> Clearly, Grub still isn't reliably doing the job of Lilo, which is where
> this all started.

  No, clearly you keep letting facts get in the way your unfounded
assertions.  A little cruft leftover from lilo near the beginning of the
boot block that has ZERO effect on bootstrapping does not in any way
make grub unreliable.

-- 
-Paul Iadonisi
 Senior System Administrator
 Red Hat Certified Engineer / Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets