Re: GRUB failure

[Jack Bowling]

On Mon, Aug 04, 2003 at 12:33:26PM -0600, Ashley M. Kirchner wrote:
> Otto Haliburton wrote:
> 
> >I have a dual boot system with HDA containing XP PRO and RH9 on HDB GRUB
> >is the boot loader and it is written to the MBR or HDA along with the XP
> >boot loader.  I just removed HDB and guess what I got a black screen
> >with GRUB in the left hand corner.
> > 
> >
>Welcome to my world.  At that point in the game, I doubt it even 
> knows about hdb, to even go find the config file.  It read the MBR, and 
> ... fell off the planet.

Hi, Ashley. Sorry to butt my head in so late. When you yanked the 2nd
drive, did you go into the BIOS and tell it that it no longer exists?

-- 
Jack Bowling
mailto: [EMAIL PROTECTED]


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re:: GRUB failure

[Ashley M. Kirchner]

Ashley M. Kirchner wrote:

   This was posted in a precious email.  Yes.
   *previous*

--
H| I haven't lost my mind; it's backed up on tape somewhere.
 +
 Ashley M. Kirchner    .   303.442.6410 x130
 IT Director / SysAdmin / WebSmith . 800.441.3873 x130
 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6
 http://www.pcraft.com . .  ..   Boulder, CO 80303, U.S.A. 





--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Ashley M. Kirchner]

Jack Bowling wrote:

Hi, Ashley. Sorry to butt my head in so late. When you yanked the 2nd
drive, did you go into the BIOS and tell it that it no longer exists?
 

   This was posted in a precious email.  Yes.

--
H| I haven't lost my mind; it's backed up on tape somewhere.
 +
 Ashley M. Kirchner    .   303.442.6410 x130
 IT Director / SysAdmin / WebSmith . 800.441.3873 x130
 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6
 http://www.pcraft.com . .  ..   Boulder, CO 80303, U.S.A. 





--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Otto Haliburton]

Last time around.  It appears that stage2 never gets called nor stage1_5
(I don't even see how it gets setup to call, but if it were called it
definitely prints a message GRUB is loading).  Also it appears that
there is no error in stage1.  So I don't believe that Ashley's problem
is with GRUB at all.  Stage1 is called with the boot, checks all of its
parameters and then long jumps to a stage2(which it can't find in memory
even though it thinks it read it in correctly).  This leads me to
believe that block offset for stage2 has changed (probably due to
removing hdb) but there is a wild possibility that it was never correct
and purely by coincidence it loaded a correct values when hdb was
loaded(being a software type this definitely has happened to me before
and it blows my mind) It possibly was loading offsets from hdb that were
correct for the location of stage2 or something similar.  The other
thing is that the bios is outdated for the GRUB you are using.  In any
case the problem is to force GRUB to load correctly with hdb not there. 
my suggestion is to 1) make a boot disk. 2)(optional) get the latest and
greatest GRUB software.  There may have been a update to match your
bios. 3) follow the procedure in the GRUB manual to manually load GRUB.
Specifically with hdb removed and when you are boot from your boot
floppy.  Also remember to do the cd /sysroot thing to access your hda
drive properly for the floppy(I don't use this often and I don't
remember the command correctly).  you can activate the grub shell.  Its
should be in sbin on hda and let it do a find on stage 2.  The procedure
is in the manual. Good luck!!!


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Ashley M. Kirchner]

Michael Schwendt wrote:

- is BIOS set to LBA?

   Last I checked, it was.

- does grub-install with --force-lba work?

   No errors.

- does LILO work?
 

   Ain't trying that.  The server is up and running as it should be, 
and I can't take it down in the name of science right now.

--
W | I haven't lost my mind; it's backed up on tape somewhere.
 +
 Ashley M. Kirchner    .   303.442.6410 x130
 IT Director / SysAdmin / WebSmith . 800.441.3873 x130
 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6
 http://www.pcraft.com . .  ..   Boulder, CO 80303, U.S.A.




--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Michael Schwendt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 4 Aug 2003 16:16:46 -0400, Kenneth Goodwin wrote:

> I dont have the RH 7.2 version of
> the grub source to look at. Might have 7.1 levels. The MBR
> is probably the same.
> If you have source - What does it do after printing out
> "GRUB", everything or
> just a few last things before jumping to the newly loaded
> image?

RHL 7.3: grub-0.91-4
RHL 9:   grub-0.93-6

And surprise, the stage1 code is exactly the same.

It prints "GRUB ", then does a few BIOS software interrupt calls to
look whether LBA is supported, else falls back to CHS scheme. It
also contains a bit of floppy probing code. If it doesn't print
anything else than GRUB, it assumes it has loaded the next stage and
executes it.

A bit more sane code (if space permits) would print a few dots right
before executing the next stage or would even verify whether the
loaded next stage starts with a proper signature.

Open questions:

 - is BIOS set to LBA?
 - does grub-install with --force-lba work?
 - does LILO work?
 
- -- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/Lsco0iMVcrivHFQRAm9BAJ9CtMyWU/qpnoLoKhT7tIm010aXkgCcDVFi
ko2oaeln8AVlwEnTQarX1kk=
=V+e7
-END PGP SIGNATURE-


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: [RH List] RE: GRUB failure

[Kenneth Goodwin]

Otto , Ashley stated he REMOVED THEM BOTH , I was just
confirming
that all of them was gone, not just a piece at the admin
level.

>  -Original Message-
>  From: [EMAIL PROTECTED]
>  [mailto:[EMAIL PROTECTED] Behalf Of Otto
Haliburton
>  Sent: Monday, August 04, 2003 4:23 PM
>  To: [EMAIL PROTECTED]
>  Subject: RE: [RH List] RE: GRUB failure
>
>
>  They both are there trust me. In RH8/9
>
>  > -Original Message-
>  > From: [EMAIL PROTECTED] [mailto:redhat-list-
>  > [EMAIL PROTECTED] On Behalf Of Kenneth Goodwin
>  > Sent: Monday, August 04, 2003 2:44 PM
>  > To: [EMAIL PROTECTED]
>  > Subject: RE: [RH List] RE: GRUB failure
>  >
>  > I thought Kudzu was replaced by Anaconda I dont recall
>  > seeing it on my RH 8/9 systems
>  > but I may have been asleep at the console at the
time...
>  >
>  >
>  > >  -Original Message-
>  > >  From: [EMAIL PROTECTED]
>  > >  [mailto:[EMAIL PROTECTED] Behalf Of
Ashley
>  > M. Kirchner
>  > >  Sent: Monday, August 04, 2003 3:35 PM
>  > >  To: [EMAIL PROTECTED]
>  > >  Subject: Re: [RH List] RE: GRUB failure
>  > >
>  > >
>  > >  Kenneth Goodwin wrote:
>  > >
>  > >  >yOU DONT GET A BOOT time  MESSAGE ABOUTING CHECKING
FOR
>  > new
>  > >  >hardware?
>  > >  >
>  > >  >
>  > >  That's kudzu's job, and it's been long removed.
(So
>  > the
>  > >  answer to
>  > >  your question is no, I don't.)
>  > >
>  > >  --
>  > >  W | I haven't lost my mind; it's backed up on tape
>  > somewhere.
>  > >
>  > >
>  >
+---
>  > -
>  > >Ashley M. Kirchner <mailto:[EMAIL PROTECTED]>   .
>  > >  303.442.6410 x130
>  > >IT Director / SysAdmin / WebSmith .
>  > >  800.441.3873 x130
>  > >Photo Craft Laboratories, Inc..
3550
>  > >  Arapahoe Ave. #6
>  > >http://www.pcraft.com . .  ..
Boulder, CO
>  > >  80303, U.S.A.
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >  --
>  > >  redhat-list mailing list
>  > >  unsubscribe
>  >
mailto:[EMAIL PROTECTED]
>  > >  https://www.redhat.com/mailman/listinfo/redhat-list
>  > >
>  >
>  >
>  > --
>  > redhat-list mailing list
>  > unsubscribe
>  mailto:[EMAIL PROTECTED]
>  > https://www.redhat.com/mailman/listinfo/redhat-list
>
>
>  --
>  redhat-list mailing list
>  unsubscribe
mailto:[EMAIL PROTECTED]
>  https://www.redhat.com/mailman/listinfo/redhat-list
>


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: [RH List] RE: GRUB failure

[Otto Haliburton]

They both are there trust me. In RH8/9

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:redhat-list-
> [EMAIL PROTECTED] On Behalf Of Kenneth Goodwin
> Sent: Monday, August 04, 2003 2:44 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [RH List] RE: GRUB failure
> 
> I thought Kudzu was replaced by Anaconda I dont recall
> seeing it on my RH 8/9 systems
> but I may have been asleep at the console at the time...
> 
> 
> >  -Original Message-
> >  From: [EMAIL PROTECTED]
> >  [mailto:[EMAIL PROTECTED] Behalf Of Ashley
> M. Kirchner
> >  Sent: Monday, August 04, 2003 3:35 PM
> >  To: [EMAIL PROTECTED]
> >  Subject: Re: [RH List] RE: GRUB failure
> >
> >
> >  Kenneth Goodwin wrote:
> >
> >  >yOU DONT GET A BOOT time  MESSAGE ABOUTING CHECKING FOR
> new
> >  >hardware?
> >  >
> >  >
> >  That's kudzu's job, and it's been long removed.  (So
> the
> >  answer to
> >  your question is no, I don't.)
> >
> >  --
> >  W | I haven't lost my mind; it's backed up on tape
> somewhere.
> >
> >
> +---
> -
> >Ashley M. Kirchner <mailto:[EMAIL PROTECTED]>   .
> >  303.442.6410 x130
> >IT Director / SysAdmin / WebSmith .
> >  800.441.3873 x130
> >Photo Craft Laboratories, Inc.. 3550
> >  Arapahoe Ave. #6
> >http://www.pcraft.com . .  ..   Boulder, CO
> >  80303, U.S.A.
> >
> >
> >
> >
> >
> >  --
> >  redhat-list mailing list
> >  unsubscribe
> mailto:[EMAIL PROTECTED]
> >  https://www.redhat.com/mailman/listinfo/redhat-list
> >
> 
> 
> --
> redhat-list mailing list
> unsubscribe mailto:[EMAIL PROTECTED]
> https://www.redhat.com/mailman/listinfo/redhat-list


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: [RH List] RE: GRUB failure

[Kenneth Goodwin]

Every time I run Anaconda during installs, it does device
detection Probing.
"looking for hardware", does this mean it is silently
calling
kudzu underneath?
IMWTK  (Inquiring Minds Want To Know.)

>  -Original Message-
>  From: [EMAIL PROTECTED]
>  [mailto:[EMAIL PROTECTED] Behalf Of Michael
Schwendt
>  Sent: Monday, August 04, 2003 4:12 PM
>  To: [EMAIL PROTECTED]
>  Subject: Re: [RH List] RE: GRUB failure
>
>
>  -BEGIN PGP SIGNED MESSAGE-
>  Hash: SHA1
>
>  On Mon, 4 Aug 2003 15:43:38 -0400, Kenneth Goodwin wrote:
>
>  > I thought Kudzu was replaced by Anaconda I dont recall
>  > seeing it on my RH 8/9 systems
>  > but I may have been asleep at the console at the
time...
>
>  Kudzu and Anaconda are two separate things. The former is
a hardware
>  detection and configuration tool. The latter is Red Hat's
installer.
>
>  - --
>  -BEGIN PGP SIGNATURE-
>  Version: GnuPG v1.2.2 (GNU/Linux)
>
>
iD8DBQE/Lr4N0iMVcrivHFQRAot/AJ0WxUEmuAqkS35935l9GCrfkWTX/wCf
ZiZo
>  C8VW4t2C3Oxz6d9z2mV3lS4=
>  =yzwJ
>  -END PGP SIGNATURE-
>
>
>  --
>  redhat-list mailing list
>  unsubscribe
mailto:[EMAIL PROTECTED]
>  https://www.redhat.com/mailman/listinfo/redhat-list
>


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Kenneth Goodwin]

>  >
>  > Now Mike, This is not Fair! You cant keep changing the
>  > nomenclature
>  > like this, It just confuses my poor little brain...
>  > I thut I thaw a put-tee tat..
>
>  GRUB in MBR does not care at all whether the _next_ stage
is the
>  final stage as found in file /boot/grub/stage2 or whether
it is an
>  intermediate stage that loads another stage.
>
>  So, in the stage1 source code they call the next stage
>  "stage2", which
>  is the stage1.5 we've been referring to all the time.
It's that
>  intermediate stage1.5 which provides ext2 fs access and
>  hence can load
>  any ordinary file on GRUB's root partition.
>
>  The important thing to point out repeatedly is that if
stage1 (in
>  MBR) doesn't recognize any error upon determining drive
geometry and
>  upon loading the next stage, it doesn't print anything
else than
>  "GRUB ". And what can happen in stage1? In stage1 the
BIOS is used
>  to access the disk. CHS/LBA confusion, time-out waiting
for hda to
>  respond, what else?
>
It was a Joke Son, It was  A Joke  (Foghorn Leghorn)
We went from Stage 1 to Stage 1.5 to Stage 2 sequencing to

Stage 1 to Stage 2 to Stage  sequencing,, and you
probably confusing
a few of the younger crowd.

You and I are in agreement, the issue is with stage 1 - the
MBR boot program.
It loads and dies before launching Stage 1.5. I dont have
the RH 7.2 version of
the grub source to look at. Might have 7.1 levels. The MBR
is probably the same.
If you have source - What does it do after printing out
"GRUB", everything or
just a few last things before jumping to the newly loaded
image?


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: [RH List] RE: GRUB failure

[Michael Schwendt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 4 Aug 2003 15:43:38 -0400, Kenneth Goodwin wrote:

> I thought Kudzu was replaced by Anaconda I dont recall
> seeing it on my RH 8/9 systems
> but I may have been asleep at the console at the time...

Kudzu and Anaconda are two separate things. The former is a hardware
detection and configuration tool. The latter is Red Hat's installer.

- -- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/Lr4N0iMVcrivHFQRAot/AJ0WxUEmuAqkS35935l9GCrfkWTX/wCfZiZo
C8VW4t2C3Oxz6d9z2mV3lS4=
=yzwJ
-END PGP SIGNATURE-


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Ashley M. Kirchner]

Kenneth Goodwin wrote:

Oh, BTW I skipped from 7.1 to 8.0 and rapidly from there to
9.0
 

   I went 5.2 -> 6.2 -> 7.3 - and currently I have only one machine 
that has 8 on it.  None has 9...

--
W | I haven't lost my mind; it's backed up on tape somewhere.
 +
 Ashley M. Kirchner    .   303.442.6410 x130
 IT Director / SysAdmin / WebSmith . 800.441.3873 x130
 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6
 http://www.pcraft.com . .  ..   Boulder, CO 80303, U.S.A.




--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Kenneth Goodwin]

>
>  >I thought Kudzu was replaced by Anaconda I dont recall
>  >seeing it on my RH 8/9 systems
>  >but I may have been asleep at the console at the
time...
>  >
>  >
>  You skipped a post somewhere...the machine has 7.3 on
it.
>
>

actually i missed all the early ones and said so.
I only jump in when some poor soul like you
is being dragged around hell by the heels.

Oh, BTW I skipped from 7.1 to 8.0 and rapidly from there to
9.0
so 7.3 isnt even a faint happy memory. It never existed.



-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Michael Schwendt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 4 Aug 2003 15:40:53 -0400, Kenneth Goodwin wrote:

> >  In stage1 source code, the next stage is called stage2. ;)
> 
> 
> Now Mike, This is not Fair! You cant keep changing the
> nomenclature
> like this, It just confuses my poor little brain...
> I thut I thaw a put-tee tat..

GRUB in MBR does not care at all whether the _next_ stage is the
final stage as found in file /boot/grub/stage2 or whether it is an
intermediate stage that loads another stage.

So, in the stage1 source code they call the next stage "stage2", which
is the stage1.5 we've been referring to all the time. It's that
intermediate stage1.5 which provides ext2 fs access and hence can load
any ordinary file on GRUB's root partition.

The important thing to point out repeatedly is that if stage1 (in
MBR) doesn't recognize any error upon determining drive geometry and
upon loading the next stage, it doesn't print anything else than
"GRUB ". And what can happen in stage1? In stage1 the BIOS is used
to access the disk. CHS/LBA confusion, time-out waiting for hda to
respond, what else?

- -- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/Lru50iMVcrivHFQRAtjbAJwPU4SCTMXtbZRSfgvnvBNEThbC5gCfbm+h
v1qrbCK5S1MMno1+zvUxgmk=
=xr0f
-END PGP SIGNATURE-


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Ashley M. Kirchner]

Kenneth Goodwin wrote:

I thought Kudzu was replaced by Anaconda I dont recall
seeing it on my RH 8/9 systems
but I may have been asleep at the console at the time...
 

   You skipped a post somewhere...the machine has 7.3 on it.

--
W | I haven't lost my mind; it's backed up on tape somewhere.
 +
 Ashley M. Kirchner    .   303.442.6410 x130
 IT Director / SysAdmin / WebSmith . 800.441.3873 x130
 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6
 http://www.pcraft.com . .  ..   Boulder, CO 80303, U.S.A.




--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: [RH List] RE: GRUB failure

[Kenneth Goodwin]

I thought Kudzu was replaced by Anaconda I dont recall
seeing it on my RH 8/9 systems
but I may have been asleep at the console at the time...


>  -Original Message-
>  From: [EMAIL PROTECTED]
>  [mailto:[EMAIL PROTECTED] Behalf Of Ashley
M. Kirchner
>  Sent: Monday, August 04, 2003 3:35 PM
>  To: [EMAIL PROTECTED]
>  Subject: Re: [RH List] RE: GRUB failure
>
>
>  Kenneth Goodwin wrote:
>
>  >yOU DONT GET A BOOT time  MESSAGE ABOUTING CHECKING FOR
new
>  >hardware?
>  >
>  >
>  That's kudzu's job, and it's been long removed.  (So
the
>  answer to
>  your question is no, I don't.)
>
>  --
>  W | I haven't lost my mind; it's backed up on tape
somewhere.
>
>
+---
-
>Ashley M. Kirchner <mailto:[EMAIL PROTECTED]>   .
>  303.442.6410 x130
>IT Director / SysAdmin / WebSmith .
>  800.441.3873 x130
>Photo Craft Laboratories, Inc.. 3550
>  Arapahoe Ave. #6
>http://www.pcraft.com . .  ..   Boulder, CO
>  80303, U.S.A.
>
>
>
>
>
>  --
>  redhat-list mailing list
>  unsubscribe
mailto:[EMAIL PROTECTED]
>  https://www.redhat.com/mailman/listinfo/redhat-list
>


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Kenneth Goodwin]

>
>  On Mon, 04 Aug 2003 13:06:19 -0600, Ashley M. Kirchner
wrote:
>
>  > >If it doesn't print
>  > >an error message, it has loaded and jumped into stage2
either with
>  > >LBA or CHS geometry.
>  > >
>  > >
>  > I'm curious, where does stage1_5 come into play, if
>  what you're
>  > suggesting is that it jumps from stage1 to stage2?
>
>  In stage1 source code, the next stage is called stage2.
;)


Now Mike, This is not Fair! You cant keep changing the
nomenclature
like this, It just confuses my poor little brain...
I thut I thaw a put-tee tat..

So lets see, no stage 1.5 unless you are reading the grub
manual
by the light of the full moon under a pear tree, divide by
27,
carry the 2, divide again by four and multiply by PI
R-squared to the Nth power.
Lets seeh. Bing...Warp
Speed Mr Sulu..

Okay , so we have Stage 1 the MBR or Primary Boot Loader
which calls
Stage 2 the Main Boot Decision loader which calls Stage 3
the OS loader?

Or is it just Stage 1 and Stage 2 followed by the OS LOAD
and boot?
or it is Stage 1, 1.5 and 2 and carry the 3 if you are using
the same motherboard
as Ashley?


for the unwary -  CTS and CHS refer to the same thing

For really old ones like me, we refer to disk in terms of
Tracks,
which was the original nomenclature used with removal pack
disk drives
later generations like heads better, I guess they changed it
because
of Winchester technology


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: [RH List] RE: GRUB failure

[Ashley M. Kirchner]

Kenneth Goodwin wrote:

yOU DONT GET A BOOT time  MESSAGE ABOUTING CHECKING FOR new
hardware?
 

   That's kudzu's job, and it's been long removed.  (So the answer to 
your question is no, I don't.)

--
W | I haven't lost my mind; it's backed up on tape somewhere.
 +
 Ashley M. Kirchner    .   303.442.6410 x130
 IT Director / SysAdmin / WebSmith . 800.441.3873 x130
 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6
 http://www.pcraft.com . .  ..   Boulder, CO 80303, U.S.A.




--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Kenneth Goodwin]

