Re[2]: make installworld for i386 fails on Kyuafile

Hello, Seems this issue raised again in r272469, at least today and yesterday installworld fails. Last time was few minutes ago with the revision shown. > > install: /usr/tests/lib/libproc/Kyuafile: No such file or directory > > Fixed in r271950. Problem introduced in r271937 which seems to h

Recent changes in libthr broke base bind package tools and named on amd64

I've recently installworld my test setup and found bind tools: dig, host hangs during usage (latest bind 9.8.2 in -CURRENT base. The same with named too. Replacing /lib/libthr.so.3 with previous build (26 march) eliminates the problem. backtrace every time the same: (gdb) bt #0 0x00080123a

Re: buildworld fails on FreeBSD 7.x for HEAD from 19.04.2012

===> usr.bin/file (all) /usr/bin/clang -O2 -pipe -DMAGIC='"/usr/share/misc/magic"' -DHAVE_CONFIG_H -I/usr/src/usr.bin/file/../../lib/libmagic -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes

building port zsh (static version) failed on r235325

cc -L/usr/local/lib -rpath=/usr/lib:/usr/local/lib -static   -o zsh main.o  `cat stamp-modobjs`   -L/usr/local/lib -Wl,-R/usr/local/lib -lpcre -liconv -lncursesw -lrt -lm  -lc /usr/lib/libc.a(jemalloc_jemalloc.o): In function `calloc': jemalloc_jemalloc.c:(.text+0x1d80): multiple definition of `c

Recent nandfs commits broke buildworld with clang

env MACHINE=amd64 CPP="/usr/bin/clang-cpp"  sh /usr/src/usr.bin/kdump/mkioctls print /usr/obj/usr/src/tmp/usr/include > ioctl.c :34:10: fatal error: 'fs/nandfs/nandfs_fs.h' file not found #include ^ 1 error generated. /bin/sh /usr/src/usr.bin/kdump/../../sys/kern/makesyscalls.sh  /usr/s

pf reply-to malfunction after r258468 (seems r258479)

I have a test setup with direct internet connection Reail_IP_A and netgraph tunnel with Real_IP_B. I have used a reply-to pf ruleset to sent all the traffic back via tunnel, if it came via tunnel: pass in quick on $tunnel_if reply-to ($tunnel_if 10.1.0.1) \ proto tcp from any to Real_IP_B port 4

pf reply-to malfunction after r258468 (seems r258479)

I have a test setup with direct internet connection Reail_IP_A and netgraph tunnel with Real_IP_B. I have used a reply-to pf ruleset to sent all the traffic back via tunnel, if it came via tunnel: pass in quick on $tunnel_if reply-to ($tunnel_if 10.1.0.1) \ proto tcp from any to Real_IP_B por

Re[2]: pf reply-to malfunction after r258468 (seems r258479)

Dear Gleb, Is kernel rebuilding enuff ? Vladimir, On Tue, Dec 03, 2013 at 11:52:26AM +0200, Vladimir Sharun wrote: V> I have a test setup with direct internet connection Reail_IP_A and netgraph tunnel with Real_IP_B. V> I have used a reply-to pf ruleset to sent all the traffic ba

Re[2]: pf reply-to malfunction after r258468 (seems r258479)

Dear Gleb, Unfortunately can't boot both revisions kernel, it hangs on "trying to mount root from ssdzfs"  (which is my zfs root). Vladimir, On Tue, Dec 03, 2013 at 11:52:26AM +0200, Vladimir Sharun wrote: V> I have a test setup with direct internet connection Reail_IP_A an

Re[2]: pf reply-to malfunction after r258468 (seems r258479)

Dear Gleb, Yesterday I (finally) got my server back to work and the problem disappear. Can't reproduce it anymore on r258865. On Tue, Dec 03, 2013 at 07:54:08PM +0200, Vladimir Sharun wrote: V> Dear Gleb, V> Unfortunately can't boot both revisions kernel, it hangs on "

ARC "pressured out", how to control/stabilize ? (reformatted to text/plain)

Good day community, We ran the system in production with r259544 on it. 128Gb RAM, 72Gb - arc_max and 42Gb - arc_min set in loader.conf. The system ran both application (which are FS ops hungry) and 18Tb storage on this setup. >From the start, ARC clearly shows 72Gb of memory consumed, but durin

