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>