yOU DONT GET A BOOT time  MESSAGE ABOUTING CHECKING FOR new
hardware?

tHERE IS A PIECE OF ANACONDA THAT IS THE ADMINISTRATOR WHICH
YOU
may have removed, but the hardware auto-detect piece
may be still installed. If it is, you get the "checking for
new hardware"
message on the console which is anaconda running on your
system.
Need to know because if it is totally purged, we know that
you did not cuase any config file changes through anaconda.
what do you remember about drive detection during the first
install of
drive B that might be a clue here?

>  -Original Message-
>  From: [EMAIL PROTECTED]
>  [mailto:[EMAIL PROTECTED] Behalf Of Ashley
M. Kirchner
>  Sent: Monday, August 04, 2003 2:31 PM
>  To: [EMAIL PROTECTED]
>  Subject: Re: GRUB failure
>
>
>  Kenneth Goodwin wrote:
>
>  >what I am saying is that the MBR may be crafted or
rebuild
>  >by anaconda
>  >for the two drive setup disk info. Anaconda may not be
able
>  >to go
>  >backwards here, may not be able to undo in a return to
>  >single drive
>  >configuration - most people add hardware, not remove it,
it
>  >may have
>  >not been a tested situation. "Something" changed on the
>  >linux system
>  >in response to the addition of the hard drive that is
not
>  >being undone
>  >when he reboots with only one drive installed.
>  >
>  >
>  This never occurred to me till now, but...the only
time
>  anaconda ran
>  and did anything, was when the system was first
installed.  Both
>  anaconda and kudzu get removed after installation.  I run
a
>  tight ship,
>  and don't like having packages installed that aren't
needed
>  for daily
>  operations, so they go.  When I added the second drive
months later,
>  what would cause any kind of configuration being redone,
or whatever
>  config file rewritten (other than me manually running
fdisk
>  and mkfs.ext3)?
>
>  --
>  W | I haven't lost my mind; it's backed up on tape
somewhere.
>
>
+---
-
>Ashley M. Kirchner <mailto:[EMAIL PROTECTED]>   .
>  303.442.6410 x130
>IT Director / SysAdmin / WebSmith .
>  800.441.3873 x130
>Photo Craft Laboratories, Inc.. 3550
>  Arapahoe Ave. #6
>http://www.pcraft.com . .  ..   Boulder, CO
>  80303, U.S.A.
>
>
>
>
>
>  --
>  redhat-list mailing list
>  unsubscribe
mailto:[EMAIL PROTECTED]
>  https://www.redhat.com/mailman/listinfo/redhat-list
>


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Kenneth Goodwin]

WOULD BE INTERESTING IF THEY BOTH HAVE THE SAME MOTHERBOARD
/ rom bios
NOW WOuLDNT IT..


