Date: Sun, 15 Jan 2006 17:10:12 GMT From: Ruben Kerkhof <ruben.kerkhof@gmail.com> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/91720: pxeboot always tries to do an rpc call to an nfs-server Message-ID: <200601151710.k0FHACpx010333@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/91720; it has been noted by GNATS. From: Ruben Kerkhof <ruben.kerkhof@gmail.com> To: Ceri Davies <ceri@submonkey.net> Cc: freebsd-gnats-submit@freebsd.org Subject: Re: kern/91720: pxeboot always tries to do an rpc call to an nfs-server Date: Sun, 15 Jan 2006 18:03:57 +0100 ------=_Part_7636_17784620.1137344637091 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 1/14/06, Ceri Davies <ceri@submonkey.net> wrote: > > > On 12 Jan 2006, at 19:23, Ruben Kerkhof wrote: > > > I want to use the pxeboot loader to use an mfsroot as root, not an > > nfs mount. > > In /usr/src/sys/boot/i386/libi386/pxe.c line 340, the function > > pxe_setnfshandle always gets called. If you don't have an nfs > > server running, the loader gives the error "NFS MOUNT RPC Error". > > It continues loading the mfsroot over tftp though. > > Sorry, can you confirm whether it works or not. > > "It continues loading the mfsroot over tftp" sounds like it's doing > what you want, but it obviously is not. Could you clarify that a > little please? > > Thanks, > > Ceri > Hi Ceri, It does indeed do what I want, but the issue is that it takes a while for pxeboot to notice that it can't mount nfs. Since I compiled the loader with LOADER_TFTP_SUPPORT, I don't think it should try to do an rpc call in the first place. This slows down the booting process. Although the nfs mount error is harmless, it makes people (like me) think there's something wrong. If my memory is right, it behaved ok before patch 1.21 ( http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/i386/libi386/pxe.c.diff?= r1=3D1.20&r2=3D1.21 ) Cheers, Ruben ------=_Part_7636_17784620.1137344637091 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline <br><br> <div><span class=3D"gmail_quote">On 1/14/06, <b class=3D"gmail_sendername">= Ceri Davies</b> <<a href=3D"mailto:ceri@submonkey.net">ceri@submonkey.ne= t</a>> wrote:</span> <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0= px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>On 12 Jan 2006, at 19:23, Ru= ben Kerkhof wrote:<br><br>> I want to use the pxeboot loader to use an m= fsroot as root, not an <br>> nfs mount.<br>> In /usr/src/sys/boot/i386/libi386/pxe.c line 34= 0, the function<br>> pxe_setnfshandle always gets called. If you don't h= ave an nfs<br>> server running, the loader gives the error "NFS MOU= NT RPC Error". <br>> It continues loading the mfsroot over tftp though.<br><br>Sorry, c= an you confirm whether it works or not.<br><br>"It continues loading t= he mfsroot over tftp" sounds like it's doing<br>what you want, but it = obviously is not. Could you clarify that a <br>little please?<br><br>Thanks,<br><br>Ceri<br></blockquote></div> <div>Hi Ceri,</div> <div> </div> <div>It does indeed do what I want, but the issue is that it takes a while = for pxeboot to notice that it can't mount nfs.</div> <div>Since I compiled the loader with LOADER_TFTP_SUPPORT, I don't think it= should try to do an rpc call in the first place.</div> <div>This slows down the booting process. Although the nfs mount error is h= armless, it makes people (like me) think there's something wrong.</div> <div> </div> <div>If my memory is right, it behaved ok before patch 1.21 (<a href=3D"htt= p://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/i386/libi386/pxe.c.diff?r1= =3D1.20&r2=3D1.21">http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/i= 386/libi386/pxe.c.diff?r1=3D1.20&r2=3D1.21 </a>)</div> <div> </div> <div>Cheers,</div> <div> </div> <div>Ruben<br> </div> ------=_Part_7636_17784620.1137344637091--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200601151710.k0FHACpx010333>