Re: Read-only /usr/obj/ no longer kosher?
On Tue, Aug 25, 2015 at 03:32:35PM -0700, NGie Cooper wrote: On Tue, Aug 25, 2015 at 3:21 PM, Xin Li delp...@delphij.net wrote: On 08/25/15 14:55, Pawel Jakub Dawidek wrote: Now that I think of it, it might have been that I did buildworld/buildkernel before -p1. Then freebsd-update updated newvers.sh and then I was trying to do installworld. Yes, I can now reproduce it with source updated to -p2. Yes, that's because freebsd-version.sh is generated from the files (but it's not clear to me whether if it's a bug or a feature that 'make install' checks if it's up-to-date and decides to regenerate it...). It's a quirk for sure. If you change the behavior, people will definitely complain as they will now need to go back and rebuild everything. What we have now is misleading. People should recompile. It is rather rare to see security advisory which bumps only patch level and something that doesn't require recompilation (eg. a shell script). Current behaviour would make people think they are running latest patch level because freebsd-version says so, eventhough they only did 'make installworld' without rebuilding affected binaries. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com pgpRsLnByGkaA.pgp Description: PGP signature
Re: HEADS UP: sparc64 backend for llvm/clang imported
On Wed, Aug 19, 2015 at 04:19:03PM -0400, Kurt Lidl wrote: Dimitry Andric wrote this message on Fri, Feb 28, 2014 at 20:22 +0100: In r262613 I have merged the clang-sparc64 branch back to head. This imports an updated sparc64 backend for llvm and clang, allowing clang to bootstrap itself on sparc64, and to completely build world. To be able to build the GENERIC kernel, there is still one patch to be finalized, see below. If you have any sparc64 hardware, and are not afraid to encounter rough edges, please try out building and running your system with clang. To do so, update to at least r262613, and enable the following options in e.g. src.conf, or in your build environment: WITH_CLANG=y WITH_CLANG_IS_CC=y WITH_LIBCPLUSPLUS=y (optional) Alternatively, if you would rather keep gcc as /usr/bin/cc for the moment, build world using just WITH_CLANG, enabling clang to be built (by gcc) and installed. After installworld, you can then set CC=clang, CXX=clang++ and CPP=clang-cpp for building another world. For building the sparc64 kernel, there is one open issue left, which is that sys/sparc64/include/pcpu.h uses global register variables, and this is not supported by clang. A preliminary patch for this is attached, but it may or may not blow up your system, please beware! The patch changes the pcpu and curpcb global register variables into inline functions, similar to what is done on other architectures. However, the current approach is not optimal, and the emitted code is slightly different from what gcc outputs. Any improvements to this patch are greatly appreciated! Last but not least, thanks go out to Roman Divacky for his work with llvm/clang upstream in getting the sparc64 backend into shape. Ok, I have a new pcpu patch to try. I have only compile tested it. It is available here: https://www.funkthat.com/~jmg/sparc64.pcpu.patch I've also attached it. Craig, do you mind testing it? This patch also removes curpcb as it appears to not be used by any sparc64 C code. A GENERIC kernel compiles fine, and fxr only turns up curpcb used in machdep code, and no references to it under sparc64. This is not a proper solution in that it can mean counters/stats can be copied/moved to other cpus overwriting the previous values if a race happens... We use PCPU_SET(mem, PCPU_GET(mem) + val) for PCPU_ADD, not great, but it's no worse than what we were previously using.. Until we get a proper fix which involves mapping all the cpu's PCPU data on all CPUs, this will have to sufice.. This patch is based upon, I believe, a patch from Marius and possibly modified by rdivacky. Thanks for testing.. The above message was posted a while ago, and I decided that I would give the patch a test run on a spare sparc that I have, now that the instability problem with multiprocessor sparc64 machines has been resolved. So, I have an up-to-date stable/10 V240 (2x1.5Ghz cpus, 8GB of memory), running a completely stock r286861. That all seems to work just fine. I applied the patch referenced in the email: https://www.funkthat.com/~jmg/sparc64.pcpu.patch (it applied cleanly), and then rebuilt the kernel on the machine, using the stock gcc 4.2.1 compiler. When rebooting with that kernel, the machine panics pretty early in the boot: FreeBSD 10.2-STABLE #3 r286861M: Wed Aug 19 14:28:45 EDT 2015 l...@spork.pix.net:/usr/obj/usr/src/sys/GENERIC sparc64 gcc version 4.2.1 20070831 patched [FreeBSD] real memory = 8589934592 (8192 MB) avail memory = 8379719680 (7991 MB) cpu0: Sun Microsystems UltraSparc-IIIi Processor (1503.00 MHz CPU) cpu1: Sun Microsystems UltraSparc-IIIi Processor (1503.00 MHz CPU) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs random device not loaded; using insecure entropy panic: trap: illegal instruction (kernel) cpuid = 0 KDB: stack backtrace: #0 0xc05750e0 at panic+0x20 #1 0xc08db9f8 at trap+0x558 Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... timeout shutting down CPUs. So, the patch to get rid of the pcpu usage (as a prereq to poking at the clang compiler issues) does not work properly. As I pointed out when that patch was posted, the approach taken by it assumes a CPU can access foreign PCPU data, which currently isn't true on sparc64. So the patch is at least incomplete but also may have further issues. Such a patch is no longer a prerequisite for compiling a sparc64 kernel with clang, though, as clang meanwhile has been told to grok at least the global registers used by the PCPU code. Besides some default options like the choice of code model not being appropriate for FreeBSD, clang-compiled loader and kernel don't work due to two major problems present in clang up to at least version 3.6.0: a) it uses a different stack layout than GCC so any unwinding code fails and b) it produces broken
Re: Instant panic while trying run ports-mgmt/poudriere
Hi Konstantin, On 2015-08-23 15:54 +0300, Konstantin Belousov kostik...@gmail.com wrote: After looking at your data closely, I think you are right. The panic occurs when the exit1(9) does KNOTE_LOCKED(NOTE_EXIT). This is the only case in the tree where filter uses knlist_remove_inevent() to detach processed note, so indeed the slist is modified under the iterator. Below is the patch with the suggested change and unrelated cleanup of the uma(9) KPI use. Please test, everybody who has a panic with the backtrace pointing to the sys_exit(). This patch fixes issue for me. Thank you. -- pozdrawiam / with regards Paweł Pękala ___ 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: HEADS UP: sparc64 backend for llvm/clang imported
On Wed, Aug 26, 2015 at 11:14:51PM +0200, Marius Strobl wrote: On Wed, Aug 19, 2015 at 04:19:03PM -0400, Kurt Lidl wrote: Dimitry Andric wrote this message on Fri, Feb 28, 2014 at 20:22 +0100: In r262613 I have merged the clang-sparc64 branch back to head. This imports an updated sparc64 backend for llvm and clang, allowing clang to bootstrap itself on sparc64, and to completely build world. To be able to build the GENERIC kernel, there is still one patch to be finalized, see below. If you have any sparc64 hardware, and are not afraid to encounter rough edges, please try out building and running your system with clang. To do so, update to at least r262613, and enable the following options in e.g. src.conf, or in your build environment: WITH_CLANG=y WITH_CLANG_IS_CC=y WITH_LIBCPLUSPLUS=y (optional) Alternatively, if you would rather keep gcc as /usr/bin/cc for the moment, build world using just WITH_CLANG, enabling clang to be built (by gcc) and installed. After installworld, you can then set CC=clang, CXX=clang++ and CPP=clang-cpp for building another world. For building the sparc64 kernel, there is one open issue left, which is that sys/sparc64/include/pcpu.h uses global register variables, and this is not supported by clang. A preliminary patch for this is attached, but it may or may not blow up your system, please beware! The patch changes the pcpu and curpcb global register variables into inline functions, similar to what is done on other architectures. However, the current approach is not optimal, and the emitted code is slightly different from what gcc outputs. Any improvements to this patch are greatly appreciated! Last but not least, thanks go out to Roman Divacky for his work with llvm/clang upstream in getting the sparc64 backend into shape. Ok, I have a new pcpu patch to try. I have only compile tested it. It is available here: https://www.funkthat.com/~jmg/sparc64.pcpu.patch I've also attached it. Craig, do you mind testing it? This patch also removes curpcb as it appears to not be used by any sparc64 C code. A GENERIC kernel compiles fine, and fxr only turns up curpcb used in machdep code, and no references to it under sparc64. This is not a proper solution in that it can mean counters/stats can be copied/moved to other cpus overwriting the previous values if a race happens... We use PCPU_SET(mem, PCPU_GET(mem) + val) for PCPU_ADD, not great, but it's no worse than what we were previously using.. Until we get a proper fix which involves mapping all the cpu's PCPU data on all CPUs, this will have to sufice.. This patch is based upon, I believe, a patch from Marius and possibly modified by rdivacky. Thanks for testing.. The above message was posted a while ago, and I decided that I would give the patch a test run on a spare sparc that I have, now that the instability problem with multiprocessor sparc64 machines has been resolved. So, I have an up-to-date stable/10 V240 (2x1.5Ghz cpus, 8GB of memory), running a completely stock r286861. That all seems to work just fine. I applied the patch referenced in the email: https://www.funkthat.com/~jmg/sparc64.pcpu.patch (it applied cleanly), and then rebuilt the kernel on the machine, using the stock gcc 4.2.1 compiler. When rebooting with that kernel, the machine panics pretty early in the boot: FreeBSD 10.2-STABLE #3 r286861M: Wed Aug 19 14:28:45 EDT 2015 l...@spork.pix.net:/usr/obj/usr/src/sys/GENERIC sparc64 gcc version 4.2.1 20070831 patched [FreeBSD] real memory = 8589934592 (8192 MB) avail memory = 8379719680 (7991 MB) cpu0: Sun Microsystems UltraSparc-IIIi Processor (1503.00 MHz CPU) cpu1: Sun Microsystems UltraSparc-IIIi Processor (1503.00 MHz CPU) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs random device not loaded; using insecure entropy panic: trap: illegal instruction (kernel) cpuid = 0 KDB: stack backtrace: #0 0xc05750e0 at panic+0x20 #1 0xc08db9f8 at trap+0x558 Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... timeout shutting down CPUs. So, the patch to get rid of the pcpu usage (as a prereq to poking at the clang compiler issues) does not work properly. As I pointed out when that patch was posted, the approach taken by it assumes a CPU can access foreign PCPU data, which currently isn't true on sparc64. So the patch is at least incomplete but also may have further issues. Such a patch is no longer a prerequisite for compiling a sparc64 kernel with clang, though, as clang meanwhile has been told to grok at least the global registers used by the PCPU code. Besides some default options like the choice of code model not being appropriate for FreeBSD, clang-compiled loader and kernel don't
Jenkins build is back to normal : Build-UFS-image #2200
See https://jenkins.FreeBSD.org/job/Build-UFS-image/2200/ ___ 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: Instant panic while trying run ports-mgmt/poudriere
Andriy Gapon wrote this message on Sun, Aug 23, 2015 at 09:54 +0300:
On 12/08/2015 17:11, Lawrence Stewart wrote:
On 08/07/15 07:33, Pawel Pekala wrote:
Hi K.,
On 2015-08-06 12:33 -0700, K. Macy km...@freebsd.org wrote:
Is this still happening?
Still crashes:
+1 for me running r286617
Here is another +1 with r286922.
I can add a couple of bits of debugging data:
(kgdb) fr 8
#8 0x80639d60 in knote (list=0xf8019a733ea0,
hint=2147483648, lockflags=value optimized out) at
/usr/src/sys/kern/kern_event.c:1964
1964} else if ((lockflags KNF_NOKQLOCK) != 0) {
(kgdb) p *list
$2 = {kl_list = {slh_first = 0x0}, kl_lock = 0x8063a1e0
We should/cannot get here w/ an empty list. If we do, then there is
something seriously wrong... The current kn (which we must have as we
are here) MUST be on the list, but as you just showed, there are no
knotes on the list.
Can you get me a print of the knote? That way I can see what flags
are on it?
knlist_mtx_lock, kl_unlock = 0x8063a200 knlist_mtx_unlock,
kl_assert_locked = 0x8063a220 knlist_mtx_assert_locked,
kl_assert_unlocked = 0x8063a240 knlist_mtx_assert_unlocked,
kl_lockarg = 0xf8019a733bb0}
(kgdb) disassemble
Dump of assembler code for function knote:
0x80639d00 knote+0: push %rbp
0x80639d01 knote+1: mov%rsp,%rbp
0x80639d04 knote+4: push %r15
0x80639d06 knote+6: push %r14
0x80639d08 knote+8: push %r13
0x80639d0a knote+10: push %r12
0x80639d0c knote+12: push %rbx
0x80639d0d knote+13: sub$0x18,%rsp
0x80639d11 knote+17: mov%edx,%r12d
0x80639d14 knote+20: mov%rsi,-0x30(%rbp)
0x80639d18 knote+24: mov%rdi,%rbx
0x80639d1b knote+27: test %rbx,%rbx
0x80639d1e knote+30: je 0x80639ef6 knote+502
0x80639d24 knote+36: mov%r12d,%eax
0x80639d27 knote+39: and$0x1,%eax
0x80639d2a knote+42: mov%eax,-0x3c(%rbp)
0x80639d2d knote+45: mov0x28(%rbx),%rdi
0x80639d31 knote+49: je 0x80639d38 knote+56
0x80639d33 knote+51: callq *0x18(%rbx)
0x80639d36 knote+54: jmp0x80639d42 knote+66
0x80639d38 knote+56: callq *0x20(%rbx)
0x80639d3b knote+59: mov0x28(%rbx),%rdi
0x80639d3f knote+63: callq *0x8(%rbx)
0x80639d42 knote+66: mov%rbx,-0x38(%rbp)
0x80639d46 knote+70: mov(%rbx),%rbx
0x80639d49 knote+73: test %rbx,%rbx
0x80639d4c knote+76: je 0x80639ee5 knote+485
0x80639d52 knote+82: and$0x2,%r12d
0x80639d56 knote+86: nopw %cs:0x0(%rax,%rax,1)
0x80639d60 knote+96: mov0x28(%rbx),%r14
Panic is in the last quoted instruction.
And:
(kgdb) i reg
rax0x246582
rbx0xdeadc0dedeadc0de -2401050962867404578
rcx0x0 0
rdx0x12e302
rsi0x80a26a5a -2136839590
rdi0x80e81b80 -2132272256
rbp0xfe02b7efea20 0xfe02b7efea20
rsp0xfe02b7efe9e0 0xfe02b7efe9e0
r8 0x80a269ce -2136839730
r9 0x80e82838 -2132269000
r100x1 65536
r110x80fabd10 -2131051248
r120x0 0
r130xf801ff84a818 -8787511171048
r140xf801ff84a800 -8787511171072
r150xf8019a6974f0 -8789207452432
rip0x80639d60 0x80639d60 knote+96
eflags 0x10286 66182
I think that $rbx stands out here (this is a kernel with INVARIANTS).
Yeh, it was probably r284861 that I added to catch use after free bugs
like this... You could try reverting r284861 to see if the bug goes
away... If it does, then this is most likely a use after free bug...
Looking at the code, is it possible that one of the calls from within
the loop's body modifies the list? If that is so and provided that is a
valid behavior, then maybe using SLIST_FOREACH_SAFE would help.
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
___
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: Instant panic while trying run ports-mgmt/poudriere
Konstantin Belousov wrote this message on Mon, Aug 24, 2015 at 11:10 +0300:
On Sun, Aug 23, 2015 at 10:35:44PM -0700, John-Mark Gurney wrote:
Konstantin Belousov wrote this message on Sun, Aug 23, 2015 at 15:54 +0300:
if (kev-flags EV_ADD)
- tkn = knote_alloc(waitok); /* prevent waiting with locks */
+ /*
+ * Prevent waiting with locks. Non-sleepable
+ * allocation failures are handled in the loop, only
+ * if the spare knote appears to be actually required.
+ */
+ tkn = knote_alloc(waitok);
if you add this comment, please add curly braces around the block...
Ok.
else
tkn = NULL;
@@ -1310,8 +1315,7 @@ done:
FILEDESC_XUNLOCK(td-td_proc-p_fd);
if (fp != NULL)
fdrop(fp, td);
- if (tkn != NULL)
- knote_free(tkn);
+ knote_free(tkn);
Probably should just change knote_free to a static inline that does
a uma_zfree as uma_zfree also does nothing is the input is NULL...
This was already done in the patch (the removal of the NULL check in
knote_free()). I usually do not add excessive inline keywords. Compilers
are good, sometimes even too good, at figuring out the possibilities for
inlining. knote_free() is inlined automatically.
Though it is, if we really change knote_free to a bare uma_free, then
either mark it inline (to be explicit about it's behavior), or make a
macro out of it... I don't particularly like functions that contain one
line of simple code...
@@ -1948,7 +1948,7 @@ knote(struct knlist *list, long hint, int lockflags)
* only safe if you want to remove the current item, which we are
* not doing.
*/
- SLIST_FOREACH(kn, list-kl_list, kn_selnext) {
+ SLIST_FOREACH_SAFE(kn, list-kl_list, kn_selnext, tkn) {
Clearly you didn't read the comment that preceeds this line, or at
least didn't update it:
* SLIST_FOREACH, SLIST_FOREACH_SAFE is not safe in our case, it is
* only safe if you want to remove the current item, which we are
* not doing.
So, you'll need to be more specific in why this needs to change...
When I wrote this code, I spent a lot of time looking at this, and
reasoned as to why SLIST_FOREACH_SAFE was NOT correct usage here...
I explained what happens in the message. The knote list is modified
by the filter, see knlist_remove_inevent() call in filt_proc().
kq = kn-kn_kq;
KQ_LOCK(kq);
if ((kn-kn_status (KN_INFLUX | KN_SCAN)) == KN_INFLUX) {
@@ -2385,15 +2385,16 @@ SYSINIT(knote, SI_SUB_PSEUDO, SI_ORDER_ANY,
knote_init, NULL);
static struct knote *
knote_alloc(int waitok)
{
- return ((struct knote *)uma_zalloc(knote_zone,
- (waitok ? M_WAITOK : M_NOWAIT)|M_ZERO));
+
+ return (uma_zalloc(knote_zone, (waitok ? M_WAITOK : M_NOWAIT) |
+ M_ZERO));
}
static void
per above, we should add inline here...
knote_free(struct knote *kn)
{
- if (kn != NULL)
- uma_zfree(knote_zone, kn);
+
+ uma_zfree(knote_zone, kn);
}
/*
I agree w/ the all the non-SLIST changes, but I disagree w/ the SLIST
change as I don't believe that all cases was considered...
What cases do you mean ?
The patch does not unlock knlist lock in the iteration. As such, the
only thread which could remove elements from the knlist, or rearrange
the list, while loop is active, is the current thread. So I claim that
the only the current iterating element can be removed, and the next list
element stays valid. This is enough for _SAFE loop to work.
Why do you think that _SAFE is incorrect ? Comment talks about very
I can't think of the reason right now, but I do remeber puzzling over
this issue for some hours when I wrote this code, and I had proved
to myself that _SAFE was NOT _SAFE for this use case...
In the quick look I just had, I have not been able to decide one way
or the other, but I'm suspicious that this is a recent issue, as this
code has been running for close to a decade w/o any issues, and wonder
if there was some other change that trigger the issue...
The reason I'm cautious about changing this is that the code has been
running fine for over a decade... Have you done a full test to
validate that nothing else breaks?
Ok, after looking more at the original dump, this is a use after free
bug... As I said in another email, it should not be possible to get
into the _FOREACH loop where knlist is an empty list. If it does,
then there is another major bug that needs to be found... A simple
change to _SAFE will not fix this use after free bug...
different case, where the knlist lock is dropped. Then indeed, other
thread may iterate in parallel, and invalidate the memoized next element
while KN_INFLUX is set for the current element and knlist is dropped.
But _SAFE in sys/queue.h never means 'safe for
HWPMC panic
Was playing with pmcstats -S instructions -T, and got the following when I tried to ctrl/c out. oldtbh.lerctr.org dumped core - see /var/crash/vmcore.3 Wed Aug 26 16:05:16 CDT 2015 FreeBSD oldtbh.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #18 r287033: Sun Aug 23 18:08:24 CDT 2015 r...@oldtbh.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 panic: [p4,700] class mismatch pd 260 != id class 4 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... Unread portion of the kernel message buffer: panic: [p4,700] class mismatch pd 260 != id class 4 cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0238744770 vpanic() at vpanic+0x189/frame 0xfe02387447f0 kassert_panic() at kassert_panic+0x132/frame 0xfe0238744860 p4_read_pmc() at p4_read_pmc+0x185/frame 0xfe02387448b0 pmc_stop() at pmc_stop+0x132/frame 0xfe02387448f0 pmc_syscall_handler() at pmc_syscall_handler+0x1752/frame 0xfe0238744ae0 amd64_syscall() at amd64_syscall+0x25d/frame 0xfe0238744bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0238744bf0 --- syscall (0, FreeBSD ELF64, nosys), rip = 0x801407ffa, rsp = 0x7fffe588, rbp = 0x7fffe5a0 --- Uptime: 2d8h36m19s Dumping 3475 out of 8158 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/if_lagg.ko.symbols...done. Loaded symbols for /boot/kernel/if_lagg.ko.symbols Reading symbols from /boot/kernel/hwpmc.ko.symbols...done. Loaded symbols for /boot/kernel/hwpmc.ko.symbols #0 doadump (textdump=1) at pcpu.h:221 221 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:221 #1 0x80b34ca5 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:329 #2 0x80b35298 in vpanic (fmt=value optimized out, ap=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:626 #3 0x80b350c2 in kassert_panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:516 #4 0x8242ee25 in p4_read_pmc (cpu=1, ri=12, v=0xf8012b206aa0) at /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_piv.c:699 #5 0x82425102 in pmc_stop (pm=0xf8012b206a80) at /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_mod.c:2741 #6 0x82423a12 in pmc_syscall_handler (td=value optimized out, syscall_args=value optimized out) at /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_mod.c:3923 #7 0x80f7c38d in amd64_syscall (td=0xf801060759a0, traced=0) at subr_syscall.c:133 #8 0x80f5b26b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:395 #9 0x000801407ffa in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) vmcore IS available, and I *CAN* give ssh access. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 ___ 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: [fix] Shared object libsodium.so.13 not found, required by dnscrypt-proxy
I was testing with this again recently and it seems the big difference is
local_unbound!
BtW Barry thanks for the suggestion but I (and I think others) mentioned in
the thread that adding ldconfig REQUIRE in dnscrypt made no difference.
A box with dnscrypt+unbound doesn't have the issue,so I compared the 2 rc.d
scripts and noticed unbound doesn't use:
# BEFORE: NETWORKING
btw why would we want local_unbound BEFORE networking? doesn't it make
more sense to run it after, If something fails there (NETWORKG)
local_unbound won't be usable anyway, or am I saying something stupid? :P
Melhores Cumprimentos // Best Regards
---
*Miguel Clara*
*IT - Sys Admin Developer*
On Fri, Jul 24, 2015 at 11:35 PM, Barry Allard barry.all...@gmail.com
wrote:
Folks,
The issue is that ldconfig must run before dnscrypt-proxy so it can find
the sodium shared lib.
One simple fix is to change /usr/local/etc/rc.d/dnscrypt-proxy (might not
cover every edge case, but it appears to work.)
# PROVIDE: dnscrypt_proxy
# REQUIRE: ldconfig cleanvar
# BEFORE: SERVERS
# KEYWORD: shutdown
No more circular depends and ldconfig is always first.
$ rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | awk
'/SERVERS|dnscrypt-proxy|cleanvar|ldconfig|dbus/{print NR,$0}'
rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision
`kerberos'
rcorder: file `/usr/local/etc/rc.d/tcsd' is before unknown provision
`named'
rcorder: requirement `tpmd' in file `/usr/local/etc/rc.d/tcsd' has no
providers.
rcorder: requirement `slapd' in file `/usr/local/etc/rc.d/postfix' has no
providers.
rcorder: requirement `slapd' in file `/usr/local/etc/rc.d/dovecot' has no
providers.
18 /etc/rc.d/cleanvar
67 /etc/rc.d/ldconfig
68 /usr/local/etc/rc.d/dnscrypt-proxy
75 /etc/rc.d/SERVERS
(Feel free to fw: to the list. Also documented upstream
https://github.com/jedisct1/dnscrypt-proxy/issues/242 in case someone
else runs into this.)
Regards,
Barry Allard
___
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: Read-only /usr/obj/ no longer kosher?
On 27 Aug 2015, at 08:25, Pawel Jakub Dawidek p...@freebsd.org wrote: On Tue, Aug 25, 2015 at 03:32:35PM -0700, NGie Cooper wrote: On Tue, Aug 25, 2015 at 3:21 PM, Xin Li delp...@delphij.net wrote: On 08/25/15 14:55, Pawel Jakub Dawidek wrote: Now that I think of it, it might have been that I did buildworld/buildkernel before -p1. Then freebsd-update updated newvers.sh and then I was trying to do installworld. Yes, I can now reproduce it with source updated to -p2. Yes, that's because freebsd-version.sh is generated from the files (but it's not clear to me whether if it's a bug or a feature that 'make install' checks if it's up-to-date and decides to regenerate it...). It's a quirk for sure. If you change the behavior, people will definitely complain as they will now need to go back and rebuild everything. What we have now is misleading. People should recompile. It is rather rare to see security advisory which bumps only patch level and something that doesn't require recompilation (eg. a shell script). Current behaviour would make people think they are running latest patch level because freebsd-version says so, eventhough they only did 'make installworld' without rebuilding affected binaries. So.. How hard would it be to force CC/CXX to /usr/bin/false during installworld? -- 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 https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
FreeBSD_HEAD - Build #3131 - Failure
FreeBSD_HEAD - Build #3131 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3131/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3131/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3131/console Change summaries: 287186 by imp: Automatically append SUBDIR.yes to the SUBDIR variable, and remove duplicates. We cannot sort SUBDIR because many Makefiles have .WAIT in the list which is strongly ordering. Rather than try to second guess when to sort and when to not sort depending on .WAIT being in the list, just remove duplicates. 287185 by imp: For each FOO in FILESLISTS, append the value of FOO.yes, sort, and remove duplicates. 287183 by imp: When the kernel is compiled with INVARIANTS, export that as debug.invariants. Differential Revision: https://reviews.freebsd.org/D3488 MFC after: 3 days 287182 by tuexen: Add SCTP support. PR: 201585 MFC after: 3 weeks 287181 by delphij: Replace strndup with OpenBSD's implementation. MFC after: 2 weeks 287179 by tuexen: Remove a variable which is set but never used. PR: 201585 MFC after: 3 weeks 287178 by tuexen: Print the status on the first line of a socket description, not at the last one. This doesn't matter for TCP, but it does for the upcoming SCTP support. PR: 201585 MFC after: 3 weeks The end of the build log: [...truncated 56593 lines...] clang-tblgen -gen-clang-diags-defs -clang-component=Sema -I /builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Basic -d DiagnosticSemaKinds.inc.d -o DiagnosticSemaKinds.inc.h /builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td --- DiagnosticCommonKinds.inc.h --- --- Options.inc.h --- --- DiagnosticCommonKinds.inc.h --- clang-tblgen -gen-clang-diags-defs -clang-component=Common -I /builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Basic -d DiagnosticCommonKinds.inc.d -o DiagnosticCommonKinds.inc.h /builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td --- Options.inc.h --- tblgen -gen-opt-parser-defs -I /builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/include -I /builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Driver -d Options.inc.d -o Options.inc.h /builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Driver/Options.td --- .depend --- rm -f .depend mkdep -f .depend -a -I/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/include -I/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include -I/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver -I. -I/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE=\x86_64-unknown-freebsd11.0\ -DLLVM_HOST_TRIPLE=\x86_64-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp\ -I/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/include -std=c++11 -stdlib=libc++ /builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver/cc1_main.cpp /builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver/cc1as_main.cpp /builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools /clang/tools/driver/driver.cpp echo clang: /usr/lib/libc.a /builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../lib/clang/libclangfrontendtool/libclangfrontendtool.a /builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../lib/clang/libclangfrontend/libclangfrontend.a /builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../lib/clang/libclangdriver/libclangdriver.a /builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../lib/clang/libclangserialization/libclangserialization.a /builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../lib/clang/libclangcodegen/libclangcodegen.a /builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../lib/clang/libclangparse/libclangparse.a /builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../li b/clang/libclangsema/libclangsema.a /builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../lib/clang/libclangrewritefrontend/libclangrewritefrontend.a /builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../lib/clang/libclangrewrite/libclangrewrite.a
ramblings.. or not
I just enjoyed the following video. http://nextbsd.org/jordan-hubbard-visits-bafug/ The talk itself is fun to listen to (in a nerdy way) but the final 3 minutes are, I think, the most important.. We need to look harder at bringing in features from people's various science experiments. On the other hand sometimes I think that some things come in a little too quickly.. The cloud-os wprk could spend a little more time in a branch I think. I didn't see any consensus on bringing it in.. It's just coming in on its own.. (not that it's bad , just that I didn't see any discusssion). We should certainly be looking at a closer connection with PCBSD (despite their change to no longer use the original PBI concept). We should certainly be looking at a closer connection with HardenedBSD, and now I think we really should be looking at launchd and friends. Do we have a standard path for ideas from these projects and DragonFly? We should also do a better job of productising and incorporating GSOC work.. Maybe we should make the ideas page more mainline. Where people can put in a more standard way links to their pet projects and offically submit work for inclusion. and then make it better known.. ___ 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
