Date: Sat, 04 May 2013 01:03:30 +0300 From: Andrew Romanenko <melanhit@gmail.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: Jeremy Chadwick <jdc@koitsu.org>, freebsd-stable@freebsd.org Subject: Re: /usr/src over NFS: buildworld fail Message-ID: <51843432.6060401@gmail.com> In-Reply-To: <1269813286.56503.1367447453738.JavaMail.root@erie.cs.uoguelph.ca> References: <1269813286.56503.1367447453738.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On 05/02/2013 01:30 AM, Rick Macklem wrote: > Andrew Romanenko wrote: >> On 04/30/2013 02:51 AM, Jeremy Chadwick wrote: >>> On Mon, Apr 29, 2013 at 09:42:06PM +0300, Andrew Romanenko wrote: >>>> Hi everyone! >>>> /usr/src imported via NFS >>>> make buildworld is always fails in the same place with error: >>>> "make: result too large". >>>> Localy its works fine >>>> Does anybody know how to fix it? >>>> >>>> i386 FreeBSD 9-STABLE (r250044) >>> Actual output would have been more useful than a paraphrased >>> response. >>> The same goes for actual NFS server and client details (OS, backing >>> filesystems, make.conf, src.conf, rc.conf, loader.conf, sysctl.conf, >>> etc.). >>> >>> "Result too large" is error ERANGE (see /usr/include/errno.h), errno >>> 34, >>> assuming that it has a capital "R" ("Result", not "result"). >>> >>> I see no cases in src/usr.bin/make/* where ERANGE or errno 34 is >>> returned directly. >>> >>> I do not believe NFS returns ERANGE either. >>> >>> There may be cases where the backing filesystem (i.e. the filesystem >>> used on the NFS server) could return ERANGE. I know ZFS does, but >>> only >>> in one specific case (only if the compression property is enabled). >>> I do see some other cases in the ZFS code pertaining to UTF-8 >>> support >>> that can return ERANGE but did not look at what those cases may be. >>> >>> You may end up having to do the following: >>> >>> rm -fr /usr/obj/* >>> cd /usr/src >>> ktrace -t+ -f /tmp/ktrace.out make buildworld >>> {wait until the failure} >>> cd /tmp >>> kdump >>> >>> Then look to see what syscall/operation returns this. You may have >>> to >>> put this file up on the web somewhere (it should gzip quite well), >>> and >>> be aware there may be personal information in it (environment >>> variables, >>> contents of files, etc.), so choose wisely. >>> >>> Good luck. >>> >> Fixed. Trouble was in Linux NFS-server. >> Also, thx Jeremy for the tip (ktrace + kdump) >> thanks, everyone >> > Coule you please provide more information on the Linux NFS-server issue? > It might be useful if/when others run into interoperability > problems against a Linux NFS server. > > Thanks, rick > >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to >> "freebsd-stable-unsubscribe@freebsd.org" Server: Linux Sabayon (Linux localhost.localdomain 3.8.0-sabayon #1 SMP Fri Mar 29 13:54:24 UTC 2013 i686 Genuine Intel(R) CPU T2080 @ 1.73GHz GenuineIntel GNU/Linux) Package: net-fs/nfs-utils-1.2.7 /etc/exports /home/bsd/src 192.168.56.1/24(rw,async,no_subtree_check,root_squash,anonuid=1000,anongid=1001,fsid=1000) Client: Freebsd 9-STABLE (FreeBSD ion.uabsd.org 9.1-STABLE FreeBSD 9.1-STABLE #0 r250121: Wed May 1 23:38:36 EEST 2013 root@ion.uabsd.org:/usr/obj/usr/src/sys/GENERIC i386) mount command: mount -t nfs -o ro,nfsv3,tcp 192.168.56.1:/home/bsd/src /usr/src Fix: add option fsid=(1000 or any number) to /etc/exports . I don't understand, Why fsid is so important?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51843432.6060401>