Subject: Re: netboot
To: Mark H. Levine <yba@polytronics.com>
From: Curt Sampson <cjs@portal.ca>
List: port-alpha
Date: 11/03/1997 22:30:12
This is a known problem, and it comes up in other contexts, such
as when you want to boot a kernel other than /netbsd. I don't have
a workaround at the moment, but it's definitely on my List Of Things
To Fix. The problem is as much with the Alpha console as anything
else, sad to say.

There seems to be a general movement away from using bootparamd,
which is a bit of a relief to tell the truth. Let me know if you
find any interesting workarounds; I won't have any time to work on
this until after the 1.3 release.

cjs

Curt Sampson    cjs@portal.ca	   Info at http://www.portal.ca/
Internet Portal Services, Inc.	   Through infinite myst, software reverberates
Vancouver, BC  (604) 257-9400	   In code possess'd of invisible folly.

On Mon, 3 Nov 1997, Mark H. Levine wrote:

> To: cjs@netbsd.org
> Cc: port-alpha@netbsd.org
> Subject: netboot
> Date: Mon, 03 Nov 1997 18:25:39 -0500
> From: "Mark H. Levine" <yba@polytronics.com>
> 
> 
> I'm  checking  out  NetBSD/Alpha  1.3  and  have  read  your  new
> netbooting page at www.cynic.net. 
> 
> We lost something in the recent change --  previously  we  at  my
> site  were  able to get the kernel from our build machine, from a
> separate spot on it so as not to conflict with the running kernel
> on the development machine using "rp", and then mount the network
> file systems for swap and root off our disk farm (a sparc storage
> array). 
> 
> It seems you are now using the remote path (rp=) field  for  both
> the  location  of a kernel and the root directory of the nfs file
> system, and these can no longer be on two separate machines,  the
> way it could be by using rpc.bootparamd. 
> 
> This isn't severe of course, we can just ftp kernels to the sparc
> array  before  booting  and take from the root partitions, but it
> also means setting up a tftp server there since we can't use  the
> Alphas at the same time. 
> 
> Is there a workaround available, perhaps can we add new variables
> that the kernel will use to support separate tftp and nfs servers
> (some sort of remote nfs path, and an nfs server field)? 
>