From owner-freebsd-alpha Fri Dec 24 14:18: 3 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 905C614D64; Fri, 24 Dec 1999 14:17:54 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id XAA11748; Fri, 24 Dec 1999 23:10:20 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id XAA68176; Fri, 24 Dec 1999 23:02:57 +0100 (CET) (envelope-from wilko) Date: Fri, 24 Dec 1999 23:02:57 +0100 From: Wilko Bulte To: Mike Smith Cc: FreeBSD-alpha mailing list Subject: Re: diskless boot on Alpha Message-ID: <19991224230257.A67738@yedi.iaf.nl> References: <19991224174708.A63398@yedi.iaf.nl> <199912242014.MAA10876@mass.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <199912242014.MAA10876@mass.cdrom.com>; from msmith@freebsd.org on Fri, Dec 24, 1999 at 12:14:16PM -0800 X-OS: FreeBSD yedi.iaf.nl 3.4-STABLE FreeBSD 3.4-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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: : Mount using filesystem eg. ufs:/dev/da0s1a ? List valid disk boot devices 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