>  -Original Message-
>  From: [EMAIL PROTECTED]
>  [mailto:[EMAIL PROTECTED] Behalf Of Otto
Haliburton
>  Sent: Monday, August 04, 2003 2:31 PM
>  To: [EMAIL PROTECTED]
>  Subject: RE: GRUB failure
>
>
>  This is different from the setup Ashley has but the
results are the
>  same.  I don't exactly know what that means but it
certainly means
>  something.
>
>  > -Original Message-
>  > From: [EMAIL PROTECTED] [mailto:redhat-list-
>  > [EMAIL PROTECTED] On Behalf Of Otto Haliburton
>  > Sent: Monday, August 04, 2003 1:25 PM
>  > To: [EMAIL PROTECTED]
>  > Subject: RE: GRUB failure
>  >
>  > I have a dual boot system with HDA containing XP PRO
and RH9 on HDB
>  > GRUB
>  > is the boot loader and it is written to the MBR or HDA
>  along with the
>  > XP
>  > boot loader.  I just removed HDB and guess what I got a
>  black screen
>  > with GRUB in the left hand corner.
>  >
>  > > -Original Message-
>  > > From: [EMAIL PROTECTED]
[mailto:redhat-list-
>  > > [EMAIL PROTECTED] On Behalf Of Michael Schwendt
>  > > Sent: Monday, August 04, 2003 12:59 PM
>  > > To: [EMAIL PROTECTED]
>  > > Subject: Re: GRUB failure
>  > >
>  > > -BEGIN PGP SIGNED MESSAGE-
>  > > Hash: SHA1
>  > >
>  > > On Mon, 4 Aug 2003 13:39:54 -0400, Kenneth Goodwin
wrote:
>  > >
>  > > > what I am saying is that the MBR may be crafted or
rebuild
>  > > > by anaconda for the two drive setup disk info.
>  > >
>  > > It's grub-install/grub that creates stage1 based on
the grub.conf
>  > > created by anaconda.
>  > >
>  > > > "Grub-install". which I have not seen admittedly,
may be based
>  > > > on a MAKE environment strategy. IF SO IT ONLY
REBUILDS The
>  > > > MBR if and only if some local disk file has changed
that a
>  > > > dependency has been declared for. It may not check
to see
>  > > > if the hardware environment changed. By cleansing
out the
>  > > > existing config
>  > > > info via a MAKE CLEAN or CLOBBER sequence , you
should force
>  > > > it to do a fresh
>  > > > rebuild from scratch on the MBR program which
should insert
>  > > > the new single drive related information. ie SO FAR
your
>  > > > newly written grub
>  > > > is the same image as the old grub that was on the
mbr to
>  > > > begin with.
>  > >
>  > > You can get rid of the generated files like this,
>  preferably after
>  > > removing slave drive and after booting with boot
disk:
>  > >
>  > >   rm /boot/grub/*1_5 /boot/grub/stage*
>  > >   grub-install --recheck --force-lba /dev/hda
>  > >
>  > > Option --force-lba might be interesting.
>  > >
>  > > - --
>  > > -BEGIN PGP SIGNATURE-
>  > > Version: GnuPG v1.2.2 (GNU/Linux)
>  > >
>  > >
iD8DBQE/Lp7Y0iMVcrivHFQRAoFkAJ0Z9nIV5jhIQgnmpDLuoJrbg43CgQCf
cEWT
>  > > LMknoC8k84oEiBhxdCtWxb0=
>  > > =y8mK
>  > > -END PGP SIGNATURE-
>  > >
>  > >
>  > > --
>  > > redhat-list mailing list
>  > > unsubscribe mailto:redhat-list-
>  > [EMAIL PROTECTED]
>  > > https://www.redhat.com/mailman/listinfo/redhat-list
>  >
>  >
>  > --
>  > redhat-list mailing list
>  > unsubscribe
mailto:[EMAIL PROTECTED]
> https://www.redhat.com/mailman/listinfo/redhat-list


--
redhat-list mailing list
unsubscribe
mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Kenneth Goodwin]

>  Kenneth Goodwin wrote:
>
>  >1 - this system had two IDE drives in it at Linux
>  >installation time.
>  >A (the MASTER) and B (The Slave), There is no SCSI, NO
>  >RAID, no LVM.  just a simple plain vanilla LINUX setup.
>  >
>  >
>
>  Nope.  The machine had ONE drive upon installation.
hdb wasn't
>  added till months later and was used only for storage of
>  backup files
>  (it doesn't even stay mounted all the time.)  This was
>  explained in a
>  previous email.
>

I stand corrected. I remember you now stating that,
sorry if I added to further confusion here,
but the correction does not change anything other than to
definitively prove your/our point that Drive B is not an
issue
in regards to GRUB. It is a side effect of it's removal from
the IDE Bus
that is behind your mystery and nothing else.

I think the Grub Developers might be interested in
discussing this with you.
Their code should not be having an issue here irregardless
of your
hardware changes. They probably have not come across
whatever the ROM BIOS
is presumably doing here before to mess things up. Maybe a
new grub tool
for floppy is in order here


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Otto Haliburton]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:redhat-list-
> [EMAIL PROTECTED] On Behalf Of Michael Schwendt
> Sent: Monday, August 04, 2003 2:12 PM
> To: [EMAIL PROTECTED]
> Subject: Re: GRUB failure
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Mon, 04 Aug 2003 13:06:19 -0600, Ashley M. Kirchner wrote:
> 
> > >If it doesn't print
> > >an error message, it has loaded and jumped into stage2 either with
> > >LBA or CHS geometry.
> > >
> > >
> > I'm curious, where does stage1_5 come into play, if what you're
> > suggesting is that it jumps from stage1 to stage2?
> 
> In stage1 source code, the next stage is called stage2. ;)
As I understand stage1_5 it is a sort of extension of stage1 i.e. since
stage1 is only 512 bytes long if some reason depending on the
architecture it will use stage1_5. I'm not totally clear on this but
that is the reason it is written to the area behind the MBR because that
is not used most of the time and it provides more space, but if for some
reason it can use that area then it just drops stage1_5 and goes
directly to stage2.  It really is not clear.  But in the mean time
Ashley you might need to upgrade your GRUB software if you want to solve
this particular problem because I don't think you will get the GRUB
developers to help you unless you are using the latest and the greatest.

> 
> - --
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.2 (GNU/Linux)
> 
> iD8DBQE/LrAS0iMVcrivHFQRAolhAJwNGFhjtYWA2WnGnHXGhL6tmEwBAQCeOW9W
> X7Xf//ENF73ShEow/UVizrI=
> =rjz6
> -END PGP SIGNATURE-
> 
> 
> --
> redhat-list mailing list
> unsubscribe mailto:[EMAIL PROTECTED]
> https://www.redhat.com/mailman/listinfo/redhat-list


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Kenneth Goodwin]

>
>  > what I am saying is that the MBR may be crafted or
rebuild
>  > by anaconda for the two drive setup disk info.
>
>  It's grub-install/grub that creates stage1 based on the
grub.conf
>  created by anaconda.
>
>  > "Grub-install". which I have not seen admittedly, may
be based
>  > on a MAKE environment strategy. IF SO IT ONLY REBUILDS
The
>  > MBR if and only if some local disk file has changed
that a
>  > dependency has been declared for. It may not check to
see
>  > if the hardware environment changed. By cleansing out
the
>  > existing config
>  > info via a MAKE CLEAN or CLOBBER sequence , you should
force
>  > it to do a fresh
>  > rebuild from scratch on the MBR program which should
insert
>  > the new single drive related information. ie SO FAR
your
>  > newly written grub
>  > is the same image as the old grub that was on the mbr
to
>  > begin with.
>
>  You can get rid of the generated files like this,
preferably after
>  removing slave drive and after booting with boot disk:
>
>rm /boot/grub/*1_5 /boot/grub/stage*
>grub-install --recheck --force-lba /dev/hda
>
>  Option --force-lba might be interesting.

Especially if the MBR was originally created to use LBA
based IO routines
and the drive now thinks it's is something other than LBA
mode
or vise versa..

In any case, good luck Ashley.contact the grub
developers with your problem. They might be interested.




-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Michael Schwendt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 4 Aug 2003 15:03:08 -0400, Kenneth Goodwin wrote:

>   Phase 1.5 - Grub OS Loader Part one (OS filesystem
> selector) Knows? os fs structures

That one would give considerably more status/error output,
in particular:

"GRUB loading, please wait..."

- -- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/LrGl0iMVcrivHFQRAqpsAJwMOy0/Dm+uSO8AwbdXlcnZp7/UbgCfcpIf
ciB38xOhXWdB6LZSQ+S9PgQ=
=9kov
-END PGP SIGNATURE-


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Michael Schwendt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 04 Aug 2003 13:06:19 -0600, Ashley M. Kirchner wrote:

> >If it doesn't print
> >an error message, it has loaded and jumped into stage2 either with
> >LBA or CHS geometry.
> >  
> >
> I'm curious, where does stage1_5 come into play, if what you're 
> suggesting is that it jumps from stage1 to stage2?

In stage1 source code, the next stage is called stage2. ;)

- -- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/LrAS0iMVcrivHFQRAolhAJwNGFhjtYWA2WnGnHXGhL6tmEwBAQCeOW9W
X7Xf//ENF73ShEow/UVizrI=
=rjz6
-END PGP SIGNATURE-


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Ashley M. Kirchner]

Michael Schwendt wrote:

If it doesn't print
an error message, it has loaded and jumped into stage2 either with
LBA or CHS geometry.
 

   I'm curious, where does stage1_5 come into play, if what you're 
suggesting is that it jumps from stage1 to stage2?

--
W | I haven't lost my mind; it's backed up on tape somewhere.
 +
 Ashley M. Kirchner    .   303.442.6410 x130
 IT Director / SysAdmin / WebSmith . 800.441.3873 x130
 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6
 http://www.pcraft.com . .  ..   Boulder, CO 80303, U.S.A.




--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Kenneth Goodwin]

Otto we are not on the same page, perhaps this will help.
This is (perhaps) my
(MIS)Understanding that from having written and worked with
such bootloaders
but not personal expertise with GRUB That Grub is organized
in a manner such as -

Phase 1 - Grub MBR 512 byte initial boot loader - knows how
to get to Phase 1.5 only.
Phase 1.5 - Grub OS Loader Part one (OS filesystem
selector) Knows? os fs structures
Phase 2 - Grub OS Loader Part Two (OS loader, knows
particular OS FS structures)

Phase 1 the GRUB MBR DOES NOT KNOW THE OS FILE STRUCTURES.
It is too small a program to hold that level of knowledge
It deals in RAW DISK ONLY through the ROM BIOS disk IO code
mechanism.
Loaded and executed by the ROM BIOS boot strap code.

GRUB Phase 1.5 and/or Phase 2.0 IS the piece of GRUB That
knows about the
OS File structures, etc as you have stated. loaded and
executed by Grub MBR/Phase 1/

Mike and I are working on the Premise that Phase 1 (MBR) can
not find the Phase 1.5 (OSFS)
image on DRIVE A in order to load it. The drive and offset
info are hard coded low
level device references from a HARDWARE, not OS perspective,
IE. IT does not
know what a /dev/hda is. It only knows "select Drive 0,
Start loading 20 sectors starting
at LBA 14,208 (or Cylind 10, track 5, sector 4) into low ram
and execute the program.
The initial fresh GRUB INSTALL stuffs Phase 1.5/Phase 2
images into /boot, converts
their partition relative locations into physical drive
offsets and stores the info the MBR needs
into the MBR image when it builds them.


What we are trying to say is that something happens when
Ashley removes the drive such that
the BIOS and/or the Hard Drive A no longer maps to either
Drive 0 or the
Image being at LBA 14,208. Therefore the MBR Phase One boot
loader
fails to be able to load in the Phase 1.5 Loader.
However this is an ASSUMPTION, we could be loading in Phase
1.5 and dieing
before it spits out any text. But Mike is not seeing
any output from Ashley's tests that would indicate that
Phase 1.5 actually loaded.

We are not executing the piece of Grub that needs to know
about FS structures or OS
versions at this point, just the piece that loads that
piece.

the device.map has no references to /dev/hdb.
The scsi devices are in the same state as when he had a
single drive
and the original two drive setup.
The only variable is the addition or removal of drive B and
reconfiguring
the Drive A drive select jumper from Master-Slave to Single
drive configurations.

So the question becomes why does the removal of a single
drive not related to
the boot process cause the boot process to fail?

Unless we can prove that Phase one is successfully loading
Phase 1.5 and that phase 1.5
is actually failing, we can only go on the assumption that
Phase 1, the MBR, is failing to
load Phase 1.5 into memory. The only reason this type of
failure would happen
if Suddenly the hard coded device references in the MBR no
longer map as they should
to either the drive's ide bus address or if the stored
LBA/CTS information no longer
maps to the same physical disk area because something in the
BIOS that tells the MBR/BIOS
disk io routines what the drive looks like and how to read
data off of it
has changed. So the MBR actually reads the wrong disk blocks
off the hard drive
and grub then crashes trying to execute an invalid Phase 1.5
image.

In any case, this is really a dead thread at this point,
being all theory
and no real proof. If Ashley wishes to persue
this for the common good, he needs to take all of this to
the Grub Developers
Group and have them help him figure out what is really going
on here.
It may be an issue that may need to be addressed in a future
Grub Version release
so that no one else gets burnt Grub in the future.

>  -Original Message-
>  From: [EMAIL PROTECTED]
>  [mailto:[EMAIL PROTECTED] Behalf Of Otto
Haliburton
>  Sent: Monday, August 04, 2003 1:00 PM
>  To: [EMAIL PROTECTED]
>  Subject: RE: GRUB failure
>
>
>  This is why you need to read the manual.  GRUB does know
the file
>  structures for the OS it boots the kernel for otherwise
it
>  chain loads
>  the boot loader for the other OS's.  Remember what GRUB
stands for.
>
>  > -Original Message-
>  > From: [EMAIL PROTECTED] [mailto:redhat-list-
>  > [EMAIL PROTECTED] On Behalf Of Kenneth Goodwin
>  > Sent: Monday, August 04, 2003 11:51 AM
>  > To: [EMAIL PROTECTED]
>  > Subject: RE: GRUB failure
>  >
>  > >  >
>  > >  > BIOS loads and starts the code from master boot
record,
>  > but code in
>  > >  > MBR fails to load stage1.5 which is located at a
fixed
>  > position on
>  > >  > hda. At that point, GRUB does not even know about
>  > >  "directories" yet,
>  > >  > since it is this later stage that would give
native
>  > access to ext2

Re: GRUB failure

[Michael Schwendt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 04 Aug 2003 12:33:26 -0600, Ashley M. Kirchner wrote:

> Otto Haliburton wrote:
> 
> >I have a dual boot system with HDA containing XP PRO and RH9 on HDB GRUB
> >is the boot loader and it is written to the MBR or HDA along with the XP
> >boot loader.  I just removed HDB and guess what I got a black screen
> >with GRUB in the left hand corner.
> >  
> >
> Welcome to my world.  At that point in the game, I doubt it even 
> knows about hdb, to even go find the config file.  It read the MBR, and 
> ... fell off the planet.

Great! It's reproducible on another machine. 

Now, if Otto is good, he modifies the short assembler code of stage1
and inserts a debug string to confirm that stage1 fails at the end
of copy_buffer where it executes the loaded stage2.

Stage1 starts with "GRUB " and certain error conditions given, it
prints only a very few and short error messages. If it doesn't print
an error message, it has loaded and jumped into stage2 either with
LBA or CHS geometry.

- -- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/Lq5v0iMVcrivHFQRAsPxAJ94QxAvwlpOroJYuH3yDyYYmY9DnQCfY5pk
q4cACFIXuiDiY8ICk9qZrZA=
=8V5w
-END PGP SIGNATURE-


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Ashley M. Kirchner]

Otto Haliburton wrote:

You've never said (that I can remember ) what version of RH you are
running.
   7.3

Also I want to note
that it is not a foregone conclusion that it calls stage1_5.  So we
don't know how far it gets into the process, it seems it would print an
error message if it discovered something which makes me think it just
branches off to never, never land.
 

   I prefer Lalaland.

--
W | I haven't lost my mind; it's backed up on tape somewhere.
 +
 Ashley M. Kirchner    .   303.442.6410 x130
 IT Director / SysAdmin / WebSmith . 800.441.3873 x130
 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6
 http://www.pcraft.com . .  ..   Boulder, CO 80303, U.S.A.




--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Otto Haliburton]

>
> >
> Welcome to my world.  At that point in the game, I doubt it even
> knows about hdb, to even go find the config file.  It read the MBR,
> and
> ... fell off the planet.
> 
> --
You've never said (that I can remember ) what version of RH you are
running.  If it is an old version then you may not be running the new
version of GRUB.  But in the manual there is a procedure you can thru to
manually reinstall GRUB interactively. The manual says that stage1 does
some things before it calls stage1_5 or stage2.  Also I want to note
that it is not a foregone conclusion that it calls stage1_5.  So we
don't know how far it gets into the process, it seems it would print an
error message if it discovered something which makes me think it just
branches off to never, never land.


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Ashley M. Kirchner]

Otto Haliburton wrote:

I have a dual boot system with HDA containing XP PRO and RH9 on HDB GRUB
is the boot loader and it is written to the MBR or HDA along with the XP
boot loader.  I just removed HDB and guess what I got a black screen
with GRUB in the left hand corner.
 

   Welcome to my world.  At that point in the game, I doubt it even 
knows about hdb, to even go find the config file.  It read the MBR, and 
... fell off the planet.

--
W | I haven't lost my mind; it's backed up on tape somewhere.
 +
 Ashley M. Kirchner    .   303.442.6410 x130
 IT Director / SysAdmin / WebSmith . 800.441.3873 x130
 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6
 http://www.pcraft.com . .  ..   Boulder, CO 80303, U.S.A.




--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Ashley M. Kirchner]

Kenneth Goodwin wrote:

what I am saying is that the MBR may be crafted or rebuild
by anaconda
for the two drive setup disk info. Anaconda may not be able
to go
backwards here, may not be able to undo in a return to
single drive
configuration - most people add hardware, not remove it, it
may have
not been a tested situation. "Something" changed on the
linux system
in response to the addition of the hard drive that is not
being undone
when he reboots with only one drive installed.
 

   This never occurred to me till now, but...the only time anaconda ran 
and did anything, was when the system was first installed.  Both 
anaconda and kudzu get removed after installation.  I run a tight ship, 
and don't like having packages installed that aren't needed for daily 
operations, so they go.  When I added the second drive months later, 
what would cause any kind of configuration being redone, or whatever 
config file rewritten (other than me manually running fdisk and mkfs.ext3)?

--
W | I haven't lost my mind; it's backed up on tape somewhere.
 +
 Ashley M. Kirchner    .   303.442.6410 x130
 IT Director / SysAdmin / WebSmith . 800.441.3873 x130
 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6
 http://www.pcraft.com . .  ..   Boulder, CO 80303, U.S.A.




--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Otto Haliburton]

This is different from the setup Ashley has but the results are the
same.  I don't exactly know what that means but it certainly means
something.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:redhat-list-
> [EMAIL PROTECTED] On Behalf Of Otto Haliburton
> Sent: Monday, August 04, 2003 1:25 PM
> To: [EMAIL PROTECTED]
> Subject: RE: GRUB failure
> 
> I have a dual boot system with HDA containing XP PRO and RH9 on HDB
> GRUB
> is the boot loader and it is written to the MBR or HDA along with the
> XP
> boot loader.  I just removed HDB and guess what I got a black screen
> with GRUB in the left hand corner.
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:redhat-list-
> > [EMAIL PROTECTED] On Behalf Of Michael Schwendt
> > Sent: Monday, August 04, 2003 12:59 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: GRUB failure
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On Mon, 4 Aug 2003 13:39:54 -0400, Kenneth Goodwin wrote:
> >
> > > what I am saying is that the MBR may be crafted or rebuild
> > > by anaconda for the two drive setup disk info.
> >
> > It's grub-install/grub that creates stage1 based on the grub.conf
> > created by anaconda.
> >
> > > "Grub-install". which I have not seen admittedly, may be based
> > > on a MAKE environment strategy. IF SO IT ONLY REBUILDS The
> > > MBR if and only if some local disk file has changed that a
> > > dependency has been declared for. It may not check to see
> > > if the hardware environment changed. By cleansing out the
> > > existing config
> > > info via a MAKE CLEAN or CLOBBER sequence , you should force
> > > it to do a fresh
> > > rebuild from scratch on the MBR program which should insert
> > > the new single drive related information. ie SO FAR your
> > > newly written grub
> > > is the same image as the old grub that was on the mbr to
> > > begin with.
> >
> > You can get rid of the generated files like this, preferably after
> > removing slave drive and after booting with boot disk:
> >
> >   rm /boot/grub/*1_5 /boot/grub/stage*
> >   grub-install --recheck --force-lba /dev/hda
> >
> > Option --force-lba might be interesting.
> >
> > - --
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1.2.2 (GNU/Linux)
> >
> > iD8DBQE/Lp7Y0iMVcrivHFQRAoFkAJ0Z9nIV5jhIQgnmpDLuoJrbg43CgQCfcEWT
> > LMknoC8k84oEiBhxdCtWxb0=
> > =y8mK
> > -END PGP SIGNATURE-
> >
> >
> > --
> > redhat-list mailing list
> > unsubscribe mailto:redhat-list-
> [EMAIL PROTECTED]
> > https://www.redhat.com/mailman/listinfo/redhat-list
> 
> 
> --
> redhat-list mailing list
> unsubscribe mailto:[EMAIL PROTECTED]
> https://www.redhat.com/mailman/listinfo/redhat-list


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Otto Haliburton]

I have a dual boot system with HDA containing XP PRO and RH9 on HDB GRUB
is the boot loader and it is written to the MBR or HDA along with the XP
boot loader.  I just removed HDB and guess what I got a black screen
with GRUB in the left hand corner.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:redhat-list-
> [EMAIL PROTECTED] On Behalf Of Michael Schwendt
> Sent: Monday, August 04, 2003 12:59 PM
> To: [EMAIL PROTECTED]
> Subject: Re: GRUB failure
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Mon, 4 Aug 2003 13:39:54 -0400, Kenneth Goodwin wrote:
> 
> > what I am saying is that the MBR may be crafted or rebuild
> > by anaconda for the two drive setup disk info.
> 
> It's grub-install/grub that creates stage1 based on the grub.conf
> created by anaconda.
> 
> > "Grub-install". which I have not seen admittedly, may be based
> > on a MAKE environment strategy. IF SO IT ONLY REBUILDS The
> > MBR if and only if some local disk file has changed that a
> > dependency has been declared for. It may not check to see
> > if the hardware environment changed. By cleansing out the
> > existing config
> > info via a MAKE CLEAN or CLOBBER sequence , you should force
> > it to do a fresh
> > rebuild from scratch on the MBR program which should insert
> > the new single drive related information. ie SO FAR your
> > newly written grub
> > is the same image as the old grub that was on the mbr to
> > begin with.
> 
> You can get rid of the generated files like this, preferably after
> removing slave drive and after booting with boot disk:
> 
>   rm /boot/grub/*1_5 /boot/grub/stage*
>   grub-install --recheck --force-lba /dev/hda
> 
> Option --force-lba might be interesting.
> 
> - --
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.2 (GNU/Linux)
> 
> iD8DBQE/Lp7Y0iMVcrivHFQRAoFkAJ0Z9nIV5jhIQgnmpDLuoJrbg43CgQCfcEWT
> LMknoC8k84oEiBhxdCtWxb0=
> =y8mK
> -END PGP SIGNATURE-
> 
> 
> --
> redhat-list mailing list
> unsubscribe mailto:[EMAIL PROTECTED]
> https://www.redhat.com/mailman/listinfo/redhat-list


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Ashley M. Kirchner]

Kenneth Goodwin wrote:

1 - this system had two IDE drives in it at Linux
installation time.
	A (the MASTER) and B (The Slave), There is no SCSI, NO
RAID, no LVM.  just a simple plain vanilla LINUX setup.
 

   Nope.  The machine had ONE drive upon installation.  hdb wasn't 
added till months later and was used only for storage of backup files 
(it doesn't even stay mounted all the time.)  This was explained in a 
previous email.

--
W | I haven't lost my mind; it's backed up on tape somewhere.
 +
 Ashley M. Kirchner    .   303.442.6410 x130
 IT Director / SysAdmin / WebSmith . 800.441.3873 x130
 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6
 http://www.pcraft.com . .  ..   Boulder, CO 80303, U.S.A.




--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Michael Schwendt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 4 Aug 2003 13:39:54 -0400, Kenneth Goodwin wrote:

> what I am saying is that the MBR may be crafted or rebuild
> by anaconda for the two drive setup disk info.

It's grub-install/grub that creates stage1 based on the grub.conf
created by anaconda.

> "Grub-install". which I have not seen admittedly, may be based
> on a MAKE environment strategy. IF SO IT ONLY REBUILDS The
> MBR if and only if some local disk file has changed that a
> dependency has been declared for. It may not check to see
> if the hardware environment changed. By cleansing out the
> existing config
> info via a MAKE CLEAN or CLOBBER sequence , you should force
> it to do a fresh
> rebuild from scratch on the MBR program which should insert
> the new single drive related information. ie SO FAR your
> newly written grub
> is the same image as the old grub that was on the mbr to
> begin with.

You can get rid of the generated files like this, preferably after
removing slave drive and after booting with boot disk:

  rm /boot/grub/*1_5 /boot/grub/stage* 
  grub-install --recheck --force-lba /dev/hda

Option --force-lba might be interesting.

- -- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/Lp7Y0iMVcrivHFQRAoFkAJ0Z9nIV5jhIQgnmpDLuoJrbg43CgQCfcEWT
LMknoC8k84oEiBhxdCtWxb0=
=y8mK
-END PGP SIGNATURE-


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Kenneth Goodwin]

>
>  I think this goes too far, and I don't see what it would
change.
>  IIRC, it has been mentioned that grub-install works
flawlessly when
>  slave drive is available and even when slave drive is
removed and
>  system is booted with bootdisk. However, the newly
written GRUB then
>  fails in MBR as soon as slave drive is not available.
>
>

this was in response solely to Ashleys GRUB_INSTALLS not
apparently
having an effect - this is only a theory, but it seems a
reasonable explanation
frogive me if I am redundant here

what I am saying is that the MBR may be crafted or rebuild
by anaconda
for the two drive setup disk info. Anaconda may not be able
to go
backwards here, may not be able to undo in a return to
single drive
configuration - most people add hardware, not remove it, it
may have
not been a tested situation. "Something" changed on the
linux system
in response to the addition of the hard drive that is not
being undone
when he reboots with only one drive installed.

If the contents of the MBR in regards to the location of the
Phase 1.5 image
are the real issue here, then replacing it with a freshly
rebuilt version would
be required in order to correct the issue.

"Grub-install". which I have not seen admittedly, may be
based
on a MAKE environment strategy. IF SO IT ONLY REBUILDS The
MBR
if and only if some local disk file has changed that a
dependency
has been declared for. It may not check to see
if the hardware environment changed. By cleansing out the
existing config
info via a MAKE CLEAN or CLOBBER sequence , you should force
it to do a fresh
rebuild from scratch on the MBR program which should insert
the new single drive related information. ie SO FAR your
newly written grub
is the same image as the old grub that was on the mbr to
begin with.
You may have changed nothing by running grub-install in
regards to the MBR
image on sector 0. Ashley just rewrote the same 512 byte
block over and over again.

To rephrase, What I am saying is the copy of the MBR on
drive A is the same as the copy
of the MBR image on /boot that grub-install stuffs back onto
the MBR,
so all the grub installs changed nothing, just rewrote the
same info
over and over again unchanged for the new single drive
configuration
he was trying to configure for.. Popping the hard drive
on/off
changes the underlying hardware/bios info such that it
matched/"did not match" the
contents of the MBR. So it worked any time he had the drive
configuration
matching the corresponding info in the MBR.

One would need to rebuild the MBR based on the new single
drive architecture to
correct this issue - recompile from sources as it were after
booting to a single drive setup.


The boot floppy does not use the MBR, It is the MBR and
probably phase 1.5 as well
all rolled into one. So if you boot from it, you will boot
linux  from /boot directly
then do your grub-install which may just be writting the
same 512 byte image into the
MBR as IS ALREADY THERE.

I hope this is now clear


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Otto Haliburton]

This is why you need to read the manual.  GRUB does know the file
structures for the OS it boots the kernel for otherwise it chain loads
the boot loader for the other OS's.  Remember what GRUB stands for.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:redhat-list-
> [EMAIL PROTECTED] On Behalf Of Kenneth Goodwin
> Sent: Monday, August 04, 2003 11:51 AM
> To: [EMAIL PROTECTED]
> Subject: RE: GRUB failure
> 
> >  >
> >  > BIOS loads and starts the code from master boot record,
> but code in
> >  > MBR fails to load stage1.5 which is located at a fixed
> position on
> >  > hda. At that point, GRUB does not even know about
> >  "directories" yet,
> >  > since it is this later stage that would give native
> access to ext2
> >  > fs. The reason that GRUB fails to access hda can be
> that
> >  BIOS uses a
> >  > different method to access the drive, while GRUB maybe
> gets a wrong
> >  > drive Id and hence fails to find hda.
> >  >
> >  > However, Ashley has mentioned that this computer has
> been working
> >  > fine with a single drive for several months until hdb
> was added.
> >  > Only when hdb was removed, it started to malfunction.
> So, if it's
> >  > not a BIOS thing that confuses GRUB, I don't see why
> GRUB
> >  would fail
> >  > loading from hda.
> >
> >  You haven't gotten the point of the question.  GRUB is in
> >  the MBR from
> >  the install.  It has a location to get to the GRUB
> directory to load
> >  stage1 (we know that stage1 and stage2 and all other
> things
> >  are in the
> >  GRUB directory look them up yourself).  So it locates the
> >  GRUB directory
> >  to load stage1 then why would it now lose that location
> to
> >  load stage2.
> 
> 
> GRUB MBR DOES NOT KNOW LINUX DIRECTORY STRUCTURES
> GRUB MBR DOES NOT KNOW EXTFS Filesystems
> 
> 
> ALL IT KNOWS is an PHYSICal offset into the disk to start
> reading from and a count
> of bytes to read. This is very low level stuff. where it is
> reading from on the drive
> is not where the phase 1.5 is. (Or phase 1.5 is having  a
> similiar issue itself
> 
> 
> --
> redhat-list mailing list
> unsubscribe mailto:[EMAIL PROTECTED]
> https://www.redhat.com/mailman/listinfo/redhat-list


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Kenneth Goodwin]

>  >
>  > BIOS loads and starts the code from master boot record,
but code in
>  > MBR fails to load stage1.5 which is located at a fixed
position on
>  > hda. At that point, GRUB does not even know about
>  "directories" yet,
>  > since it is this later stage that would give native
access to ext2
>  > fs. The reason that GRUB fails to access hda can be
that
>  BIOS uses a
>  > different method to access the drive, while GRUB maybe
gets a wrong
>  > drive Id and hence fails to find hda.
>  >
>  > However, Ashley has mentioned that this computer has
been working
>  > fine with a single drive for several months until hdb
was added.
>  > Only when hdb was removed, it started to malfunction.
So, if it's
>  > not a BIOS thing that confuses GRUB, I don't see why
GRUB
>  would fail
>  > loading from hda.
>
>  You haven't gotten the point of the question.  GRUB is in
>  the MBR from
>  the install.  It has a location to get to the GRUB
directory to load
>  stage1 (we know that stage1 and stage2 and all other
things
>  are in the
>  GRUB directory look them up yourself).  So it locates the
>  GRUB directory
>  to load stage1 then why would it now lose that location
to
>  load stage2.


GRUB MBR DOES NOT KNOW LINUX DIRECTORY STRUCTURES
GRUB MBR DOES NOT KNOW EXTFS Filesystems


ALL IT KNOWS is an PHYSICal offset into the disk to start
reading from and a count
of bytes to read. This is very low level stuff. where it is
reading from on the drive
is not where the phase 1.5 is. (Or phase 1.5 is having  a
similiar issue itself


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Michael Schwendt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 4 Aug 2003 12:26:05 -0400, Kenneth Goodwin wrote:

> ASHLEY -   Your grub issue may be that
> 
> grub-install may only install an already compiled and loaded
> version of the
> MBR phase one piece. YOU MAy have to do a GRUB Make to
> rebuild the
> MBR piece with the new system architecture taken into
> account..
> Ie you were just  installing the same MBR as the existing
> one, when what you need to
> do is build a new single drive version of the MBR and
> install that.
> 
> In a standard MAKE environment, Make install only rebuilds
> the
> executables if the sources they depend on have changed.
> otherwise
> they just install the compiled binary image already in the
> directory
> from the last full build.
> 
> In your case, you need to do the GRUB equiivalent of a "Make
> clean"
> which purges all the binarys and the executables
> and then a "make install" to built the new binaries and
> install them.
> 
> Michael S may know how to direct you there as he seems to
> have more grub expertise than I
> and may know the rebuild from scratch commands required.

I think this goes too far, and I don't see what it would change.
IIRC, it has been mentioned that grub-install works flawlessly when
slave drive is available and even when slave drive is removed and
system is booted with bootdisk. However, the newly written GRUB then
fails in MBR as soon as slave drive is not available.

How about trying LILO just to see how it behaves?

Install the lilo package, create /etc/lilo.conf, probably 
like this,

boot=/dev/hda
lba32
prompt
timeout=10
default=linux
image=/boot/2.4.20-18.7smp
  initrd=/boot/initrd-2.4.20-18.7smp.img
  label=linux
  read-only
  root=/dev/hda1

then install with "lilo -v". Might be interesting.

- -- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/Lo+P0iMVcrivHFQRAkDTAJ9KwpBYembnoJqP1Fk7yAygOf6KrwCeN8n8
FR9opvjhrjsejWelnEjDIyE=
=OTLU
-END PGP SIGNATURE-


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Kenneth Goodwin]

>
>  >To those of you, who have the theory that GRUB is
loading stage1
>  > and can't load stage2 answer the question, "how it can
>  find stage1 and
>  > then can't find stage2?", when both are in the same
GRUB
>  directory.  It
>  > can not find the GRUB directory period.
>
>  BIOS loads and starts the code from master boot record,
but code in
>  MBR fails to load stage1.5 which is located at a fixed
position on
>  hda. At that point, GRUB does not even know about
"directories" yet,
>  since it is this later stage that would give native
access to ext2
>  fs. The reason that GRUB fails to access hda can be that
BIOS uses a
>  different method to access the drive, while GRUB maybe
gets a wrong
>  drive Id and hence fails to find hda.
>
>  However, Ashley has mentioned that this computer has been
working
>  fine with a single drive for several months until hdb was
added.
>  Only when hdb was removed, it started to malfunction. So,
if it's
>  not a BIOS thing that confuses GRUB, I don't see why GRUB
would fail
>  loading from hda.
>

I would presume when he added in the second drive, Anaconda
or something similiar came along and made the necessary
internal reference adjustments for the drive changes
that occured. maybe its not smart enough
to back them out when he pops the drive out.
Maybe its 1.5 that fails before it prints out a message?

In any case, talking is not going to find the cause,
He would need to debug it with grub itself
and playin garound with things
and it is a moot point to Ahsley for the moment as his
system is now operational again.

It would nice to know what the cause is so fixes could be
implemented
for future considerations.


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Otto Haliburton]

By your response you have failed to read the GRUB manual.  I will say no
further until you read it.  Some points I will concede up to 11.  Stage
1 is hard coded in the mbr or track 0. It is 512 bytes.  It loads
stage1_5 which can be located behind the MBR or in "boot" partition or
it loads part of stage2 partition which when loaded will load itself
fully.  As far as changing the disk geometry and etc. GRUB was designed
to handle any such situation and that's why you need to read the manual
that I pointed to in a later email.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:redhat-list-
> [EMAIL PROTECTED] On Behalf Of Kenneth Goodwin
> Sent: Monday, August 04, 2003 11:18 AM
> To: [EMAIL PROTECTED]
> Subject: RE: GRUB failure
> 
> Otto  -I think you are missing the big picture here and
> Ashley can confirm it or
> disprove me -
> 
> 1 - this system had two IDE drives in it at Linux
> installation time.
>   A (the MASTER) and B (The Slave), There is no SCSI, NO
> RAID, no LVM.
> just a simple plain vanilla LINUX setup.
> 
> 2 - Linux was installed in its entirety along with grub as
> the
> boot loader onto Drive A
> 
> 3 - NOTHING was loaded onto Drive B at time of linux
> installation.
> 
> 4 - Drive B was later used to store files and such.
> 
> 5 - GRUB NEVER used any part of DRIVE B at any time during
> it's lifetime It ONLY used
> the contents of DRIVE A to boot from.
> 
> 6 - DRIVE B Crashed. Upon removal of drive b from the ide
> chain, Ashley found HIMSELF
> with a totally unbootable system for absolutely no sane
> reason. The only drive he needed
> for booting was Drive A which was still intact.
> 
> 7 - this is proven by the addition of a replacement BLANK
> Drive
> B which then cured his system.
> 
> 8 - GRUB is not trying to load anything from Drive B. The
> Phase one half of GRUB ,
> stored on the boot block of Drive A (MBR), can not find the
> Phase 1.5 part of Grub
> also stored on drive A because it's concept of
> where that information is stored has been altered by the
> ROM BIOS's changed perception
> of the drive layout info for Drive A. This changed
> perception , probably the
> address of the drive or its geometry, is being caused by the
> changes in
> the drive select jumpers required by DRIVE A
> when a SLAVE drive is removed or added onto the chain.
> 
> 9 - The system can ALWAYS load the MBR because it is always
> on BLOCK 0
> or Cylinder Track and Sector 0
> on the disk drive. It is a known fixed location which does
> not change
> even if drive geometrys are changed. The ROM BIOS on the
> Motherboard loads
> this single disk block into RAM and executes it.
> It prints out "GRUB" to let you know it is there, then
> attempts to locate the /boot partition start on the hard
> drive to load Phase 1.5 which is the real OS Bootstrap
> program.
> 
> 10 - The MBR "KNOWS" where phase 1.5 is because the location
> of the start of the
> the /boot partition and phase 1.5 is HARDCODED into the MBR
> program when it is
> built and placed on the boot block.
> The MBR merely know to go some far into the disk and read.
> If You change the offset of /boot on the harddrive
> by resizing the parition spaces between cylinder 0 and where
> ever /boot originally started at
> you trash the MBR's ability to find Phase 1.5 for the same
> reason - you relocated Phase 1.5
> on the drive and did not tell the MBR. The MBR uses the same
> IO code the DOS bootstraps
> use and has their same constraints about maximum Logical
> block or
> CTS values.
> 
> 11 - the issue here is that somehow removing the drive b and
> changing the drive select
> on DRIVE A changes
> where everything but where block 0 is located on the disk
> drive. I dont know why, have
> not read the GRUB sources or how as
> I cant see his machine - his drives would normally be
> LOGICAL BLOCK ADDRESSED,maybe
> CTS addressed, but somehow, and only Ashley can figure this
> out, the BIOS view of
> the drive changes when he changes the drive select jumper.
> And it is the BIOS DISK IO routines
> that are normally used by the MBR boot strap to read the
> disk contents.
> The MBR is a sector long program which means at best it can
> be 512 bytes long.
> 
> Lets take this to a CTS (Cylinder TRACK and SECTOR) View of
> the hard drive -
> I dont know if you program, but if you do -
> View CTS as indices into a three dimensional Matrix. The
> base address of the matrix
> is always at the same address no matter what.
> Think of Cylinders are Rings on a Tree, Tracks as fixed
> horizontal slices
> through the tree (like slicing a banana,) and sectors as pie
&g

RE: GRUB failure

[Kenneth Goodwin]

>  - set hda's jumper back to master otherwise BIOS
>  complains and won't
>  boot
>  - shoved floppy in, booted up just fine
>  - ran grub-install /dev/hda, no errors
>  - removed floppy, reboot
>  - BIOS finds hda, knows there's no hdb, goes on to
boot
>  - black screen, with 'GRUB' in the corner: system
dead
>
>  I ran the same cycle again, this time issuing:
> grub-install --root-directory=/boot '(hd0)'
>  as the info page suggests.  Same result, won't boot,
dead system.
>


ASHLEY -   Your grub issue may be that

grub-install may only install an already compiled and loaded
version of the
MBR phase one piece. YOU MAy have to do a GRUB Make to
rebuild the
MBR piece with the new system architecture taken into
account..
Ie you were just  installing the same MBR as the existing
one, when what you need to
do is build a new single drive version of the MBR and
install that.

In a standard MAKE environment, Make install only rebuilds
the
executables if the sources they depend on have changed.
otherwise
they just install the compiled binary image already in the
directory
from the last full build.

In your case, you need to do the GRUB equiivalent of a "Make
clean"
which purges all the binarys and the executables
and then a "make install" to built the new binaries and
install them.

Michael S may know how to direct you there as he seems to
have more grub expertise than I
and may know the rebuild from scratch commands required.




-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Kenneth Goodwin]

 nothing once the drive select jumpers
change to BIOS's
idea of what the drive controller address should be. The
disk used to be IDE1DriveM,
now its IDE1DriveOnly. The mbr still is looking for
IDE1DriveM
which no longer exists.

The bottom line is his issue is not with GRUB, but with his
motherboard and the particular drives he is using.
The cure may lie in a  FIRMWARE upgrade or in finding a way
to regenerate the MBR
in the new configuration in the same manner
as it is created during the install process. to reset the
now incorrect
references to their new equivalents.


THe Phase 1 MBR cant find the phase 1.5 piece not because it
is on DRIVE B
but because it is now looking in the wrong space on  drive A
because the perception of
drive A has changed either in it's address it's layout so
the ROM BIOS routines
essentially read the wrong information off the drive (say
the contents of /etc/passwd
instead of the phase 1.5 bootstrap program and then try to
execute non-code and crash.

You would have to play with his system and GRUB to figure
exactly what has
changed. One can only guess otherwise.


>  -Original Message-
>  From: [EMAIL PROTECTED]
>  [mailto:[EMAIL PROTECTED] Behalf Of Otto
Haliburton
>  Sent: Sunday, August 03, 2003 5:13 AM
>  To: [EMAIL PROTECTED]
>  Subject: RE: GRUB failure
>
>
>
>  Hi all,
>   We have all been ignoring one fact and that is for some
reason
>  GRUB is loading part of the boot loader on the second
drive.  It
>  apparently thinks that linux is on the second drive.  A
>  setup where the
>  boot loader is on the MBR of drive A but linux is on
drive B
>  so that the
>  boot is A -> B -> A.  Ashley while I believe you when you
>  say that there
>  is nothing on drive B would you post a fdisk listing of
partitions on
>  drive b.  In the meantime, you can remove drive b and
boot
>  from floppy
>  and then reinstall GRUB with B removed from the system
and note any
>  error messages that install prints when this occurs
because either it
>  will install successfully or it will fail with error
messages.
>
>   To those of you, who have the theory that GRUB is
loading stage1
>  and can't load stage2 answer the question, "how it can
find
>  stage1 and
>  then can't find stage2?", when both are in the same GRUB
>  directory.  It
>  can not find the GRUB directory period.
>
>
>  --
>  redhat-list mailing list
>  unsubscribe
mailto:[EMAIL PROTECTED]
>  https://www.redhat.com/mailman/listinfo/redhat-list
>


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Kenneth Goodwin]

Ashley

Are the drive  Manufacturers different?
Although EIDE is supposed to be a standard
manufacturers will tend to do their own thing in regards to
jumpers and how things behave.
You could be running into such an issue here and it will
affect how the drives respond
on the control line/ide-cmd responses to the BIOS reset and
query sequences.

You see on a normal EIDE drive, you should have either had
to change jumpers to  single drive mode
or leave it as master. It should not impact what the drive
looks like or is addressed
as being the master. The jumpers control only the drives
behaviour in response to the drive select lines.

In any case, the consensus seems to be at the moment, that
the issue here is how the
BIOS perceives the layout and/or addressing for your master
drive when you change
configurations between master-slave  and single drive
setups. It seems to be a BIOS or drive firmware issue. There
may be nothing you can do to cure it. Using drives from the
same
manufacturer may help as it is the drives that interact
based on master slave. The controller just
turns on a  drive select bit hooked to a control cable lead
usually to select one or the other
drive. -the drives/jumpers determine who responses as master
or slave. with the same
manufacturer you can generally be assured that the drives
will behave in the same way.
Your A drive is apparently a model in which the drive has to
BE Single, Master or Slave
some drives allow for MAster to also be the definition for
single
On top of this your MB bios seems to have a feature by which
it's on board ide controllers
treats a single drive setup differently from a dual drive
setup, changing the perceive drive addressing enough to
confuse grub phase 1

The only real concrete suggestion possible here is to make
sure your motherboard and the drives ide controller firmware
are all up to the latest revision levels. Dont assume just
because
you bought it a short tiem ago it will be because it might
have been on the shelf for a year
and be down two revisions from the current level.

there might be a way to get grub to rebuild it's MBR boot
strap based on the single drive configuration if you setup a
floppy/cdrom boot program to do that. short of a partial
reinstall of Linux
restricted to just the MBR

>  -Original Message-
>  From: [EMAIL PROTECTED]
>  [mailto:[EMAIL PROTECTED] Behalf Of Ashley
M. Kirchner
>  Sent: Sunday, August 03, 2003 4:37 AM
>  To: [EMAIL PROTECTED]
>  Subject: Re: GRUB failure
>
>
>  brian davison wrote:
>
>  >Ashley...  try not changing the drive to single...
leave
>  it as the Master.
>  >( as in  "don't change the jumper when removing the
second drive")
>  >
>  >
>  No can do.  hda has three settings on it: Master,
Master
>  w/ Slave,
>  and Slave.  Since hdb was installed, it's been set to
Master
>  w/ Slave
>  (leaving it as Master resulted in hdb not being detected
by
>  the BIOS.)
>   Consequently, removing hdb without changing the jumper
on
>  hda resulted
>  in the machine not booting because the BIOS expected a
slave
>  since hda's
>  jumper was set as such.
>
>  Mind you, I've played with this a whole lot already,
and it just
>  doesn't work with just leaving the jumper alone and not
>  changing it.  If
>  I leave it set to Master, the BIOS won't see hdb.  If I
leave it on
>  Master w/ Slave, the BIOS complains about not seeing a
slave
>  (when hdb
>  gets removed.)  So I had to change that anyway.
>
>  PS: Ashley's a guy.
>
>  --
>  H| I haven't lost my mind; it's backed up on tape
somewhere.
>
>
+---
-
>Ashley M. Kirchner <mailto:[EMAIL PROTECTED]>   .
>  303.442.6410 x130
>IT Director / SysAdmin / WebSmith .
>  800.441.3873 x130
>Photo Craft Laboratories, Inc.. 3550
>  Arapahoe Ave. #6
>http://www.pcraft.com . .  ..   Boulder, CO
>  80303, U.S.A.
>
>
>
>
>
>  --
>  redhat-list mailing list
>  unsubscribe
mailto:[EMAIL PROTECTED]
>  https://www.redhat.com/mailman/listinfo/redhat-list
>


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Otto Haliburton]

BTW -- "Life is not an exact science, but only an approximation.  If it
was an exact science then we all would be unhappy because of our own
imperfections"

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:redhat-list-
> [EMAIL PROTECTED] On Behalf Of Otto Haliburton
> Sent: Monday, August 04, 2003 2:42 AM
> To: [EMAIL PROTECTED]
> Subject: RE: GRUB failure
> 
> 
> 
> > Otto,  you may be missing this point..
> > Grub isn't loading anything.
> > Bios is loading the MBR  from the drive.
> > this mbr.. part of grub is being called stage 1.
> >
> Yes, this is correct if you read the latter parts of the manual that I
> published then you know that stage1 is 512 bytes long so it doesn't do
> much except either load stage1_5 or stage2. but in the manual it
> listed
> the error messages from each stage and the output reported doesn't
> fall
> into any of the categories reported.  And it also rules out any
> geometry
> change, etc... The possibility it left open is that it is not able to
> resolve how the bios reports the disk so it guesses and then uses it
> device map to resolve the issue and it says it can be quite wrong
> about
> this guess.   So I'm suggesting that everyone reload, read the manual
> and go from there.  Also I'm noting Ashley's response to this email.
> 
> 
> --
> redhat-list mailing list
> unsubscribe mailto:[EMAIL PROTECTED]
> https://www.redhat.com/mailman/listinfo/redhat-list


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Otto Haliburton]

> Otto,  you may be missing this point..
> Grub isn't loading anything.
> Bios is loading the MBR  from the drive.
> this mbr.. part of grub is being called stage 1.
> 
Yes, this is correct if you read the latter parts of the manual that I
published then you know that stage1 is 512 bytes long so it doesn't do
much except either load stage1_5 or stage2. but in the manual it listed
the error messages from each stage and the output reported doesn't fall
into any of the categories reported.  And it also rules out any geometry
change, etc... The possibility it left open is that it is not able to
resolve how the bios reports the disk so it guesses and then uses it
device map to resolve the issue and it says it can be quite wrong about
this guess.   So I'm suggesting that everyone reload, read the manual
and go from there.  Also I'm noting Ashley's response to this email.


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Ashley M. Kirchner]

brian davison wrote:

with the additional info from Mr. Kirchner, that the board has scsi
interface on board, I wonder if it also has a self modifying portion in its
cmos... (I've seen a couple of these)  where it keeps track of the scsi
devices and bootability. 
 

   Good theory, except I have the SCSI bus disabled in BIOS, so it's 
not scanning it.  At least, it *shouldn't* be.

--
H| I haven't lost my mind; it's backed up on tape somewhere.
 +
 Ashley M. Kirchner    .   303.442.6410 x130
 IT Director / SysAdmin / WebSmith . 800.441.3873 x130
 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6
 http://www.pcraft.com . .  ..   Boulder, CO 80303, U.S.A. 





--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[brian davison]

>You haven't gotten the point of the question.  GRUB is in the MBR from
>the install.  It has a location to get to the GRUB directory to load
>stage1 (we know that stage1 and stage2 and all other things are in the
>GRUB directory look them up yourself).  So it locates the GRUB directory
>to load stage1 then why would it now lose that location to load stage2.
>> 
>
Otto,  you may be missing this point..  
Grub isn't loading anything.
Bios is loading the MBR  from the drive.   
this mbr.. part of grub is being called stage 1.

with the additional info from Mr. Kirchner, that the board has scsi
interface on board, I wonder if it also has a self modifying portion in its
cmos... (I've seen a couple of these)  where it keeps track of the scsi
devices and bootability. 
 When there are two devices on the ide interface, one of the first two is
the boot device,  when only one ide is present then the search in bios
continues on to the scsi interface.  If the scsi interface has something it
has ever registered, this may be seen as another bootable device, or in some
other way change the base addressing of the drives.   
Linux doesn't use bios to access the drives past the initial bootloader
stages, and thus could ignore bios addressing problems if booting from
floppy, (or cd), because it doesn't have to go to the hard drive for
booting.  If there are two ide devices, the bios shouldn't  (yes I know
there are new ones not following these old guidelines) even look at the scsi
interface in search of boot points.
this posibility could be tested if there were a utility to reset the scsi
device tables, or even just to read them.
Oh well, now that its a moot point. I'll never have my curiosity
satisfied   (good thing I'm not a cat!)
brian  :)  ;}
**
---
 [EMAIL PROTECTED]


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Ashley M. Kirchner]

Bret Hughes wrote:

Just curious what is in the device.map file?  This is where grub assigns
device numbers used in grub.conf.  I don't know if this is used in the
installation of grub on the mbr or after but since I don't remember
anything about this I thought I would ask.  If it was posted already I
appologize.
   This was posted already, but here it is again:

   # this device map was generated by anaconda
   (fd0) /dev/fd0
   (hd0) /dev/hda
--
H| I haven't lost my mind; it's backed up on tape somewhere.
 +
 Ashley M. Kirchner    .   303.442.6410 x130
 IT Director / SysAdmin / WebSmith . 800.441.3873 x130
 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6
 http://www.pcraft.com . .  ..   Boulder, CO 80303, U.S.A. 





--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Otto Haliburton]

This is excerpts from the GNU GRUB manual.  The manual suggests that you
may have a problem with the device map in /boot/grub (this maybe where
it is located).  It says that GRUB doesn't know how to translate from
bios disk to OS designations so it uses the device map in the grub
directory. So Ashley you might check that out to see if it is corrupted
or contains hdb which is causing a problem when you remove the device.

The grub manual is located at http://www.gnu.org/manual/grub/index.html
GRUB features
=

Recognize multiple executable formats

Support non-Multiboot kernels

Load multiples modules

Load a configuration file

Provide a menu interface

Have a flexible command-line interface

Support multiple filesystem types
 Support multiple filesystem types transparently, plus a useful
 explicit blocklist notation. The currently supported filesystem
 types are "BSD FFS", "DOS FAT16 and FAT32", "Minix fs", "Linux
 ext2fs", "ReiserFS", "JFS", "XFS", and "VSTa fs". *Note
 Filesystem::, for more information.

Support automatic decompression

Access data on any installed device
 Support reading data from any or all floppy or hard disk(s)
 recognized by the BIOS, independent of the setting of the root
 device.

Be independent of drive geometry translations
 Unlike many other boot loaders, GRUB makes the particular drive
 translation irrelevant. A drive installed and running with one
 translation may be converted to another translation without any
 adverse effects or changes in GRUB's configuration.

Detect all installed RAM

Support Logical Block Address mode
 In traditional disk calls (called "CHS mode"), there is a geometry
 translation problem, that is, the BIOS cannot access over 1024
 cylinders, so the accessible space is limited to at least 508 MB
 and to at most 8GB. GRUB can't universally solve this problem, as
 there is no standard interface used in all machines. However,
 several newer machines have the new interface, Logical Block
 Address ("LBA") mode. GRUB automatically detects if LBA mode is
 available and uses it if available. In LBA mode, GRUB can access
 the entire disk.

Support network booting
 GRUB is basically a disk-based boot loader but also has network
 support. You can load OS images from a network by using the "TFTP"
 protocol.

Support remote terminals

Errors reported by the Stage 1
==

   The general way that the Stage 1 handles errors is to print an error
string and then halt. Pressing `--' will reboot.

   The following is a comprehensive list of error messages for the
Stage 1:

Hard Disk Error
 The stage2 or stage1.5 is being read from a hard disk, and the
 attempt to determine the size and geometry of the hard disk failed.

Floppy Error
 The stage2 or stage1.5 is being read from a floppy disk, and the
 attempt to determine the size and geometry of the floppy disk
 failed. It's listed as a separate error since the probe sequence
 is different than for hard disks.

Errors reported by the Stage 1.5


   The general way that the Stage 1.5 handles errors is to print an
error number in the form `Error NUM' and then halt. Pressing
`--' will reboot.

   The error numbers correspond to the errors reported by Stage 2.
*Note Stage2 errors::.

Errors reported by the Stage 2
==

   The general way that the Stage 2 handles errors is to abort the
operation in question, print an error string, then (if possible) either
continue based on the fact that an error occurred or wait for the user
to deal with the error.

   The following is a comprehensive list of error messages for the
Stage 2 (error numbers for the Stage 1.5 are listed before the colon in
each description):




-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Otto Haliburton]

thanks

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:redhat-list-
> [EMAIL PROTECTED] On Behalf Of Michael Schwendt
> Sent: Sunday, August 03, 2003 1:39 PM
> To: [EMAIL PROTECTED]
> Subject: Re: GRUB failure
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Sun, 3 Aug 2003 13:13:46 -0500, Otto Haliburton wrote:
> 
> > Knowing where the GRUB directory is doesn't have anything to do with
> > knowing where things are located.  The MBR is in the 1st sector of
> the
> > drive we agree.  Once GRUB is called it goes to a particular
> location on
> > the disk to load stage1 (that particular location on linux just
> happens
> > to be /boot/grub).  I suggest you go to /boot/grub and see what is
> in
> > that directory.  Again I am saying something very simple.  If it
> knows
> > where stage1 is then it knows where stage2 is!!!1
> 
> *sigh*
> 
> No. Because
> 
>   1) stage1 is the MBR and NOT the file in grub directory,
> 
>   2) two completely different techniques are used to load
>   stage1.5 and stage2.
> 
> While the physical location of stage1.5 is hardcoded into the MBR,
> the location of stage2 is not. At a later point in the booting
> process, GRUB is able to access the ext2 file-system directly
> and *then* can access stage2 and any file on its root partition.
> 
> But all this is irrelevant. Ashley is confronted with a problem
> where GRUB stage1 (the MBR!) fails/hangs. IMO, and I've mentioned
> that earlier, the only reason can be that it gets a wrong BIOS drive
> Id or loads wrong sectors due to geometry mismatch. We don't know
> what role primary slave drive plays when it is removed. Hence I
> don't have any other comment.
> 
> Btw, since I'm tired of your replies in this thread, welcome to my
> ~/.procmailrc! Don't expect another reply from me.
> 
> - --
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.2 (GNU/Linux)
> 
> iD8DBQE/LVbU0iMVcrivHFQRAsXmAJ9BndNBko84D+EutCyewq0VPBsHAACfUAro
> 429/pTz0rncvSaMZLzbO34k=
> =gJCZ
> -END PGP SIGNATURE-
> 
> 
> --
> redhat-list mailing list
> unsubscribe mailto:[EMAIL PROTECTED]
> https://www.redhat.com/mailman/listinfo/redhat-list


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Michael Schwendt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, 3 Aug 2003 13:13:46 -0500, Otto Haliburton wrote:

> Knowing where the GRUB directory is doesn't have anything to do with
> knowing where things are located.  The MBR is in the 1st sector of the
> drive we agree.  Once GRUB is called it goes to a particular location on
> the disk to load stage1 (that particular location on linux just happens
> to be /boot/grub).  I suggest you go to /boot/grub and see what is in
> that directory.  Again I am saying something very simple.  If it knows
> where stage1 is then it knows where stage2 is!!!1

*sigh*

No. Because

  1) stage1 is the MBR and NOT the file in grub directory,
  
  2) two completely different techniques are used to load
  stage1.5 and stage2. 

While the physical location of stage1.5 is hardcoded into the MBR,
the location of stage2 is not. At a later point in the booting
process, GRUB is able to access the ext2 file-system directly
and *then* can access stage2 and any file on its root partition.

But all this is irrelevant. Ashley is confronted with a problem
where GRUB stage1 (the MBR!) fails/hangs. IMO, and I've mentioned
that earlier, the only reason can be that it gets a wrong BIOS drive
Id or loads wrong sectors due to geometry mismatch. We don't know
what role primary slave drive plays when it is removed. Hence I
don't have any other comment.

Btw, since I'm tired of your replies in this thread, welcome to my
~/.procmailrc! Don't expect another reply from me.

- -- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/LVbU0iMVcrivHFQRAsXmAJ9BndNBko84D+EutCyewq0VPBsHAACfUAro
429/pTz0rncvSaMZLzbO34k=
=gJCZ
-END PGP SIGNATURE-


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Otto Haliburton]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:redhat-list-
> [EMAIL PROTECTED] On Behalf Of Michael Schwendt
> Sent: Sunday, August 03, 2003 1:03 PM
> To: [EMAIL PROTECTED]
> Subject: Re: GRUB failure
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Sun, 3 Aug 2003 09:28:56 -0500, Otto Haliburton wrote:
> 
> > > BIOS loads and starts the code from master boot record, but code
> in
> > > MBR fails to load stage1.5 which is located at a fixed position on
> > > hda. At that point, GRUB does not even know about "directories"
> yet,
> > > since it is this later stage that would give native access to ext2
> > > fs. The reason that GRUB fails to access hda can be that BIOS uses
> a
> > > different method to access the drive, while GRUB maybe gets a
> wrong
> > > drive Id and hence fails to find hda.
> > >
> > > However, Ashley has mentioned that this computer has been working
> > > fine with a single drive for several months until hdb was added.
> > > Only when hdb was removed, it started to malfunction. So, if it's
> > > not a BIOS thing that confuses GRUB, I don't see why GRUB would
> fail
> > > loading from hda.
> >
> > You haven't gotten the point of the question. GRUB is in the MBR
> from
> > the install.  It has a location to get to the GRUB directory to load
> > stage1 (we know that stage1 and stage2 and all other things are in
> the
> > GRUB directory look them up yourself).  So it locates the GRUB
> directory
> > to load stage1 then why would it now lose that location to load
> stage2.
> 
> GRUB code in MBR does not know about "directories" at all. It has a
> physical harddisk location hardcoded and uses a BIOS function to
> read some sectors at a fixed position, usually the first cylinder
> following the MBR.
> 
> Please do us all a favour and reboot after removing the stage2 file
> in /boot/grub. That will be enlightening experience for you.
Knowing where the GRUB directory is doesn't have anything to do with
knowing where things are located.  The MBR is in the 1st sector of the
drive we agree.  Once GRUB is called it goes to a particular location on
the disk to load stage1 (that particular location on linux just happens
to be /boot/grub).  I suggest you go to /boot/grub and see what is in
that directory.  Again I am saying something very simple.  If it knows
where stage1 is then it knows where stage2 is!!!1




-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Michael Schwendt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, 3 Aug 2003 09:28:56 -0500, Otto Haliburton wrote:

> > BIOS loads and starts the code from master boot record, but code in
> > MBR fails to load stage1.5 which is located at a fixed position on
> > hda. At that point, GRUB does not even know about "directories" yet,
> > since it is this later stage that would give native access to ext2
> > fs. The reason that GRUB fails to access hda can be that BIOS uses a
> > different method to access the drive, while GRUB maybe gets a wrong
> > drive Id and hence fails to find hda.
> > 
> > However, Ashley has mentioned that this computer has been working
> > fine with a single drive for several months until hdb was added.
> > Only when hdb was removed, it started to malfunction. So, if it's
> > not a BIOS thing that confuses GRUB, I don't see why GRUB would fail
> > loading from hda.
> 
> You haven't gotten the point of the question. GRUB is in the MBR from
> the install.  It has a location to get to the GRUB directory to load
> stage1 (we know that stage1 and stage2 and all other things are in the
> GRUB directory look them up yourself).  So it locates the GRUB directory
> to load stage1 then why would it now lose that location to load stage2.

GRUB code in MBR does not know about "directories" at all. It has a
physical harddisk location hardcoded and uses a BIOS function to
read some sectors at a fixed position, usually the first cylinder
following the MBR.

Please do us all a favour and reboot after removing the stage2 file
in /boot/grub. That will be enlightening experience for you.

- -- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/LU5O0iMVcrivHFQRAnydAJ93m6agCWc9C8qBoZ8TOz057x2/YwCfcH1R
XUjrYjdwdxbqtOwbPvmS4Qc=
=lG59
-END PGP SIGNATURE-


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Bret Hughes]

On Sun, 2003-08-03 at 02:27, brian davison wrote:
> Kenneth... I feel  Your on the right track here...  you may have missed her
> post where she said  nothing was changed  and went on to say she did
> switch jumper positions...   this changes  same parts of the hardware
> addressing.  so a hard coded "go there" might not see what a bios call
> would
> brian  :)/
> 

Just curious what is in the device.map file?  This is where grub assigns
device numbers used in grub.conf.  I don't know if this is used in the
installation of grub on the mbr or after but since I don't remember
anything about this I thought I would ask.  If it was posted already I
appologize.

Bret 


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Otto Haliburton]

BTW the MBR is on HDA

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:redhat-list-
> [EMAIL PROTECTED] On Behalf Of Michael Schwendt
> Sent: Sunday, August 03, 2003 9:05 AM
> To: [EMAIL PROTECTED]
> Subject: Re: GRUB failure
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Sun, 3 Aug 2003 04:13:09 -0500, Otto Haliburton wrote:
> 
> > We have all been ignoring one fact and that is for some reason
> > GRUB is loading part of the boot loader on the second drive.
> 
> Unfortunately, the shown grub.conf does not agree with this theory
> at all. It does not contain any reference to hd1, so there's no
> single reason why "grub-install /dev/hda" would work without errors,
> but the booting from hda would fail.
> 
> > It apparently thinks that linux is on the second drive.
> 
> This conclusion is beyond me.
> 
> > To those of you, who have the theory that GRUB is loading stage1
> > and can't load stage2 answer the question, "how it can find stage1
> and
> > then can't find stage2?", when both are in the same GRUB directory.
> It
> > can not find the GRUB directory period.
> 
> BIOS loads and starts the code from master boot record, but code in
> MBR fails to load stage1.5 which is located at a fixed position on
> hda. At that point, GRUB does not even know about "directories" yet,
> since it is this later stage that would give native access to ext2
> fs. The reason that GRUB fails to access hda can be that BIOS uses a
> different method to access the drive, while GRUB maybe gets a wrong
> drive Id and hence fails to find hda.
> 
> However, Ashley has mentioned that this computer has been working
> fine with a single drive for several months until hdb was added.
> Only when hdb was removed, it started to malfunction. So, if it's
> not a BIOS thing that confuses GRUB, I don't see why GRUB would fail
> loading from hda.
> 
> - --
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.2 (GNU/Linux)
> 
> iD8DBQE/LRZ70iMVcrivHFQRAmf+AJ4qbjgdK+3rpvdCsXgz47rIeh6SPgCfQlWU
> sYhitwThMNCKrXCfpgBk1kU=
> =kcXm
> -END PGP SIGNATURE-
> 
> 
> --
> redhat-list mailing list
> unsubscribe mailto:[EMAIL PROTECTED]
> https://www.redhat.com/mailman/listinfo/redhat-list


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Otto Haliburton]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:redhat-list-
> [EMAIL PROTECTED] On Behalf Of Michael Schwendt
> Sent: Sunday, August 03, 2003 9:05 AM
> To: [EMAIL PROTECTED]
> Subject: Re: GRUB failure
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Sun, 3 Aug 2003 04:13:09 -0500, Otto Haliburton wrote:
> 
> > We have all been ignoring one fact and that is for some reason
> > GRUB is loading part of the boot loader on the second drive.
> 
> Unfortunately, the shown grub.conf does not agree with this theory
> at all. It does not contain any reference to hd1, so there's no
> single reason why "grub-install /dev/hda" would work without errors,
> but the booting from hda would fail.
> 
> > It apparently thinks that linux is on the second drive.
> 
> This conclusion is beyond me.
> 
> > To those of you, who have the theory that GRUB is loading stage1
> > and can't load stage2 answer the question, "how it can find stage1
> and
> > then can't find stage2?", when both are in the same GRUB directory.
> It
> > can not find the GRUB directory period.
> 
> BIOS loads and starts the code from master boot record, but code in
> MBR fails to load stage1.5 which is located at a fixed position on
> hda. At that point, GRUB does not even know about "directories" yet,
> since it is this later stage that would give native access to ext2
> fs. The reason that GRUB fails to access hda can be that BIOS uses a
> different method to access the drive, while GRUB maybe gets a wrong
> drive Id and hence fails to find hda.
> 
> However, Ashley has mentioned that this computer has been working
> fine with a single drive for several months until hdb was added.
> Only when hdb was removed, it started to malfunction. So, if it's
> not a BIOS thing that confuses GRUB, I don't see why GRUB would fail
> loading from hda.

You haven't gotten the point of the question.  GRUB is in the MBR from
the install.  It has a location to get to the GRUB directory to load
stage1 (we know that stage1 and stage2 and all other things are in the
GRUB directory look them up yourself).  So it locates the GRUB directory
to load stage1 then why would it now lose that location to load stage2.
> 
> - --
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.2 (GNU/Linux)
> 
> iD8DBQE/LRZ70iMVcrivHFQRAmf+AJ4qbjgdK+3rpvdCsXgz47rIeh6SPgCfQlWU
> sYhitwThMNCKrXCfpgBk1kU=
> =kcXm
> -END PGP SIGNATURE-
> 
> 
> --
> redhat-list mailing list
> unsubscribe mailto:[EMAIL PROTECTED]
> https://www.redhat.com/mailman/listinfo/redhat-list


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Michael Schwendt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, 3 Aug 2003 04:13:09 -0500, Otto Haliburton wrote:

>   We have all been ignoring one fact and that is for some reason
> GRUB is loading part of the boot loader on the second drive. 

Unfortunately, the shown grub.conf does not agree with this theory
at all. It does not contain any reference to hd1, so there's no
single reason why "grub-install /dev/hda" would work without errors,
but the booting from hda would fail.

> It apparently thinks that linux is on the second drive. 

This conclusion is beyond me.

>   To those of you, who have the theory that GRUB is loading stage1
> and can't load stage2 answer the question, "how it can find stage1 and
> then can't find stage2?", when both are in the same GRUB directory.  It
> can not find the GRUB directory period.

BIOS loads and starts the code from master boot record, but code in
MBR fails to load stage1.5 which is located at a fixed position on
hda. At that point, GRUB does not even know about "directories" yet,
since it is this later stage that would give native access to ext2
fs. The reason that GRUB fails to access hda can be that BIOS uses a
different method to access the drive, while GRUB maybe gets a wrong
drive Id and hence fails to find hda.

However, Ashley has mentioned that this computer has been working
fine with a single drive for several months until hdb was added.
Only when hdb was removed, it started to malfunction. So, if it's
not a BIOS thing that confuses GRUB, I don't see why GRUB would fail
loading from hda.

- -- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/LRZ70iMVcrivHFQRAmf+AJ4qbjgdK+3rpvdCsXgz47rIeh6SPgCfQlWU
sYhitwThMNCKrXCfpgBk1kU=
=kcXm
-END PGP SIGNATURE-


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Ashley M. Kirchner]

Otto Haliburton wrote:

What kind of disk contoller do you have and what
kind of computer system(manufacturer) is this computer.
   I can tell you Monday when I get to the office and pull the specs on 
the board.  It's a (custom built) white box  containing an Intel board. 
One IDE bus, and 2 aic7899 Ultra160 SCSI ports on it (which aren't 
being used).  I don't remember which specific board model it is, so 
you'll have to wait till Monday.

   IDE info from dmesg:


SvrWks OSB4: IDE controller at PCI slot 00:0f.1
SvrWks OSB4: chipset revision 0
SvrWks OSB4: not 100% native mode: will probe irqs later
   ide0: BM-DMA at 0x54d0-0x54d7, BIOS settings: hda:DMA, hdb:DMA
   ide1: BM-DMA at 0x54d8-0x54df, BIOS settings: hdc:DMA, hdd:DMA

   Yes, it lists both ide0 and ide1, however there is no physical ide1 
connector on the board.  Only ide0, and the two scsi connectors.

   I'd also like to point out that this has now become a moot point 
since I already have hdb in and the system works.

--
H| I haven't lost my mind; it's backed up on tape somewhere.
 +
 Ashley M. Kirchner    .   303.442.6410 x130
 IT Director / SysAdmin / WebSmith . 800.441.3873 x130
 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6
 http://www.pcraft.com . .  ..   Boulder, CO 80303, U.S.A. 





--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Otto Haliburton]

No, actually I wanted to see if when it booted it was creating a
partition or swap space on drive b.  Don't be so sensitive.  I also
wanted to see if it was chaining the partitions together in a way that
would cause it to renumber the partitions so that it could not locate
the GRUB directory.  What kind of disk contoller do you have and what
kind of computer system(manufacturer) is this computer.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:redhat-list-
> [EMAIL PROTECTED] On Behalf Of Ashley M. Kirchner
> Sent: Sunday, August 03, 2003 4:41 AM
> To: [EMAIL PROTECTED]
> Subject: Re: GRUB failure
> 
> Otto Haliburton wrote:
> 
> >Ashley while I believe you when you say that there
> >is nothing on drive B would you post a fdisk listing of partitions on
> >drive b.
> >
> You really don't believe me when I say there's -NOTHING- on the
> drive, do you?  How about this?  I've actually killed everything,
> including partitions on said drive.  GRUB comes up just fine as long
> as
> that device is connected.  As soon as it's disconnected, it fails.
> But,
> you want to see, so here, there is nothing on it:
> 
>  fdisk -l /dev/hdb
> 
> Disk /dev/hdb: 255 heads, 63 sectors, 7476 cylinders
> Units = cylinders of 16065 * 512 bytes
> 
>Device BootStart   EndBlocks   Id  System
> 
> 
> 
> It boots up fine when it's connected, but not when removed from
> the
> chain.
> 
> >  In the meantime, you can remove drive b and boot from floppy
> >and then reinstall GRUB with B removed from the system and note any
> >error messages that install prints when this occurs because either it
> >will install successfully or it will fail with error messages.
> >
> I've been over this time and time again: I HAVE DONE THAT.
> 
> - removed hdb
> - set hda's jumper back to master otherwise BIOS complains and
> won't
> boot
> - shoved floppy in, booted up just fine
> - ran grub-install /dev/hda, no errors
> - removed floppy, reboot
> - BIOS finds hda, knows there's no hdb, goes on to boot
> - black screen, with 'GRUB' in the corner: system dead
> 
> I ran the same cycle again, this time issuing:
>grub-install --root-directory=/boot '(hd0)'
> as the info page suggests.  Same result, won't boot, dead system.
> 
> As soon as I plug hdb back in, whether the drive has partitions on
> it or not, it boots just fine.  I even tried a completely different
> drive, one that has an NTFS partition on it, and the system boots just
> fine with it.  I doubt GRUB is actually trying to READ anything of the
> drive.
> 
> So I ask you again, how can GRUB possibly be reading ANYTHING from
> hdb when there's -NOTHING- on it (or when there is something, but
> totally different, such as the NTFS drive I tried)?
> 
> --
> H| I haven't lost my mind; it's backed up on tape somewhere.
>   +---
> -
>   Ashley M. Kirchner <mailto:[EMAIL PROTECTED]>   .   303.442.6410
> x130
>   IT Director / SysAdmin / WebSmith . 800.441.3873
> x130
>   Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave.
> #6
>   http://www.pcraft.com . .  ..   Boulder, CO 80303,
> U.S.A.
> 
> 
> 
> 
> 
> --
> redhat-list mailing list
> unsubscribe mailto:[EMAIL PROTECTED]
> https://www.redhat.com/mailman/listinfo/redhat-list


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Ashley M. Kirchner]

Otto Haliburton wrote:

Ashley while I believe you when you say that there
is nothing on drive B would you post a fdisk listing of partitions on
drive b.
   You really don't believe me when I say there's -NOTHING- on the 
drive, do you?  How about this?  I've actually killed everything, 
including partitions on said drive.  GRUB comes up just fine as long as 
that device is connected.  As soon as it's disconnected, it fails.  But, 
you want to see, so here, there is nothing on it:

 fdisk -l /dev/hdb

Disk /dev/hdb: 255 heads, 63 sectors, 7476 cylinders
Units = cylinders of 16065 * 512 bytes
  Device BootStart   EndBlocks   Id  System



   It boots up fine when it's connected, but not when removed from the 
chain.

 In the meantime, you can remove drive b and boot from floppy
and then reinstall GRUB with B removed from the system and note any
error messages that install prints when this occurs because either it
will install successfully or it will fail with error messages.
   I've been over this time and time again: I HAVE DONE THAT.

   - removed hdb
   - set hda's jumper back to master otherwise BIOS complains and won't 
boot
   - shoved floppy in, booted up just fine
   - ran grub-install /dev/hda, no errors
   - removed floppy, reboot
   - BIOS finds hda, knows there's no hdb, goes on to boot
   - black screen, with 'GRUB' in the corner: system dead

   I ran the same cycle again, this time issuing:
  grub-install --root-directory=/boot '(hd0)'
   as the info page suggests.  Same result, won't boot, dead system.
   As soon as I plug hdb back in, whether the drive has partitions on 
it or not, it boots just fine.  I even tried a completely different 
drive, one that has an NTFS partition on it, and the system boots just 
fine with it.  I doubt GRUB is actually trying to READ anything of the 
drive.

   So I ask you again, how can GRUB possibly be reading ANYTHING from 
hdb when there's -NOTHING- on it (or when there is something, but 
totally different, such as the NTFS drive I tried)?

--
H| I haven't lost my mind; it's backed up on tape somewhere.
 +
 Ashley M. Kirchner    .   303.442.6410 x130
 IT Director / SysAdmin / WebSmith . 800.441.3873 x130
 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6
 http://www.pcraft.com . .  ..   Boulder, CO 80303, U.S.A. 





--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Otto Haliburton]

Hi all,
We have all been ignoring one fact and that is for some reason
GRUB is loading part of the boot loader on the second drive.  It
apparently thinks that linux is on the second drive.  A setup where the
boot loader is on the MBR of drive A but linux is on drive B so that the
boot is A -> B -> A.  Ashley while I believe you when you say that there
is nothing on drive B would you post a fdisk listing of partitions on
drive b.  In the meantime, you can remove drive b and boot from floppy
and then reinstall GRUB with B removed from the system and note any
error messages that install prints when this occurs because either it
will install successfully or it will fail with error messages.

To those of you, who have the theory that GRUB is loading stage1
and can't load stage2 answer the question, "how it can find stage1 and
then can't find stage2?", when both are in the same GRUB directory.  It
can not find the GRUB directory period.


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Ashley M. Kirchner]

brian davison wrote:

Ashley...  try not changing the drive to single...  leave it as the Master.
( as in  "don't change the jumper when removing the second drive")
 

   No can do.  hda has three settings on it: Master, Master w/ Slave, 
and Slave.  Since hdb was installed, it's been set to Master w/ Slave 
(leaving it as Master resulted in hdb not being detected by the BIOS.) 
Consequently, removing hdb without changing the jumper on hda resulted 
in the machine not booting because the BIOS expected a slave since hda's 
jumper was set as such.

   Mind you, I've played with this a whole lot already, and it just 
doesn't work with just leaving the jumper alone and not changing it.  If 
I leave it set to Master, the BIOS won't see hdb.  If I leave it on 
Master w/ Slave, the BIOS complains about not seeing a slave (when hdb 
gets removed.)  So I had to change that anyway.

   PS: Ashley's a guy.

--
H| I haven't lost my mind; it's backed up on tape somewhere.
 +
 Ashley M. Kirchner    .   303.442.6410 x130
 IT Director / SysAdmin / WebSmith . 800.441.3873 x130
 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6
 http://www.pcraft.com . .  ..   Boulder, CO 80303, U.S.A. 





--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[brian davison]

Kenneth... I feel  Your on the right track here...  you may have missed her
post where she said  nothing was changed  and went on to say she did
switch jumper positions...   this changes  same parts of the hardware
addressing.  so a hard coded "go there" might not see what a bios call
would
brian  :)/


At 07:38 PM 8/1/03 -0400, Kenneth Goodwin wrote:
>
>>  Maybe I misunderstand here, but this seems to be a
>situation
>>  where -
>>
>>  A working Linux system using GRUB with MBR on HD-A,
>.conf
>>  file on HD-A
>>  had a new disk drive HD-B added to it.
>>
>>  They did nothing apparently to reconfigure the box
>>  bootwise.
>>  They added the filesystems onto HD-B and used them for
>>  whatever.
>>
>>  HD-B croaked.
>>
>>  When they removed HD-B from the ide BUS, things with
>GRUB
>>  broke
>>  AND THEY DONT UNDERSTAND WHY?
>>
>>  Since everything for GRUB should be on HD-A which is
>still
>>  operational.
>>  Grub should not have a problem locating the .conf file
>>  since it should still
>>  exist on HD-A.
>>
>>  Why would GRUB whose ENTIRE RESOURCES SHOULD BE STILL
>INTACT
>>  On DRIVE A
>>  fail to work when DRIVE B is Removed from the IDE Chain?
>>  >  >
>>  >  > > The problem is, I have understood the problem.
>You
>>  >  can't boot when GRUB
>>  >  > > can't find grub.conf.
>>  >  >
>>  >  > GRUB doesn't even come that far as was explained in
>the
>>  first
>>  >  > message.
>>  >  >
>>  >  > If it booted into GRUB shell and then wouldn't find
>the
>>  >  config file,
>>  >  > that would be a minor problem.
>>  >  >
>>  >  > > You can when it can.  When you remove hdb GRUB
>>  >  > > can't find the .conf file and that is why you
>can't
>>  boot.
>>
>
>>>OTTO's REPLY 
>>  I agree with the what you are saying.  Something is
>changing
>>  when HDB is
>>  removed.  I don't know what.  I can tell you that the
>same thing will
>>  happen if you add/delete a partition on 'HAD'.  We
>>  conjectured that it
>>  could be hardware, but they say its not so I don't know,
>but
>>  we do know
>>  for a fact that it can't locate the .conf file by what
>projection has
>>  taken place.  It could be as simple as the partition are
>being
>>  renumbered or as complicated as a GRUB problem.  But the
>addition and
>>  removal of the drive is changing something.
>
>I have not seen grub source, but Grub is apparently a
>multi-load phase boot loader,
>the MBR piece loads the rest of the boot loader
>off of the /boot partition which then loads the OS etc.
>
>Okay, Most boot loaders do not record things as Partition
>numbers in the MBR piece.
>Ie from an OS / LINUX perspective of hardware, it wont be
>/dev/hda00 or whatever
>in the MBR.
>
>Instead, It will be hardcoded as a disk drive number from a
>hardware perspective
>IDE Controller, unit select info, the stuff you see in the
>messages file
>during boot and a
>Block offset on the disk from whence to start looking for
>the superblock.
>This will be the first block number on the ide disk that
>/boot starts physically at.
>
>However, The MBR record should have the correct pointers to
>the
>HD-A drive and /boot partition since the system was
>initially setup that way.
>If you stick drive B back on the bus and change nothing
>else, things work again
>from what I understand here. I think your GRUB prompt is
>coming out of the MBR piece
>but you would have to check the source code.
>
>Since the /boot filesystem
>is where the CONF file and the rest of grub is apparently
>located and is supposed
>to be the first partition on the drive this should always
>work.
>
>
>Now if you make /boot further in on the drive and then
>change the sizes of the partition(s)
>before the /boot partition and dont tell grub's MBR piece
>about the change
>you will have the kinda problem that Otto apparently had
>with Grub, thats because
>grub cant find the real start of the /boot partition since
>the block offset into the
>disk just changed. Otto would have to confirm that was the
>case in his situation.
>
>I think that Otto was on the right track, but was not
>explaining his position clearly.
>The issue here is apparently why does adding in Drive B Not
>mess up
>the MBR's sense of where Drive A is on the IDE chain , but
>when drive B is removed
>the MBR can't find drive A.
>
>There must be a radical shift in how the BIOS is dealing
>with the drives
>since the original create of LINUX in a single drive
>configuration, the addition
>of the second drive and subsequent removal there of.
>
>(Of course, this is only a theory mind you...)
>
>Sort of an example to give you the idea of where I am going
>here -
>
>   At Create time of LINUX
>
>   Drive A - bus address 123456 - recorded that way in MBR
>
>   Add in Drive B
>   ROM BIOS reconfiguration of it's device tables.
>
>   Drive A - bus address 123456  MBR points to 123456
>   Drive B 

RE: GRUB failure

[brian davison]

If this hasn't been tried yet
the bioses don't all need/ want the drives to be set any way but master or
slave.   
Ashley...  try not changing the drive to single...  leave it as the Master.
( as in  "don't change the jumper when removing the second drive")
the addressing of the drive  can be different between the two settings.

The symptoms you reported  are consistent with the bios loading the first
part of the "grub" loader, and grub not being able to find itself (2nd
stage) to continue the boot.   those symptoms say the drive isn't at the
address grub is looking at.  Since it IS there with the other settings, it
is probably the jumper changes causing the problem.

brian...   hth.  :)
///





At 
---
 [EMAIL PROTECTED]


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Otto Haliburton]

This is a test message to see the format. Do not respond to this
message. It has already been sent.
HIII
ISSSAAATTTEE
T.
HIII
ISSSAAATTTEE
T.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Otto Haliburton
Sent: Saturday, August 02, 2003 10:02 AM
To: [EMAIL PROTECTED]
Subject: RE: GRUB failure

This is a test message to see the format. Do not respond to this
message. It has already been sent.
HIII
ISSSAAATTTEE
T.
HIII
ISSSAAATTTEE
T.
> On Sat, 2003-08-02 at 09:50, Otto Haliburton wrote:
> This is a test message to see the format. Do not respond to this
> message. It has already been sent.
>
HIII
>
ISSSAAATTTEE
> T.
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:redhat-list-
> > [EMAIL PROTECTED] On Behalf Of Michael Schwendt
> > Sent: Saturday, August 02, 2003 2:31 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: GRUB failure
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> > 
> > On Fri, 1 Aug 2003 19:36:17 -0500, Otto Haliburton wrote:
> > 
> > > Is your configuration a SCSI?  If it is then there is a
explanation
> > 
> > That wouldn't access the harddisk drives as /dev/hda and /dev/hdb,
> > respectively.
> > 
> > Btw, it would be great if you could trim your quotes. There's no
need
> > in
> > quoting list footers and superfluous things.
> > 
> > - --
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1.2.2 (GNU/Linux)
> > 
> > iD8DBQE/K2ie0iMVcrivHFQRAqV/AJ4z41SxMKRnYTzo/JGOHaOv1RfvrgCfVr7C
> > bdY0YAUR8Q3njzv7VO4t0V0=
> > =o+v2
> > -END PGP SIGNATURE-
> > 
> > 
> > --
> > redhat-list mailing list
> > unsubscribe
mailto:[EMAIL PROTECTED]
> > https://www.redhat.com/mailman/listinfo/redhat-list
> 


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Otto Haliburton]

This is a test message to see the format. Do not respond to this
message. It has already been sent.
HIII
ISSSAAATTTEE
T.
HIII
ISSSAAATTTEET.
> On Sat, 2003-08-02 at 09:50, Otto Haliburton wrote:
> This is a test message to see the format. Do not respond to this
> message. It has already been sent.
> HIII
> ISSSAAATTTEE
> T.
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:redhat-list-
> > [EMAIL PROTECTED] On Behalf Of Michael Schwendt
> > Sent: Saturday, August 02, 2003 2:31 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: GRUB failure
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> > 
> > On Fri, 1 Aug 2003 19:36:17 -0500, Otto Haliburton wrote:
> > 
> > > Is your configuration a SCSI?  If it is then there is a explanation
> > 
> > That wouldn't access the harddisk drives as /dev/hda and /dev/hdb,
> > respectively.
> > 
> > Btw, it would be great if you could trim your quotes. There's no need
> > in
> > quoting list footers and superfluous things.
> > 
> > - --
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1.2.2 (GNU/Linux)
> > 
> > iD8DBQE/K2ie0iMVcrivHFQRAqV/AJ4z41SxMKRnYTzo/JGOHaOv1RfvrgCfVr7C
> > bdY0YAUR8Q3njzv7VO4t0V0=
> > =o+v2
> > -END PGP SIGNATURE-
> > 
> > 
> > --
> > redhat-list mailing list
> > unsubscribe mailto:[EMAIL PROTECTED]
> > https://www.redhat.com/mailman/listinfo/redhat-list
> 


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Otto Haliburton]

This is a test message to see the format. Do not respond to this
message. It has already been sent.
HIII
ISSSAAATTTEE
T.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:redhat-list-
> [EMAIL PROTECTED] On Behalf Of Michael Schwendt
> Sent: Saturday, August 02, 2003 2:31 AM
> To: [EMAIL PROTECTED]
> Subject: Re: GRUB failure
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Fri, 1 Aug 2003 19:36:17 -0500, Otto Haliburton wrote:
> 
> > Is your configuration a SCSI?  If it is then there is a explanation
> 
> That wouldn't access the harddisk drives as /dev/hda and /dev/hdb,
> respectively.
> 
> Btw, it would be great if you could trim your quotes. There's no need
> in
> quoting list footers and superfluous things.
> 
> - --
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.2 (GNU/Linux)
> 
> iD8DBQE/K2ie0iMVcrivHFQRAqV/AJ4z41SxMKRnYTzo/JGOHaOv1RfvrgCfVr7C
> bdY0YAUR8Q3njzv7VO4t0V0=
> =o+v2
> -END PGP SIGNATURE-
> 
> 
> --
> redhat-list mailing list
> unsubscribe mailto:[EMAIL PROTECTED]
> https://www.redhat.com/mailman/listinfo/redhat-list


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB Failure

[Michael Schwendt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 1 Aug 2003 19:40:49 -0500, Otto Haliburton wrote:

> There is also a explanation if the volumes are LVM or RAID.

No.

LVM is not available before the initrd is loaded and the kernel is
started. Same for Software-RAID. You boot from a physical device,
not a logical one. With Hardware-RAID, the two drives would not
appear as individual drives hda and hdb.

- -- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/K3Ql0iMVcrivHFQRAiMJAJsGF5HbdJvuHdxDg+d4o3wnrGbFeACfb7EH
1ea25xkELlxijz59z0GM6Rs=
=HadU
-END PGP SIGNATURE-


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Michael Schwendt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 1 Aug 2003 19:47:47 -0400, Kenneth Goodwin wrote:

> Anyone know for certain who is printing out the INitial GRUB
> message?
> 
> The MBR or phase two piece.

MBR (stage1) prints only GRUB because of space constraints. It has
only very few and short error messages.

The next code (stage 1.5) is still loaded directly from harddisk,
but after that GRUB is able to access the ext2 file-system and load
stage2 and other files.

- -- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/K3OP0iMVcrivHFQRAlmSAJsHpc5Cflh8QAKQQwdLR2sB3ojmKACePGFL
mlDPw65Adctvdcrs0lbSEn8=
=hKPX
-END PGP SIGNATURE-


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Michael Schwendt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 1 Aug 2003 19:36:17 -0500, Otto Haliburton wrote:

> Is your configuration a SCSI?  If it is then there is a explanation

That wouldn't access the harddisk drives as /dev/hda and /dev/hdb,
respectively.

Btw, it would be great if you could trim your quotes. There's no need in
quoting list footers and superfluous things.

- -- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/K2ie0iMVcrivHFQRAqV/AJ4z41SxMKRnYTzo/JGOHaOv1RfvrgCfVr7C
bdY0YAUR8Q3njzv7VO4t0V0=
=o+v2
-END PGP SIGNATURE-


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB Failure

[Kenneth Goodwin]

>
>
>  Remember. You can boot with a floppy and everything works
correctly

But you are not using the MBR on DRIVE A when you do that
and you are probably
using the entire GRUB package on the floppy disk. This means
that grub phase two
launched from the floppy
can recognize the filesystem on drive A and presumably load
the kernel
from there ( i am assuming the boot floppy does not contain
the OS image
which may not be true.)  The kernel (from where ever it
launches from will autodetect the new hardware layout
and presumably adjust how it accesses the hard drive.

In any case, time to go home.

>
>  -Original Message-
>  From: [EMAIL PROTECTED]
>  [mailto:[EMAIL PROTECTED]
>  On Behalf Of Kenneth Goodwin
>  Sent: Friday, August 01, 2003 6:59 PM
>  To: [EMAIL PROTECTED]
>  Subject: RE: GRUB Failure
>
>  >
>  >Well I'm not so sure about that.. whenever GRUB
doesn't
>  >  find it's grub.conf file,
>  >  it just enters it's CLI mode from where you can do
things
>  >  manually. This is not the
>  >  problem.
>  >I've had the same situation happen to me with LILO,
>  when I
>  >  first installed RH,
>  >  , and one fine day for no reason at all it happened to
>  GRUB
>  >  too.. I fixed it with
>  >  grub-install /dev/hda, but always wondered how could
GRUB
>  be
>  >  so unstable. This is
>  >  the kind of problem that happens for no reason at all
and
>  >  will make a regular user
>  >  lose his mind.. wish I could help more;
>  >
>  >  --
>  >  Herculano de Lima Einloft Neto <[EMAIL PROTECTED]>
>
>  I wonder if the real issue in this case is that the ROM
Bios
>  and/or drive
>  firmware involved here has a bug in it and it is acting
>  wierd
>  under certain circumstances and changing the boot time
>  definitions of what
>  the drive configuration/access mode/ geometry is on the
fly?
>  Such that the MBR cant find the /boot partition because
the
>  drive address
>  and/or geometry definition has suddenly changed or
something
>  along that line of
>  thought??
>
>  Did you check for firmware upgrades for your motherboard
and
>  disk drives
>  at the time?
>
>
>  --
>  redhat-list mailing list
>  unsubscribe
mailto:[EMAIL PROTECTED]
>  https://www.redhat.com/mailman/listinfo/redhat-list
>
>
>  --
>  redhat-list mailing list
>  unsubscribe
mailto:[EMAIL PROTECTED]
>  https://www.redhat.com/mailman/listinfo/redhat-list
>


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB Failure

[Otto Haliburton]

There is also a explanation if the volumes are LVM or RAID.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Otto Haliburton
Sent: Friday, August 01, 2003 7:38 PM
To: [EMAIL PROTECTED]
Subject: RE: GRUB Failure

Remember. You can boot with a floppy and everything works correctly

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Kenneth Goodwin
Sent: Friday, August 01, 2003 6:59 PM
To: [EMAIL PROTECTED]
Subject: RE: GRUB Failure

>
>Well I'm not so sure about that.. whenever GRUB doesn't
>  find it's grub.conf file,
>  it just enters it's CLI mode from where you can do things
>  manually. This is not the
>  problem.
>I've had the same situation happen to me with LILO,
when I
>  first installed RH,
>  , and one fine day for no reason at all it happened to
GRUB
>  too.. I fixed it with
>  grub-install /dev/hda, but always wondered how could GRUB
be
>  so unstable. This is
>  the kind of problem that happens for no reason at all and
>  will make a regular user
>  lose his mind.. wish I could help more;
>
>  --
>  Herculano de Lima Einloft Neto <[EMAIL PROTECTED]>

I wonder if the real issue in this case is that the ROM Bios
and/or drive
firmware involved here has a bug in it and it is acting
wierd
under certain circumstances and changing the boot time
definitions of what
the drive configuration/access mode/ geometry is on the fly?
Such that the MBR cant find the /boot partition because the
drive address
and/or geometry definition has suddenly changed or something
along that line of
thought??

Did you check for firmware upgrades for your motherboard and
disk drives
at the time?


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB Failure

[Otto Haliburton]

Remember. You can boot with a floppy and everything works correctly

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Kenneth Goodwin
Sent: Friday, August 01, 2003 6:59 PM
To: [EMAIL PROTECTED]
Subject: RE: GRUB Failure

>
>Well I'm not so sure about that.. whenever GRUB doesn't
>  find it's grub.conf file,
>  it just enters it's CLI mode from where you can do things
>  manually. This is not the
>  problem.
>I've had the same situation happen to me with LILO,
when I
>  first installed RH,
>  , and one fine day for no reason at all it happened to
GRUB
>  too.. I fixed it with
>  grub-install /dev/hda, but always wondered how could GRUB
be
>  so unstable. This is
>  the kind of problem that happens for no reason at all and
>  will make a regular user
>  lose his mind.. wish I could help more;
>
>  --
>  Herculano de Lima Einloft Neto <[EMAIL PROTECTED]>

I wonder if the real issue in this case is that the ROM Bios
and/or drive
firmware involved here has a bug in it and it is acting
wierd
under certain circumstances and changing the boot time
definitions of what
the drive configuration/access mode/ geometry is on the fly?
Such that the MBR cant find the /boot partition because the
drive address
and/or geometry definition has suddenly changed or something
along that line of
thought??

Did you check for firmware upgrades for your motherboard and
disk drives
at the time?


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Otto Haliburton]

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Ashley M. Kirchner
Sent: Friday, August 01, 2003 6:57 PM
To: [EMAIL PROTECTED]
Subject: Re: GRUB failure

Michael Schwendt wrote:

>Unless we hear once
>more from Ashley (who is confronted with this weird problem), we can
>only speculate that is hardware-related most likely. Setting the
>disk geometry scheme to LBA and re-installing GRUB should
>_theoretically_ fix it.
>  
>
This has certainly sparked an interesting conversation, and aside 
from me trying everything everyone has suggested here, I don't know what

else to do than to just say 'fuck it'.  It works with hdb in place. 
 There is, to me, no logical explanation as to why grub would just 
decide to not boot after removing a drive it never depended on in the 
first place.  Another mystery of life.  Thanks to all who tried to help.

-- 
W | I haven't lost my mind; it's backed up on tape somewhere.
  +
  Ashley M. Kirchner <mailto:[EMAIL PROTECTED]>   .   303.442.6410 x130
  IT Director / SysAdmin / WebSmith . 800.441.3873 x130
  Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6
  http://www.pcraft.com . .  ..   Boulder, CO 80303, U.S.A.





-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Is your configuration a SCSI?  If it is then there is a explanation


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Kenneth Goodwin]

>  This has certainly sparked an interesting
conversation,
>  and aside
>  from me trying everything everyone has suggested here, I
>  don't know what
>  else to do than to just say 'fuck it'.  It works with hdb
in place.
>   There is, to me, no logical explanation as to why grub
would just
>  decide to not boot after removing a drive it never
depended
>  on in the
>  first place.  Another mystery of life.  Thanks to all who
>  tried to help.
>


Please Dont go, we are not done playing with you
yet... :-}

Have you checked for Motherboard and disk drive firmware
upgrades
on the respective manufacturers web sites? I think your
problem lies at the primitive level of the rom bios
and not with linux or grub. They are just the innocent
victims.

The Grub-ette (MBR) can not find the Mega-Grub (Phase two
under /boot)
because the B drive removal must be doing something in  the
bios that
makes drive A look different from how it looks with drive b
present.
In fact different from how it looked when you had a single
drive
setup originally.

The real question is WHY because this is far from normal and
you may
be running with unstable "BAD BAD" firmware here that will
whack you
again somewhere else down the road


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Kenneth Goodwin]

>
>  Let refine my answer to it can't find the grub directory
period.

The MBR is not even finding the start of the secondary
loader here.

Perhaps it all happens too fast -

Does the drive light flicker when it tries to load phase two
or not? If no disk activity after the initial MBR load is
seen
then the MBR cant find the drive, if the MBR loads and then
accesses
the disk drive again, then it fails to locate phase 2
because the disk geometry has somehow changed from what it
was.



-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Kenneth Goodwin]

>
>  > What I did notice is there wasn't a /boot
>  > partition in the listing that was sent
>
>  You don't need a /boot partition. The grub.conf was
>  perfectly valid with
>  /dev/hda1 = (hd0,0) being the root partition and
containing the /boot
>  directory.
>
>  The code from MBR fails to load GRUB main program on
primary master
>  drive. Either because it can't access the disk at all or
>  because of disk
>  geometry confusion it loads and executes wrong sectors
which
>  causes the
>  machine to hang.
>
>  And since /dev/hdb doesn't appear in device.map, /dev/hdb
>  was not even
>  known at install time.
>
>

Precisely my point, the issue is that  toggling drive B
on/off the
ide bus is changing how the hardware sees drive A in a way
that
is not compatible with the original single drive A
configuration at original OS installation time..

Grub is not broken, the drive is not broken,
We have a ide bus, bios, or other hardware issue that
impacts
the identity and/or disk definitions of drive A.

In other words, popping drive b off the system does not put
you back into Kansas with Auntie Em Dorothy, but instead

you land smack right into the Twilight Zone.


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB Failure

[Kenneth Goodwin]

>
>Well I'm not so sure about that.. whenever GRUB doesn't
>  find it's grub.conf file,
>  it just enters it's CLI mode from where you can do things
>  manually. This is not the
>  problem.
>I've had the same situation happen to me with LILO,
when I
>  first installed RH,
>  , and one fine day for no reason at all it happened to
GRUB
>  too.. I fixed it with
>  grub-install /dev/hda, but always wondered how could GRUB
be
>  so unstable. This is
>  the kind of problem that happens for no reason at all and
>  will make a regular user
>  lose his mind.. wish I could help more;
>
>  --
>  Herculano de Lima Einloft Neto <[EMAIL PROTECTED]>

I wonder if the real issue in this case is that the ROM Bios
and/or drive
firmware involved here has a bug in it and it is acting
wierd
under certain circumstances and changing the boot time
definitions of what
the drive configuration/access mode/ geometry is on the fly?
Such that the MBR cant find the /boot partition because the
drive address
and/or geometry definition has suddenly changed or something
along that line of
thought??

Did you check for firmware upgrades for your motherboard and
disk drives
at the time?


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Ashley M. Kirchner]

Michael Schwendt wrote:

Unless we hear once
more from Ashley (who is confronted with this weird problem), we can
only speculate that is hardware-related most likely. Setting the
disk geometry scheme to LBA and re-installing GRUB should
_theoretically_ fix it.
 

   This has certainly sparked an interesting conversation, and aside 
from me trying everything everyone has suggested here, I don't know what 
else to do than to just say 'fuck it'.  It works with hdb in place. 
There is, to me, no logical explanation as to why grub would just 
decide to not boot after removing a drive it never depended on in the 
first place.  Another mystery of life.  Thanks to all who tried to help.

--
W | I haven't lost my mind; it's backed up on tape somewhere.
 +
 Ashley M. Kirchner    .   303.442.6410 x130
 IT Director / SysAdmin / WebSmith . 800.441.3873 x130
 Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6
 http://www.pcraft.com . .  ..   Boulder, CO 80303, U.S.A.




--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Kenneth Goodwin]

weird thought 

>  switching her disk geometry scheme to LBA and
re-installing GRUB should
>

I did not see her? original psoting so I dont
know exactly what her two drive setup was.

But I thought most systems were running LBA mode by default
now adays.

Perhaps the setup had two different configurations on the
hard drives
LBA on one, something else on the other  SAY LBA on Drive B,
and XYZ on Drive A and the result is that the BIOS gets
confused
pulling out drive B now and sets drive A to be LBA mode
instead of
XYZ mode making it impossible for MBR to locate the /boot
partition
on drive a because the disk geometry definition in the rom
bios table
just chnaged from what the real drive is set up as. You can
always
load the MBR because it is always logical block 0   CTS
0-0-0 on the drive.

any case, just another whacky theory to consider.


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Kenneth Goodwin]

>  Ashley said that was done as well as changed the hardware
to
>  single boot
>  disk from master/slave.  The only solution seems to be
reinstall hdb
>  which indicates to me that it is not hardware related but
>  something is
>  causing the partitions to be changed. There maybe some
link or
>  something.  What I did notice is there wasn't a /boot
>  partition in the
>  listing that was sent


The new Drive B was apparently "Blank", but fixed the
problem
which in my mind points to the BIOS doing something to the
hardware
level address to shift the drive A address away from the
canned value
stored within the MBR.

GRUB wont care about partition tables or the fdisk drive
slices
in the MBR section, it is too small a program to have too
much
filesystem intelligence. It just needs to know which disk
drive and how
far in to reach the binary for the second phase and how much
to load off the drive.
It will copy itself to higher ram, load the phase two image
into Ram address 0
and execute it via a BRANCH 0 instruction. Phase two does
all the real load work.

Anyone know for certain who is printing out the INitial GRUB
message?

The MBR or phase two piece.

If youi know grub internals, then translate this theory into
the reality of GRUB
and see where that leads us (and hopefully not straight into
/dev/null :-} )


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Kenneth Goodwin]

>  Maybe I misunderstand here, but this seems to be a
situation
>  where -
>
>   A working Linux system using GRUB with MBR on HD-A,
.conf
>  file on HD-A
>   had a new disk drive HD-B added to it.
>
>   They did nothing apparently to reconfigure the box
>  bootwise.
>   They added the filesystems onto HD-B and used them for
>  whatever.
>
>   HD-B croaked.
>
>   When they removed HD-B from the ide BUS, things with
GRUB
>  broke
>   AND THEY DONT UNDERSTAND WHY?
>
>   Since everything for GRUB should be on HD-A which is
still
>  operational.
>   Grub should not have a problem locating the .conf file
>  since it should still
>   exist on HD-A.
>
>  Why would GRUB whose ENTIRE RESOURCES SHOULD BE STILL
INTACT
>  On DRIVE A
>  fail to work when DRIVE B is Removed from the IDE Chain?
>  >  >
>  >  > > The problem is, I have understood the problem.
You
>  >  can't boot when GRUB
>  >  > > can't find grub.conf.
>  >  >
>  >  > GRUB doesn't even come that far as was explained in
the
>  first
>  >  > message.
>  >  >
>  >  > If it booted into GRUB shell and then wouldn't find
the
>  >  config file,
>  >  > that would be a minor problem.
>  >  >
>  >  > > You can when it can.  When you remove hdb GRUB
>  >  > > can't find the .conf file and that is why you
can't
>  boot.
>

>>OTTO's REPLY 
>  I agree with the what you are saying.  Something is
changing
>  when HDB is
>  removed.  I don't know what.  I can tell you that the
same thing will
>  happen if you add/delete a partition on 'HAD'.  We
>  conjectured that it
>  could be hardware, but they say its not so I don't know,
but
>  we do know
>  for a fact that it can't locate the .conf file by what
projection has
>  taken place.  It could be as simple as the partition are
being
>  renumbered or as complicated as a GRUB problem.  But the
addition and
>  removal of the drive is changing something.

I have not seen grub source, but Grub is apparently a
multi-load phase boot loader,
the MBR piece loads the rest of the boot loader
off of the /boot partition which then loads the OS etc.

Okay, Most boot loaders do not record things as Partition
numbers in the MBR piece.
Ie from an OS / LINUX perspective of hardware, it wont be
/dev/hda00 or whatever
in the MBR.

Instead, It will be hardcoded as a disk drive number from a
hardware perspective
IDE Controller, unit select info, the stuff you see in the
messages file
during boot and a
Block offset on the disk from whence to start looking for
the superblock.
This will be the first block number on the ide disk that
/boot starts physically at.

However, The MBR record should have the correct pointers to
the
HD-A drive and /boot partition since the system was
initially setup that way.
If you stick drive B back on the bus and change nothing
else, things work again
from what I understand here. I think your GRUB prompt is
coming out of the MBR piece
but you would have to check the source code.

Since the /boot filesystem
is where the CONF file and the rest of grub is apparently
located and is supposed
to be the first partition on the drive this should always
work.


Now if you make /boot further in on the drive and then
change the sizes of the partition(s)
before the /boot partition and dont tell grub's MBR piece
about the change
you will have the kinda problem that Otto apparently had
with Grub, thats because
grub cant find the real start of the /boot partition since
the block offset into the
disk just changed. Otto would have to confirm that was the
case in his situation.

I think that Otto was on the right track, but was not
explaining his position clearly.
The issue here is apparently why does adding in Drive B Not
mess up
the MBR's sense of where Drive A is on the IDE chain , but
when drive B is removed
the MBR can't find drive A.

There must be a radical shift in how the BIOS is dealing
with the drives
since the original create of LINUX in a single drive
configuration, the addition
of the second drive and subsequent removal there of.

(Of course, this is only a theory mind you...)

Sort of an example to give you the idea of where I am going
here -

At Create time of LINUX

Drive A - bus address 123456 - recorded that way in MBR

Add in Drive B
ROM BIOS reconfiguration of it's device tables.

Drive A - bus address 123456  MBR points to 123456
Drive B - bus address 123455

Remove drive B -

ROM BIOS reconfiguration of it's device tables.

Drive A - bus address 123454   MBR points to 123456

Rom Bios loads MBR, MBR tries to load rest of Grub
from disk at bus address 123456 and fails
(no such device or address since BIOS changed the base
address
of drive A for whatever reason during reconfiguration.)

reinstall driv

Re: GRUB failure

[Otto Haliburton]

On Fri, 2003-08-01 at 16:56, Otto Haliburton wrote:
> For you to solve this problem I think that you need to read what happens
> when you boot.  I'm not trying to insult you but from what you are
> stating you don't understand how the computer boots and therefore what
> happens in GRUB.
> 
> 
> On Fri, 2003-08-01 at 16:52, Michael Schwendt wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> > 
> > On 01 Aug 2003 16:46:29 -0500, Otto Haliburton wrote:
> > 
> > > You are getting GRUB when you boot because it is properly transferring
> > > to the MBR, but when it tries to determine where to locate the kernel
> > > image it can't fine the .conf file which tells it where that image is
> > > located.  If you added a string to the boot instruction telling it where
> > > the .conf file is it will boot.
> > 
> > Replies at the top only mess up the context.
> > 
> > The boot process does not even come as far as GRUB stage2, so forget
> > about adding any boot parameters.
> > 
> > - -- 
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1.2.2 (GNU/Linux)
> > 
> > iD8DBQE/KuES0iMVcrivHFQRAtIuAJ9bxz1aFBKqQnPJ8JuwU1Qj9haWYQCeKVsH
> > AB6xmvntWVGj03cGSqNw3Nk=
> > =NjZe
> > -END PGP SIGNATURE-

Let refine my answer to it can't find the grub directory period.
> > 
> 


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Michael Schwendt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 1 Aug 2003 17:51:38 -0500, Otto Haliburton wrote:

> What I did notice is there wasn't a /boot
> partition in the listing that was sent

You don't need a /boot partition. The grub.conf was perfectly valid with
/dev/hda1 = (hd0,0) being the root partition and containing the /boot
directory.

The code from MBR fails to load GRUB main program on primary master
drive. Either because it can't access the disk at all or because of disk
geometry confusion it loads and executes wrong sectors which causes the
machine to hang.

And since /dev/hdb doesn't appear in device.map, /dev/hdb was not even
known at install time.

- -- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/KvMN0iMVcrivHFQRAnE2AJ950MbIewcW/8JSfPBOrKfmyKh1fgCgiA/U
KD2ENGsj52Idb7yBEObc36o=
=N/ik
-END PGP SIGNATURE-


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Michael Schwendt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 1 Aug 2003 17:41:13 -0500, Otto Haliburton wrote:

> > That's where you are wrong!!!  It doesn't find the .conf file that is
> > why it goes no further.  The very first thing it does is try to locate
> > the .conf file so that [...]
> 
> *sigh*  That's certainly NOT the very first thing.
> 
> Okay it print GRUB!!!

Why don't you try what I've suggested earlier?

Test 1:

  mv /boot/grub/stage2 /boot/grub/stage2.bak
  reboot

Test 2:

  mv /boot/grub/grub.conf /boot/grub/grub.conf.bak
  reboot

- -- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/KvCZ0iMVcrivHFQRAv+aAJwNtlIGXeTb8yGCR7J1cXLFfoepnQCfYcIB
sv/5Do8fjOtYXN8r6EFrtWo=
=YM5w
-END PGP SIGNATURE-


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB Failure

[Herculano de Lima Einloft Neto]

Otto Haliburton wrote:
> 
>What I'm saying is that we know what the problem is and that is GRUB
>can't find the .conf file period.  Your solution lies in getting GRUB to
>find the .conf file.
>

  Well I'm not so sure about that.. whenever GRUB doesn't find it's grub.conf file,
it just enters it's CLI mode from where you can do things manually. This is not the
problem.
  I've had the same situation happen to me with LILO, when I first installed RH,
, and one fine day for no reason at all it happened to GRUB too.. I fixed it with
grub-install /dev/hda, but always wondered how could GRUB be so unstable. This is
the kind of problem that happens for no reason at all and will make a regular user
lose his mind.. wish I could help more;

-- 
Herculano de Lima Einloft Neto <[EMAIL PROTECTED]>


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Otto Haliburton]

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Michael Schwendt
Sent: Friday, August 01, 2003 5:42 PM
To: [EMAIL PROTECTED]
Subject: Re: GRUB failure

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 1 Aug 2003 18:26:39 -0400, Kenneth Goodwin wrote:

> Perhaps the problem owner can explain what I am
> misunderstanding here?

IMHO you have understood the problem perfectly. Unless we hear once
more from Ashley (who is confronted with this weird problem), we can
only speculate that is hardware-related most likely. Setting the
disk geometry scheme to LBA and re-installing GRUB should
_theoretically_ fix it.

- -- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/Kuyo0iMVcrivHFQRAvStAKCDlOid65zzY6vZgsgDO8Slj390rgCfeSCn
tZAZaUM33Inqz7Tddd7zhfU=
=NIUM
-END PGP SIGNATURE-


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

She


Ashley said that was done as well as changed the hardware to single boot
disk from master/slave.  The only solution seems to be reinstall hdb
which indicates to me that it is not hardware related but something is
causing the partitions to be changed. There maybe some link or
something.  What I did notice is there wasn't a /boot partition in the
listing that was sent


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Kenneth Goodwin]

Update, forgot one little detail.

>
>  Maybe I misunderstand here, but this seems to be a
situation
>  where -
>
>   A working Linux system using GRUB with MBR on HD-A,
.conf
>  file on HD-A
>   had a new disk drive HD-B added to it.
>
>   They did nothing apparently to reconfigure the box
>  bootwise.
>   They added the filesystems onto HD-B and used them for
>  whatever.
>
>   HD-B croaked.
>
>   When they removed HD-B from the ide BUS, things with
GRUB
>  broke
>   AND THEY DONT UNDERSTAND WHY?
And this is important.

AND IF they put a new hard drive back for HD-B,
grub then works fine with no changes to HD-A

>
>   Since everything for GRUB should be on HD-A which is
still
>  operational.
>   Grub should not have a problem locating the .conf file
>  since it should still
>   exist on HD-A.
>
>   So Otto, please explain why GRUB cant find the .conf
file
>  in this case
>   since it was never on the HD-B drive in the first place?
>
>   Does it copy a backup to new drives upon boot?
>   Does it "know" about new drives and get whacked out when
it
>  cant find them?
>
>  Why would GRUB whose ENTIRE RESOURCES SHOULD BE STILL
INTACT
>  On DRIVE A
>  fail to work when DRIVE B is Removed from the IDE Chain?
>
>  FYI, I am a UNIX systems programmer with 20 years of
source
>  code kernel level expertise
>  for UNIX V6 through SysV and BSD including Pyramids OSX.
>  I understand about boot loaders, have written them, and I
>  dont know why
>  they are having a problem here unless it is either
>   a hardware issue
>   a "uniqueness" in Grub that causes it to fail when
hardware
>  it does
>   not need to boot from disappears.
>
>  Perhaps the problem owner can explain what I am
>  misunderstanding here?
>
>
>
>  >  On Fri, 2003-08-01 at 16:49, Michael Schwendt wrote:
>  >  > -BEGIN PGP SIGNED MESSAGE-
>  >  > Hash: SHA1
>  >  >
>  >  > On 01 Aug 2003 16:41:17 -0500, Otto Haliburton
wrote:
>  >  >
>  >  > > The problem is, I have understood the problem.
You
>  >  can't boot when GRUB
>  >  > > can't find grub.conf.
>  >  >
>  >  > GRUB doesn't even come that far as was explained in
the
>  first
>  >  > message.
>  >  >
>  >  > If it booted into GRUB shell and then wouldn't find
the
>  >  config file,
>  >  > that would be a minor problem.
>  >  >
>  >  > > You can when it can.  When you remove hdb GRUB
>  >  > > can't find the .conf file and that is why you
can't
>  boot.
>  >  >
>  >  > As was shown, the config file is on /dev/hda1 and
>  /dev/hdb does not
>  >  > appear anywhere.
>  >  >
>  >  > - --
>  >  > -BEGIN PGP SIGNATURE-
>  >  > Version: GnuPG v1.2.2 (GNU/Linux)
>  >  >
>  >  >
>
iD8DBQE/KuBg0iMVcrivHFQRAi4nAJ4/hOWZw+ZQi5jwybAgZQVEnjsMNgCf
>  f5p1
>  >  > 8+i+mKCfBFF6sUAbDcIieQA=
>  >  > =E7F/
>  >  > -END PGP SIGNATURE-
>  >  >
>  >
>  >
>  >  --
>  >  redhat-list mailing list
>  >  unsubscribe
>  mailto:[EMAIL PROTECTED]
>  >  https://www.redhat.com/mailman/listinfo/redhat-list
>  >
>
>
>  --
>  redhat-list mailing list
>  unsubscribe
mailto:[EMAIL PROTECTED]
>  https://www.redhat.com/mailman/listinfo/redhat-list
>


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Michael Schwendt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 1 Aug 2003 18:26:39 -0400, Kenneth Goodwin wrote:

> Perhaps the problem owner can explain what I am
> misunderstanding here?

IMHO you have understood the problem perfectly. Unless we hear once
more from Ashley (who is confronted with this weird problem), we can
only speculate that is hardware-related most likely. Setting the
disk geometry scheme to LBA and re-installing GRUB should
_theoretically_ fix it.

- -- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/Kuyo0iMVcrivHFQRAvStAKCDlOid65zzY6vZgsgDO8Slj390rgCfeSCn
tZAZaUM33Inqz7Tddd7zhfU=
=NIUM
-END PGP SIGNATURE-


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Otto Haliburton]

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Michael Schwendt
Sent: Friday, August 01, 2003 5:39 PM
To: [EMAIL PROTECTED]
Subject: Re: GRUB failure

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 1 Aug 2003 17:23:40 -0500, Otto Haliburton wrote:

> That's where you are wrong!!!  It doesn't find the .conf file that is
> why it goes no further.  The very first thing it does is try to locate
> the .conf file so that [...]

*sigh*  That's certainly NOT the very first thing.

Okay it print GRUB!!!

- -- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/Kuvo0iMVcrivHFQRAvyRAJ9ZGuQJvJzhjKizIcvNLAupZ4MyqQCfZn8B
7gFkR4PUK37loYfootviriw=
=JE8v
-END PGP SIGNATURE-


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Otto Haliburton]

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Kenneth Goodwin
Sent: Friday, August 01, 2003 5:27 PM
To: [EMAIL PROTECTED]
Subject: RE: GRUB failure

>
>  Again, you're not understanding the problem.  When you
boot
>  you transfer
>  to the MBR which loads GRUB.  GRUB then loads the config
>  file and prints
>  the boot images and identifies to itself where the
kernels images are
>  located.  When you select one it transfers to that kernel
image
>  location. Sines it can't find the .conf file it has
nothing
>  to post so
>  it crashes.
>
>

Maybe I misunderstand here, but this seems to be a situation
where -

A working Linux system using GRUB with MBR on HD-A, .conf
file on HD-A
had a new disk drive HD-B added to it.

They did nothing apparently to reconfigure the box
bootwise.
They added the filesystems onto HD-B and used them for
whatever.

HD-B croaked.

When they removed HD-B from the ide BUS, things with GRUB
broke
AND THEY DONT UNDERSTAND WHY?

Since everything for GRUB should be on HD-A which is still
operational.
Grub should not have a problem locating the .conf file
since it should still
exist on HD-A.

So Otto, please explain why GRUB cant find the .conf file
in this case
since it was never on the HD-B drive in the first place?

Does it copy a backup to new drives upon boot?
Does it "know" about new drives and get whacked out when it
cant find them?

Why would GRUB whose ENTIRE RESOURCES SHOULD BE STILL INTACT
On DRIVE A
fail to work when DRIVE B is Removed from the IDE Chain?

FYI, I am a UNIX systems programmer with 20 years of source
code kernel level expertise
for UNIX V6 through SysV and BSD including Pyramids OSX.
I understand about boot loaders, have written them, and I
dont know why
they are having a problem here unless it is either
a hardware issue
a "uniqueness" in Grub that causes it to fail when hardware
it does
not need to boot from disappears.

Perhaps the problem owner can explain what I am
misunderstanding here?



>  On Fri, 2003-08-01 at 16:49, Michael Schwendt wrote:
>  > -BEGIN PGP SIGNED MESSAGE-
>  > Hash: SHA1
>  >
>  > On 01 Aug 2003 16:41:17 -0500, Otto Haliburton wrote:
>  >
>  > > The problem is, I have understood the problem.  You
>  can't boot when GRUB
>  > > can't find grub.conf.
>  >
>  > GRUB doesn't even come that far as was explained in the
first
>  > message.
>  >
>  > If it booted into GRUB shell and then wouldn't find the
>  config file,
>  > that would be a minor problem.
>  >
>  > > You can when it can.  When you remove hdb GRUB
>  > > can't find the .conf file and that is why you can't
boot.
>  >
>  > As was shown, the config file is on /dev/hda1 and
/dev/hdb does not
>  > appear anywhere.
>  >
>  > - --
>  > -BEGIN PGP SIGNATURE-
>  > Version: GnuPG v1.2.2 (GNU/Linux)
>  >
>  >
iD8DBQE/KuBg0iMVcrivHFQRAi4nAJ4/hOWZw+ZQi5jwybAgZQVEnjsMNgCf
f5p1
>  > 8+i+mKCfBFF6sUAbDcIieQA=
>  > =E7F/
>  > -END PGP SIGNATURE-
>  >
>
>
>  --
>  redhat-list mailing list
>  unsubscribe
mailto:[EMAIL PROTECTED]
>  https://www.redhat.com/mailman/listinfo/redhat-list
>


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

I agree with the what you are saying.  Something is changing when HDB is
removed.  I don't know what.  I can tell you that the same thing will
happen if you add/delete a partition on 'HAD'.  We conjectured that it
could be hardware, but they say its not so I don't know, but we do know
for a fact that it can't locate the .conf file by what projection has
taken place.  It could be as simple as the partition are being
renumbered or as complicated as a GRUB problem.  But the addition and
removal of the drive is changing something. 


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Michael Schwendt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 1 Aug 2003 17:23:40 -0500, Otto Haliburton wrote:

> That's where you are wrong!!!  It doesn't find the .conf file that is
> why it goes no further.  The very first thing it does is try to locate
> the .conf file so that [...]

*sigh*  That's certainly NOT the very first thing.

- -- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/Kuvo0iMVcrivHFQRAvyRAJ9ZGuQJvJzhjKizIcvNLAupZ4MyqQCfZn8B
7gFkR4PUK37loYfootviriw=
=JE8v
-END PGP SIGNATURE-


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Kenneth Goodwin]

>
>  Again, you're not understanding the problem.  When you
boot
>  you transfer
>  to the MBR which loads GRUB.  GRUB then loads the config
>  file and prints
>  the boot images and identifies to itself where the
kernels images are
>  located.  When you select one it transfers to that kernel
image
>  location. Sines it can't find the .conf file it has
nothing
>  to post so
>  it crashes.
>
>

Maybe I misunderstand here, but this seems to be a situation
where -

A working Linux system using GRUB with MBR on HD-A, .conf
file on HD-A
had a new disk drive HD-B added to it.

They did nothing apparently to reconfigure the box
bootwise.
They added the filesystems onto HD-B and used them for
whatever.

HD-B croaked.

When they removed HD-B from the ide BUS, things with GRUB
broke
AND THEY DONT UNDERSTAND WHY?

Since everything for GRUB should be on HD-A which is still
operational.
Grub should not have a problem locating the .conf file
since it should still
exist on HD-A.

So Otto, please explain why GRUB cant find the .conf file
in this case
since it was never on the HD-B drive in the first place?

Does it copy a backup to new drives upon boot?
Does it "know" about new drives and get whacked out when it
cant find them?

Why would GRUB whose ENTIRE RESOURCES SHOULD BE STILL INTACT
On DRIVE A
fail to work when DRIVE B is Removed from the IDE Chain?

FYI, I am a UNIX systems programmer with 20 years of source
code kernel level expertise
for UNIX V6 through SysV and BSD including Pyramids OSX.
I understand about boot loaders, have written them, and I
dont know why
they are having a problem here unless it is either
a hardware issue
a "uniqueness" in Grub that causes it to fail when hardware
it does
not need to boot from disappears.

Perhaps the problem owner can explain what I am
misunderstanding here?



>  On Fri, 2003-08-01 at 16:49, Michael Schwendt wrote:
>  > -BEGIN PGP SIGNED MESSAGE-
>  > Hash: SHA1
>  >
>  > On 01 Aug 2003 16:41:17 -0500, Otto Haliburton wrote:
>  >
>  > > The problem is, I have understood the problem.  You
>  can't boot when GRUB
>  > > can't find grub.conf.
>  >
>  > GRUB doesn't even come that far as was explained in the
first
>  > message.
>  >
>  > If it booted into GRUB shell and then wouldn't find the
>  config file,
>  > that would be a minor problem.
>  >
>  > > You can when it can.  When you remove hdb GRUB
>  > > can't find the .conf file and that is why you can't
boot.
>  >
>  > As was shown, the config file is on /dev/hda1 and
/dev/hdb does not
>  > appear anywhere.
>  >
>  > - --
>  > -BEGIN PGP SIGNATURE-
>  > Version: GnuPG v1.2.2 (GNU/Linux)
>  >
>  >
iD8DBQE/KuBg0iMVcrivHFQRAi4nAJ4/hOWZw+ZQi5jwybAgZQVEnjsMNgCf
f5p1
>  > 8+i+mKCfBFF6sUAbDcIieQA=
>  > =E7F/
>  > -END PGP SIGNATURE-
>  >
>
>
>  --
>  redhat-list mailing list
>  unsubscribe
mailto:[EMAIL PROTECTED]
>  https://www.redhat.com/mailman/listinfo/redhat-list
>


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Otto Haliburton]

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Michael Schwendt
Sent: Friday, August 01, 2003 5:12 PM
To: [EMAIL PROTECTED]
Subject: Re: GRUB failure

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01 Aug 2003 16:54:23 -0500, Otto Haliburton wrote:

> Again, you're not understanding the problem.  When you boot you
transfer
> to the MBR which loads GRUB.  GRUB then loads the config file and
prints
> the boot images and identifies to itself where the kernels images are
> located.  When you select one it transfers to that kernel image
> location. Sines it can't find the .conf file it has nothing to post so
> it crashes.

I won't repeat myself a third time after this one: If you had read
Ashley's original post, you would have seen this description:

: I was presented with a black screen with the word GRUB in the
: upper left hand corner.  Nothing else, it wouldn't boot, it just
: sat there. 

What does that tell you? Certainly not that GRUB doesn't find the
config file. It doesn't not even load stage2 from within stage1.5.
Period.

- -- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/KuW00iMVcrivHFQRAg4PAJ4qM5d54+iOoZHLOtS5iukGa/p9owCgg4Qr
llH9e6XtQJG1/Bzmc3WVAV8=
=Mr5o
-END PGP SIGNATURE-


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

That's where you are wrong!!!  It doesn't find the .conf file that is
why it goes no further.  The very first thing it does is try to locate
the .conf file so that it can print the image that you select to boot.
The first thing it prints is GRUB to tell you that GRUB was started.
Since it can't locate the .conf file it doesn't post the image.


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

RE: GRUB failure

[Otto Haliburton]

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Michael Schwendt
Sent: Friday, August 01, 2003 5:09 PM
To: [EMAIL PROTECTED]
Subject: Re: GRUB failure

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01 Aug 2003 16:56:58 -0500, Otto Haliburton wrote:

> For you to solve this problem I think that you need to read what
happens
> when you boot.  I'm not trying to insult you but from what you are
> stating you don't understand how the computer boots and therefore what
> happens in GRUB.

It's not me who has the problem. It's Ashley. ;)

I suggest you dig out the very first message and read it again.
If you want to see how it looks like, try the following:

  $ su -
  # mv /boot/grub/stage2 /boot/grub/stage2.bak
  # reboot
  
Then from what you see on the black screen, drop everything except
the word GRUB in the upper left corner.

- -- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/KuT10iMVcrivHFQRAkaxAJ92e/v8upGLr5FPoJ6uvz/R9pRkLACfXMIu
zebxM/XZ7HZ0aosfvesoMBA=
=o07C
-END PGP SIGNATURE-


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

I think if you hit the shift key it will cause GRUB to bypass the
screen. I'm not sure if it is the shift key though.  If you observe the
boot process you will see the GRUB printed first then over printed by
the "GRUB version ..." so it is transferring properly.  I've had this
happen to me before so I'm telling you what you need to do to solve the
problem.


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Michael Schwendt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01 Aug 2003 16:54:23 -0500, Otto Haliburton wrote:

> Again, you're not understanding the problem.  When you boot you transfer
> to the MBR which loads GRUB.  GRUB then loads the config file and prints
> the boot images and identifies to itself where the kernels images are
> located.  When you select one it transfers to that kernel image
> location. Sines it can't find the .conf file it has nothing to post so
> it crashes.

I won't repeat myself a third time after this one: If you had read
Ashley's original post, you would have seen this description:

: I was presented with a black screen with the word GRUB in the
: upper left hand corner.  Nothing else, it wouldn't boot, it just
: sat there. 

What does that tell you? Certainly not that GRUB doesn't find the
config file. It doesn't not even load stage2 from within stage1.5.
Period.

- -- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/KuW00iMVcrivHFQRAg4PAJ4qM5d54+iOoZHLOtS5iukGa/p9owCgg4Qr
llH9e6XtQJG1/Bzmc3WVAV8=
=Mr5o
-END PGP SIGNATURE-


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Michael Schwendt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01 Aug 2003 16:56:58 -0500, Otto Haliburton wrote:

> For you to solve this problem I think that you need to read what happens
> when you boot.  I'm not trying to insult you but from what you are
> stating you don't understand how the computer boots and therefore what
> happens in GRUB.

It's not me who has the problem. It's Ashley. ;)

I suggest you dig out the very first message and read it again.
If you want to see how it looks like, try the following:

  $ su -
  # mv /boot/grub/stage2 /boot/grub/stage2.bak
  # reboot
  
Then from what you see on the black screen, drop everything except
the word GRUB in the upper left corner.

- -- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/KuT10iMVcrivHFQRAkaxAJ92e/v8upGLr5FPoJ6uvz/R9pRkLACfXMIu
zebxM/XZ7HZ0aosfvesoMBA=
=o07C
-END PGP SIGNATURE-


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Re: GRUB failure

[Otto Haliburton]

On Fri, 2003-08-01 at 16:52, Michael Schwendt wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 01 Aug 2003 16:46:29 -0500, Otto Haliburton wrote:
> 
> > You are getting GRUB when you boot because it is properly transferring
> > to the MBR, but when it tries to determine where to locate the kernel
> > image it can't fine the .conf file which tells it where that image is
> > located.  If you added a string to the boot instruction telling it where
> > the .conf file is it will boot.
> 
> Replies at the top only mess up the context.
> 
> The boot process does not even come as far as GRUB stage2, so forget
> about adding any boot parameters.
> 
> - -- 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.2 (GNU/Linux)
> 
> iD8DBQE/KuES0iMVcrivHFQRAtIuAJ9bxz1aFBKqQnPJ8JuwU1Qj9haWYQCeKVsH
> AB6xmvntWVGj03cGSqNw3Nk=
> =NjZe
> -END PGP SIGNATURE-
> 
sorry about replying at the top.


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list