Date: Fri, 24 Dec 1999 23:02:57 +0100 From: Wilko Bulte <wilko@yedi.iaf.nl> To: Mike Smith <msmith@freebsd.org> Cc: FreeBSD-alpha mailing list <freebsd-alpha@freebsd.org> Subject: Re: diskless boot on Alpha Message-ID: <19991224230257.A67738@yedi.iaf.nl> In-Reply-To: <199912242014.MAA10876@mass.cdrom.com>; from msmith@freebsd.org on Fri, Dec 24, 1999 at 12:14:16PM -0800 References: <19991224174708.A63398@yedi.iaf.nl> <199912242014.MAA10876@mass.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Dec 24, 1999 at 12:14:16PM -0800, Mike Smith wrote:
> > that the compile of autoconf.c should include opt_nfs.h in addition to
> > opt_nfsroot.h. The latter is already present.
> ...
> > When I add opt_nfs.h to the include files in autoconf.c thing compile like
> > expected. Can somebody please verify this for me?
>
> Sounds about right to me.
OK. Do you want a wrap-up send-pr for this (i.e. as soon as I can get
it to mount it's root (assuming I can .. :-) ?
> Did you try entering
>
> nfs:192.168.200.22:/usr/sandpiper
>
> here?
Yes, I did. Forgot to include the results. These are:
>>## in cpu_rootconf
>>## nfsroot before ufs
Mounting root from ufs:192.168.200.22:/usr/sandpiper
Can't allocate root mount for filesystem 'ufs': 19
Root mount failed: 19
Manual root filesystem specification:
<fstype>:<device> Mount <device> using filesystem <fstype>
eg. ufs:/dev/da0s1a
? List valid disk boot devices
<empty line> Abort manual input
>>> nfs:192.168.200.22:/usr/sandpiper
Mounting root from nfs:192.168.200.22:/usr/sandpiper
no such device 'sandpiper'
setrootbyname failed
panic: nfs_mountroot: socreate(0000): 43
Which stems from:
nfs/nfs_vfsops.c:
/*
* Do enough of ifconfig(8) so that the critical net interface can
* talk to the server.
*/
error = socreate(nd->myif.ifra_addr.sa_family, &so, SOCK_DGRAM, 0,
p);
if (error)
panic("nfs_mountroot: socreate(%04x): %d",
nd->myif.ifra_addr.sa_family, error);
I discovered this can be fixed by adding 'options BOOTP_NFSROOT'
to the netbooted kernel.
> > Which I don't understand because vfs_mountroot() should try nfs before
> > ufs because that is the order in which cpu_rootconf sets up the
> > rootdevnames ? And in my case the kernel is compiled without
> > FFS and FFS_ROOT so it should only do NFS.
>
> I don't think that it's even getting down to the paths in rootdevnames[],
> I think it's trying to boot the path from the vfs.root.mountfrom variable
> which is set by the loader. I'm puzzled as to why it doesn't then move
> on to the fallbacks.
>
> Can you add some debugging to to sys/kern/vfs_conf.c:vfs_mountroot() and
> see exactly what's going on there? Thanks...
Like:
le0 XXX: driver didn't set ifq_maxlen
>>## in cpu_rootconf
>>## nfsroot before ufs
>>## vfs_mountroot: getenv(mountfrom) = ufs:192.168.200.22:/usr/sandpiper
Mounting root from ufs:192.168.200.22:/usr/sandpiper
Can't allocate root mount for filesystem 'ufs': 19
Root mount failed: 19
>>## vfs_mountroot: trying legacy 0
Mounting root from nfs:
bootpc_init: using network interface 'le0'
Bootpc testing starting
bootpc hw address is 8:0:2b:3c:61:45
BOOTP timeout for server 0xffffffff
BOOTP timeout for server 0xffffffff
[... etc]
It gets this far after adding "options BOOTP_NFSROOT" to the kernel
config file.
You were right with the mountfrom variable. It got a hybrid of ufs and nfs
which did not work too well. The fallback to legacy 0 gives it nfs to try
and it gets a bit further. I'm not too sure why the BOOTP timeouts keep
occuring but that is another matter.
Guessing mode: the netboot/loader code probably does a kind of setenv
which subsequently get getenv-ed by the booted kernel. If yes, where does
that value reside, and how is it foud/read back by the kernel? In new
SRM versions you can set do "set foo bar" to create a variable and give
it a value. The old SRM (like the Sandpiper has) this is not possible.
Long shot, but could this be the culprit?
--
Wilko Bulte Arnhem, The Netherlands - The FreeBSD Project
WWW : http://www.tcja.nl http://www.freebsd.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991224230257.A67738>