<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;"><meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8"><title></title><meta name="GENERATOR" content="OpenOffice.org 2.0 (Win32)"><meta name="AUTHOR" content="Paul Zander"><meta name="CREATED" content="20091105;12010618"><meta name="CHANGED" content="16010101;0"><style>
<!--
@page { size: 8.5in 11in; margin: 0.79in }
P { margin-bottom: 0.08in }
-->
</style>
<p style="margin-bottom: 0in;">Rick,</p><p style="margin-bottom: 0in;"><br></p><p style="margin-bottom: 0in;">Thanks for detailed advise. Some specific replies are below.</p><p style="margin-bottom: 0in;"><br></p><p style="margin-bottom: 0in;">Paul<br></p><p style="margin-bottom: 0in;"><br></p><p style="margin-bottom: 0in;">>Quoting Paul Zander
(paulz@ieee.org):<br>><br>>> So, from rescue CD, grub find
/boot/stage1 returns (hd0,4)<br>>> That matches with knowing
that it is also on sda5.<br><br>>Do I correctly assume that this
means you have an MS-Windows<br>>installation on /dev/sda1 and a
Linux installation on /dev/sda5?<br><br>YES, that is correct.</p>
<p style="margin-bottom: 0in;"><br>>> So I gave the commands:<br>>>
root(hd0)<br>>> setup(hd0,4)<br>>> quit<br>>> <br>>>
and rebooted the machine w/o the CD.<br><br>>And it worked, right?
I'm unclear, from your description. At the <br>>point where you
typed "quit", above, that merely took you back to the<br>>GRUB
prompt where you _could_ have then typed "b" to boot using
the<br>>revised, manually-entered directives you specified above.
Did you do<br>>that?<br>><br>>(Late addition, written after
the section that follows: Actually, at<br>>that point you didn't
have quite enough. You haven't (at that point)<br>>yet specified
where to find a kernel and what root filesystem it should <br>>mount
at boot time. So, I'm inferring that you never tried "b".
<br>>"setup(hd0,4)" writes persistent bootable
information to the superblock<br>>of /dev/sda5, a point I'll
return to, below.)<br><br>
</p>
<p style="margin-bottom: 0in;">I'm still in the steep part of the
learning curve on grub. Knowing about “b”,
</p>
<p style="margin-bottom: 0in;">would have been a useful thing.<br><br>>Part
of the point of doing entry of commands manually at the GRUB
prompt<br>>is to validate your understanding of where everything
is, phrased in<br>>GRUB-speak, so that you can (if necessary)
correct the contents of a<br>>copy of menu.lst prior to running
grub-install, which implements those<br>>contents as instructions,
and writes bootable information to wherever<br>>you said in
menu.lst to put it.<br><br>
</p>
<p style="margin-bottom: 0in;">--<br>-- much IMPORTANT info about MBR
skipped for further study<br>--<br><br><br>>> once the grub
menu appeared, I gave "c" for command,<br>>> find
/boot/grub/stage1)<br>>> and it returns (hd2,4)<br><br>>OK,
so GRUB found a GRUB "stage1" file on the fifth partition
(first<br>>logical partition) of one of your secondary hard
drives.<br><br>>> The confusion between sda and sdc would be
enough to explain the wrong<br>>> partition types.<br><br>>I'm
not sure what you mean when you say "the confusion" --
though, yes,<br>>I do remember your account of boot failures
citing incomprehensible <br>>partition types. Whose confusion,
though? One of the unanswered<br>>questions, IIRC, is what on
Earth happened to your system. It seems <br>>reasonable to suppose
that either there was some substantive hardware<br>>change, e.g.,
insertion or removal of hard drives, rejumpering, etc., or<br>>that
you or some piece of hardware operating on your behalf attempted to
<br>>rewrite your bootloader setup and got wrong the
identification of<br>>filesystems.<br><br>
</p>
<p style="margin-bottom: 0in;">For openers, I was certainly confused.
</p>
<p style="margin-bottom: 0in;">Now I know that sda, sdb, etc are
defined by the hardware connections.</p>
<p style="margin-bottom: 0in;">However hd0 does not always map to sda.</p>
<p style="margin-bottom: 0in;"><br>>It _might_ be useful to attempt
to retrace what happened -- or,<br>>alternatively, you could
decide you'd rather just concentrate on fixing<br>>the setup and
deliberately disregard the question of how it got that<br>>way.
Either choice could be defensible.<br><br>>Anyhow, it's your
hardware, i.e., you can see right in front of you what<br>>you do
and do not have, which is a big advantage you have over the rest<br>>of
us. Presumably, you know where MS-Windows is -- probably
(hd0,1).<br>>Presumably, you know how many hard drives you have
and where Linux is --<br>>maybe (hd0,4) aka /dev/sda5. So, how
about you use that knowledge and<br>>see if you can make GRUB do
what you want?<br><br><br>>Backing up a bit, a large part of the
rationale for _first_ doing a<br>>manually-driven boot from the
GRUB command line is to test your <br>>understanding of where
everything is in GRUB-speak, _before_ fooling<br>>with the
contents of menu.lst. You can test <br>><br>> grub> root
(hd0,0)<br>> grub> kernel /vmlinuz root=/dev/sda5<br>> grub>
quit<br>> "b"<br><br>...all day long without writing any
persistent information anywhere.<br><br>>GRUB's "setup"
directive, by contrast, says "Write first-stage<br>>bootloader
information to _here_". So, it does create a persistent
<br>>result.<br><br>>You did: <br>>grub>
setup(hd0,4)<br><br>>That wrote first-stage bootloader information
to /dev/sda5's superblock.<br>>Which leaves me wondering, how were
you expecting GRUB to branch to<br>>there? What do you have in the
MBR?<br><br>>Anyway, to answer your question, you should test your
ability to boot<br>>MS-Windows and Linux entirely from the grub
command line manually.<br>>Then, armed with that confirmed
knowledge of where your OS filesystems<br>>and other essential
objects are, start up Linux and revise<br>>/boot/grub/menu.lst to
match reality. Then, do "grub-install [something]"<br>>to
make /sbin/grub write bootable stuff somewhere. The [something]
<br>>could be "(hd0)" if you want to make /sbin/grub
write to the MBR, for<br>>example.<br><br>>The equivalent
command from the GRUB command line:<br>><br>>grub>
setup(hd0)<br><br>
</p>
<p style="margin-bottom: 0in;">At this point, I can get grub to boot
debian from the hard drive by</p>
<p style="margin-bottom: 0in;">modifying menu.lst to read (hd2,4).
From the above, I now understand
</p>
<p style="margin-bottom: 0in;">that there are possibly cleaner fixes
to my work-around. I will experiment</p>
<p style="margin-bottom: 0in;">with them.</p>
<p style="margin-bottom: 0in;"><br>
</p>
<p style="margin-bottom: 0in;">However I have not been able to get
windows to boot. Most likely
</p>
<p style="margin-bottom: 0in;">that install was not correct. What I
know is that I took computer to
</p>
<p style="margin-bottom: 0in;">have windows re-installed after it got
some serious malware.</p>
<p style="margin-bottom: 0in;">I told the installer it was OK to
over-write the MBR. He said he</p>
<p style="margin-bottom: 0in;">did the first part of the install. He
rebooted and windows started</p>
<p style="margin-bottom: 0in;">as he expected. Then he installed
“some drivers”. After that, grub</p>
<p style="margin-bottom: 0in;">re-appeared and he could not boot and
was stuck.</p>
<p style="margin-bottom: 0in;"><br>
</p>
<p style="margin-bottom: 0in;">So, I am going to
</p>
<p style="margin-bottom: 0in;"><br>
</p>
<p style="margin-bottom: 0in;">1. re-read and experiment with grub
until
</p>
<p style="margin-bottom: 0in;">I have a better understanding of what
is going on.</p>
<p style="margin-bottom: 0in;"><br>
</p>
<p style="margin-bottom: 0in;">2. Then I will look more closely at
Rick's comments about MBR and</p>
<p style="margin-bottom: 0in;">figure out how to make that a non-issue
so I can return to the</p>
<p style="margin-bottom: 0in;">MS installation,</p>
<p style="margin-bottom: 0in;"><br>
</p>
<p style="margin-bottom: 0in;">3. Expect to re-install grub because
MS will mess with the MBR.</p>
<p style="margin-bottom: 0in;"><br>
</p>
</td></tr></table>