Re[2]: ARC "pressured out", how to control/stabilize ? (reformatted to text/plain)

Dear Andriy and FreeBSD community, I got the few minutes run for this dtrace hook; here's the output for 15 minutes run: http://pastebin.com/pKm9kLwa Does it explain something ? > on 04/01/2014 14:50 Vladimir Sharun said the following: > [snip] > > ARC: 28G Total, 2085M

Re[2]: ARC "pressured out", how to control/stabilize ? (reformatted to text/plain)

Let's imagine the situation, we found l2arc_feed_thread allocations is the cause, what shall our next step ? The feedback from us will be here within few days (can't reproduce faster) > on 06/01/2014 13:14 Vladimir Sharun said the following: > > Dear Andriy and FreeBSD community

Re[2]: ARC "pressured out", how to control/stabilize ? (reformatted to text/plain)

Dear Andriy and FreeBSD community, > I am not sure if the buffers are leaked somehow or if they are actually in > use. > It's one of the very few places where data buffers are allocated without > charging ARC. In all other places it's quite easy to match allocations and > deallocations. But in

Re[2]: ARC "pressured out", how to control/stabilize ? (reformatted to text/plain)

So, again, what shall we do to better understand/mitigate the problem further ? Thank you. > on 15/01/2014 12:28 Vitalij Satanivskij said the following: > > Dear Andriy and FreeBSD community, > > > > Andriy Gapon wrote: > > AG> on 14/01/2014 07:27 Vladimir Sharun said

Re[2]: ARC "pressured out", how to control/stabilize ? (reformatted to text/plain)

within few days and will come back with the result. Thank you for your help. > on 28/01/2014 11:28 Vladimir Sharun said the following: > > Dear Andriy and FreeBSD community, > > > > After applying this path one of the systems runs fine (disk subsystem load > > lo

Re: sshd sandbox failure

Dear Ian, Seems it must be in UPDATING or even in the buildworld: without capsicum framework support no ssh access to the server anymore. I step in the same problem this weekend, thank to the IPMI on the home testebed I figured out what's the cause. > Hi > > Since the openssh update in re

Re: sshd sandbox failure

Dear Ian, Seems it must be in UPDATING or even in the buildworld: without capsicum framework support no ssh access to the server anymore. I step in the same problem this weekend, thank to the IPMI on the home testebed I figured out what's the cause. > Hi > > Since the openssh update in re

Unable to build kernel #263665 "config: illegal option -- I"

Hello FreeBSD comunity, Got yesterday following issue with #263665: # make kernel -- >>> Kernel build for COBALT started on Sun Mar 23 17:44:45 EET 2014 -- ===> COBALT mkdir -

Re[2]: Unable to build kernel #263665 "config: illegal option -- I"

Hello Milan, This solution (make toolchain first) cure the problem. Thank you. > did see this (or something similar) too. Cured with 'make > kernel-toolchain' and only then 'make buildkernel'. Could you try tis? ___ freebsd-current@freebsd.org mailing

Strong memory leak in r264294

Hello there, We're just put on test e5-1650 with 128Gb RAM 36x1Tb in several zmirrors, 2 days uptime and: Mem: 1643M Active, 13G Inact, 96G Wired, 37M Cache, 14G Free ARC: 48G Total, 30G MFU, 10G MRU, 3296K Anon, 790M Header, 6992M Other Swap: Wired minus ARC = 48G, then: quick calculation on

gpart destroy, zpool destroy, zfs destroy under securelevel 3

Hello FreeBSD community, Recently plays with securelevel and what I discover: no chance for data to survive against remote root, except backups of course. Maybe this log can be a proposal for raising securelevel further or include securelevel support against the software which can deal with zfs

Re[2]: gpart destroy, zpool destroy, zfs destroy under securelevel 3

Hello, > if you have root privileges you can just write some random bytes in some > places and this will be enough to break your system. So, restricting > some gpart's or zpool's actions depending from securelevel looks like > protection from kids. Having root under securelevel 3 confirmed disall

Re[2]: gpart destroy, zpool destroy, zfs destroy under securelevel 3

Hello, > Ok, you are right. But geom_dev restricts access only from user level > applications. When GEOM object does access directly via GEOM methods > this protection won't work. And it seems it isn't easy to fix, all > classes should have own check. Thank you for better clarification. This is t