[[ forwarding this to port-sparc64 where it belongs, but where I'm not
(yet) subscribed.... ]]

[ On Friday, September 27, 2002 at 14:42:28 (-0700), Andrey Petrov wrote: ]
> Subject: Re: better success netbooting SunFire V100 with 1.6 (miniroot image must be corrupt)
>
> On Thu, Sep 26, 2002 at 09:51:07PM -0400, Greg A. Woods wrote:
> > It seems the miniroot.fs image for NetBSD/sparc64 1.6 is corrupt.  I
> > have been able to successfully netboot a SunFire V100, but am unable to
> > get it to even begin to load the miniroot image, as I noted in a post
> > the other day.
> 
> That's unlikely, I tried that very miniboot image and it works all right
> on ultra2. I'd suspect ofwboot in this failure.

If by "ofwboot" you mean the copy of the "ofwboot" program that's
supposed to be installed in the miniroot filesystem image, then isn't
that much the same as saying the miniroot.fs is corrupt in some respect?  :-)

OK, "corrupt" is the wrong word I suppose.

However isn't the ofwboot installed in the miniroot filesystem identical
to the one that gets installed when you install on a local disk?  I can
boot the system successfully from the local disk once it's installed.

How is the primary bootstrap (/usr/mdec/bootblk) installed in the
miniroot.fs image for sparc64?

I read in installboot(8):

   NetBSD/sparc64
     Install the Berkeley Fast File System primary bootstrap on to disk `wd0':
           installboot /dev/rwd0c /usr/mdec/bootblk

     The secondary NetBSD/sparc64 bootstrap is located in /usr/mdec/ofwboot.

Also I was wondering: is the miniroot is using the memory-disk INSTALL
kernel yet?  I know that in 1.5W on sparc it wasn't -- I've been having
fun working around the issues that causes when you re-partition the
drive out from under the running minitroot....  :-)


> > Note that it seems impossible to pass the filename properly to ofwboot,
> > at least when using BOOTPARAMS.  I had to put the kernel in the NFS
> > server's directory as "netbsd".  Attempts to boot with any different
> > filename simply resulted in a "Boot:" prompt and when I failed to type
> > the correct filename and then hit return it tried to boot what I typed
> > and then fell back to trying to boot the alternate kernel names starting
> > with "netbsd.gz" IIRC.  During this process the ofwboot program seemed
> > impervious to BREAK signals (i.e. LOM "break" commands).
> 
> 'works for me' on different hardware, so ofwboot might be under suspicion.

I was wondering if maybe the logic in ofwboot clobbered the filename
when it failed to get a bootp reply, but I haven't yet looked at the
source code....

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>