Re: buildworld broken
On Mon, Nov 09, 2015 at 10:56:12AM -0700, Ian Lepore wrote: > On Mon, 2015-11-09 at 06:09 -0800, Chris H wrote: > > On Sun, 8 Nov 2015 10:28:17 -0800 Steve Kargl > > wrote > > > > > On Sun, Nov 01, 2015 at 11:19:09PM -0800, NGie Cooper wrote: > > > > > > > > > /usr/obj/usr/src/tmp/usr/lib/libcrypto.so: undefined reference > > > > > to > > > > > 'PKCS7_dataInit' /usr/obj/usr/src/tmp/usr/lib/libcrypto.so: > > > > > undefined > > > > > reference to 'PKCS7_dataDecode' > > > > > /usr/obj/usr/src/tmp/usr/lib/libcrypto.so: undefined reference > > > > > to > > > > > 'PKCS7_signatureVerify' > > > > > Hi Steve, > > > > What are your custom build options? Have you patched your > > > > copy of > > > > FreeBSD? > Thanks! > > > > > > Back to trying to build freebsd. I have discovered that > > > 'make buildworld' is simply broken if one attempts to use > > > a symlink for /usr/obj. At least doing doing > > > > > > % rm -rf /usr/obj > > > > I must perform a > > chflags -R noschg > > on /usr/obj prior to blowing it away. Is it different for you, > > or did you just omit that step? > > > > In 19 years of using freebsd, I have never once needed to chflags on an > obj directory. Nothing in the build process sets any non-standard > flags in the obj dirs, and a simple rm -rf will remove everything just > fine (you would need to sudo the rm -rf if you built as root). You do not build amd64 as root, do you ? pooma% ls -lo obj-amd64/usr/home/kostik/work/build/bsd/DEV/src/lib32/usr/lib32/libc.so.7 -r--r--r-- 1 root wheel schg 1429600 Oct 24 23:23 obj-amd64/usr/home/kostik/work/build/bsd/DEV/src/lib32/usr/lib32/libc.so.7 This is an annoyance with COMPAT32 build which existed forewer. > > -- Ian > > > > % ln -s /mnt/obj /usr/obj > > > % cd /usr/src > > > % nice make -j2 buildworld > > > > > > with /mnt a UFS2 file system on a USB2 disk yields errors of the > > > above form. > > > > > > If one does > > > > > > % rm -rf /usr/obj > > > % setenv OBJDIR /mnt/obj > > > % cd /usr/src > > > % nice make -j2 buildworld > > > > > > works. So, it appears soemthing inside the make infrastructure > > > cannot > > > follow symlinks. This used to work. > > > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pf NAT and VNET Jails
On Mon, Nov 09, 2015 at 08:18:32AM -0500, Shawn Webb wrote:
> I'm using iocage for jailing.
>
> It's now looking like pf is back to being broken for me. I've tried every
> combination possible, even hardcoding the values:
>
> nat on wlan0 from {192.168.6.0/24, 192.168.7.0/24} to any -> 129.6.251.181
> pass in
> pass out
>
> I have zero idea why this isn't working. It seems that from the
> documentation,
> I'm doing everything right. I can see from tcpdump that the packets are
> getting forwarded, but without the src IP address being rewritten to
> 129.6.251.181.
>
> tcpdump output for a single ICMP packet, pinging to 8.8.8.8:
>
> 08:12:30.544462 IP 192.168.7.3 > 8.8.8.8: ICMP echo request, id 28131, seq 0,
> length 64
>
> That src IP should say 129.6.251.181.
I found the problem: it seems that the new Intel Haswell graphics
support (which I've been running with) is at odds somehow with pf NAT.
Removing Haswell graphics support means working pf NAT.
Thanks,
--
Shawn Webb
HardenedBSD
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
pgpK8LBaWhTDU.pgp
Description: PGP signature
Re: Failing buildword due to execution permission (with fix)
> >> include/Makefile:MK_OSRELDATE_SH= ${.CURDIR}/mk-osreldate.sh
> >> include/Makefile: sh ${MK_OSRELDATE_SH}
>
> I actually wrote up a patch recently to use ${SH} in all places of 'sh'
> and '/bin/sh', and noted on SHELL?= that was not useful to use, but did
> not commit it (yet).
We (junos) use HOST_SH I think for this, since if building on a non-native
host, /bin/sh cannot be relied on.
FreeBSD sys.mk already has
__MAKE_SHELL?=/bin/sh
so I guess you could use that.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cannot installworld, don't expect to...Workaround?
On Mon, 9 Nov 2015 16:10:55 -0800, Bryan Drewery wrote:
> On 11/7/2015 7:14 PM, Jeffrey Bouquet wrote:
> > I've a not-complete-installworld from today, dumped core halfway through
> > despite single-user mode...
>
> Did you use -j to installworld?
>
> --
> Regards,
> Bryan Drewery
No. May have used -j 2 to buildworld...
Just then reading Makefile and Makefile.inc1 I was wondering (for lack of
which way to proceed... install to /tmp and rsync back over the system...)
Since the build tree appears to be too complex (Makefiles too numerous) to
test each command in installworld in advance before completion to be sure
the whole lot would complete, I wonder which of the targets in those two
files are most complete in making installworld complete, at the cost of a
longer buildworld.
Something like tinderbox; toolchain; > buildworld or whatever ensures that
all binaries, libraries etc used or referenced in the buildworld/installworld
cycle
can complete a CLI without error; and that all target directories exist...
[I've had installworld fail due to missing target directories in
/usr/share for example.. which I patched up with a make -k ...]
A slight chance the installworld failed because of a drive bios quirk, though
the
chance is only slight
Another slight chance it was due to EIDE rather than SATA cabling...
Another slight chance it ran "too fast" and if slowed down (twenty Makefiles
one starts
manually. sh Makefile.1 sh Makefile.2 ... ) may complete or at least be
scrutinized
better.
...
Just so reading this post doesn't entirely anyone's time, here is an alias to
try
possibly...
[ most recent files in the current directory listed last] ... which I could
use daily.
/usr/local/bin/gnuls -halstir |grep -v drw | awk '{print $11}'
...easier to read than the plain gnuls command above.
that I figured out today. Maybe duplicate of another "ls" alias
I've already crafted, but here too many to count... so I seldom remember
more than a few.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Failing buildword due to execution permission (with fix)
On 11/9/2015 6:01 PM, Garrett Cooper wrote:
>
>> On Nov 9, 2015, at 17:27, Bryan Drewery wrote:
>>
>>> On 11/9/2015 5:17 PM, Garrett Cooper wrote:
>>>
On Nov 9, 2015, at 16:13, Bryan Drewery wrote:
>>>
>>>
>>> ...
>>>
If this is a shell file then it is best to invoke it with 'sh' rather
than a chmod/#!. The src checkout should be noexec-safe.
>>>
>>> Right. I think it'd be a good idea for me to hunt down other issues though
>>> in the build by setting -o noexec.
>>>
>>>
>>> The only thing that concerns me with doing that is that it could result in
>>> weirdness, e.g. The osreldate.h generation script in include/ .
>>
>> It prepends 'sh'.
>>
>> include/Makefile:MK_OSRELDATE_SH= ${.CURDIR}/mk-osreldate.sh
>> include/Makefile: sh ${MK_OSRELDATE_SH}
>
> Yeah... I forgot.
>
> I wrote up that patch at iX, and it was iterated over a bit. I was just
> remembering what happens when you use ${SHELL} (hint: no bueno if your build
> is kicked off with a csh/non-POSIX sh..).
>
I actually wrote up a patch recently to use ${SH} in all places of 'sh'
and '/bin/sh', and noted on SHELL?= that was not useful to use, but did
not commit it (yet).
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
Re: Failing buildword due to execution permission (with fix)
> On Nov 9, 2015, at 17:27, Bryan Drewery wrote:
>
>> On 11/9/2015 5:17 PM, Garrett Cooper wrote:
>>
>>> On Nov 9, 2015, at 16:13, Bryan Drewery wrote:
>>
>>
>> ...
>>
>>> If this is a shell file then it is best to invoke it with 'sh' rather
>>> than a chmod/#!. The src checkout should be noexec-safe.
>>
>> Right. I think it'd be a good idea for me to hunt down other issues though
>> in the build by setting -o noexec.
>>
>>
>> The only thing that concerns me with doing that is that it could result in
>> weirdness, e.g. The osreldate.h generation script in include/ .
>
> It prepends 'sh'.
>
> include/Makefile:MK_OSRELDATE_SH= ${.CURDIR}/mk-osreldate.sh
> include/Makefile: sh ${MK_OSRELDATE_SH}
Yeah... I forgot.
I wrote up that patch at iX, and it was iterated over a bit. I was just
remembering what happens when you use ${SHELL} (hint: no bueno if your build is
kicked off with a csh/non-POSIX sh..).
I'll do that soon-ish.
Thanks!
-NGie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Failing buildword due to execution permission (with fix)
On 11/9/2015 5:17 PM, Garrett Cooper wrote:
>
>> On Nov 9, 2015, at 16:13, Bryan Drewery wrote:
>
>
> ...
>
>> If this is a shell file then it is best to invoke it with 'sh' rather
>> than a chmod/#!. The src checkout should be noexec-safe.
>
> Right. I think it'd be a good idea for me to hunt down other issues though in
> the build by setting -o noexec.
>
>
> The only thing that concerns me with doing that is that it could result in
> weirdness, e.g. The osreldate.h generation script in include/ .
>
It prepends 'sh'.
include/Makefile:MK_OSRELDATE_SH= ${.CURDIR}/mk-osreldate.sh
include/Makefile: sh ${MK_OSRELDATE_SH}
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
Re: Failing buildword due to execution permission (with fix)
> On Nov 9, 2015, at 16:13, Bryan Drewery wrote: ... > If this is a shell file then it is best to invoke it with 'sh' rather > than a chmod/#!. The src checkout should be noexec-safe. Right. I think it'd be a good idea for me to hunt down other issues though in the build by setting -o noexec. The only thing that concerns me with doing that is that it could result in weirdness, e.g. The osreldate.h generation script in include/ . Thanks! -NGie ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildincludes: don't know how to make libelf.h etc.
On 11/9/2015 4:21 PM, Bryan Drewery wrote: > On 11/8/2015 10:41 AM, Franco Fichtner wrote: >> Hi everyone, >> >> I'm trying to build 11-CURRENT, but seeing missing header files >> in lib/libelf, lib/libdwarf and lib/nucurses during a seemingly >> simple `make buildworld' run. >> >> The include files land e.g. in a tmp/legacy/usr/include object >> path and copying them manually fixes that particular issue until >> the next error is triggered. >> >> I'm currently using 10.1 to build 11-CURRENT. Has anyone else >> seen this or has any idea how to solve this? >> >> > > Are you still having this problem? > > What exact release of 10.1 are you on? The release, or somewhere in head > during the 10.1 lifecycle? > > What revision were you trying to build? > > What do you have in /etc/make.conf and /etc/src.conf? > > What exact command did you run? > > Can you provide a full buildworld log please? > Also check your source tree for unknown files, such as with 'svn status'. You might have files in there which prevent an objdir from being used properly. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: buildincludes: don't know how to make libelf.h etc.
On 11/8/2015 10:41 AM, Franco Fichtner wrote: > Hi everyone, > > I'm trying to build 11-CURRENT, but seeing missing header files > in lib/libelf, lib/libdwarf and lib/nucurses during a seemingly > simple `make buildworld' run. > > The include files land e.g. in a tmp/legacy/usr/include object > path and copying them manually fixes that particular issue until > the next error is triggered. > > I'm currently using 10.1 to build 11-CURRENT. Has anyone else > seen this or has any idea how to solve this? > > Are you still having this problem? What exact release of 10.1 are you on? The release, or somewhere in head during the 10.1 lifecycle? What revision were you trying to build? What do you have in /etc/make.conf and /etc/src.conf? What exact command did you run? Can you provide a full buildworld log please? -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: Failing buildword due to execution permission (with fix)
On 11/9/2015 2:42 PM, Garrett Cooper wrote: > >> On Nov 9, 2015, at 13:35, José Pérez wrote: >> >> Hello, >> I have this buildwordl failure: >> >> ===> libexec/rbootd (depend) >> --- depend_subdir_lib --- >> --- aton_ether_subr.c --- >> /usr/src/contrib/netbsd-tests/lib/libc/net/gen_ether_subr >> /usr/src/sys/net/if_ethersubr.c ato >> n_ether_subr.c >> sh: /usr/src/contrib/netbsd-tests/lib/libc/net/gen_ether_subr: Permission >> denied >> *** [aton_ether_subr.c] Error code 126 >> >> >> I fixed with: >> chmod +x /usr/src/contrib/netbsd-tests/lib/libc/net/gen_ether_subr >> >> >> This was from a fresh checkout of current on a new machine. >> >> Is it me or shall I report a bug? > > Please file a bug and assign it to me (ngie). Is the file system mounted with > noexec? > Thanks, > -NGie If this is a shell file then it is best to invoke it with 'sh' rather than a chmod/#!. The src checkout should be noexec-safe. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: Cannot installworld, don't expect to...Workaround?
On 11/7/2015 7:14 PM, Jeffrey Bouquet wrote: > I've a not-complete-installworld from today, dumped core halfway through > despite single-user mode... Did you use -j to installworld? -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: FreeBSD_HEAD_sparc64 - Build #1311 - Still Failing
On 11/8/2015 5:55 PM, NGie Cooper wrote: > >> On Nov 7, 2015, at 10:39, Garrett Cooper wrote: >> >>> On Nov 7, 2015, at 06:18, Andriy Gapon wrote: >>> On 07/11/2015 10:00, jenkins-ad...@freebsd.org wrote: In file included from /builds/FreeBSD_HEAD_sparc64/gnu/lib/libstdc++/../../../contrib/gcc/debug.c:19: /builds/FreeBSD_HEAD_sparc64/gnu/lib/libstdc++/../../../contrib/gcc/system.h:418: error: conflicting types for 'strsignal' /builds/FreeBSD_HEAD_sparc64/obj/sparc64.sparc64/builds/FreeBSD_HEAD_sparc64/tmp/usr/include/string.h:115: error: previous declaration of 'strsignal' was here >>> >>> Has this been fixed? >> >> I don't think so.. > > Nope, still a problem. > > We have it defined in some of the config.h files — why isn’t it picking them > up properly now? > > $ grep -r HAVE_STRSIGNAL gnu/ > gnu/usr.bin/cc/libiberty/config.h:#define HAVE_STRSIGNAL 1 > gnu/usr.bin/cc/cc_tools/auto-host.h:#define HAVE_STRSIGNAL 1 > gnu/usr.bin/binutils/libiberty/config.h:#define HAVE_STRSIGNAL 1 > $ r290629 fixes it. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: r288669 breaks ports building with USE_GCC=yes
On Sun, 8 Nov 2015, Pedro Giffuni wrote: > Great! We already worked around the issue by disabling > stack-protector-strong for gcc48 though. Yep - it still felt like the right thing to also address this in the port. > What looks somewhat strange to me is that lang/gcc is an independent > port when it should just be a link to the current gcc default. This is the direction I'm working towards by establishing lang/gccX-devel ports (for snapshots) in addition to ang/gccX ports (for releases). > BTW, perhaps it’s time to bump the default gcc to gcc49? ;). Absolutely. Sadly there is a fair amount of broken software out there, and while we are close, having to fix/work around all of that has been delaying things. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196712 . In case you (or anyone else) want to help, I created a couple of bug reports that now are marked as blocking this upgrade. Help definitely appreciated. Gerald ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Failing buildword due to execution permission (with fix)
> On Nov 9, 2015, at 13:35, José Pérez wrote: > > Hello, > I have this buildwordl failure: > > ===> libexec/rbootd (depend) > --- depend_subdir_lib --- > --- aton_ether_subr.c --- > /usr/src/contrib/netbsd-tests/lib/libc/net/gen_ether_subr > /usr/src/sys/net/if_ethersubr.c ato > n_ether_subr.c > sh: /usr/src/contrib/netbsd-tests/lib/libc/net/gen_ether_subr: Permission > denied > *** [aton_ether_subr.c] Error code 126 > > > I fixed with: > chmod +x /usr/src/contrib/netbsd-tests/lib/libc/net/gen_ether_subr > > > This was from a fresh checkout of current on a new machine. > > Is it me or shall I report a bug? Please file a bug and assign it to me (ngie). Is the file system mounted with noexec? Thanks, -NGie ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Failing buildword due to execution permission (with fix)
Hello, I have this buildwordl failure: ===> libexec/rbootd (depend) --- depend_subdir_lib --- --- aton_ether_subr.c --- /usr/src/contrib/netbsd-tests/lib/libc/net/gen_ether_subr /usr/src/sys/net/if_ethersubr.c ato n_ether_subr.c sh: /usr/src/contrib/netbsd-tests/lib/libc/net/gen_ether_subr: Permission denied *** [aton_ether_subr.c] Error code 126 I fixed with: chmod +x /usr/src/contrib/netbsd-tests/lib/libc/net/gen_ether_subr This was from a fresh checkout of current on a new machine. Is it me or shall I report a bug? Regards, -- José Pérez ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: strange kernel crash
On Friday, November 06, 2015 07:02:59 PM Hans Petter Selasky wrote: > On 11/06/15 12:20, Andriy Gapon wrote: > > Now the strange part: > > > > 0x80619a18 <+744>: jne0x80619a61 > > <__mtx_lock_flags+817> > > 0x80619a1a <+746>: mov%rbx,(%rsp) > > => 0x80619a1e <+750>: movq $0x0,0x18(%rsp) > > 0x80619a27 <+759>: movq $0x0,0x10(%rsp) > > 0x80619a30 <+768>: movq $0x0,0x8(%rsp) > > Were these instructions dumped from RAM or from the kernel ELF file? Probably not from RAM. You can use 'info files' in gdb to see what is handling the address range in question (core vs executable). x/i in ddb would have been the "real" truth. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic with MAC_PORTACL on current.
On Friday, November 06, 2015 01:34:26 AM Daniel Dettlaff wrote: > Hello. > > I have my second kernel panic, related with “MAC_PORTACL” kernel module > loading in CURRENT. > The only thing to do is to put mac_portacl_load=“YES” in loader.conf and boot > machine. > > I built kernel using this config: > https://github.com/VerKnowSys/ServeD-OS/blob/master/kernel/VERKNOWSYS-11.0 > My make.conf: > https://github.com/VerKnowSys/ServeD-OS/blob/master/etc/make.conf > My src.conf: https://github.com/VerKnowSys/ServeD-OS/blob/master/etc/src.conf > My loader.conf: > https://github.com/VerKnowSys/ServeD-OS/blob/master/etc/loader.conf.served > My sysctl.conf: > https://github.com/VerKnowSys/ServeD-OS/blob/master/etc/sysctl.conf.served > > I’m using Vmware Fusion 7.0 pro as host. > > I catched that panic on main system console (verbose boot turned on): > > http://s.verknowsys.com/33551a89eda736059df6dcb35ea4eda3.png > with bt: > http://s.verknowsys.com/caeb3389d9e7399793a12c44f5760466.png > > Thank you :) Hope this will help someone, let me know if I can help somehow > further. The panic implies that the MAC policy wasn't initialized (rules_mtx hasn't been initialized). However, mac_portacl.c installs a module with a SYSINIT ordering that is long before init() starts. To debug this further you will want to trace mac_policy_modevent() to see when it is being called and if it is failing to call the init() routine in mac_portacl.c. (Arguably the portacl code should register the sysctl dynamically in its init() routine) -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildworld broken
On Mon, 09 Nov 2015 10:56:12 -0700 Ian Lepore wrote > On Mon, 2015-11-09 at 06:09 -0800, Chris H wrote: > > On Sun, 8 Nov 2015 10:28:17 -0800 Steve Kargl > > wrote > > > > > On Sun, Nov 01, 2015 at 11:19:09PM -0800, NGie Cooper wrote: > > > > > > > > > /usr/obj/usr/src/tmp/usr/lib/libcrypto.so: undefined reference > > > > > to > > > > > 'PKCS7_dataInit' /usr/obj/usr/src/tmp/usr/lib/libcrypto.so: > > > > > undefined > > > > > reference to 'PKCS7_dataDecode' > > > > > /usr/obj/usr/src/tmp/usr/lib/libcrypto.so: undefined reference > > > > > to > > > > > 'PKCS7_signatureVerify' > > > > > Hi Steve, > > > > What are your custom build options? Have you patched your > > > > copy of > > > > FreeBSD? > Thanks! > > > > > > Back to trying to build freebsd. I have discovered that > > > 'make buildworld' is simply broken if one attempts to use > > > a symlink for /usr/obj. At least doing doing > > > > > > % rm -rf /usr/obj > > > > I must perform a > > chflags -R noschg > > on /usr/obj prior to blowing it away. Is it different for you, > > or did you just omit that step? > > > > In 19 years of using freebsd, I have never once needed to chflags on an > obj directory. Nothing in the build process sets any non-standard > flags in the obj dirs, and a simple rm -rf will remove everything just > fine (you would need to sudo the rm -rf if you built as root). > > -- Ian Right you are! It has been no different for me, in those same 19yrs. I read read /usr/src && ! /usr/obj Next time, I'll take the time to finish my coffee, before I reply. Sorry for the noise. --Chris ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildworld broken
> On Nov 9, 2015, at 09:56, Ian Lepore wrote: ... >> I must perform a >> chflags -R noschg >> on /usr/obj prior to blowing it away. Is it different for you, >> or did you just omit that step? > > In 19 years of using freebsd, I have never once needed to chflags on an > obj directory. Nothing in the build process sets any non-standard > flags in the obj dirs, and a simple rm -rf will remove everything just > fine (you would need to sudo the rm -rf if you built as root). I used to have to do that in earlier/custom versions of 10.x. Vanilla FreeBSD shouldn't be setting schg on files in MAKEOBJDIRPREFIX though, ever. Thanks, -NGie ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildworld broken
On Mon, 2015-11-09 at 06:09 -0800, Chris H wrote: > On Sun, 8 Nov 2015 10:28:17 -0800 Steve Kargl > wrote > > > On Sun, Nov 01, 2015 at 11:19:09PM -0800, NGie Cooper wrote: > > > > > > > /usr/obj/usr/src/tmp/usr/lib/libcrypto.so: undefined reference > > > > to > > > > 'PKCS7_dataInit' /usr/obj/usr/src/tmp/usr/lib/libcrypto.so: > > > > undefined > > > > reference to 'PKCS7_dataDecode' > > > > /usr/obj/usr/src/tmp/usr/lib/libcrypto.so: undefined reference > > > > to > > > > 'PKCS7_signatureVerify' > > > > Hi Steve, > > > What are your custom build options? Have you patched your > > > copy of > > > FreeBSD? > Thanks! > > > > Back to trying to build freebsd. I have discovered that > > 'make buildworld' is simply broken if one attempts to use > > a symlink for /usr/obj. At least doing doing > > > > % rm -rf /usr/obj > > I must perform a > chflags -R noschg > on /usr/obj prior to blowing it away. Is it different for you, > or did you just omit that step? > In 19 years of using freebsd, I have never once needed to chflags on an obj directory. Nothing in the build process sets any non-standard flags in the obj dirs, and a simple rm -rf will remove everything just fine (you would need to sudo the rm -rf if you built as root). -- Ian > > % ln -s /mnt/obj /usr/obj > > % cd /usr/src > > % nice make -j2 buildworld > > > > with /mnt a UFS2 file system on a USB2 disk yields errors of the > > above form. > > > > If one does > > > > % rm -rf /usr/obj > > % setenv OBJDIR /mnt/obj > > % cd /usr/src > > % nice make -j2 buildworld > > > > works. So, it appears soemthing inside the make infrastructure > > cannot > > follow symlinks. This used to work. > > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 11.0-CURRENT r290273: installer fails with "out of swap space" error
On 2015-11-09 03:50, Boris Samorodov wrote: > 03.11.2015 23:50, Maxim Pugachev пишет: > >> I tried to install r29273 into Parallels VM, but got an error on >> "distextract" stage. Here is the last messages from bsdinstall_log: >> >> DEBUG: f_debug_init: ARGV=[distextract] GETOPTS_STDARGS=[dD:] >> DEBUG: f_debug_init: debug=[1] debugFile=[/tmp/bsdinstall_log] >> DEBUG: Running installation step: distextract >> Killed >> >> Last message from /var/log/messages: >> >> Nov 3 20:02:9 kernel: pid 967 (distextract), uid 0, was killed: out >> of swap space >> >> My VM has 2 gigs of memory, vmstat tells that I have ~537M free >> (swapinfo tells nothing). I dunno is it a bug or I'm doing something >> wrong. > > I've also come across with this recently. > > Don't remember all the details, something like this: > . install CURRENT to bhyve using 1G memory, get out of swap error; > . set 2G memory, got the same error, didn't try more memory (seemed > not sane to). > > Took a look at the boot environment and found out that something was > wrong (with the filesystem). Unfortunately, I do not recall now what > was it. :-( Something like too small /tmp, no /tmp at all, something > else... > > But definitely the error message was misleading and not the case of > the failure. > /tmp is usually a tmpfs, which is memory backed, and it would seem that writing something here is what would cause the out-of-memory errors. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: buildworld broken
On Sun, 8 Nov 2015 10:28:17 -0800 Steve Kargl wrote > On Sun, Nov 01, 2015 at 11:19:09PM -0800, NGie Cooper wrote: > > > > > /usr/obj/usr/src/tmp/usr/lib/libcrypto.so: undefined reference to > > > 'PKCS7_dataInit' /usr/obj/usr/src/tmp/usr/lib/libcrypto.so: undefined > > > reference to 'PKCS7_dataDecode' > > > /usr/obj/usr/src/tmp/usr/lib/libcrypto.so: undefined reference to > > > 'PKCS7_signatureVerify' > > > Hi Steve, > > What are your custom build options? Have you patched your copy of > > FreeBSD? > Thanks! > > Back to trying to build freebsd. I have discovered that > 'make buildworld' is simply broken if one attempts to use > a symlink for /usr/obj. At least doing doing > > % rm -rf /usr/obj I must perform a chflags -R noschg on /usr/obj prior to blowing it away. Is it different for you, or did you just omit that step? > % ln -s /mnt/obj /usr/obj > % cd /usr/src > % nice make -j2 buildworld > > with /mnt a UFS2 file system on a USB2 disk yields errors of the > above form. > > If one does > > % rm -rf /usr/obj > % setenv OBJDIR /mnt/obj > % cd /usr/src > % nice make -j2 buildworld > > works. So, it appears soemthing inside the make infrastructure cannot > follow symlinks. This used to work. > > -- > Steve --Chris ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pf NAT and VNET Jails
On Thursday, 05 November 2015 11:45:25 PM Kristof Provost wrote:
> > On 05 Nov 2015, at 17:25, Shawn Webb wrote:
> > I've figured it out. I've removed all rules and went with a barebones
> > config.
> >
> > Right now, the laptop I'm using for NAT has an outbound interface of wlan0
> > with an IP of 129.6.251.181 (from DHCP). The following line works:
> >
> > nat on wlan0 from any to any -> 129.6.251.181
> >
> > The following line doesn't:
> >
> > nat on wlan0 from any to any -> (wlan0)
> >
> > Nor does this:
> >
> > nat on wlan0 from any to any -> wlan0
> >
> > From the Handbook, the lines that don't work are prefered especially the
> > first non-working line, since using (wlan0) would cause pf to pick up
> > wlan0's IP dynamically (which is good, since wlan0 is DHCP'd).
> >
> > So it seems at some point of time, doing NAT dynamically broke.
>
> So far I’ve had no luck reproducing this.
> With pf.conf:
> nat on vtnet0 from any to any -> (vtnet0)
> pass in
> pass out
>
> And setup code:
> ifconfig bridge0 create
> ifconfig epair0 create
> ifconfig epair0a up
> ifconfig epair0b up
> ifconfig bridge0 addm epair0a
>
> jail -c name=test host.hostname=test vnet persist
> ifconfig epair0b vnet test
>
> ifconfig bridge0 inet 10.0.0.1/24
>
> jexec test ifconfig epair0b 10.0.0.2/23
> jexec test route add default 10.0.0.1
>
> # Activate routing
> sysctl net.inet.ip.forwarding=1
>
> pfctl -e
> pfctl -g -f pf.conf
>
> Then I run exec test ping 8.8.8.8, which works as expected.
>
> My home routing is running CURRENT, used vnet jails and also doesn’t seem to
> be triggering the problem.
>
> Perhaps we’re still missing a component of the problem, but right now I have
> no idea what that would be.
>
> Hmm. Perhaps… do you happen to know in what order things are done during
> startup? Perhaps it’s related to the fact that wlan0 is both wifi and DHCP,
> in the sense that pf is configured before the IP is assigned to the
> interface.
>
> Can you try reloading pf with the (wlan0) rule? (Just pfctl -g -f
> /etc/pf.conf should do the trick).
I'm using iocage for jailing.
It's now looking like pf is back to being broken for me. I've tried every
combination possible, even hardcoding the values:
nat on wlan0 from {192.168.6.0/24, 192.168.7.0/24} to any -> 129.6.251.181
pass in
pass out
I have zero idea why this isn't working. It seems that from the documentation,
I'm doing everything right. I can see from tcpdump that the packets are
getting forwarded, but without the src IP address being rewritten to
129.6.251.181.
tcpdump output for a single ICMP packet, pinging to 8.8.8.8:
08:12:30.544462 IP 192.168.7.3 > 8.8.8.8: ICMP echo request, id 28131, seq 0,
length 64
That src IP should say 129.6.251.181.
Thanks,
--
Shawn Webb
HardenedBSD
GPG Key ID:0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
signature.asc
Description: This is a digitally signed message part.
FreeBSD_HEAD-tests - Build #1680 - Still Unstable
FreeBSD_HEAD-tests - Build #1680 - Still Unstable:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1680/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1680/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1680/console
Change summaries:
No changes
The failed test cases:
5 tests failed.
FAILED: bin.sh.builtins.functional_test.case7
Error Message:
atf-check failed; see the output of the test for details
FAILED: bin.sh.builtins.functional_test.locale1
Error Message:
atf-check failed; see the output of the test for details
FAILED: lib.libc.locale.c16rtomb_test.c16rtomb_test
Error Message:
Premature exit; test case received signal 11 (core dumped)
FAILED: lib.libc.locale.mbrtoc16_test.mbrtoc16_test
Error Message:
Premature exit; test case received signal 11 (core dumped)
FAILED:
lib.libc.stdio.printfloat_test.thousands_separator_and_other_locale_tests
Error Message:
printf("%'.4f", 12345678.0625) ==> [1,23,45,678.0625], expected
[123,456,78.0625]<>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 11.0-CURRENT r290273: installer fails with "out of swap space" error
03.11.2015 23:50, Maxim Pugachev пишет: > I tried to install r29273 into Parallels VM, but got an error on > "distextract" stage. Here is the last messages from bsdinstall_log: > > DEBUG: f_debug_init: ARGV=[distextract] GETOPTS_STDARGS=[dD:] > DEBUG: f_debug_init: debug=[1] debugFile=[/tmp/bsdinstall_log] > DEBUG: Running installation step: distextract > Killed > > Last message from /var/log/messages: > > Nov 3 20:02:9 kernel: pid 967 (distextract), uid 0, was killed: out > of swap space > > My VM has 2 gigs of memory, vmstat tells that I have ~537M free > (swapinfo tells nothing). I dunno is it a bug or I'm doing something > wrong. I've also come across with this recently. Don't remember all the details, something like this: . install CURRENT to bhyve using 1G memory, get out of swap error; . set 2G memory, got the same error, didn't try more memory (seemed not sane to). Took a look at the boot environment and found out that something was wrong (with the filesystem). Unfortunately, I do not recall now what was it. :-( Something like too small /tmp, no /tmp at all, something else... But definitely the error message was misleading and not the case of the failure. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD_HEAD-tests - Build #1679 - Still Unstable
FreeBSD_HEAD-tests - Build #1679 - Still Unstable:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1679/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1679/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1679/console
Change summaries:
No changes
The failed test cases:
5 tests failed.
FAILED: bin.sh.builtins.functional_test.case7
Error Message:
atf-check failed; see the output of the test for details
FAILED: bin.sh.builtins.functional_test.locale1
Error Message:
atf-check failed; see the output of the test for details
FAILED: lib.libc.locale.c16rtomb_test.c16rtomb_test
Error Message:
Premature exit; test case received signal 11 (core dumped)
FAILED: lib.libc.locale.mbrtoc16_test.mbrtoc16_test
Error Message:
Premature exit; test case received signal 11 (core dumped)
FAILED:
lib.libc.stdio.printfloat_test.thousands_separator_and_other_locale_tests
Error Message:
printf("%'.4f", 12345678.0625) ==> [1,23,45,678.0625], expected
[123,456,78.0625]<>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
