Date: Tue, 29 Jun 2010 11:29:00 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: alexs@ulgsm.ru Cc: freebsd-stable@freebsd.org Subject: Re: diskless boot, nfs server behind router Message-ID: <Pine.GSO.4.63.1006291122170.28831@muncher.cs.uoguelph.ca> In-Reply-To: <20100629064902.GA39446@mail.ulgsm.ru> References: <20100625152027.GA78442@mail.ulgsm.ru> <Pine.GSO.4.63.1006252008340.8512@muncher.cs.uoguelph.ca> <20100626113418.GA80299@mail.ulgsm.ru> <Pine.GSO.4.63.1006261020100.15701@muncher.cs.uoguelph.ca> <20100628061601.GA51359@mail.ulgsm.ru> <20100628102703.GA78354@mail.ulgsm.ru> <Pine.GSO.4.63.1006281011180.8202@muncher.cs.uoguelph.ca> <E1OTFDh-000OrT-LR@kabab.cs.huji.ac.il> <Pine.GSO.4.63.1006282038070.20639@muncher.cs.uoguelph.ca> <20100629064902.GA39446@mail.ulgsm.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 29 Jun 2010, alexs@ulgsm.ru wrote:
>>
>> I think using NFS_ROOT but not the BOOTPxxx options will work around this
>> or you could test the following patch and see if it helps. (Testing the
>> patch would be appreciated, since I don't have any way to test across
>> multiple subnets and it would be nice to have a fix for the BOOTPxxx
>> cases.)
>>
>> rick
>> --- untested patch for bootp_subr.c ---
>> --- nfsclient/bootp_subr.c.sav 2010-06-28 19:16:02.000000000 -0400
>> +++ nfsclient/bootp_subr.c 2010-06-28 19:21:52.000000000 -0400
>> @@ -1524,6 +1524,7 @@
>> printf(" ");
>> ifctx->gotgw = 1;
>> gctx->gotgw = 1;
>> + nd->mygateway = ifctx->gw;
>> }
>> }
>
>
> Yes. without BOOTPxxx options boot is fine.
>
Ok, so at least you got it working.
>
> I tryed your path with BOOTPxxx options, result panic.
>
> Trying to mount root from nfs:
> Panic: nfs_mountroot: RTM_ADD: 17
> cpuid=1
> Uptime 10s
>
Oh well, the patch was just a stab in the dark. The panic indicates that
it already has the route set up (17 == EEXIST), so trying to set it
again failed and panic'd.
So, I don't know why the case with BOOTPxxx options fails to get through
the gateway. If you feel like doing so, you could capture a packet trace
(via tcpdump, wireshark, ...) after reverting the patch. The easiest way
to do this would be to plug the client and another machine that can
do the packet capture into an old 10baseT (non-switched) hub. If you don't
have one of those, most network switches will allow a port to be
"mirrored" (at least I think that's the term used), so that the packets
come out on a second port for the machine doing the capturing. You could
do a capture at the server end, but it probably wouldn't tell you anything
useful (the packets wouldn't show up, is my guess?).
Anyhow, thanks for the help tracking this down and we now know NFS_ROOT
works for this case and BOOTPxxx doesn't, rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.63.1006291122170.28831>