/usr/src over NFS: buildworld fail

[Rick Macklem]

Andrew Romanenko wrote:
> 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 at freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> >> To unsubscribe, send any mail to
> >> "freebsd-stable-unsubscribe at 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 at 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?
Sounds like a question for the Linux NFS mailing list. All I can mention is
that most NFS servers use an fsid to uniquely identify a file system on the
server. It is often a part of the file handle.

Anyhow, thanks for letting us know. If someone reports a similar problem,
we can suggest trying adding fsid=<N> to their Linux server's export line.

Thanks, rick

> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
> "freebsd-stable-unsubscribe at freebsd.org"