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)?
>