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) Best regards, Andrew Romanenko
Andrew Romanenko <melanhit at gmail.com> writes:> /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?I've been doing that for years, with no problems. If you NFS-mount the src tree, do you do it read-only? When the src is reached by NFS, where is the obj tree (usually /usr/obj), and how is *it* accessed? Does it have enough space? Also, I'd generally recommend mounting the src read-only.> i386 FreeBSD 9-STABLE (r250044)Good luck.
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. -- | Jeremy Chadwick jdc at koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |
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
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"