[conspire] Help with GRUB

Rick,
Thanks for detailed advise. Some specific replies are below.
Paul
>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?
YES, that is correct.
>> 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.)
I'm still in the steep part of the
learning curve on grub. Knowing about “b”,
would have been a useful thing.
>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.
--
-- much IMPORTANT info about MBR
skipped for further study
--
>> 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.
For openers, I was certainly confused.
Now I know that sda, sdb, etc are
defined by the hardware connections.
However hd0 does not always map to sda.
>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?
>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)
At this point, I can get grub to boot
debian from the hard drive by
modifying menu.lst to read (hd2,4).
From the above, I now understand
that there are possibly cleaner fixes
to my work-around. I will experiment
with them.
However I have not been able to get
windows to boot. Most likely
that install was not correct. What I
know is that I took computer to
have windows re-installed after it got
some serious malware.
I told the installer it was OK to
over-write the MBR. He said he
did the first part of the install. He
rebooted and windows started
as he expected. Then he installed
“some drivers”. After that, grub
re-appeared and he could not boot and
was stuck.
So, I am going to
1. re-read and experiment with grub
until
I have a better understanding of what
is going on.
2. Then I will look more closely at
Rick's comments about MBR and
figure out how to make that a non-issue
so I can return to the
MS installation,
3. Expect to re-install grub because
MS will mess with the MBR.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/conspire/attachments/20091105/d766c9bf/attachment.html>