Subject: Re: better success netbooting SunFire V100 with 1.6 (miniroot image must be corrupt)
To: NetBSD/sparc64 Discussion List <port-sparc64@NetBSD.ORG>
From: Andrey Petrov <petrov@netbsd.org>
List: port-sparc64
Date: 09/27/2002 22:53:36
On Fri, Sep 27, 2002 at 07:05:58PM -0400, Greg A. Woods wrote:
> [[ 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.

Yeah, I meant that program, and if program doesn't work I wouldn't
call it 'corrupted'.

> 
> 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.

Supposed to be the same.

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

I believe this also should be there.

> 
> 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.

That's a good point, and you can easily verify that, actually
you can check what component is wrong in that miniboot.fs while I'm
guessing here.

> 
> 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....
> 

During netbooting ofwboot gets root and other filesystems locations
(i use bootparamd variant and have only rootfs specified) not filename to boot,
it gets it from firmware, that's my understanding. It's possible to build
'debug' version of ofwboot so it will be more verbose.


	Andrey