[conspire] Help with GRUB

[Rick Moen]

Quoting Paul Zander (paulz at ieee.org):

> So, from rescue CD,  grub   find /boot/stage1  returns (hd0,4)
> That matches with knowing that it is also on sda5.

Do I correctly assume that this means you have an MS-Windows
installation on /dev/sda1 and a Linux installation on /dev/sda5?


> So I gave the commands:
> root(hd0)
> setup(hd0,4)
> quit
> 
> and rebooted the machine w/o the CD.

And it worked, right?  I'm unclear, from your description.  At the 
point where you typed "quit", above, that merely took you back to the
GRUB prompt where you _could_ have then typed "b" to boot using the
revised, manually-entered directives you specified above.  Did you do
that?

(Late addition, written after the section that follows:  Actually, at
that point you didn't have quite enough.  You haven't (at that point)
yet specified where to find a kernel and what root filesystem it should 
mount at boot time.  So, I'm inferring that you never tried "b".  
"setup(hd0,4)" writes persistent bootable information to the superblock
of /dev/sda5, a point I'll return to, below.)


Part of the point of doing entry of commands manually at the GRUB prompt
is to validate your understanding of where everything is, phrased in
GRUB-speak, so that you can (if necessary) correct the contents of a
copy of menu.lst prior to running grub-install, which implements those
contents as instructions, and writes bootable information to wherever
you said in menu.lst to put it.

By the way, that destination for bootable information _can_ be the MBR
(the first 446 bytes of sector zero on the first hard disk), but doesn't
need to be.  Many people with dual-boot setups elect to surrender
control over the MBR to MS-Windows's installation routines, which tend
to overwrite whatever you've put in the MBR at the drop of a hat.

1. So, one common strategy is to let the gods-damned Microsoft software run
roughshod over the MBR and repeatedly reinstall the traditional MS-IBM 
first-stage bootloader there, a tiny program just bright enough to find
the first primary partition with the "Active" flag set, and branch to it
for further startup.  In those cases, the user cleans up after the
Microsoft software by removing the "Active" flag from the MS-Windows
partition and setting it on the Linux boot partition (that is of type
primary).  This means that the first-stage bootloader branches to what's
in the Linux boot partition, which, of course, is where you install
GRUB's bootable stuff (via said menu.lst directives).

2. Or, the alternative strategy, you _can_ if you prefer direct that GRUB 
put its first-stage bootloader directly into the MBR, branching from
there to its second-stage stuff in your Linux partition (and from there
booting either Linux or MS-Windows).

(Disclaimer:  I'm not fluent with this stuff, because I've been
eschewing the madness of multibooting for decades, preferring to have a
single OS per machine.  If I needed to run a secondary OS, it would be
in a virtual machine.  Simple boot setups are my friend -- and I can't
help noticing that they mean I never have to solve problems like the one
you have.)



> once the grub menu appeared, I gave "c" for command,
> find /boot/grub/stage1)
> and it returns (hd2,4)

OK, so GRUB found a GRUB "stage1" file on the fifth partition (first
logical partition) of one of your secondary hard drives.

> The confusion between sda and sdc would be enough to explain the wrong
> partition types.

I'm not sure what you mean when you say "the confusion" -- though, yes,
I do remember your account of boot failures citing incomprehensible 
partition types.  Whose confusion, though?  One of the unanswered
questions, IIRC, is what on Earth happened to your system.  It seems 
reasonable to suppose that either there was some substantive hardware
change, e.g., insertion or removal of hard drives, rejumpering, etc., or
that you or some piece of hardware operating on your behalf attempted to 
rewrite your bootloader setup and got wrong the identification of
filesystems.

It _might_ be useful to attempt to retrace what happened -- or,
alternatively, you could decide you'd rather just concentrate on fixing
the setup and deliberately disregard the question of how it got that
way.  Either choice could be defensible.

Anyhow, it's your hardware, i.e., you can see right in front of you what
you do and do not have, which is a big advantage you have over the rest
of us.  Presumably, you know where MS-Windows is -- probably (hd0,1).
Presumably, you know how many hard drives you have and where Linux is --
maybe (hd0,4) aka /dev/sda5.  So, how about you use that knowledge and
see if you can make GRUB do what you want?

> So what next?  Early I had web-site explaining the grub map command
> for a similar problem, but I can't seem to find it.  Or should I just
> edit menu.lst and replace hd0 with hd2?

Er...

Backing up a bit, a large part of the rationale for _first_ doing a
manually-driven boot from the GRUB command line is to test your 
understanding of where everything is in GRUB-speak, _before_ fooling
with the contents of menu.lst.  You can test 

grub> root (hd0,0)
grub> kernel /vmlinuz root=/dev/sda5
grub> quit
"b"

...all day long without writing any persistent information anywhere.

GRUB's "setup" directive, by contrast, says "Write first-stage
bootloader information to _here_".  So, it does create a persistent 
result.

You did:  
grub> setup(hd0,4)

That wrote first-stage bootloader information to /dev/sda5's superblock.
Which leaves me wondering, how were you expecting GRUB to branch to
there?  What do you have in the MBR?

Anyway, to answer your question, you should test your ability to boot
MS-Windows and Linux entirely from the grub command line manually.
Then, armed with that confirmed knowledge of where your OS filesystems
and other essential objects are, start up Linux and revise
/boot/grub/menu.lst to match reality.  Then, do "grub-install [something]"
to make /sbin/grub write bootable stuff somewhere.  The [something] 
could be "(hd0)" if you want to make /sbin/grub write to the MBR, for
example.

The equivalent command from the GRUB command line:

grub> setup(hd0)


-- 
Cheers,
Rick (who _still_ like lilo better) Moen 
rick at linuxmafia.com