Re: libthr and main thread stack size
On 08/08/2014 09:28 AM, Konstantin Belousov wrote: On Thu, Aug 07, 2014 at 04:18:12PM +0400, Ivan A. Kosarev wrote: Hello, According to libthr's thr_init.c (the 9.2 version) init_main_thread() allocates s.c. "red zone" below the main stack in order to protect other stacks. The size of the main stack is determined by the _thr_stack_initial variable that is declared extern though it doesn't seem it can be changed. The value of the variable is set to 4M on 64-bit platforms which is obviously not sufficient for the most of real programs. Can anyone please confirm that there is no way to increase the stack size for the main thread and thus any program linked against libthr has only a few megabytes of stack memory for its main thread--whatever the system stack size (ulimit -s) is set to? Yes, there is no way to change the main thread stack clamping. Could you provide a reasonable use case for the 4MB stack ? Traversing trees with recursive functions or on-stack grammar parsers? Anyway, I somewhat sympathize to the idea to stop clamping the main thread stack, and to not reuse it for other threads stack carving. This also means that non-main threads stack allocator should stop tracking the explicit location for the stacks and rely on vm mmap(2) base selection instead. Yes, that would solve the problem. I do not know the motivations why the current scheme of stacks allocation was chosen. The changes do not look too involved. Thanks a lot. -- ___ 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: libthr and main thread stack size
On Fri, Aug 08, 2014 at 12:32:56PM +0400, Ivan A. Kosarev wrote:
>
> On 08/08/2014 09:28 AM, Konstantin Belousov wrote:
> > On Thu, Aug 07, 2014 at 04:18:12PM +0400, Ivan A. Kosarev wrote:
> >> Hello,
> >>
> >> According to libthr's thr_init.c (the 9.2 version) init_main_thread()
> >> allocates s.c. "red zone" below the main stack in order to protect other
> >> stacks. The size of the main stack is determined by the
> >> _thr_stack_initial variable that is declared extern though it doesn't
> >> seem it can be changed. The value of the variable is set to 4M on 64-bit
> >> platforms which is obviously not sufficient for the most of real programs.
> >>
> >> Can anyone please confirm that there is no way to increase the stack
> >> size for the main thread and thus any program linked against libthr has
> >> only a few megabytes of stack memory for its main thread--whatever the
> >> system stack size (ulimit -s) is set to?
> > Yes, there is no way to change the main thread stack clamping.
> > Could you provide a reasonable use case for the 4MB stack ?
>
> Traversing trees with recursive functions or on-stack grammar parsers?
>
> >
> > Anyway, I somewhat sympathize to the idea to stop clamping the main
> > thread stack, and to not reuse it for other threads stack carving.
> > This also means that non-main threads stack allocator should stop
> > tracking the explicit location for the stacks and rely on vm mmap(2)
> > base selection instead.
>
> Yes, that would solve the problem.
>
> > I do not know the motivations why the current scheme of stacks allocation
> > was chosen. The changes do not look too involved.
In fact, I can resonably explain the current behaviour. The motivation
seems to come from desire to interpret the RLIMIT_STACK as the global
limit to the stack usage by all threads. From this PoV, it becomes clean
why the other thread stacks are carved from the main stack.
Of course, it does not quite work this way, because there is no check
that we did not overflowed from the main stack area.
>
> Thanks a lot.
>
Below is the patch which adds environment variable LIBPTHREAD_BIGSTACK_MAIN.
Setting it to any value results in the main thread stack left as is, and
other threads allocate stack below the area of RLIMIT_STACK. Try it.
I do not want to set this behaviour as default.
diff --git a/lib/libthr/thread/thr_init.c b/lib/libthr/thread/thr_init.c
index 937d83f..9bf0e29 100644
--- a/lib/libthr/thread/thr_init.c
+++ b/lib/libthr/thread/thr_init.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -441,6 +442,7 @@ init_main_thread(struct pthread *thread)
static void
init_private(void)
{
+ struct rlimit rlim;
size_t len;
int mib[2];
char *env;
@@ -471,6 +473,12 @@ init_private(void)
len = sizeof (_usrstack);
if (sysctl(mib, 2, &_usrstack, &len, NULL, 0) == -1)
PANIC("Cannot get kern.usrstack from sysctl");
+ env = getenv("LIBPTHREAD_BIGSTACK_MAIN");
+ if (env != NULL) {
+ if (getrlimit(RLIMIT_STACK, &rlim) == -1)
+ PANIC("Cannot get stack rlimit");
+ _thr_stack_initial = rlim.rlim_cur;
+ }
len = sizeof(_thr_is_smp);
sysctlbyname("kern.smp.cpus", &_thr_is_smp, &len, NULL, 0);
_thr_is_smp = (_thr_is_smp > 1);
diff --git a/lib/libthr/thread/thr_stack.c b/lib/libthr/thread/thr_stack.c
index 15a9c82..e5d149e 100644
--- a/lib/libthr/thread/thr_stack.c
+++ b/lib/libthr/thread/thr_stack.c
@@ -246,7 +246,10 @@ _thr_stack_alloc(struct pthread_attr *attr)
THREAD_LIST_UNLOCK(curthread);
}
else {
- /* Allocate a stack from usrstack. */
+ /*
+* Allocate a stack from or below usrstack, depending
+* on the LIBPTHREAD_BIGSTACK_MAIN env variable.
+*/
if (last_stack == NULL)
last_stack = _usrstack - _thr_stack_initial -
_thr_guard_default;
@@ -268,7 +271,7 @@ _thr_stack_alloc(struct pthread_attr *attr)
/* Map the stack and guard page together, and split guard
page from allocated space: */
- if ((stackaddr = mmap(stackaddr, stacksize+guardsize,
+ if ((stackaddr = mmap(stackaddr, stacksize + guardsize,
_rtld_get_stack_prot(), MAP_STACK,
-1, 0)) != MAP_FAILED &&
(guardsize == 0 ||
pgpUGNSGxeqgN.pgp
Description: PGP signature
Re: r269147: NULL mp in getnewvnode() via kern_proc_filedesc_out()
On Thu, Aug 07, 2014 at 08:11:11AM +0200, Peter Holm wrote: > On Wed, Aug 06, 2014 at 09:15:12PM +0300, Konstantin Belousov wrote: > > On Wed, Aug 06, 2014 at 12:48:28PM -0500, Bryan Drewery wrote: > > > On 8/5/2014 10:56 PM, Bryan Drewery wrote: > > > > On 8/5/2014 10:19 PM, Konstantin Belousov wrote: > > > >> On Tue, Aug 05, 2014 at 09:47:57PM -0500, Bryan Drewery wrote: > > > >>> Has anyone else encountered this? Got it while running poudriere. > > > >>> > > > NULL mp in getnewvnode() > > > [...] > > > vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfe1247d8e540 > > > vn_fullpath() at vn_fullpath+0xc1/frame 0xfe1247d8e590 > > > export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfe1247d8e7c0 > > > kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame > > > 0xfe1247d8e840 > > > sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/frame > > > 0xfe1247d8e900 > > > sysctl_root_handler_locked() at > > > sysctl_root_handler_locked+0x68/frame 0xfe1247d8e940 > > > sysctl_root() at sysctl_root+0x18e/frame 0xfe1247d8e990 > > > userland_sysctl() at userland_sysctl+0x192/frame 0xfe1247d8ea30 > > > sys___sysctl() at sys___sysctl+0x74/frame 0xfe1247d8eae0 > > > amd64_syscall() at amd64_syscall+0x25a/frame 0xfe1247d8ebf0 > > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1247d8ebf0 > > > >>> > > > >>> Unfortunately I have no dump as the kmem was too large compared to my > > > >>> swap, and I didn't get to the console before some of the text was > > > >>> overwritten. Perhaps it will hit it again soon after reboot and I'll > > > >>> get > > > >>> a core. > > > >> > > > >> "NULL mp in getnewvnode()" is only the printf(), it is not a panic or > > > >> KASSERT. The event does not stop the machine, nor it prints the > > > >> backtrace. > > > >> > > > >> You mentioned that you was unable to dump, so did the system paniced ? > > > >> Without full log of the panic messages and backtrace, it is impossible > > > >> to start guessing what the problem is. > > > >> > > > >> That said, the printf seemingly outlived its usefulness. > > > >> > > > > > > > > Got it. I've set debug.debugger_on_panic=1 to not auto reboot on panic > > > > next time this happens. I had it at 0 which was causing the lack of > > > > information in these. > > > > > > Here is the full trace: > > > > > > > > > > NULL mp in getnewvnode() > > > > VNASSERT failed > > > > 0xf806071dc760: tag null, type VDIR > > > > usecount 1, writecount 0, refcount 1 mountedhere 0 > > > > flags () > > > > lock type zfs: EXCL by thread 0xf8009a53f490 (pid 1028, tmux, > > > > tid 100881) > > > > vp=0xf806071dc760, lowervp=0xf8013157f588 > > > > panic: Don't call insmntque(foo, NULL) > > > > cpuid = 5 > > > > KDB: stack backtrace: > > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > > > 0xfe1247e76b50 > > > > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1247e76c00 > > > > vpanic() at vpanic+0x126/frame 0xfe1247e76c40 > > > > kassert_panic() at kassert_panic+0x139/frame 0xfe1247e76cb0 > > > > insmntque1() at insmntque1+0x230/frame 0xfe1247e76cf0 > > > > null_nodeget() at null_nodeget+0x158/frame 0xfe1247e76d60 > > > > null_lookup() at null_lookup+0xeb/frame 0xfe1247e76dd0 > > > > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xf1/frame 0xfe1247e76e00 > > > > lookup() at lookup+0x5ad/frame 0xfe1247e76e90 > > > > namei() at namei+0x4e4/frame 0xfe1247e76f50 > > > > vn_open_cred() at vn_open_cred+0x27a/frame 0xfe1247e770a0 > > > > vop_stdvptocnp() at vop_stdvptocnp+0x161/frame 0xfe1247e773e0 > > > > null_vptocnp() at null_vptocnp+0x2b/frame 0xfe1247e77440 > > > > VOP_VPTOCNP_APV() at VOP_VPTOCNP_APV+0xf7/frame 0xfe1247e77470 > > > > vn_vptocnp_locked() at vn_vptocnp_locked+0x118/frame 0xfe1247e774e0 > > > > vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfe1247e77540 > > > > vn_fullpath() at vn_fullpath+0xc1/frame 0xfe1247e77590 > > > > export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfe1247e777c0 > > > > kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame > > > > 0xfe1247e77840 > > > > sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/frame > > > > 0xfe1247e77900 > > > > sysctl_root_handler_locked() at sysctl_root_handler_locked+0x68/frame > > > > 0xfe1247e77940 > > > > sysctl_root() at sysctl_root+0x18e/frame 0xfe1247e77990 > > > > userland_sysctl() at userland_sysctl+0x192/frame 0xfe1247e77a30 > > > > sys___sysctl() at sys___sysctl+0x74/frame 0xfe1247e77ae0 > > > > amd64_syscall() at amd64_syscall+0x25a/frame 0xfe1247e77bf0 > > > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1247e77bf0 > > > > --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x801041fca, rsp > > > > = 0x7fffd878, rbp = 0x7fffd8b0 --- > > > > KDB: enter: panic > > > > [ thread pid 1
Re: r269147: NULL mp in getnewvnode() via kern_proc_filedesc_out()
On 8/8/2014 6:46 AM, Konstantin Belousov wrote: > On Thu, Aug 07, 2014 at 08:11:11AM +0200, Peter Holm wrote: >> On Wed, Aug 06, 2014 at 09:15:12PM +0300, Konstantin Belousov wrote: >>> On Wed, Aug 06, 2014 at 12:48:28PM -0500, Bryan Drewery wrote: On 8/5/2014 10:56 PM, Bryan Drewery wrote: > On 8/5/2014 10:19 PM, Konstantin Belousov wrote: >> On Tue, Aug 05, 2014 at 09:47:57PM -0500, Bryan Drewery wrote: >>> Has anyone else encountered this? Got it while running poudriere. >>> NULL mp in getnewvnode() [...] vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfe1247d8e540 vn_fullpath() at vn_fullpath+0xc1/frame 0xfe1247d8e590 export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfe1247d8e7c0 kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame 0xfe1247d8e840 sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/frame 0xfe1247d8e900 sysctl_root_handler_locked() at sysctl_root_handler_locked+0x68/frame 0xfe1247d8e940 sysctl_root() at sysctl_root+0x18e/frame 0xfe1247d8e990 userland_sysctl() at userland_sysctl+0x192/frame 0xfe1247d8ea30 sys___sysctl() at sys___sysctl+0x74/frame 0xfe1247d8eae0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfe1247d8ebf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1247d8ebf0 >>> >>> Unfortunately I have no dump as the kmem was too large compared to my >>> swap, and I didn't get to the console before some of the text was >>> overwritten. Perhaps it will hit it again soon after reboot and I'll get >>> a core. >> >> "NULL mp in getnewvnode()" is only the printf(), it is not a panic or >> KASSERT. The event does not stop the machine, nor it prints the >> backtrace. >> >> You mentioned that you was unable to dump, so did the system paniced ? >> Without full log of the panic messages and backtrace, it is impossible >> to start guessing what the problem is. >> >> That said, the printf seemingly outlived its usefulness. >> > > Got it. I've set debug.debugger_on_panic=1 to not auto reboot on panic > next time this happens. I had it at 0 which was causing the lack of > information in these. Here is the full trace: > NULL mp in getnewvnode() > VNASSERT failed > 0xf806071dc760: tag null, type VDIR > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags () > lock type zfs: EXCL by thread 0xf8009a53f490 (pid 1028, tmux, tid > 100881) > vp=0xf806071dc760, lowervp=0xf8013157f588 > panic: Don't call insmntque(foo, NULL) > cpuid = 5 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfe1247e76b50 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1247e76c00 > vpanic() at vpanic+0x126/frame 0xfe1247e76c40 > kassert_panic() at kassert_panic+0x139/frame 0xfe1247e76cb0 > insmntque1() at insmntque1+0x230/frame 0xfe1247e76cf0 > null_nodeget() at null_nodeget+0x158/frame 0xfe1247e76d60 > null_lookup() at null_lookup+0xeb/frame 0xfe1247e76dd0 > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xf1/frame 0xfe1247e76e00 > lookup() at lookup+0x5ad/frame 0xfe1247e76e90 > namei() at namei+0x4e4/frame 0xfe1247e76f50 > vn_open_cred() at vn_open_cred+0x27a/frame 0xfe1247e770a0 > vop_stdvptocnp() at vop_stdvptocnp+0x161/frame 0xfe1247e773e0 > null_vptocnp() at null_vptocnp+0x2b/frame 0xfe1247e77440 > VOP_VPTOCNP_APV() at VOP_VPTOCNP_APV+0xf7/frame 0xfe1247e77470 > vn_vptocnp_locked() at vn_vptocnp_locked+0x118/frame 0xfe1247e774e0 > vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfe1247e77540 > vn_fullpath() at vn_fullpath+0xc1/frame 0xfe1247e77590 > export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfe1247e777c0 > kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame > 0xfe1247e77840 > sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/frame > 0xfe1247e77900 > sysctl_root_handler_locked() at sysctl_root_handler_locked+0x68/frame > 0xfe1247e77940 > sysctl_root() at sysctl_root+0x18e/frame 0xfe1247e77990 > userland_sysctl() at userland_sysctl+0x192/frame 0xfe1247e77a30 > sys___sysctl() at sys___sysctl+0x74/frame 0xfe1247e77ae0 > amd64_syscall() at amd64_syscall+0x25a/frame 0xfe1247e77bf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1247e77bf0 > --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x801041fca, rsp = > 0x7fffd878, rbp = 0x7fffd8b0 --- > KDB: enter: panic > [ thread pid 1028 tid 100881 ] > Stopped at kdb_enter+0x3e: movq$0,kdb_why > db> call doadump() > > Dump failed. Partition too s
poudriere: setting up jail failes
Hello, I'm setting up a jail with poudriere(8) to compile my ports; after some hours it is crashing with: # poudriere jail -c -j freebsd-head -m svn+http -v head ; date ... >>> Making hierarchy -- cd /usr/local/poudriere/jails/freebsd-head/usr/src; make -f Makefile.inc1 LOCAL_MTREE= hierarchy cd /usr/local/poudriere/jails/freebsd-head/usr/src/etc && PATH=/usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/usr/games:/usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/bin:/usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/usr/sbin:/usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/usr/bin:/usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/usr/games:/usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/usr/games:/usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/bin:/usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/usr/sbin:/usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/usr/bin:/usr/obj/usr/local/poudriere/jails/freebsd-head/usr /src/tmp/usr/games:/tmp/install.l1aks4sC make LOCAL_MTREE= distrib-dirs mtree -N /usr/local/poudriere/jails/freebsd-head/usr/src/etc -deU -f /usr/local/poudriere/jails/freebsd-head/usr/src/etc/mtree/BSD.root.dist -p /usr/local/poudriere/jails/freebsd-head/ mtree: illegal option -- N usage: mtree [-LPUcdeinqruxw] [-f spec] [-f spec] [-K key] [-k key] [-p path] [-s seed] [-X excludes] *** Error code 1 Stop. make[4]: stopped in /usr/local/poudriere/jails/freebsd-head/usr/src/etc *** Error code 1 ... make: stopped in /usr/local/poudriere/jails/freebsd-head/usr/src >> Error: Failed to 'make installworld' >> Error while creating jail, cleaning up. >> Removing freebsd-head jail... done The host where poudriere is running is: # uname -a FreeBSD vm-tiny-r255948 10.0-ALPHA4 FreeBSD 10.0-ALPHA4 #1: Fri Oct 18 12:10:57 CEST 2013 g...@aurora.sisis.de:/usr/obj/usr/src/sys/GENERIC i386 i.e. a CURRENT from Oct 2013 (r255948). Does this mean I should update the host where poudriere is running before? Thanks matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign ___ 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: poudriere: setting up jail failes
On 8/8/2014 11:46 AM, Matthias Apitz wrote: > > Hello, > > I'm setting up a jail with poudriere(8) to compile my ports; after some > hours it is crashing with: > > # poudriere jail -c -j freebsd-head -m svn+http -v head ; date [...] > mtree: illegal option -- N > usage: mtree [-LPUcdeinqruxw] [-f spec] [-f spec] [-K key] [-k key] [-p > path] [-s seed] > [-X excludes] > *** Error code 1 [...] > The host where poudriere is running is: > > # uname -a > FreeBSD vm-tiny-r255948 10.0-ALPHA4 FreeBSD 10.0-ALPHA4 #1: Fri Oct 18 > 12:10:57 CEST 2013 g...@aurora.sisis.de:/usr/obj/usr/src/sys/GENERIC > i386 > > i.e. a CURRENT from Oct 2013 (r255948). Does this mean I should update > the host where poudriere is running before? Yes. For you it is fixed in stable/10 r257460 (which was in before 10.0 release) which added -N to mtree. There was a lot of polish at the end of 10.0 so you should probably upgrade to at least 10.0 either way. It could be that older releases building 10 and head for Poudriere may be an issue still. I'll have to test more. Specifically the call of 'make distrib-dirs DB_FROM_SRC=1' seemingly not using the itools version of mtree. Also note that running a head jail on a 10.0 system is not really supported. You may run into many weird issues building packages. It's supported to have your host be newer than the jails but not the other way around. Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: poudriere: setting up jail failes
El día Friday, August 08, 2014 a las 07:12:15PM +0200, Kurt Jaeger escribió: > Hi! > > > The host where poudriere is running is: > > > > # uname -a > > FreeBSD vm-tiny-r255948 10.0-ALPHA4 FreeBSD 10.0-ALPHA4 #1: Fri Oct 18 > > 12:10:57 CEST 2013 g...@aurora.sisis.de:/usr/obj/usr/src/sys/GENERIC > > i386 > > > > i.e. a CURRENT from Oct 2013 (r255948). Does this mean I should update > > the host where poudriere is running before? > > Yes. Go for 10.0-REL p7, then retry. Can you explain, why? If one looks at the code which is executed in the jail, it looks like this (for better readability I have changed the colons ':' in the PATH by newlines): PATH=/usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/usr/sbin /usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/usr/bin /usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/usr/games /usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/bin /usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/usr/sbin /usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/usr/bin /usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/usr/games /usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/usr/sbin /usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/usr/bin /usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/usr/games /usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/bin /usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/usr/sbin /usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/usr/bin /usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/usr/games /tmp/install.l1aks4sC make LOCAL_MTREE= distrib-dirs mtree -N /usr/local/poudriere/jails/freebsd-head/usr/src/etc -deU -f /usr/local/poudriere/jails/freebsd-head/usr/src/etc/mtree/BSD.root.dist -p /usr/local/poudriere/jails/freebsd-head/ mtree: illegal option -- N usage: mtree [-LPUcdeinqruxw] [-f spec] [-f spec] [-K key] [-k key] [-p path] [-s seed] [-X excludes] *** Error code 1 i.e. the tool 'mtree' is run from a hardcoded PATH from inside the jail which was just compiled. Why the 'mtree' from a Makefile in CURRENT is called with the -N flag, or why the 'mtree' from CURRENT does not understand the -N flag? I do not have a SVN checked out CURRENT to look into at the moment, but I think either the Makefile or mtree is broken in CURRENT. And, btw., why is poudriere removing all the jail when an error occures? Wouldn't it be better to let it there to have a look into and remove it on the next run? > > -- > 6 years to go ! 6 years to go to where or what? Thanks matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign ___ 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: poudriere: setting up jail failes
El día Friday, August 08, 2014 a las 01:43:51PM -0500, Bryan Drewery escribió: > Yes. For you it is fixed in stable/10 r257460 (which was in before 10.0 > release) which added -N to mtree. There was a lot of polish at the end > of 10.0 so you should probably upgrade to at least 10.0 either way. > > It could be that older releases building 10 and head for Poudriere may > be an issue still. I'll have to test more. Specifically the call of > 'make distrib-dirs DB_FROM_SRC=1' seemingly not using the itools version > of mtree. This is perhaps the problem. > Also note that running a head jail on a 10.0 system is not really > supported. You may run into many weird issues building packages. It's > supported to have your host be newer than the jails but not the other > way around. Hmm? The poudriere has the '-m svn' flag for creating jails. If one uses this flag, the jail will always be newer than the host. If this is an issue (which I do not understand if things are done in a jail, using the toolchain of the jail) then this flag should be deleted from poudriere, IMHO. Thanks matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign ___ 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: poudriere: setting up jail failes
Hi! > > > i.e. a CURRENT from Oct 2013 (r255948). Does this mean I should update > > > the host where poudriere is running before? > > > > Yes. Go for 10.0-REL p7, then retry. > > Can you explain, why? bdrewery@ knows much more about it than I do 8-) I only know that it helps to use a recent system if one tries to debug issues 8-} And: It takes time for others to help if one tries to use some -ALPHA to do recent things... -- p...@opsec.eu+49 171 3101372 6 years to go ! ___ 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: poudriere: setting up jail failes
On 8/8/2014 2:11 PM, Matthias Apitz wrote: > El día Friday, August 08, 2014 a las 01:43:51PM -0500, Bryan Drewery escribió: > >> Yes. For you it is fixed in stable/10 r257460 (which was in before 10.0 >> release) which added -N to mtree. There was a lot of polish at the end >> of 10.0 so you should probably upgrade to at least 10.0 either way. >> >> It could be that older releases building 10 and head for Poudriere may >> be an issue still. I'll have to test more. Specifically the call of >> 'make distrib-dirs DB_FROM_SRC=1' seemingly not using the itools version >> of mtree. > > This is perhaps the problem. > >> Also note that running a head jail on a 10.0 system is not really >> supported. You may run into many weird issues building packages. It's >> supported to have your host be newer than the jails but not the other >> way around. > > Hmm? The poudriere has the '-m svn' flag for creating jails. If one uses > this flag, the jail will always be newer than the host. If this is an > issue (which I do not understand if things are done in a jail, using the > toolchain of the jail) then this flag should be deleted from > poudriere, IMHO. > > Thanks > > matthias > The use of -v head from a 10.0 system is the issue. Once you start a build poudriere yells loudly that it is not supported. Major release jumps are not supported. You can usually get away with a head host using a head jail that is a few weeks newer as long as KBI does not change. Doing major releases though can get into trouble with unknown syscalls and different sized structs and capabilities. FreeBSD only tries to be backwards-compatible with its interfaces (among major releases), not guaranteed to be forward or even backwards compatible with head from yesterday. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: poudriere: setting up jail failes
On 8/8/2014 1:57 PM, Matthias Apitz wrote: > And, btw., why is poudriere removing all the jail when an error occures? > Wouldn't it be better to let it there to have a look into and remove it > on the next run? Yes I agree this should probably change. I'll evaluate it after the 3.1 release which is the major focus right now. The jail command has a lot of issues with building and error handling. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
RE: loader lszfs command
> -Original Message- > From: Garrett Cooper [mailto:yaneurab...@gmail.com] > Sent: Thursday, August 7, 2014 5:10 PM > To: dte...@freebsd.org > Cc: Sean Bruno; freebsd-current > Subject: Re: loader lszfs command > > On Thu, Aug 7, 2014 at 4:42 PM, wrote: > > > >> -Original Message- > >> From: Garrett Cooper [mailto:yaneurab...@gmail.com] > >> Sent: Thursday, August 7, 2014 4:29 PM > >> To: sbr...@freebsd.org > >> Cc: dte...@freebsd.org; freebsd-current > >> Subject: Re: loader lszfs command > >> > >> Hi Devin! > >> > >> On Thu, Aug 7, 2014 at 4:15 PM, Sean Bruno > >> wrote: > >> > On Thu, 2014-08-07 at 14:17 -0700, dte...@freebsd.org wrote: > >> >> Hi, > >> >> > >> >> People have been pestering me to update the Forth code to present > >> >> a menu of ZFS datasets (*cough* boot environments *cough*). > >> >> > >> >> Would love to, but existing code seems broken. > >> >> > >> >> Can *anybody* produce meaningful output from the following? > >> >> > >> >> http://svnweb.freebsd.org/base?view=revision&revision=241284 > >> >> > >> >> All I get on every system I've tried (multiple versions, including HEAD) > >> >> produce the following: > >> >> > >> >> OK lszfs zroot > >> >> ZFS: i/o error - all block copies unavailable > >> >> operation not permitted > >> >> > >> >> It's really hard for me to start with something that's broken. Can > >> >> I get confirmation that this doesn't appear to be working as intended? > >> >> If so, I'll go ahead and try to fix it, but need to confirm that I'm ( > >> >> a ) > >> >> not > >> >> crazy and ( b ) seeing the same thing everybody else is seeing. > >> > > >> > > >> > Hrm ... this seems to work for me. (fairly recent 11-current) > >> > > >> > OK lszfs zroot > >> > $MOS > >> > $FREE > >> > $ORIGIN > >> > tmp > >> > home > >> > usr > >> > var > >> > tftpboot > >> > poudriere > >> > OK > >> > >> Is the installed version you have in synch with the kernel and > >> zpool version for boot0, gptzfsboot, etc? > > > > Not sure how the kernel factors into all this, but I have a > > 10.0-RC1 system. > > I was asking for information to help determine whether or not the > loader could read the zpool metadata, because it's interesting why > things worked for Sean and not for you :). No explanation as of yet, but I have successfully built a system that has working lszfs command. Took a stable/10 snapshot from July 29th and that seems to be working alright. Since it's working as expected in stable/10 currently (the furthest point away that I intend to MFC these enhancements), I'm happy to ignore the fact that my aged 10.0-RC1 machine doesn't work. -- Devin ___ 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: poudriere: setting up jail failes
El día Friday, August 08, 2014 a las 02:24:18PM -0500, Bryan Drewery escribió: > The use of -v head from a 10.0 system is the issue. Once you start a > build poudriere yells loudly that it is not supported. Major release > jumps are not supported. You can usually get away with a head host using > a head jail that is a few weeks newer as long as KBI does not change. > ... OK, thanks. I will update the host to head and try again. Btw: I did not saw any loud yells of poudriere. Maybe, because I went away from the desk when poudriere was doing the SVN checkout and when I came back it was already nicely compiling. Maybe it should ask a question like: Do your really want that new jail on your old system? And wait for the answer :-) Thanks for your time. matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign ___ 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: poudriere: setting up jail failes
On 8/8/2014 2:42 PM, Matthias Apitz wrote: > El día Friday, August 08, 2014 a las 02:24:18PM -0500, Bryan Drewery escribió: > >> The use of -v head from a 10.0 system is the issue. Once you start a >> build poudriere yells loudly that it is not supported. Major release >> jumps are not supported. You can usually get away with a head host using >> a head jail that is a few weeks newer as long as KBI does not change. >> ... > > OK, thanks. I will update the host to head and try again. > > Btw: I did not saw any loud yells of poudriere. Maybe, because I went away > from > the desk when poudriere was doing the SVN checkout and when I came back > it was already nicely compiling. Maybe it should ask a question like: > Do your really want that new jail on your old system? And wait for the > answer :-) > > > Thanks for your time. > > matthias > Only in 'bulk', not 'jail'. There's also a securelevel blocker in 'bulk' that is not in 'jail'. Some of these need to move to 'jail' to warn earlier, yes. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Problems with zpool upgrade embedded_data, and rebooting
Hello everyone, I just would like to gratuitously rant about something that happened on my machine. Basically, I upgraded my zpool to use embedded_data, since it would be more efficient, and rebooted. (I installed the system with zfs using bsdinstall). It turned out that gptzfsboot wasn't able to load that filesystem, so I tried to get it working from a live system that I have on a USB drive. It didn't work on that particular live system, but, fortunately, someone could do me a favor and download the latest snapshot, and burn it to my USB drive. >From there, it was a matter of importing zroot, mounting it at /mnt, and taking a look at the code of bsdinstall, trying to find the actual command to update the bootloader. I could manage to find it, and hopefully, everything worked again. Thanks to those who helped me :) What would be the better way to avoid this happening in the future? -- Daniel ___ 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: Problems with zpool upgrade embedded_data, and rebooting
On 2014.08.08 17:41, Daniel Peyrolon wrote: > What would be the better way to avoid this happening in the future? > Always update the bootloader before doing a zpool upgrade on your root pool. ___ 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: Problems with zpool upgrade embedded_data, and rebooting
Daniel Peyrolon wrote this message on Sat, Aug 09, 2014 at 00:41 +0200: > Hello everyone, > > I just would like to gratuitously rant about something that happened on my > machine. > > Basically, I upgraded my zpool to use embedded_data, since it would be more > efficient, and rebooted. (I installed the system with zfs using bsdinstall). > It turned out that gptzfsboot wasn't able to load that filesystem, so I > tried to get it working from a live system that I have on a USB drive. > It didn't work on that particular live system, but, fortunately, someone > could do me a favor and download the latest snapshot, and burn it to my USB > drive. > > >From there, it was a matter of importing zroot, mounting it at /mnt, and > taking a look at the code of bsdinstall, trying to find the actual command > to update the bootloader. > I could manage to find it, and hopefully, everything worked again. Thanks > to those who helped me :) > > What would be the better way to avoid this happening in the future? Didn't you get the following warning: # zpool upgrade -a This system is currently running ZFS pool version 28. Successfully upgraded 'tank' If you boot from pool 'tank', don't forget to update boot code. Assuming you use GPT partitioning and da0 is your boot disk the following command will do it: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 Or something similar? If you didn't follow the warnings, how else can we help you? -- 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ddb_enable=YES doesn't reboot anymore
Hi, I noticed that on panic, the default ddb script does not reboot the machine automatically anymore. It just stays at the debugger prompt. # sysctl debug.ddb.scripting.scripts debug.ddb.scripting.scripts: lockinfo=show locks; show alllocks; show lockedvnods kdb.enter.panic=capture on; run lockinfo; show pcpu; bt; ps; alltrace; capture off; call doadump; reset kdb.enter.witness=run lockinfo I don't really know when it started to behave like this as I upgrade pretty rarely. My kernel is running r268370. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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: Problems with zpool upgrade embedded_data, and rebooting
On 2014-08-08 19:23, John-Mark Gurney wrote: > Daniel Peyrolon wrote this message on Sat, Aug 09, 2014 at 00:41 +0200: >> Hello everyone, >> >> I just would like to gratuitously rant about something that happened on my >> machine. >> >> Basically, I upgraded my zpool to use embedded_data, since it would be more >> efficient, and rebooted. (I installed the system with zfs using bsdinstall). >> It turned out that gptzfsboot wasn't able to load that filesystem, so I >> tried to get it working from a live system that I have on a USB drive. >> It didn't work on that particular live system, but, fortunately, someone >> could do me a favor and download the latest snapshot, and burn it to my USB >> drive. >> >> >From there, it was a matter of importing zroot, mounting it at /mnt, and >> taking a look at the code of bsdinstall, trying to find the actual command >> to update the bootloader. >> I could manage to find it, and hopefully, everything worked again. Thanks >> to those who helped me :) >> >> What would be the better way to avoid this happening in the future? > > Didn't you get the following warning: > # zpool upgrade -a > This system is currently running ZFS pool version 28. > > Successfully upgraded 'tank' > > If you boot from pool 'tank', don't forget to update boot code. > Assuming you use GPT partitioning and da0 is your boot disk > the following command will do it: > > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 > > Or something similar? > > If you didn't follow the warnings, how else can we help you? > Yeah, there is a big warning with explicit instructions after you zpool upgrade, warning you about this specific issue. In order to save your self from a rescue system, it'd have to support the embedded_data feature as well. -- Allan Jude signature.asc Description: OpenPGP digital signature
