[Top] [All Lists]

Re: netbooting indy

To: <>
Subject: Re: netbooting indy
From: Kenneth C Barr <kbarr@MIT.EDU>
Date: Thu, 1 Feb 2001 23:39:47 -0500 (EST)
In-reply-to: <>
On Thu, 1 Feb 2001, Dr. David Gilbert wrote:

> On Wed, 31 Jan 2001, Kenneth C Barr wrote:
> > I finally got bootp/tftp to answer my indy's pleas for an image, but get
> > the following behavior (with my own IP addr and server, obviously):
> >
> > >> boot bootp():/vmlinux
> I haven't seen the error you got - however one thing I do differently is
> to do
> bootp():/vmlinux
> without the initial 'boot ' - worth a go?

Unfortunately this gives the same behavior.  Here are some other things I
observed.  Maybe they'll help make the solution more obvious.

1.  Same behavior on two different indys.  So it's not a flukey hardware

2.  Similar behavior with 3 different ELF kernel images (hardhat,
vmlinux-indy-2.2.1-990226, and the 2.4.0-test9).  I get the spinning
cursor and watch TFTP packets fly by.  then, it stops (with the disk full
tftp error observable on the sniffer).  Sometimes it has even rebooted
itself.  Each kernel dies after receiving a different number of blocks
(IE, I'm not filling up some buffer to the max each time), but --
and this is the most interesting thing -- repeated attempts with a fixed
kernel die at the identical block number!

eg hardhat always dies at 2130
   2.4.0 always dies at 2960

Is there something in the image at a particular point that could cause a
freeze-up or reboot like that?

3.  When I specify init=/bin/sh as a parameter, it freezes halfway through
the kernel download as usual, but on the sniffer, I can see the beginning
of an NFS conversation.  It looks for /dev/console and then follows
/bin/sh to bash at which point the SGI starts issuing seemingly malformed
READ requests.  The NFS server tries to ship it "bash" but the responses
seemed malformed, too.

Thanks for your help in conquering this!


<Prev in Thread] Current Thread [Next in Thread>