[conspire] Help with GRUB

[Paul Zander]

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/fde61b5c/attachment.html>