Date: Sun, 12 Mar 2017 11:49:00 -0600 From: Ian Lepore <ian@freebsd.org> To: =?ISO-8859-1?Q?Otac=EDlio?= <otacilio.neto@bsd.com.br>, freebsd-arm@freebsd.org Subject: Re: FreeBSD on Pine64 experience Message-ID: <1489340940.40576.84.camel@freebsd.org> In-Reply-To: <fe13db5d-01ac-1e96-3d9e-e6d691193a92@bsd.com.br> References: <20170220124619.7f04ad6a@zeta.dino.sk> <20170224182831.76c15809@zeta.dino.sk> <20170312174353.13e1110d@zeta.dino.sk> <fe13db5d-01ac-1e96-3d9e-e6d691193a92@bsd.com.br>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2017-03-12 at 14:05 -0300, Otacílio wrote: > Em 12/03/2017 13:43, Milan Obuch escreveu: > > > > [ snip ] > > > > > > > > > > > > > Originally it was 12.0-CURRENT #<svn revision number> - does > > > > anybody > > > > know where this revision number is being lost? Could it be > > > > somehow > > > > caused by fact my src tree was 'svn checkout'ed on another > > > > machine > > > > (i386)? > > > > > > > Well, I can not verify my theory - I am not able to do svn > > > checkout > > > into nfs mounted directory from arm64 and armv6 systems (nfsd > > > runs on > > > i386 system). Maybe it just could not work this way... > > > > > This problem is solved, discussion was on hackers mailing list, > > basically mount option nolockd was the clue. However, on Pine64, I > > am > > getting now occasional errors > > > > pid 12421 (sh), uid 0, was killed: text file modification > > > > preventing me to rebuild some port or source if tree is mounted > > over > > nfs. I remember mentioning on some mailing list it could be related > > to > > nfs, today I decide to use HDD attached via USB for ports tree and > > no > > error occured. So this definitely means there is something in nfs > > code, > > probably arm64 specific as I did not see something like this on arm > > system, which causes this error. > > > > I will try to do another full rebuild with /usr/src and /usr/obj > > located on local USB attached HDD to see if there is any > > difference. My > > svn revision is r314342 currently, there is some discrepancy now > > however, as I have kernel slightly newer than world. > > > > Another note - I upgraded misc/mc port today, and I see something > > strange. See: > > > > # pkg check -d -a > > Checking all packages: 100% > > mc is missing a required shared library: libglib-2.0.so.0 > > mc is missing a required shared library: libssh2.so.1 > > mc is missing a required shared library: libintl.so.8 > > # ldd /usr/local/bin/mc > > /usr/local/bin/mc: > > libncursesw.so.8 => /lib/libncursesw.so.8 (0x4011c000) > > libssh2.so.1 => /usr/local/lib/libssh2.so.1 (0x4017c000) > > libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 > > (0x401b1000) > > libintl.so.8 => /usr/local/lib/libintl.so.8 (0x402b1000) > > libc.so.7 => /lib/libc.so.7 (0x402ca000) > > libz.so.6 => /lib/libz.so.6 (0x40452000) > > libssl.so.8 => /usr/lib/libssl.so.8 (0x40477000) > > libcrypto.so.8 => /lib/libcrypto.so.8 (0x404ea000) > > libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x406ba000) > > libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x407c2000) > > libthr.so.3 => /lib/libthr.so.3 (0x4084e000) > > # ll /usr/local/lib/libglib-2.0.so.0 > > lrwxr-xr-x 1 root wheel 23 Feb 17 20:13 /usr/local/lib/libglib- > > 2.0.so.0@ -> libglib-2.0.so.0.4600.2 > > # ll /usr/local/lib/libintl.so.8 > > lrwxr-xr-x 1 root wheel 16 Feb 17 00:00 > > /usr/local/lib/libintl.so.8@ -> libintl.so.8.1.5 > > # ll /usr/local/lib/libssh2.so.1 > > lrwxr-xr-x 1 root wheel 16 Feb 17 20:28 > > /usr/local/lib/libssh2.so.1@ -> libssh2.so.1.0.1 > > > > And mc seems to be just working... rebuilding misc/mc does not > > change > > the situation. > > > > Regards, > > Milan > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.o > > rg" > I faced this same problem about "text file modification" on a RPI3 > take > a look: > > https://lists.freebsd.org/pipermail/freebsd-arm/2017-March/015789.htm > l > > []'s > > -Otacilio > Another thread related to the same problem: https://lists.freebsd.org/pipermail/freebsd-current/2017-March/065131.html As I mentioned there just now, it may be possible to work around this with sysctl vfs.timestamp_precision, but I'm not sure exactly how. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1489340940.40576.84.camel>