Re: -current broken when src is on NFS
On Sat, 2015-07-18 at 10:26 -0700, Simon J. Gerraty wrote: O'Connor, Daniel dar...@dons.net.au wrote: However, Crochet _does_ build on the NFS client _and_ when the source tree isn't in /usr/src which makes this issue very strange :-/ I've seen similar errors in rescue... (no NFS) though I cannot quite recall the cause other than it seems very sensitive to MAKEOBJDIRPREFIX value. I've been following this saga (on irc and here) as much as I have time for, and I can't escape the feeling that it is the directory structure at fault somehow, but I can't quite put my finger on it. I never (ever) build from /usr/src or use /usr/obj as an object dir (they're both empty dirs on all my machines). But one thing that is always true for me is that the source dir and its related object dir are siblings in the same parent dir. That is, it's always /any/path/here obj/ src/ Given that we have (or at least had at one time) some of those magical ... paths that cause bmake to search up the hierarchy for its .mk files, I wonder if an odd relationship between src and obj dir confuses it, or if it somehow wanders into a wrong src tree while searching? -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: -current broken when src is on NFS
On Sun, Jul 19, 2015 at 10:31:36AM -0600, Ian Lepore wrote:
I've been following this saga (on irc and here) as much as I have time
for, and I can't escape the feeling that it is the directory structure
at fault somehow, but I can't quite put my finger on it.
I never (ever) build from /usr/src or use /usr/obj as an object dir
(they're both empty dirs on all my machines). But one thing that is
always true for me is that the source dir and its related object dir are
siblings in the same parent dir. That is, it's always
/any/path/here
obj/
src/
Well, as counterpoint The systems where I do FreeBSD builds are
usually set up (and have been since about 1999) so that:
* The sources reside in /usr/src.
* The file system layput is such that:
+ /usr is on a different file system from /, but these reside in
partitions 4 and 1 (respectively) of the same slice.
+ /var is a file system that resides on a partition on slice 4.
+ swap is on slice 4, partition 2.
+ /tmp is a swap-backed tmpfs. (Well, the implementation of that has
changed over the years -- used to be mfs.)
+ My home directory resides in a file system on a partition in slice
4 mounted on /common -- along with quite a few other things that do
not need to physically be on the same slice that I booted from.
+ /usr/ports is a symlink to an SVN working copy (was a CVS working
directory once upon a time) that's in the same file system as
my home directory.
+ Historically, /usr/local was also a symlink to a hierarchy in that
same file system. (I only built ports under stable, but used them
under both stable and head.)
+ /usr/obj is also a symlink to a hierarchy in that same file system
(/common) -- I had one for each slice (/common/S{1,2,3,4}).
* Each of slices 1, 2, and 3 has a / and a /usr file system (as
described above); slice 4 has those, as well as swap, /var, /common, and
(often) a few others (e.g., /repo or /bkp).
* If I'm merely booting to single-user mode, each of the 4 slices is
independent of the others, and I can boot any of them. As soon as I
start setting up swap, I become dependent on slice 4 (if I wasn't
already booted from it).
It is not at all uncommon for me to clone one slice to another using a
'dump | restore' pipeline; by having the actual contents of /usr/obj in a
separate file system, it is easy to make copying that optional -- and if
my intent is to move it (vs. copy), renaming a directory is pretty fast
and cheap.
Given that we have (or at least had at one time) some of those magical
... paths that cause bmake to search up the hierarchy for its .mk
files, I wonder if an odd relationship between src and obj dir confuses
it, or if it somehow wanders into a wrong src tree while searching?
...
Well, I suspect that if that were an issue, I'd likely have encountered
it (while muttering further deprecation against realpath all the while).
:-}
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
pgpsYPDXAjyiE.pgp
Description: PGP signature
Re: -current broken when src is on NFS
Given that we have (or at least had at one time) some of those magical ... paths that cause bmake to search up the hierarchy for its .mk files, I wonder if an odd relationship between src and obj dir confuses it, or if it somehow wanders into a wrong src tree while searching? Based on Daniel's latest mail, the issue would appear to be the way he was setting MAKEOBJDIRPREFIX. As for .../ src.sys.env.mk resolves that to absolute path since otherwise things like kernel builds wouldn't work - make run from within obj tree. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: -current broken when src is on NFS
O'Connor, Daniel dar...@dons.net.au wrote: However, Crochet _does_ build on the NFS client _and_ when the source tree isn't in /usr/src which makes this issue very strange :-/ I've seen similar errors in rescue... (no NFS) though I cannot quite recall the cause other than it seems very sensitive to MAKEOBJDIRPREFIX value. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: -current broken when src is on NFS
On 18 Jul 2015, at 13:59, Tim Kientzle t...@kientzle.com wrote:
Crochet defaults MAKEOBJDIRPREFIX to ${WORKDIR}/obj if you have not already
set it to something else. (This avoids cross-polluting the builds if you do
regular manual cross-builds on the same machine.)
If you’re having issues with /usr/obj being on NFS, that could be a factor.
I removed NFS from the equation by building on the machine holding the source
and it still bombs out.
However, Crochet _does_ build on the NFS client _and_ when the source tree
isn't in /usr/src which makes this issue very strange :-/
--
Daniel O'Connor
The nice thing about standards is that there
are so many of them to choose from.
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: -current broken when src is on NFS
On Jul 16, 2015, at 9:57 PM, O'Connor, Daniel dar...@dons.net.au wrote:
On 16 Jul 2015, at 21:41, Rick Macklem rmack...@uoguelph.ca wrote:
r285066 fixed a POLA violation w.r.t. the old NFS client where the new
client didn't return an EEXIST error return for symlink or mkdir to userland.
The behaviour of not returning this error to userland (which was inherited
from
OpenBSD and was not the behaviour of the old FreeBSD NFS client but was
default
for the new NFS client) can be enabled via:
vfs.nfs.ignore_eexist=1
You could try setting that sysctl and seeing if it makes any difference?
That is the only recent change to the NFS client that *might* affect this.
No dice :(
It's pretty weird, it bombs out if either src or obj is on NFS..
But even weirder is that if I build with crochet (a wrapper for cross
building to arm) it works. It doesn't work if I cross build manually and I
haven't been able to determine why crochet works yet.
Crochet defaults MAKEOBJDIRPREFIX to ${WORKDIR}/obj if you have not already set
it to something else. (This avoids cross-polluting the builds if you do
regular manual cross-builds on the same machine.)
If you’re having issues with /usr/obj being on NFS, that could be a factor.
Tim
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: -current broken when src is on NFS
On 17 Jul 2015, at 14:27, O'Connor, Daniel dar...@dons.net.au wrote: On 16 Jul 2015, at 21:41, Rick Macklem rmack...@uoguelph.ca wrote: r285066 fixed a POLA violation w.r.t. the old NFS client where the new client didn't return an EEXIST error return for symlink or mkdir to userland. The behaviour of not returning this error to userland (which was inherited from OpenBSD and was not the behaviour of the old FreeBSD NFS client but was default for the new NFS client) can be enabled via: vfs.nfs.ignore_eexist=1 You could try setting that sysctl and seeing if it makes any difference? That is the only recent change to the NFS client that *might* affect this. No dice :( It's pretty weird, it bombs out if either src or obj is on NFS.. But even weirder is that if I build with crochet (a wrapper for cross building to arm) it works. It doesn't work if I cross build manually and I haven't been able to determine why crochet works yet. Relly frustraing :( So, it turns out NFS is not an issue.. I think it must be that it's not on /usr/src. I changed to building on the NFS server (which runs 10 but building -current should work OK) and it still bombs out. --- rescue.all__D --- make[5]: make[5]: don't know how to make /src/obj-amd64//src/FreeBSD-SVN/rescue/rescue//src/FreeBSD-SVN/bin/cat/cat.o. Stop That still doesn't explain how crochet and freebsd-wifi-build work though - I thought it was because they don't build rescue, but crochet does. Does anyone else see this? -- Daniel O'Connor The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
-current broken when src is on NFS
I am seeing the following breakage when building -current and the source is on
NFS
make -j 4 buildworld
...
--- rescue.all__D ---
--- rescue ---
MAKEOBJDIRPREFIX=/usr/obj/src/FreeBSD-HEAD/rescue/rescue make -f rescue.mk exe
--- sbin.all__D ---
--- pfctl_qstats.o ---
cc -O2 -pipe -Wall -Wmissing-prototypes -Wno-uninitialized
-Wstrict-prototypes -DENABLE_ALTQ -I/src/FreeBSD-HEAD/sbin/pfctl -DWITH_INET6
-DWITH_INET -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall
-Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body
-Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function
-Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum
-Wno-knr-promoted-parameter -Qunused-arguments -c
/src/FreeBSD-HEAD/sbin/pfctl/pfctl_qstats.c -o pfctl_qstats.o
--- rescue.all__D ---
--- cat_stub.c ---
echo int _crunched_cat_stub(int argc, char **argv, char **envp){return
main(argc,argv,envp);} cat_stub.c
make[5]: make[5]: don't know how to make
/usr/obj/src/FreeBSD-HEAD/rescue/rescue//src/FreeBSD-HEAD/bin/cat/cat.o. Stop
make[5]: stopped in /usr/obj/src/FreeBSD-HEAD/rescue/rescue
*** [rescue] Error code 2
I copied this source tree to /usr/src (UFS) and it built fine - I guess it's
possible it is barfing on the path name but I figure someone else would have
noticed that.
The NFS server is running 10.0-RELEASE and the NFS client is running -current
r285456, lockd is running and seems to be working (e.g., cat -l works)
--
Daniel O'Connor
The nice thing about standards is that there
are so many of them to choose from.
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: -current broken when src is on NFS
Daniel O'Conner wrote:
I am seeing the following breakage when building -current and the source is
on NFS
make -j 4 buildworld
...
--- rescue.all__D ---
--- rescue ---
MAKEOBJDIRPREFIX=/usr/obj/src/FreeBSD-HEAD/rescue/rescue make -f rescue.mk
exe
--- sbin.all__D ---
--- pfctl_qstats.o ---
cc -O2 -pipe -Wall -Wmissing-prototypes -Wno-uninitialized
-Wstrict-prototypes -DENABLE_ALTQ -I/src/FreeBSD-HEAD/sbin/pfctl
-DWITH_INET6 -DWITH_INET -std=gnu99 -fstack-protector -Wsystem-headers
-Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
-Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments
-c /src/FreeBSD-HEAD/sbin/pfctl/pfctl_qstats.c -o pfctl_qstats.o
--- rescue.all__D ---
--- cat_stub.c ---
echo int _crunched_cat_stub(int argc, char **argv, char **envp){return
main(argc,argv,envp);} cat_stub.c
make[5]: make[5]: don't know how to make
/usr/obj/src/FreeBSD-HEAD/rescue/rescue//src/FreeBSD-HEAD/bin/cat/cat.o.
Stop
make[5]: stopped in /usr/obj/src/FreeBSD-HEAD/rescue/rescue
*** [rescue] Error code 2
r285066 fixed a POLA violation w.r.t. the old NFS client where the new
client didn't return an EEXIST error return for symlink or mkdir to userland.
The behaviour of not returning this error to userland (which was inherited from
OpenBSD and was not the behaviour of the old FreeBSD NFS client but was default
for the new NFS client) can be enabled via:
vfs.nfs.ignore_eexist=1
You could try setting that sysctl and seeing if it makes any difference?
That is the only recent change to the NFS client that *might* affect this.
To be honest, I have no idea what the correct behaviour for // in a pathname
is?
rick
I copied this source tree to /usr/src (UFS) and it built fine - I guess it's
possible it is barfing on the path name but I figure someone else would have
noticed that.
The NFS server is running 10.0-RELEASE and the NFS client is running -current
r285456, lockd is running and seems to be working (e.g., cat -l works)
--
Daniel O'Connor
The nice thing about standards is that there
are so many of them to choose from.
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: -current broken when src is on NFS
On 16 Jul 2015, at 21:41, Rick Macklem rmack...@uoguelph.ca wrote: r285066 fixed a POLA violation w.r.t. the old NFS client where the new client didn't return an EEXIST error return for symlink or mkdir to userland. The behaviour of not returning this error to userland (which was inherited from OpenBSD and was not the behaviour of the old FreeBSD NFS client but was default for the new NFS client) can be enabled via: vfs.nfs.ignore_eexist=1 You could try setting that sysctl and seeing if it makes any difference? That is the only recent change to the NFS client that *might* affect this. No dice :( It's pretty weird, it bombs out if either src or obj is on NFS.. But even weirder is that if I build with crochet (a wrapper for cross building to arm) it works. It doesn't work if I cross build manually and I haven't been able to determine why crochet works yet. Relly frustraing :( To be honest, I have no idea what the correct behaviour for // in a pathname is? Nothing, they just get eaten. This isn't AmigaDOS! :) -- Daniel O'Connor The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
