Re: Synth update-system again fails with recursive crash [Was: Re: ]
On Tue, 2 Jun 2020 05:06-0700, Donald Wilde wrote: > > Updating FreeBSD repository catalogue... > FreeBSD repository is up to date. > Updating Synth repository catalogue... > pkg: file:///var/synth/live_packages/meta.txz: No such file or directory > repository Synth has no meta file, using default settings > pkg: file:///var/synth/live_packages/packagesite.txz: No such file or > directory > Unable to update repository Synth > Error updating repositories! > > > I am willing to live without an updated ports tree, but how can I > resolve the issue with the Synth repo so I can use 'pkg install'? I > only need to install a few dozen ports from source for my work, but > not having pkg working is definitely a source of dismay. Try: pkg repo /var/synth/live_packages It could be that you system is so far back in the past that running synth just-build /pathname/to/packagelist && synth rebuild-repository is so much better. I ran make -C /usr/ports/print/tex-dvipsk all-depends-list on one of my well-maintained systems, and graphviz didn't show up at all. I might have disabled something in some of the ports that in turn removes the need for graphviz. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: r358661 breaks /usr/src/usr.sbin/amd/include/newvers.sh on stable/12
On Thu, 5 Mar 2020 05:01-0800, David Wolfskill wrote: > On Thu, Mar 05, 2020 at 01:54:58PM +0100, Trond Endrestøl wrote: > > The command > > "sh /usr/src/usr.sbin/amd/include/newvers.sh /usr/src/sys/conf/newvers.sh" > > is run a part of a normal build, creating config_local.h. > > > > After r358661, I find this in my build logs for stable/12: > > > > eval: 1: Syntax error: end of file unexpected (expecting ")") > > eval: 1: Syntax error: Error in command substitution > > > > As Tomoaki AOKI pointed out (in > svn-src-stable-12@): > > | This should be MFC'ed with r346022, otherwise usr.sbin/amd > | does not build. > > (I hand-applied the change, and the build (and suibsequent reboot & > smoke-test) succeeded.) Thank you. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
r358661 breaks /usr/src/usr.sbin/amd/include/newvers.sh on stable/12
The command "sh /usr/src/usr.sbin/amd/include/newvers.sh /usr/src/sys/conf/newvers.sh" is run a part of a normal build, creating config_local.h. After r358661, I find this in my build logs for stable/12: eval: 1: Syntax error: end of file unexpected (expecting ")") eval: 1: Syntax error: Error in command substitution Meta mode is activated, and the build logs gives this insight: _ERROR_CMD='@rm -f config_local.h; sh /usr/src/usr.sbin/amd/include/newvers.sh /usr/src/sys/conf/newvers.sh > config_local.h;' .CURDIR='/usr/src/usr.sbin/amd/include' Any attempts to build again, results in: --- amd.o --- /usr/src/contrib/amd/amd/amd.c:275:17: error: use of undeclared identifier 'HOST_OS_NAME' gopt.op_sys = HOST_OS_NAME; ^ /usr/src/contrib/amd/amd/amd.c:278:21: error: use of undeclared identifier 'HOST_OS_VERSION' gopt.op_sys_ver = HOST_OS_VERSION; ^ /usr/src/contrib/amd/amd/amd.c:281:22: error: use of undeclared identifier 'HOST_OS' gopt.op_sys_full = HOST_OS; ^ 3 errors generated. CC-ing imp@ as he's the author of r358661. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Making a release of stable/12 with multiple kernels
On Sat, 11 Jan 2020 12:51+0100, Trond Endrestøl wrote: > Currently, I'm running: > > /usr/bin/make -C /usr/src -D NO_CLEAN -j 8 buildworld buildkernel > /usr/bin/make -C /usr/src/release KERNEL="PE1950 DL360G5 GENERIC PER200 > PER320 XENGUEST ZFS" MAKE_CONF=/etc/make.conf NODOC=1 NOPORTS=1 NOSRC=1 > SRC_CONF=/etc/src.conf release It turns out specifying KERNEL, MAKE_CONF, and SRC_CONF belongs to release.sh. My bad. I was missing was -D NO_INSTALLEXTRAKERNELS, just what we also need to specify when running make packages. I.e.: /usr/bin/make -C /usr/src/release -D NO_INSTALLEXTRAKERNELS NODOC=1 NOPORTS=1 NOSRC=1 release Maybe GENERIC should be at the head of KERNCONF when making a release. Some .CURDIR magic in /etc/make.conf might help with that. I'm sorry for the noise. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Making a release of stable/12 with multiple kernels
Hi, I'm trying to make a release of stable/12 and I was hoping to include all my custom kernels in the generated disc1.iso and memstick.img. Currently, I'm running: /usr/bin/make -C /usr/src -D NO_CLEAN -j 8 buildworld buildkernel /usr/bin/make -C /usr/src/release KERNEL="PE1950 DL360G5 GENERIC PER200 PER320 XENGUEST ZFS" MAKE_CONF=/etc/make.conf NODOC=1 NOPORTS=1 NOSRC=1 SRC_CONF=/etc/src.conf release The latter command only picks up the first kernel. All kernels are present and accounted for. The list is based on KERNCONF from /etc/make.conf. PE1950 is the kernel for my builder and thus listed first. Should I be using release.sh instead? I prefer using the existing source tree, and skip the doc and ports trees. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: pkg thinks kernel is old
On Thu, 10 Oct 2019 15:44+0200, Bengt Ahlgren wrote:
> That might well be it - I've done some buildworld:s with -DNO_CLEAN
> lately. I'll test - thanks for the tip!
For what it's worth, I run this command prior to running
make -D NO_CLEAN buildworld buildkernel:
/usr/bin/find /usr/obj -type f -and \( -name vers.c -or -name .version -or
-name version -or -name version.c -or -name '*crt1*.s' \) -exec rm -v -- {} \;
--
Trond.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ntpd doesn't like ASLR on stable/12 post-r350672
On Sun, 25 Aug 2019 15:03+0300, Konstantin Belousov wrote:
> On Sun, Aug 25, 2019 at 12:40:22AM +0200, Trond Endrestøl wrote:
> > On Sun, 25 Aug 2019 01:28+0300, Konstantin Belousov wrote:
> >
> > > On Sun, Aug 25, 2019 at 12:19:43AM +0200, Trond Endrestøl wrote:
> > > > On Sat, 24 Aug 2019 23:41+0300, Konstantin Belousov wrote:
> > > > > > I tried changing command="/usr/sbin/${name}" to
> > > > > > command="/usr/bin/proccontrol -m aslr -s disable /usr/sbin/${name}"
> > > > > > in
> > > > > > /etc/rc.d/ntpd, but that didn't go well.
> > > > >
> > > > > If you set kern.elf64.aslr.stack_gap to zero, does it help ?
> > > >
> > > > That helped. Thank you again.
> > >
> > > Can you verify is ntpd sets new rlimit(RLIMIT_STACK) for the main thread,
> > > and if yes, what this new limit is ?
> >
> > (gdb)
> > 5265if (-1 == setrlimit(RLIMIT_STACK, )) {
> > (gdb) print rl
> > $1 = {rlim_cur = 204800, rlim_max = 536870912}
>
> So they set the stack limit to 200K, am I right ? I suspect they do
> that because ntpd wires entire process address space, so 512M blows off
> all limits on wiring.
Yes, around line 1001 of contrib/ntp/ntpd/ntpd.c:
/* Setup stack size in preparation for locking pages in memory. */
# if defined(HAVE_MLOCKALL)
# ifdef HAVE_SETRLIMIT
ntp_rlimit(RLIMIT_STACK, DFLT_RLIMIT_STACK * 4096, 4096, "4k");
> I do not have a good idea how to make this behaviour compatible with
> the gap. Might be we can change the gap sizing parameter to KBs instead
> of percentage, and set the defaults in 64KB range.
>
> > > aslr.stack_gap is the percentage for the gap on that stack, and since
> > > default size of the main stack limit is quite large 512M, even 3%
> > > (default gap upper limit) are whole 15M. If the new limit is less than
> > > 15M, there is a likely probability that only the gap is left after the
> > > rlimit(2) call, leaving no space for the program frames.
> > >
> > > At least this looks like a nice theory.
--
Trond.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ntpd doesn't like ASLR on stable/12 post-r350672
On Sun, 25 Aug 2019 01:28+0300, Konstantin Belousov wrote:
> On Sun, Aug 25, 2019 at 12:19:43AM +0200, Trond Endrestøl wrote:
> > On Sat, 24 Aug 2019 23:41+0300, Konstantin Belousov wrote:
> > > > I tried changing command="/usr/sbin/${name}" to
> > > > command="/usr/bin/proccontrol -m aslr -s disable /usr/sbin/${name}" in
> > > > /etc/rc.d/ntpd, but that didn't go well.
> > >
> > > If you set kern.elf64.aslr.stack_gap to zero, does it help ?
> >
> > That helped. Thank you again.
>
> Can you verify is ntpd sets new rlimit(RLIMIT_STACK) for the main thread,
> and if yes, what this new limit is ?
(gdb)
5265if (-1 == setrlimit(RLIMIT_STACK, )) {
(gdb) print rl
$1 = {rlim_cur = 204800, rlim_max = 536870912}
> aslr.stack_gap is the percentage for the gap on that stack, and since
> default size of the main stack limit is quite large 512M, even 3%
> (default gap upper limit) are whole 15M. If the new limit is less than
> 15M, there is a likely probability that only the gap is left after the
> rlimit(2) call, leaving no space for the program frames.
>
> At least this looks like a nice theory.
--
Trond.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ntpd doesn't like ASLR on stable/12 post-r350672
On Sat, 24 Aug 2019 23:41+0300, Konstantin Belousov wrote:
> On Sat, Aug 24, 2019 at 10:04:49PM +0200, Trond Endrestøl wrote:
>
> > Disabling ASLR, kern.elf64.aslr.enable=0, before starting ntpd
> > manually is a workaround, but this is not viable in the long run.
>
> Why ?
I like to keep ALSR enabled in the hope that it actually achieves
something. You are right, I can disable it completely.
> > I tried changing command="/usr/sbin/${name}" to
> > command="/usr/bin/proccontrol -m aslr -s disable /usr/sbin/${name}" in
> > /etc/rc.d/ntpd, but that didn't go well.
>
> If you set kern.elf64.aslr.stack_gap to zero, does it help ?
That helped. Thank you again.
--
Trond.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ntpd doesn't like ASLR on stable/12 post-r350672
Hi,
I'm running stable/12 with ASLR enabled in /etc/sysctl.conf:
kern.elf64.aslr.enable=1
kern.elf64.aslr.pie_enable=1
kern.elf32.aslr.enable=1
kern.elf32.aslr.pie_enable=1
After upgrading to anything after r350672, now at r351450, ntpd
refuses to start at boot.
Aug 24 21:25:42 HOSTNAME ntpd[5618]: ntpd 4.2.8p12-a (1): Starting
Aug 24 21:25:43 HOSTNAME kernel: [406] pid 5619 (ntpd), jid 0, uid
123: exited on signal 11
Disabling ASLR, kern.elf64.aslr.enable=0, before starting ntpd
manually is a workaround, but this is not viable in the long run.
I tried changing command="/usr/sbin/${name}" to
command="/usr/bin/proccontrol -m aslr -s disable /usr/sbin/${name}" in
/etc/rc.d/ntpd, but that didn't go well.
Running ntpd through gdb while ASLR was enabled, I narrowed it down to
/usr/src/contrib/ntp/ntpd/ntpd.c:1001
ntp_rlimit(RLIMIT_STACK, DFLT_RLIMIT_STACK * 4096, 4096, "4k");
which calls /usr/src/contrib/ntp/ntpd/ntp_config.c:5211 and proceeds
to /usr/src/contrib/ntp/ntpd/ntp_config.c:5254
if (-1 == getrlimit(RLIMIT_STACK, )) {
Single stepping from this point gave me:
(gdb) s
_thr_rtld_set_flag (mask=1) at /usr/src/lib/libthr/thread/thr_rtld.c:171
171 {
(gdb)
176 return (0);
(gdb)
_thr_rtld_rlock_acquire (lock=0x80180d200) at
/usr/src/lib/libthr/thread/thr_rtld.c:115
115 {
(gdb)
120 curthread = _get_curthread();
(gdb)
_get_curthread () at /usr/src/lib/libthr/arch/amd64/include/pthread_md.h:97
97 return (TCB_GET64(tcb_thread));
(gdb)
_thr_rtld_rlock_acquire (lock=0x80180d200) at
/usr/src/lib/libthr/thread/thr_rtld.c:121
121 SAVE_ERRNO();
(gdb)
124 THR_CRITICAL_ENTER(curthread);
(gdb)
_thr_rwlock_tryrdlock (rwlock=, flags=0) at
/usr/src/lib/libthr/thread/thr_umtx.h:192
192 (rwlock->rw_flags & URWLOCK_PREFER_READER) != 0)
(gdb)
191 if ((flags & URWLOCK_PREFER_READER) != 0 ||
(gdb)
197 while (!(state & wrflags)) {
(gdb)
201 if (atomic_cmpset_acq_32(>rw_state, state,
state + 1))
(gdb)
atomic_cmpset_int (dst=, expect=, src=1) at
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/machine/atomic.h:220
220 ATOMIC_CMPSET(int);
(gdb)
_thr_rwlock_tryrdlock (rwlock=, flags=0) at
/usr/src/lib/libthr/thread/thr_umtx.h:201
201 if (atomic_cmpset_acq_32(>rw_state, state,
state + 1))
(gdb)
_thr_rtld_rlock_acquire (lock=0x80180d200) at
/usr/src/lib/libthr/thread/thr_rtld.c:127
127 curthread->rdlock_count++;
(gdb)
128 RESTORE_ERRNO();
(gdb)
129 }
(gdb)
_thr_rtld_clr_flag (mask=1) at /usr/src/lib/libthr/thread/thr_rtld.c:181
181 {
(gdb)
182 return (0);
(gdb)
_thr_rtld_lock_release (lock=0x80180d200) at
/usr/src/lib/libthr/thread/thr_rtld.c:150
150 {
(gdb)
_get_curthread () at /usr/src/lib/libthr/arch/amd64/include/pthread_md.h:97
97 return (TCB_GET64(tcb_thread));
(gdb)
_thr_rtld_lock_release (lock=0x80180d200) at
/usr/src/lib/libthr/thread/thr_rtld.c:157
157 SAVE_ERRNO();
(gdb)
160 state = l->lock.rw_state;
(gdb)
161 if (_thr_rwlock_unlock(>lock) == 0) {
(gdb)
_thr_rwlock_unlock (rwlock=0x80180d200) at
/usr/src/lib/libthr/thread/thr_umtx.h:249
249 state = rwlock->rw_state;
(gdb)
250 if ((state & URWLOCK_WRITE_OWNER) != 0) {
(gdb)
256 if (__predict_false(URWLOCK_READER_COUNT(state)
== 0))
(gdb)
260 URWLOCK_READER_COUNT(state) == 1))
{
(gdb)
259 URWLOCK_READ_WAITERS)) != 0 &&
(gdb)
262 state, state - 1))
(gdb)
261 if
(atomic_cmpset_rel_32(>rw_state,
(gdb)
atomic_cmpset_int (dst=, expect=, src=0) at
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/machine/atomic.h:220
220 ATOMIC_CMPSET(int);
(gdb)
_thr_rwlock_unlock (rwlock=0x80180d200) at
/usr/src/lib/libthr/thread/thr_umtx.h:261
261 if
(atomic_cmpset_rel_32(>rw_state,
(gdb)
_thr_rtld_lock_release (lock=) at
/usr/src/lib/libthr/thread/thr_rtld.c:162
162 if ((state & URWLOCK_WRITE_OWNER) == 0)
(gdb)
163 curthread->rdlock_count--;
(gdb)
164 THR_CRITICAL_LEAVE(curthread);
(gdb)
_thr_ast (curthread=0x80864b000) at /usr/src/lib/libthr/thread/thr_sig.c:271
271 if (!THR_IN_CRITICAL(curthread)) {
(gdb)
272 check_deferred_signal(curthread);
(gdb)
check_deferred_signal (curthread=0x80864b000) at
/usr/src/lib/libthr/thread/thr_sig.c:332
332 if (__predict_true(curthread->deferred_siginfo.si_signo == 0 ||
(gdb)
351 }
(gdb)
_thr_ast (curthread=0x80864b000) at /usr/src/lib/libthr/thread/thr_sig.c:273
273 check_suspend(curthread);
(gdb)
check_suspend (curthread=0x80864b000) at
/usr/src/lib/libthr/thread/thr_sig.c:358
358 if
Re: `uname -a' can't display revision
On Wed, 21 Aug 2019 05:49+1000, Peter Jeremy wrote: > My solution is to mount /usr/src with the option "nolockd". Thank you so much, Peter. I learned something new today. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: `uname -a' can't display revision
On Tue, 20 Aug 2019 21:24+0900, KIRIYAMA Kazuhiko wrote: > And I've rebuild in bhyve VM tbedfs that NFS mount > /ds/src/stable/12/r351247 to /usr/src: > > admin@tbedfs:~ % df -h > Filesystem SizeUsed Avail Capacity Mounted on > /dev/vtbd0p27.7G3.2G3.9G45%/ > devfs 1.0K1.0K 0B 100%/dev > vm.tfc:/.dake13T209G 13T 2%/.dake > vm.tfc:/ds/src/stable/12/r351247 13T103G 13T 1%/usr/src > vm.tfc:/ds/obj/stable/12/r351247 13T332G 13T 2%/usr/obj Maybe NFS is to blame, particularly if file locks cannot be obtained. svnversion is run during make buildkernel, and I can't run "svn info" over NFS from my hosts, as root nor as an unpriviledged user. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: `uname -a' can't display revision
On Tue, 20 Aug 2019 20:18+0900, KIRIYAMA Kazuhiko wrote: > On Tue, 20 Aug 2019 13:47:55 +0900, > Trond Endrestøl wrote: > > > > On Tue, 20 Aug 2019 11:00+0900, KIRIYAMA Kazuhiko wrote: > > > > > I've rebuild up to r351108 but `uname -a' can't display it's > > > revision number. > > > > Add this to /etc/src.conf: > > > > WITHOUT_REPRODUCIBLE_BUILD=yes > > Add above and rebuild with r351247, then > > admin@tbedfs:~ % uname -a > FreeBSD tbedfs 12.0-STABLE FreeBSD 12.0-STABLE #0: Tue Aug 20 19:10:53 JST > 2019 root@tbedfs:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 > admin@tbedfs:~ % > > Only revision number ommitted. Why ? Hum. That's strange. Do you have dot-directories belonging to Git or some other VCS in the root of your source tree? I'm guessing this might confuse the script generating the kernel identification. As a counter, this is from a recently updated VM running 13.0-CURRENT: # uname -a FreeBSD freebsd-head-zfs.FQDN 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r351209: Mon Aug 19 11:50:33 CEST 2019 r...@freebsd-head-zfs.fqdn:/usr/obj/usr/src/amd64.amd64/sys/XENGUEST amd64 -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: `uname -a' can't display revision
On Tue, 20 Aug 2019 11:00+0900, KIRIYAMA Kazuhiko wrote: > I've rebuild up to r351108 but `uname -a' can't display it's > revision number. Add this to /etc/src.conf: WITHOUT_REPRODUCIBLE_BUILD=yes -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
net/ocserv (and ifconfig) unable to destroy tun interfaces post r345045
Hi, I have a VPN service running net/ocserv 0.12.4_1. Everything is ok until the first client disconnects. The main ocserv process hangs while destroying the tun interface, waiting indefinitely on "tun_cond". I ran an ocserv executable containing debug symbols through gdb and I had a breakpoint on the call to ioctl(fd, SIOCIFDESTROY, ), at tun.c:770 of net/ocserv. The call to ioctl() has apparently a valid file descriptor, fd, and the fields of ifr are all zero, save the ifr_name field which contains "vpns0" and is properly null terminated. On the first attempt, I let the code run its course and had to reboot to recover. On the second attempt, I killed the ocserv process from within gdb. I ran "ifconfig vpns0 destroy" myself, and ifconfig froze immediately. Rebooting is the only way to recover. Reverting to stable/12 r345045 makes ocserv serve the clients again. My guess is that one or more of r345285, r347378, and/or r348124, all related to sys/net/if_tun.c, are to blame. Can someone verify my claims? See also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238500 https://gitlab.com/openconnect/ocserv/issues/213 -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS root mount regression
On Fri, 19 Jul 2019 14:21-0400, Garrett Wollman wrote: > Other than laboriously running "zpool labelclear -f /dev/somedisk" for > every piece of media that comes into my hands, is there anything else > I could have done to avoid this? I usually incorporate the hostname in the pool names. At one point I was contemplating if I should also have generation numbers in the pool names. E.g.: enterprise_zroot enterprise_zdata enterprise_zroot_g01 enterprise_zdata_g01 enterprise_zroot_g02 enterprise_zdata_g02 -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problem with 12_STABLE on amd64
On Thu, 6 Jun 2019 12:04-, Filippo Moretti via freebsd-stable wrote: > I have the following problem on amd-64 STABLE-12for some odd reason > my custom kernel no longer boot while I could build GENERIC and that > would boot fine.Today I wrote a new configuration kernel file > removing only the devices I do not have.Unfortunately the working > kernel was not moved to kernel.old as it would be expected and now I > am locked out of the system as the new kernel fail to bott with > error sis cannot find zroot/ROOT/default.Is there a way to recover > my system?SincerelyFilippo Press 3 in the boot loader to enter the command line. Type in these commands: unload load /boot/kernel/kernel load /boot/kernel/opensolaris.ko load /boot/kernel/zfs.ko boot -s Your keyboard layout is "US" at the moment. The hyphen (minus) key is usually on the plus key when the US keyboard layout is active and you're using a non-US keyboard, and slash is usually on the hyphen key. Once you get to a proper Unix shell, you might want to change the keyboard layout to something sensible using: kbdcontrol -l If you have physical access to your system and bootable install media at hand, you could boot from said install media, select shell, and import your pool using: zpool import -Nf zroot Manually mount your rootfs, e.g.: mount -t zfs zroot/ROOT/default /mnt If one of these routes was successful, edit your /boot/loader.conf or /mnt/boot/loader.conf using edit, ed, ee, or vi, to include: zfs_load="YES" Mount other filesystems as needed, or reboot to see if your system has recovered. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: carp can't delete address
On Thu, 23 May 2019 23:04+0200, Stefan Bethke wrote: > I’ve just set up carp (for the first time) and it seems the virtual address > is not being removed on the backup host: > > May 23 20:55:09 xxx kernel: carp: 1@igb0: INIT -> BACKUP (initialization > complete) > May 23 20:55:12 xxx kernel: carp: 1@igb0: BACKUP -> MASTER (master timed out) > May 23 20:56:33 xxx kernel: carp: 1@igb0: MASTER -> BACKUP (more frequent > advertisement received) > May 23 20:56:33 xxx kernel: igb0: deletion failed: 3 > > ifconfig shows the address as active: > # ifconfig igb0 > igb0: flags=8943 metric 0 mtu > 1500 > > options=e527bb > ether ac:1f:6b:12:34:56 > inet 212.12.xxx.xxx/24 broadcast 212.12.xxx.xxx > inet 212.12.xxx.yyy/32 broadcast 212.12.xxx.yyy vhid 1 > inet6 fe80::ae1f:6bff:...%igb0/64 scopeid 0x1 > carp: BACKUP vhid 1 advbase 1 advskew 200 > media: Ethernet autoselect (1000baseT ) > status: active > nd6 options=21 > > Is there a configuration I can/need to adjust? It is normal for the common address to be present in all participating nodes. Your node above moved to the backup state since another node advertise the same (encrypted) vhid at a quicker pace. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Pkg upgrade for 12-STABLE builds in "Latest" broken?
On Fri, 26 Apr 2019 15:50-0500, Karl Denninger wrote: > pkg: > http://pkg.FreeBSD.org/FreeBSD:12:amd64/latest/All/dovecot-2.3.5.txz: > Not Found The most recent package is dovecot-2.3.5.2.txz. Sometimes pkg has stale data in its cache. Try running pkg update -f to refresh the cache. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic during reboot involving softclock_call_cc(), nd6_timer() and nd6_dad_start()
On Wed, 17 Apr 2019 12:05+0200, Trond Endrestøl wrote: > On Wed, 17 Apr 2019 12:41+0300, Andrey V. Elsukov wrote: > > > On 15.04.2019 16:31, Trond Endrestøl wrote: > > > Has anyone else witnessed a panic during reboot involving > > > softclock_call_cc(), nd6_timer(), and nd6_dad_start()? > > > > > > The stack trace goes more or less like this: > > > > > > db_trace_self_wrapper() > > > vpanic() > > > panic() > > > trap_fatal() > > > trap() > > > calltrap() > > > nd6_dad_start() > > > nd6_timer() > > > softclock_call_cc() > > > softclock() > > > ithread_loop() > > > fork_exit() > > > fork_trampoline() > > > > > > This was last seen while transitioning from r345628 to r346220 on > > > amd64 stable/12. > > > > Hi, > > > > do you have exact panic message and/or backtrace from core dump? > > Here's another system I had to shut down recently: > > root@HOSTNAME:/var/crash # kgdb /boot/kernel/kernel vmcore.0 > [...] > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x410 > fault code = supervisor read data , page not present > instruction pointer = 0x20:0x807ea33d > stack pointer = 0x28:0xfe005ad3c8d0 > frame pointer = 0x28:0xfe005ad3c960 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 12 (swi4: clock (0)) > trap number = 12 > panic: page fault > cpuid = 0 > time = 1555402802 > KDB: stack backtrace: > db_trace_self_wrapper() at 0x8054125b = > db_trace_self_wrapper+0x2b/frame 0xfe005ad3c570 > vpanic() at 0x8080aae4 = vpanic+0x1b4/frame 0xfe005ad3c5d0 > panic() at 0x8080a923 = panic+0x43/frame 0xfe005ad3c630 > trap_fatal() at 0x80b76244 = trap_fatal+0x394/frame 0xfe005ad3c690 > trap_pfault() at 0x80b762a9 = trap_pfault+0x49/frame > 0xfe005ad3c6f0 > trap() at 0x80b7588f = trap+0x29f/frame 0xfe005ad3c800 > calltrap() at 0x80b514c5 = calltrap+0x8/frame 0xfe005ad3c800 > --- trap 0xc, rip = 0x807ea33d, rsp = 0xfe005ad3c8d0, rbp = > 0xfe005ad3c960 --- > __mtx_lock_sleep() at 0x807ea33d = __mtx_lock_sleep+0xbd/frame > 0xfe005ad3c960 > mld_fasttimo() at 0x80a3ae32 = mld_fasttimo+0x492/frame > 0xfe005ad3ca50 > pffasttimo() at 0x80899fa4 = pffasttimo+0x54/frame 0xfe005ad3ca80 > softclock_call_cc() at 0x80824e0e = softclock_call_cc+0x12e/frame > 0xfe005ad3cb30 > softclock() at 0x808252f9 = softclock+0x79/frame 0xfe005ad3cb50 > ithread_loop() at 0x807cd824 = ithread_loop+0x1d4/frame > 0xfe005ad3cbb0 > fork_exit() at 0x807ca2d3 = fork_exit+0x83/frame 0xfe005ad3cbf0 > fork_trampoline() at 0x80b524be = fork_trampoline+0xe/frame > 0xfe005ad3cbf0 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > Uptime: 34d16h8m2s > Dumping 4593 out of 12258 > MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > > This particular system uses lagg0 comprised of bce0, bce1, em0, and > em1. Also, it runs a custom kernel. > > > It would be good to submit PR about such problems. > > I'll submit the details in a PR. PR is 237329. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237329 -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic during reboot involving softclock_call_cc(), nd6_timer() and nd6_dad_start()
On Wed, 17 Apr 2019 12:41+0300, Andrey V. Elsukov wrote: > On 15.04.2019 16:31, Trond Endrestøl wrote: > > Has anyone else witnessed a panic during reboot involving > > softclock_call_cc(), nd6_timer(), and nd6_dad_start()? > > > > The stack trace goes more or less like this: > > > > db_trace_self_wrapper() > > vpanic() > > panic() > > trap_fatal() > > trap() > > calltrap() > > nd6_dad_start() > > nd6_timer() > > softclock_call_cc() > > softclock() > > ithread_loop() > > fork_exit() > > fork_trampoline() > > > > This was last seen while transitioning from r345628 to r346220 on > > amd64 stable/12. > > Hi, > > do you have exact panic message and/or backtrace from core dump? Here's another system I had to shut down recently: root@HOSTNAME:/var/crash # kgdb /boot/kernel/kernel vmcore.0 [...] Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x410 fault code = supervisor read data , page not present instruction pointer = 0x20:0x807ea33d stack pointer = 0x28:0xfe005ad3c8d0 frame pointer = 0x28:0xfe005ad3c960 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12 (swi4: clock (0)) trap number = 12 panic: page fault cpuid = 0 time = 1555402802 KDB: stack backtrace: db_trace_self_wrapper() at 0x8054125b = db_trace_self_wrapper+0x2b/frame 0xfe005ad3c570 vpanic() at 0x8080aae4 = vpanic+0x1b4/frame 0xfe005ad3c5d0 panic() at 0x8080a923 = panic+0x43/frame 0xfe005ad3c630 trap_fatal() at 0x80b76244 = trap_fatal+0x394/frame 0xfe005ad3c690 trap_pfault() at 0x80b762a9 = trap_pfault+0x49/frame 0xfe005ad3c6f0 trap() at 0x80b7588f = trap+0x29f/frame 0xfe005ad3c800 calltrap() at 0x80b514c5 = calltrap+0x8/frame 0xfe005ad3c800 --- trap 0xc, rip = 0x807ea33d, rsp = 0xfe005ad3c8d0, rbp = 0xfe005ad3c960 --- __mtx_lock_sleep() at 0x807ea33d = __mtx_lock_sleep+0xbd/frame 0xfe005ad3c960 mld_fasttimo() at 0x80a3ae32 = mld_fasttimo+0x492/frame 0xfe005ad3ca50 pffasttimo() at 0x80899fa4 = pffasttimo+0x54/frame 0xfe005ad3ca80 softclock_call_cc() at 0x80824e0e = softclock_call_cc+0x12e/frame 0xfe005ad3cb30 softclock() at 0x808252f9 = softclock+0x79/frame 0xfe005ad3cb50 ithread_loop() at 0x807cd824 = ithread_loop+0x1d4/frame 0xfe005ad3cbb0 fork_exit() at 0x807ca2d3 = fork_exit+0x83/frame 0xfe005ad3cbf0 fork_trampoline() at 0x80b524be = fork_trampoline+0xe/frame 0xfe005ad3cbf0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- Uptime: 34d16h8m2s Dumping 4593 out of 12258 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% This particular system uses lagg0 comprised of bce0, bce1, em0, and em1. Also, it runs a custom kernel. > It would be good to submit PR about such problems. I'll submit the details in a PR. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS parallel mounting gone wrong?
On Mon, 15 Apr 2019 15:24+0200, Trond Endrestøl wrote: > I upgraded a non-critical system running amd64 stable/12 to r346220. > > During multiuser boot not all ZFS filesystems below zroot/usr/local > was mounted. Some more explaining is in order: This system has two 7 year old pools that complement each other. /usr/local comes mostly from the zroot pool, but other children comes from a zdata pool. The intermediary filesystems have their canmount property set to off and mountpoints are specified at the top level only. The same goes for other parts of the filesystem hierarchy, such as /var/db and /var/spool. I just upgraded to stable/12 global r346269, local r346268. During a routine "zfs mount -av" performed in single user mode, the kernel proceeded to mount a child filesystem (enterprise_zdata/var/db/mysql) without the parent filesystems being mounted first. I rebooted back to r345628 from March 28th, and this kernel has no problems correctly mounting the ZFS filesystems in parallel. That BE used LLVM 7.0.1 from base as its system compiler. Rebooting into r346220 (April 15th) or r346269 (April 17th) clearly shows problems mounting filesystems in the correct order. These BEs was compiled using LLVM 8.0.0 from base. Maybe the system compiler is irrelevant. The name of the pools might also be a factor, the zdata pool preceedes the zroot pool in alphanumerical order. Maybe there is a bug in the code, or the code breaks when parts of the filesystem hierarchy is being built from multiple pools. Here's an attempt at explaining how this fits together: zfs list -ro name,canmount,mountpoint enterprise_zroot/usr enterprise_zdata/usr enterprise_zroot/var enterprise_zdata/var [the list has been slightly edited, moving zdata below zroot and adding an empty line] NAME CANMOUNT MOUNTPOINT enterprise_zroot/usroff /usr enterprise_zroot/usr/compat on /usr/compat enterprise_zroot/usr/local on /usr/local enterprise_zroot/usr/local/certs on /usr/local/certs enterprise_zroot/usr/local/etc on /usr/local/etc enterprise_zroot/usr/local/etc/shellkonfig3 on /usr/local/etc/shellkonfig3 enterprise_zroot/usr/local/etc/shellkonfig3/head on /usr/local/etc/shellkonfig3/head enterprise_zroot/usr/local/etc/shellkonfig3/stable-10on /usr/local/etc/shellkonfig3/stable-10 enterprise_zroot/usr/local/etc/shellkonfig3/stable-11on /usr/local/etc/shellkonfig3/stable-11 enterprise_zroot/usr/local/etc/shellkonfig3/stable-8 on /usr/local/etc/shellkonfig3/stable-8 enterprise_zroot/usr/local/etc/shellkonfig3/stable-9 on /usr/local/etc/shellkonfig3/stable-9 enterprise_zroot/usr/local/info on /usr/local/info enterprise_zroot/usr/local/var on /usr/local/var enterprise_zroot/usr/obj on /usr/obj enterprise_zroot/usr/ports on /usr/ports enterprise_zroot/usr/ports/distfiles on /usr/ports/distfiles enterprise_zroot/usr/ports/localoff /usr/ports/local enterprise_zroot/usr/ports/packages on /usr/ports/packages enterprise_zroot/usr/ports/workdirs on /usr/ports/workdirs enterprise_zroot/usr/src on /usr/src enterprise_zdata/usroff /usr enterprise_zdata/usr/local off /usr/local enterprise_zdata/usr/local/moodledataon /usr/local/moodledata enterprise_zdata/usr/local/pgsql on /usr/local/pgsql enterprise_zdata/usr/local/restaurering on /usr/local/restaurering enterprise_zdata/usr/local/www on /usr/local/www enterprise_zdata/usr/local/www/moodleon /usr/local/www/moodle enterprise_zroot/varoff /var enterprise_zroot/var/Named on /var/Named enterprise_zroot/var/account on /var/account enterprise_zroot/var/audit on /var/audit enterprise_zroot/var/cache off /var/cache enterprise_zroot/var/cache/ccacheon /var/cache/ccache enterprise_zroot/var/cache/synth on /var/cache/synth enterprise_zroot/var/crash on /var/crash enterprise_zroot/var/db on /var/db enterprise_zroot/var/db/darkstat on /var/db/darkstat enterp
Re: Panic during reboot involving softclock_call_cc(), nd6_timer() and nd6_dad_start()
On Mon, 15 Apr 2019 15:31+0200, Trond Endrestøl wrote: > Has anyone else witnessed a panic during reboot involving > softclock_call_cc(), nd6_timer(), and nd6_dad_start()? > > The stack trace goes more or less like this: > > db_trace_self_wrapper() > vpanic() > panic() > trap_fatal() > trap() > calltrap() > nd6_dad_start() > nd6_timer() > softclock_call_cc() > softclock() > ithread_loop() > fork_exit() > fork_trampoline() > > This was last seen while transitioning from r345628 to r346220 on > amd64 stable/12. The NIC in question is a Chelsio T6225-CR, cxgbe(4), using the cc0 port only. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Panic during reboot involving softclock_call_cc(), nd6_timer() and nd6_dad_start()
Hi, Has anyone else witnessed a panic during reboot involving softclock_call_cc(), nd6_timer(), and nd6_dad_start()? The stack trace goes more or less like this: db_trace_self_wrapper() vpanic() panic() trap_fatal() trap() calltrap() nd6_dad_start() nd6_timer() softclock_call_cc() softclock() ithread_loop() fork_exit() fork_trampoline() This was last seen while transitioning from r345628 to r346220 on amd64 stable/12. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ZFS parallel mounting gone wrong?
Hi, I upgraded a non-critical system running amd64 stable/12 to r346220. During multiuser boot not all ZFS filesystems below zroot/usr/local was mounted. Out of these filesystems, only zroot/usr/local/etc/shellkonfig3 was mounted: zroot/usr/local zroot/usr/local/certs zroot/usr/local/etc zroot/usr/local/etc/shellkonfig3 zroot/usr/local/etc/shellkonfig3/head zroot/usr/local/etc/shellkonfig3/stable-10 zroot/usr/local/etc/shellkonfig3/stable-11 zroot/usr/local/etc/shellkonfig3/stable-8 zroot/usr/local/etc/shellkonfig3/stable-9 zroot/usr/local/info zroot/usr/local/var It's not a one-off bug, it can be replicated simply by rebooting this system. There is no M appended to my revision number. Booting into singleuser mode and correctly mount all filesystems manually before returning to multiuser mode is not something I want to repeat. I will create a shell script to ease the pain anyway. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 12-stable buildworld appears to be broken
On Thu, 7 Mar 2019 13:47+0100, Hans Ottevanger wrote:
> On 3/7/19 8:29 AM, Trond Endrestøl wrote:
> >
> > It's good to see I'm not the only one experiencing this issue. It
> > looks like r339941 was never merged to stable/12.
>
> FWIW, the same happens in stable/11 (r344876).
For the "eager beavers" of you, try the attached patch.
Later, you might want to run "svn up --accept=theirs-full".
--
Trond.Index: sbin/fsck_ffs/dir.c
===
--- sbin/fsck_ffs/dir.c (revision 339940)
+++ sbin/fsck_ffs/dir.c (revision 339941)
@@ -323,7 +323,7 @@
if (preen || reply("ADJUST") == 1) {
if (bkgrdflag == 0) {
DIP_SET(dp, di_nlink, DIP(dp, di_nlink) - lcnt);
- inodirty();
+ inodirty(dp);
} else {
cmd.value = idesc->id_number;
cmd.size = -lcnt;
@@ -449,7 +449,7 @@
pfatal("SORRY. CANNOT CREATE lost+found DIRECTORY\n\n");
return (0);
}
- inodirty();
+ inodirty(dp);
idesc.id_type = ADDR;
idesc.id_func = pass4check;
idesc.id_number = oldlfdir;
@@ -474,7 +474,7 @@
(void)makeentry(orphan, lfdir, "..");
dp = ginode(lfdir);
DIP_SET(dp, di_nlink, DIP(dp, di_nlink) + 1);
- inodirty();
+ inodirty(dp);
inoinfo(lfdir)->ino_linkcnt++;
pwarn("DIR I=%lu CONNECTED. ", (u_long)orphan);
if (parentdir != (ino_t)-1) {
@@ -535,7 +535,7 @@
dp = ginode(parent);
if (DIP(dp, di_size) % DIRBLKSIZ) {
DIP_SET(dp, di_size, roundup(DIP(dp, di_size), DIRBLKSIZ));
- inodirty();
+ inodirty(dp);
}
if ((ckinode(dp, ) & ALTERED) != 0)
return (1);
@@ -591,7 +591,7 @@
else if (reply("EXPAND") == 0)
goto bad;
dirty(bp);
- inodirty();
+ inodirty(dp);
return (1);
bad:
DIP_SET(dp, di_db[lastbn], DIP(dp, di_db[lastbn + 1]));
@@ -632,7 +632,7 @@
memmove(cp, , sizeof emptydir);
dirty(bp);
DIP_SET(dp, di_nlink, 2);
- inodirty();
+ inodirty(dp);
if (ino == UFS_ROOTINO) {
inoinfo(ino)->ino_linkcnt = DIP(dp, di_nlink);
cacheino(dp, ino);
@@ -653,7 +653,7 @@
}
dp = ginode(parent);
DIP_SET(dp, di_nlink, DIP(dp, di_nlink) + 1);
- inodirty();
+ inodirty(dp);
return (ino);
}
@@ -668,7 +668,7 @@
if (ino != parent) {
dp = ginode(parent);
DIP_SET(dp, di_nlink, DIP(dp, di_nlink) - 1);
- inodirty();
+ inodirty(dp);
}
freeino(ino);
}
Index: sbin/fsck_ffs/fsck.h
===
--- sbin/fsck_ffs/fsck.h(revision 339940)
+++ sbin/fsck_ffs/fsck.h(revision 339941)
@@ -448,7 +448,7 @@
void infohandler(int sig);
void alarmhandler(int sig);
void inocleanup(void);
-void inodirty(void);
+void inodirty(union dinode *);
struct inostat *inoinfo(ino_t inum);
void IOstats(char *what);
intlinkup(ino_t orphan, ino_t parentdir, char *name);
Index: sbin/fsck_ffs/inode.c
===
--- sbin/fsck_ffs/inode.c (revision 339940)
+++ sbin/fsck_ffs/inode.c (revision 339941)
@@ -102,7 +102,7 @@
printf(
"YOU MUST RERUN FSCK AFTERWARDS\n");
rerun = 1;
- inodirty();
+ inodirty(dp);
}
}
@@ -142,7 +142,7 @@
printf(
"YOU MUST RERUN FSCK AFTERWARDS\n");
rerun = 1;
- inodirty();
+ inodirty(dp);
break;
}
}
@@ -221,7 +221,7 @@
printf(
"YOU MUST RERUN FSCK AFTERWARDS\n");
rerun = 1;
- inodirty();
+
Re: 12-stable buildworld appears to be broken
On Thu, 7 Mar 2019 05:13-, tech-lists wrote: > Hi, > > My context is poudriere creating jails on freebsd12-stable. This procedure > worked fine for some other jails I created a couple days ago (the 5th) but > now, today I get buildworld failures with creating either amd64 or armv7 jails > (the server is amd64) > > To try to see the failure, I set jobs to J1 like so: > > poudriere jail -x -J1 -c -j 12armv7 -a arm.armv7 -m svn+https -v > stable/12 > > It bails when it's making rescue with this error: > > /data/poudriere/basefs/jails/12armv7/usr/src/sbin/fsck_ffs/pass1.c:454:13: > error: too many arguments to function call, expected 0, have 1 >inodirty(dp); > ^~ > /data/poudriere/basefs/jails/12armv7/usr/src/sbin/fsck_ffs/fsck.h:453:1: > note: 'inodirty' declared here > void inodirty(void); ^ > 1 error generated. > *** [pass1.o] Error code 1 > > I know that's probably not enough, so have pasted much more output at > https://rpi3.zyxst.net/errors/poudriere-build-failure.txt > > not tried make buildworld yet on the host. The OS is at r344763 and > /usr/src is at 344863 > > Just tried it on another 12-stable desktop, straightforward make > buildworld, same sort of error: > > --- all_subdir_sbin/fsdb --- > /usr/src/sbin/fsdb/fsdb.c:1042:14: error: too many arguments to function > call, expected 0, have 1 >inodirty(curinode); > ^~~~ /usr/src/sbin/fsck_ffs/fsck.h:453:1: note: > 'inodirty' declared >here >voidinodirty(void); > > the sources are at 344869 It's good to see I'm not the only one experiencing this issue. It looks like r339941 was never merged to stable/12. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Kernel panic, stable/12 r341604, swapon -a in SU mode, geli encrypted swap, Chelsio T6225-CR, and ccr(4)
On Thu, 6 Dec 2018 09:38-0800, Navdeep Parhar wrote: > Can you please file a bug at https://bugs.freebsd.org/bugzilla/ and > assign it to me? See PR 233851. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Kernel panic, stable/12 r341604, swapon -a in SU mode, geli encrypted swap, Chelsio T6225-CR, and ccr(4)
After booting stable/12 r341604, running a custom kernel including cxgbe(4), cxgbev(4), and ccr(4), and running swapon -a in SU mode: GEOM_ELI: Device gpt/swap0.eli created. GEOM_ELI: Encryption: AES-XTS 256 GEOM_ELI: Crypto: hardware Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 06 fault virtual address = 0x0 fault code = supervisor write data, page not present instruction pointer = 0x20:0x805be1b2 stack pointer = 0x28:0xfe00a6253770 frame pointer = 0x28:0xfe00a6253770 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 65 (g_eli[3] gpt/swap0) trap number = 12 panic: page fault cpuid = 3 time = 1544087308 KDB: stack backtrace: db_trace_self_wrapper() at 0x8055d9eb = db_trace_self_wrapper+0x2b/frame 0xfe00a6253420 vpanic() at 0x808754d3 = vpanic+0x1a3/frame 0xfe00a6253480 panic() at 0x80875323 = panic+0x43/frame 0xfe00a62534e0 trap_fatal() at 0x80bd745f = trap_fatal+0x35f/frame 0xfe00a6253530 trap_pfault() at 0x80bd74b9 = trap_pfault+0x49/frame 0xfe00a4b7f590 trap() at 0x80bd6ade = trap+0x29e/frame 0xfe00a4b7f6a0 calltrap() at 0x80bb3935 = calltrap+0x8/frame 0xfe00a4b7f6a0 --- trap 0xc, rip = 0x805be1b2, rsp = 0xfe00a4b7f770, rbp = 0xfe00a4b7f770 t4_wrq_tx_locked() at 0x805be1b2 = t4_wrq_tx_locked+0x12/frame 0xfe00a6253770 ccr_process() at 0x805e3fc3 = ccr_process+0x1953/frame 0xfe00a4b7f970 crypto_dispatch() at 0x80ae3fa4 = crypto_dispatch+0x144/frame 0xfe00a4b7f9b0 g_eli_crypto_run() at 0x807b5cb3 = g_eli_crypto_run+0x273/frame 0xfe00a4b7fa10 g_eli_worker() at 0x807aebc8 = g_eli_worker+0x3c8/frame 0xfe00a4b7fa70 fork_exit() at 0x80834d93 = fork_exit+0x83/frame 0xfe00a4b7fab0 fork_trampoline() at 0x80bb491e = fork_trampoline+0xe/frame 0xfe00a4b7fab0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- Uptime: 14s Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot, The Chelsio NIC is a T6225-CR. Kernel config is https://ximalas.info/~trond/create-zfs/canmount/ENTERPRISE-amd64-stable-12 I tried stable/12 r341623 with ccr(4) removed from the kernel, and I had no problems engaging geli encrypted swap in SU mode nor in normal mode. Has anyone else tried ccr(4) on recent stable/12? Are we discouraged from using ccr(4)? I was hoping to take advantage of the crypto accelerator. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: plenty of memory, but system us intensively swapping
On Tue, 20 Nov 2018 15:22+0500, Eugene M. Zheganin wrote:
> Hello,
>
> On 20.11.2018 15:12, Trond Endrestøl wrote:
> > On freebsd-hackers the other day,
> > https://lists.freebsd.org/pipermail/freebsd-hackers/2018-November/053575.html,
> > it was suggested to set vm.pageout_update_period=0. This sysctl is at
> > 600 initially.
> >
> > ZFS' ARC needs to be capped, otherwise it will eat most, if not all,
> > of your memory.
> Well, as you can see, ARC ate only half, and the other half is eaten by the
> kernel. So far I suppose that if I will cap the ARC, the kernel will simply
> eat the rest.
I know others have created a daemon that observe the ARC and the
amount of wired and free memory, and when these values exceed some
threshold, the daemon will allocate a number of gigabytes, writing
zero to the first byte or word of every page, and then freeing the
allocated memory before going back to sleep.
The ARC will release most of its allocations and the kernel will also
release some but not all of its wired memory, and some user pages are
likely to be thrown onto the swap device, turning the user experience
to a mild nightmare while waiting for applications to be paged back
into memory.
ZFS seems to be the common factor in most, if not all, of these cases.
I created my own and not so sophisticated C program that I run every
now and then:
#include
#include
#include
int main(int argc, char **argv)
{
const size_t pagesize = (size_t)getpagesize();
const size_t gigabyte = 1024ULL * 1024ULL * 1024ULL;
size_t amount, n = 1ULL;
char *p, *offset;
if (argc > 1) {
sscanf(argv[1], "%zu", );
}
amount = n * gigabyte;
if (amount > 0ULL) {
if ( (p = malloc(amount)) != NULL) {
for (offset = p; offset < p + amount; offset += pagesize) {
*offset = '\0';
}
free(p);
}
else {
fprintf(stderr,
"%s:%s:%d: unable to allocate %zu gigabyte%s\n",
argv[0], __FILE__, __LINE__,
n, (n == 1ULL) ? "" : "s");
return 2;
}
}
else {
return 1;
}
return 0;
} // main()
// allocate_gigabytes.c
--
Trond.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: plenty of memory, but system us intensively swapping
On Tue, 20 Nov 2018 14:53+0500, Eugene M. Zheganin wrote: > Hello, > > > I have a recent FreeBSD 11-STABLE which is mainly used as an iSCSI target. The > system has 64G of RAM but is swapping intensively. Yup, about of half of the > memory is used as ZFS ARC (isn't capped in loader.conf), and another half is > eaten by the kernel, but it oly uses only about half of it (thus 25% of the > total amount). > > Could this be tweaked by some sysctl oids (I suppose not, but worth asking). On freebsd-hackers the other day, https://lists.freebsd.org/pipermail/freebsd-hackers/2018-November/053575.html, it was suggested to set vm.pageout_update_period=0. This sysctl is at 600 initially. ZFS' ARC needs to be capped, otherwise it will eat most, if not all, of your memory. > top, vmstat 1 snapshots and zfs-stats -a are listed below. > > > Thanks. > > > [root@san01:nginx/vhost.d]# vmstat 1 > procs memory pagedisks faults cpu > r b w avm fre flt re pi pofr sr da0 da1 in sycs us sy id > 0 0 38 23G 609M 1544 68 118 64 895 839 0 0 3644 2678 649 0 13 > 87 > 0 0 53 23G 601M 1507 185 742 315 1780 33523 651 664 56438 785 476583 0 28 > 72 > 0 0 53 23G 548M 1727 330 809 380 2377 33256 758 763 5 1273 468545 0 > 26 73 > 0 0 53 23G 528M 1702 239 660 305 1347 32335 611 631 59962 1025 490365 0 > 22 78 > 0 0 52 23G 854M 2409 309 693 203 97943 16944 525 515 64309 1570 540533 0 > 29 71 > 3 0 54 23G 1.1G 2756 639 641 149 124049 19531 542 538 64777 1576 553946 0 > 35 65 > 0 0 53 23G 982M 1694 236 680 282 2754 35602 597 603 66540 1385 583687 0 > 28 72 > 0 0 41 23G 867M 1882 223 767 307 1162 34936 682 638 67284 780 568818 0 33 > 67 > 0 0 39 23G 769M 1542 167 673 336 1187 35123 646 610 65925 1176 551623 0 > 23 77 > 2 0 41 23G 700M 3602 535 688 327 2192 37109 622 594 65862 4256 518934 0 > 33 67 > 0 0 54 23G 650M 2957 219 726 464 4838 36464 852 868 65384 4110 558132 1 > 37 62 > 0 0 54 23G 641M 1576 245 730 344 1139 33681 740 679 67216 970 560379 0 31 > 69 > > > [root@san01:nginx/vhost.d]# top > last pid: 55190; load averages: 11.32, 12.15, 10.76 > up 10+16:05:14 14:38:58 > 101 processes: 1 running, 100 sleeping > CPU: 0.2% user, 0.0% nice, 28.9% system, 1.6% interrupt, 69.3% idle > Mem: 85M Active, 1528K Inact, 12K Laundry, 62G Wired, 540M Free > ARC: 31G Total, 19G MFU, 6935M MRU, 2979M Anon, 556M Header, 1046M Other > 25G Compressed, 34G Uncompressed, 1.39:1 Ratio > Swap: 32G Total, 1186M Used, 31G Free, 3% Inuse, 7920K In, 3752K Out > PID USERNAME THR PRI NICE SIZERES STATE C TIMEWCPU COMMAND > 40132 root 131 520 3152M 75876K uwait 14 36:59 6.10% java > 55142 root 1 200 7904K 2728K CPU20 20 0:00 0.72% top > 20026 root 1 200 106M 5676K nanslp 28 1:23 0.60% gstat > 53642 root 1 200 7904K 2896K select 14 0:03 0.58% top > 977 zfsreplica 1 200 30300K 3568K kqread 21 4:00 0.42% uwsgi > 968 zfsreplica 1 200 30300K 2224K swread 11 2:03 0.21% uwsgi > 973 zfsreplica 1 200 30300K 2264K swread 13 12:26 0.13% uwsgi > 53000 www1 200 23376K 1372K kqread 24 0:00 0.05% nginx > 1292 root 1 200 6584K 2040K select 29 0:23 0.04% > blacklistd > 776 zabbix 1 200 12408K 4236K nanslp 26 4:42 0.03% > zabbix_agentd > 1289 root 1 200 67760K 5148K select 13 9:50 0.03% bsnmpd > 777 zabbix 1 200 12408K 1408K select 25 5:06 0.03% > zabbix_agentd > 785 zfsreplica 1 200 27688K 3960K kqread 28 2:04 0.02% uwsgi > 975 zfsreplica 1 200 30300K 464K kqread 18 2:33 0.02% uwsgi > 974 zfsreplica 1 200 30300K 480K kqread 30 3:39 0.02% uwsgi > 965 zfsreplica 1 200 30300K 464K kqread 4 3:23 0.02% uwsgi > 976 zfsreplica 1 200 30300K 464K kqread 14 2:59 0.01% uwsgi > 972 zfsreplica 1 200 30300K 464K kqread 10 2:57 0.01% uwsgi > 963 zfsreplica 1 200 30300K 460K kqread 3 2:45 0.01% uwsgi > 971 zfsreplica 1 200 30300K 464K kqread 13 3:16 0.01% uwsgi > 69644 emz1 200 13148K 4596K select 24 0:05 0.01% sshd > 18203 vryabov1 200 13148K 4624K select 9 0:02 0.01% sshd > 636 root 1 200 6412K 1884K select 17 4:10 0.01% syslogd > 51266 emz1 200 13148K 4576K select 5 0:00 0.01% sshd > 964 zfsreplica 1 200 30300K 460K kqread 18 11:02 0.01% uwsgi > 962 zfsreplica 1 200 30300K 460K kqread 28 6:56 0.01% uwsgi > 969 zfsreplica 1 200 30300K 464K kqread 12 2:07 0.01% uwsgi > 967 zfsreplica 1 200 30300K 464K kqread 27 5:18 0.01% uwsgi > 970 zfsreplica 1 200 30300K 464K kqread 0 4:25 0.01% uwsgi > 966
Re: ldconfig(8) oddity on 11.2-BETA3?
On Mon, 28 May 2018 17:37+0200, Christoph Moench-Tegeder wrote: > (I'm not only "not a synth user", but also "rather inept with Ada"). I started learning Ada this year because of synth, and I'm barely a novice Ada programmer. :-) -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ldconfig(8) oddity on 11.2-BETA3?
On Mon, 28 May 2018 15:24+0200, Trond Endrestøl wrote: > I can see one reason for not making /etc/rc.subr accessible inside > each chroot, and thus a copy of the ldconfig startup script, and that > is to prevent services from being started automatically within each > chroot. The latest commits to the synth repo forces synth to copy /etc/rc.subr and /etc/rc.d/ldconfig into each chroot. CommitDate: Fri May 25 08:16:19 2018 -0500 A new release might be imminent. Don't look at me, I'm just a synth luser. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ldconfig(8) oddity on 11.2-BETA3?
On Mon, 28 May 2018 13:44+0200, Christoph Moench-Tegeder wrote: > has synth some special "optimization" for handling ldconfig? Looking at src/replicant.adb of synth, I see it runs ldconfig when setting up each chroot env using this procedure: -- execute_ldconfig -- procedure execute_ldconfig (id : builders) is smount : constant String := get_slave_mount (id); bsd_command : constant String := chroot & smount & " /sbin/ldconfig -m /lib /usr/lib"; lin_command : constant String := chroot & smount & " /usr/sbin/ldconfig /lib /usr/lib"; begin case platform_type is when dragonfly | freebsd => execute (bsd_command); when linux => execute (lin_command); when netbsd | solaris => null; when unknown => null; end case; end execute_ldconfig; synth probably expects the packages to handle localbase libraries upon installation in each chroot. I can see one reason for not making /etc/rc.subr accessible inside each chroot, and thus a copy of the ldconfig startup script, and that is to prevent services from being started automatically within each chroot. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: pdeathsig_helper and .debug/pdeathsig_helper.debug placed in /mnt when DESTDIR=/mnt
On Wed, 9 May 2018 22:52+0300, Konstantin Belousov wrote: > On Wed, May 09, 2018 at 09:19:12PM +0200, Trond Endrestøl wrote: > > On Wed, 9 May 2018 20:46+0200, Trond Endrestøl wrote: > > > > In case it helps, here's the result from a single-job run: > > > > ===> tests/sys/geom/class/uzip (install) > > install -o root -g wheel -m 555 1_test > > /mnt/usr/tests/sys/geom/class/uzip/1_test > > install -o root -g wheel -m 444 > > /usr/src/tests/sys/geom/class/uzip/etalon/etalon.txt > > /mnt/usr/tests/sys/geom/class/uzip/etalon/ > > install -o root -g wheel -m 444 Kyuafile > > /mnt/usr/tests/sys/geom/class/uzip/Kyuafile > > install -o root -g wheel -m 444 > > /usr/src/tests/sys/geom/class/uzip/conf.sh 1.img.uzip.uue > > /mnt/usr/tests/sys/geom/class/uzip/ > > ===> tests/sys/kern (install) > > /tmp/install.84PWkNVS/sh: cannot create Kyuafile.tmp: Read-only file system > > This error probably means that you did not correctly rebuild the world > before attempting the installation. Thanks. I'll arrange for the builder to rebuild everything when running the scheduled build tomorrow morning. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: pdeathsig_helper and .debug/pdeathsig_helper.debug placed in /mnt when DESTDIR=/mnt
On Wed, 9 May 2018 20:46+0200, Trond Endrestøl wrote: > But this one's persistent: > > --- realinstall_subdir_tests --- > --- subr_unit_test.install --- > (cd /usr/src/tests/sys/kern && DEPENDFILE=.depend.subr_unit_test > NO_SUBDIR=1 make -f /usr/src/tests/sys/kern/Makefile _RECURSING_PROGS=t > PROG=subr_unit_test install) > --- realinstall_subdir_usr.sbin --- > install -o root -g wheel -m 444 ancontrol.debug > /mnt/usr/lib/debug/usr/sbin/ancontrol.debug > --- maninstall --- > install -o root -g wheel -m 444 ancontrol.8.gz /mnt/usr/share/man/man8/ > --- realinstall_subdir_usr.sbin/wlandebug --- > ===> usr.sbin/wlandebug (install) > --- realinstall_subdir_tests --- > --- _proginstall --- > install -s -o root -g wheel -m 555 subr_unit_test > /mnt/usr/tests/sys/kern/subr_unit_test > install -o root -g wheel -m 444 subr_unit_test.debug > /mnt/usr/lib/debug/usr/tests/sys/kern/subr_unit_test.debug > --- realinstall_subdir_usr.sbin --- > --- _proginstall --- > install -s -o root -g wheel -m 555 wlandebug /mnt/usr/sbin/wlandebug > --- realinstall_subdir_tests --- > --- Kyuafile --- > sh: cannot create Kyuafile.tmp: Read-only file system > sh: cannot create Kyuafile.tmp: Read-only file system > *** [Kyuafile] Error code 2 > > make[6]: stopped in /usr/src/tests/sys/kern > 1 error In case it helps, here's the result from a single-job run: ===> tests/sys/geom/class/uzip (install) install -o root -g wheel -m 555 1_test /mnt/usr/tests/sys/geom/class/uzip/1_test install -o root -g wheel -m 444 /usr/src/tests/sys/geom/class/uzip/etalon/etalon.txt /mnt/usr/tests/sys/geom/class/uzip/etalon/ install -o root -g wheel -m 444 Kyuafile /mnt/usr/tests/sys/geom/class/uzip/Kyuafile install -o root -g wheel -m 444 /usr/src/tests/sys/geom/class/uzip/conf.sh 1.img.uzip.uue /mnt/usr/tests/sys/geom/class/uzip/ ===> tests/sys/kern (install) /tmp/install.84PWkNVS/sh: cannot create Kyuafile.tmp: Read-only file system *** Error code 2 Stop. make[6]: stopped in /usr/src/tests/sys/kern -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: pdeathsig_helper and .debug/pdeathsig_helper.debug placed in /mnt when DESTDIR=/mnt
On Wed, 9 May 2018 20:39+0300, Konstantin Belousov wrote:
> There is a typo, it should be TESTSDIR.
>
> Index: tests/sys/kern/Makefile
> ===
> --- tests/sys/kern/Makefile (revision 333400)
> +++ tests/sys/kern/Makefile (working copy)
> @@ -4,6 +4,7 @@
> .PATH: ${SRCTOP}/sys/kern
>
> TESTSDIR=${TESTSBASE}/sys/kern
> +BINDIR= ${TESTSDIR}
>
> ATF_TESTS_C+=kern_copyin
> ATF_TESTS_C+=kern_descrip_test
This looks more promising:
--- realinstall_subdir_tests ---
--- pdeathsig_helper.install ---
(cd /usr/src/tests/sys/kern && DEPENDFILE=.depend.pdeathsig_helper
NO_SUBDIR=1 make -f /usr/src/tests/sys/kern/Makefile _RECURSING_PROGS=t
PROG=pdeathsig_helper install)
--- realinstall_subdir_usr.sbin ---
install -o root -g wheel -m 444 unbound.conf.5.gz /mnt/usr/share/man/man5/
--- realinstall_subdir_usr.sbin/unbound/anchor ---
===> usr.sbin/unbound/anchor (install)
--- realinstall_subdir_tests ---
--- _proginstall ---
install -s -o root -g wheel -m 555 pdeathsig_helper
/mnt/usr/tests/sys/kern/pdeathsig_helper
--- realinstall_subdir_usr.sbin ---
--- _proginstall ---
install -s -o root -g wheel -m 555 unbound-anchor
/mnt/usr/sbin/unbound-anchor
--- realinstall_subdir_tests ---
install -o root -g wheel -m 444 pdeathsig_helper.debug
/mnt/usr/lib/debug/usr/tests/sys/kern/pdeathsig_helper.debug
--- realinstall_subdir_usr.sbin ---
install -o root -g wheel -m 444 unbound-anchor.debug
/mnt/usr/lib/debug/usr/sbin/unbound-anchor.debug
But this one's persistent:
--- realinstall_subdir_tests ---
--- subr_unit_test.install ---
(cd /usr/src/tests/sys/kern && DEPENDFILE=.depend.subr_unit_test NO_SUBDIR=1
make -f /usr/src/tests/sys/kern/Makefile _RECURSING_PROGS=t
PROG=subr_unit_test install)
--- realinstall_subdir_usr.sbin ---
install -o root -g wheel -m 444 ancontrol.debug
/mnt/usr/lib/debug/usr/sbin/ancontrol.debug
--- maninstall ---
install -o root -g wheel -m 444 ancontrol.8.gz /mnt/usr/share/man/man8/
--- realinstall_subdir_usr.sbin/wlandebug ---
===> usr.sbin/wlandebug (install)
--- realinstall_subdir_tests ---
--- _proginstall ---
install -s -o root -g wheel -m 555 subr_unit_test
/mnt/usr/tests/sys/kern/subr_unit_test
install -o root -g wheel -m 444 subr_unit_test.debug
/mnt/usr/lib/debug/usr/tests/sys/kern/subr_unit_test.debug
--- realinstall_subdir_usr.sbin ---
--- _proginstall ---
install -s -o root -g wheel -m 555 wlandebug /mnt/usr/sbin/wlandebug
--- realinstall_subdir_tests ---
--- Kyuafile ---
sh: cannot create Kyuafile.tmp: Read-only file system
sh: cannot create Kyuafile.tmp: Read-only file system
*** [Kyuafile] Error code 2
make[6]: stopped in /usr/src/tests/sys/kern
1 error
--
Trond.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: pdeathsig_helper and .debug/pdeathsig_helper.debug placed in /mnt when DESTDIR=/mnt
On Wed, 9 May 2018 20:39+0300, Konstantin Belousov wrote:
> On Wed, May 09, 2018 at 06:44:09PM +0200, Trond Endrest?l wrote:
> > On Wed, 9 May 2018 16:50+0300, Konstantin Belousov wrote:
> >
> > > On Wed, May 09, 2018 at 02:49:34PM +0200, Trond Endrest?l wrote:
> > > > I noticed two new entries in / after running make installworld today
> > > > using amd64 stable/11 r90:
> > > >
> > > > # LANG=en_US.UTF-8 ls -lT /pdeathsig_helper
> > > > /.debug/pdeathsig_helper.debug
> > > > -r--r--r-- 1 root wheel 7528 May 9 12:06:58 2018
> > > > /.debug/pdeathsig_helper.debug
> > > > -r-xr-xr-x 1 root wheel 8576 May 9 12:06:58 2018 /pdeathsig_helper
> > > >
> > > > I'm sure these belong in /usr/tests/sys/kern. This must have happened
> > > > in r333162 or shortly after.
> > > >
> > > > See PR 228018, of which I hijacked.
> > >
> > > Can you try this ?
> > >
> > > Index: tests/sys/kern/Makefile
> > > ===
> > > --- tests/sys/kern/Makefile (revision 333400)
> > > +++ tests/sys/kern/Makefile (working copy)
> > > @@ -4,6 +4,7 @@
> > > .PATH: ${SRCTOP}/sys/kern
> > >
> > > TESTSDIR=${TESTSBASE}/sys/kern
> > > +BINDIR= ${TESTDIR}
> There is a type, it should be TESTSDIR.
>
> Index: tests/sys/kern/Makefile
> ===
> --- tests/sys/kern/Makefile (revision 333400)
> +++ tests/sys/kern/Makefile (working copy)
> @@ -4,6 +4,7 @@
> .PATH: ${SRCTOP}/sys/kern
>
> TESTSDIR=${TESTSBASE}/sys/kern
> +BINDIR= ${TESTSDIR}
>
> ATF_TESTS_C+=kern_copyin
> ATF_TESTS_C+=kern_descrip_test
I should've guessed that when I looked at the siblings.
Anyway, the builder is nearly finished and the patch is in place.
We'll soon find out.
--
Trond.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: pdeathsig_helper and .debug/pdeathsig_helper.debug placed in /mnt when DESTDIR=/mnt
On Wed, 9 May 2018 18:44+0200, Trond Endrestøl wrote:
> On Wed, 9 May 2018 16:50+0300, Konstantin Belousov wrote:
>
> > On Wed, May 09, 2018 at 02:49:34PM +0200, Trond Endrest?l wrote:
> > > I noticed two new entries in / after running make installworld today
> > > using amd64 stable/11 r90:
> > >
> > > # LANG=en_US.UTF-8 ls -lT /pdeathsig_helper /.debug/pdeathsig_helper.debug
> > > -r--r--r-- 1 root wheel 7528 May 9 12:06:58 2018
> > > /.debug/pdeathsig_helper.debug
> > > -r-xr-xr-x 1 root wheel 8576 May 9 12:06:58 2018 /pdeathsig_helper
> > >
> > > I'm sure these belong in /usr/tests/sys/kern. This must have happened
> > > in r333162 or shortly after.
> > >
> > > See PR 228018, of which I hijacked.
> >
> > Can you try this ?
> >
> > Index: tests/sys/kern/Makefile
> > ===
> > --- tests/sys/kern/Makefile (revision 333400)
> > +++ tests/sys/kern/Makefile (working copy)
> > @@ -4,6 +4,7 @@
> > .PATH: ${SRCTOP}/sys/kern
> >
> > TESTSDIR= ${TESTSBASE}/sys/kern
> > +BINDIR=${TESTDIR}
> >
> > ATF_TESTS_C+= kern_copyin
> > ATF_TESTS_C+= kern_descrip_test
>
> I was not so lucky:
>
> ===> tests/sys/geom/class/uzip (install)
> --- realinstall_subdir_tests/sys/kern ---
> --- _proginstall ---
> install -s -o root -g wheel -m 555 pdeathsig_helper /mnt/pdeathsig_helper
> install -d /mnt/.debug/
> install -o root -g wheel -m 444 pdeathsig_helper.debug
> /mnt/.debug/pdeathsig_helper.debug
> --- kern_copyin.install ---
> (cd /usr/src/tests/sys/kern && DEPENDFILE=.depend.kern_copyin NO_SUBDIR=1
> make -f /usr/src/tests/sys/kern/Makefile _RECURSING_PROGS=t PROG=kern_copyin
> install)
> --- realinstall_subdir_tests/sys/geom ---
> --- _etalonINS ---
> install -o root -g wheel -m 444
> /usr/src/tests/sys/geom/class/uzip/etalon/etalon.txt
> /mnt/usr/tests/sys/geom/class/uzip/etalon/
> --- _SCRIPTSINS_1_test ---
> install -o root -g wheel -m 555 1_test
> /mnt/usr/tests/sys/geom/class/uzip/1_test
> --- _testsFILESINS_Kyuafile ---
> install -o root -g wheel -m 444 Kyuafile
> /mnt/usr/tests/sys/geom/class/uzip/Kyuafile
> --- _testsFILESINS ---
> install -o root -g wheel -m 444 /usr/src/tests/sys/geom/class/uzip/conf.sh
> 1.img.uzip.uue /mnt/usr/tests/sys/geom/class/uzip/
> --- _testsFILESINS ---
> install -o root -g wheel -m 444 /usr/src/tests/sys/geom/class/geom_subr.sh
> /mnt/usr/tests/sys/geom/class/
> --- realinstall_subdir_tests/sys/kern ---
> --- _proginstall ---
> --- realinstall_subdir_tests/sys/geom ---
> --- _testsFILESINS_Kyuafile ---
> --- realinstall_subdir_tests/sys/kern ---
> install -s -o root -g wheel -m 555 kern_copyin /mnt
> /usr/tests/sys/kern/kern_copyin
> --- realinstall_subdir_tests/sys/geom ---
> install -o root -g wheel -m 444 Kyuafile
> /mnt/usr/tests/sys/geom/class/Kyuafile
> --- realinstall_subdir_tests/sys/kern ---
> install: target `/usr/tests/sys/kern/kern_copyin' is not a directory
> usage: install [-bCcpSsUv] [-f flags] [-g group] [-m mode] [-o owner]
>[-M log] [-D dest] [-h hash] [-T tags]
>[-B suffix] [-l linkflags] [-N dbdir]
>file1 file2
>install [-bCcpSsUv] [-f flags] [-g group] [-m mode] [-o owner]
>[-M log] [-D dest] [-h hash] [-T tags]
>[-B suffix] [-l linkflags] [-N dbdir]
>file1 ... fileN directory
>install -dU [-vU] [-g group] [-m mode] [-N dbdir] [-o owner]
>[-M log] [-D dest] [-h hash] [-T tags]
>directory ...
> *** [_proginstall] Error code 64
>
> make[7]: stopped in /usr/src/tests/sys/kern
> 1 error
If I revert the changes to tests/sys/kern/Makefile, and try
installworld installkernel again, I get:
--- maninstall ---
install -o root -g wheel -m 444 mailstats.8.gz
/mnt/usr/share/man/man8/
--- realinstall_subdir_tests ---
sh: cannot create Kyuafile.tmp: Read-only file system
sh: cannot create Kyuafile.tmp: Read-only file system
*** [Kyuafile] Error code 2
make[6]: stopped in /usr/src/tests/sys/kern
1 error
Both /usr/src and /usr/obj are read-only NFSv3 exports.
I should probably wipe the object tree before proceeding.
--
Trond.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: pdeathsig_helper and .debug/pdeathsig_helper.debug placed in /mnt when DESTDIR=/mnt
On Wed, 9 May 2018 16:50+0300, Konstantin Belousov wrote:
> On Wed, May 09, 2018 at 02:49:34PM +0200, Trond Endrest?l wrote:
> > I noticed two new entries in / after running make installworld today
> > using amd64 stable/11 r90:
> >
> > # LANG=en_US.UTF-8 ls -lT /pdeathsig_helper /.debug/pdeathsig_helper.debug
> > -r--r--r-- 1 root wheel 7528 May 9 12:06:58 2018
> > /.debug/pdeathsig_helper.debug
> > -r-xr-xr-x 1 root wheel 8576 May 9 12:06:58 2018 /pdeathsig_helper
> >
> > I'm sure these belong in /usr/tests/sys/kern. This must have happened
> > in r333162 or shortly after.
> >
> > See PR 228018, of which I hijacked.
>
> Can you try this ?
>
> Index: tests/sys/kern/Makefile
> ===
> --- tests/sys/kern/Makefile (revision 333400)
> +++ tests/sys/kern/Makefile (working copy)
> @@ -4,6 +4,7 @@
> .PATH: ${SRCTOP}/sys/kern
>
> TESTSDIR=${TESTSBASE}/sys/kern
> +BINDIR= ${TESTDIR}
>
> ATF_TESTS_C+=kern_copyin
> ATF_TESTS_C+=kern_descrip_test
I was not so lucky:
===> tests/sys/geom/class/uzip (install)
--- realinstall_subdir_tests/sys/kern ---
--- _proginstall ---
install -s -o root -g wheel -m 555 pdeathsig_helper /mnt/pdeathsig_helper
install -d /mnt/.debug/
install -o root -g wheel -m 444 pdeathsig_helper.debug
/mnt/.debug/pdeathsig_helper.debug
--- kern_copyin.install ---
(cd /usr/src/tests/sys/kern && DEPENDFILE=.depend.kern_copyin NO_SUBDIR=1
make -f /usr/src/tests/sys/kern/Makefile _RECURSING_PROGS=t PROG=kern_copyin
install)
--- realinstall_subdir_tests/sys/geom ---
--- _etalonINS ---
install -o root -g wheel -m 444
/usr/src/tests/sys/geom/class/uzip/etalon/etalon.txt
/mnt/usr/tests/sys/geom/class/uzip/etalon/
--- _SCRIPTSINS_1_test ---
install -o root -g wheel -m 555 1_test
/mnt/usr/tests/sys/geom/class/uzip/1_test
--- _testsFILESINS_Kyuafile ---
install -o root -g wheel -m 444 Kyuafile
/mnt/usr/tests/sys/geom/class/uzip/Kyuafile
--- _testsFILESINS ---
install -o root -g wheel -m 444 /usr/src/tests/sys/geom/class/uzip/conf.sh
1.img.uzip.uue /mnt/usr/tests/sys/geom/class/uzip/
--- _testsFILESINS ---
install -o root -g wheel -m 444 /usr/src/tests/sys/geom/class/geom_subr.sh
/mnt/usr/tests/sys/geom/class/
--- realinstall_subdir_tests/sys/kern ---
--- _proginstall ---
--- realinstall_subdir_tests/sys/geom ---
--- _testsFILESINS_Kyuafile ---
--- realinstall_subdir_tests/sys/kern ---
install -s -o root -g wheel -m 555 kern_copyin /mnt
/usr/tests/sys/kern/kern_copyin
--- realinstall_subdir_tests/sys/geom ---
install -o root -g wheel -m 444 Kyuafile
/mnt/usr/tests/sys/geom/class/Kyuafile
--- realinstall_subdir_tests/sys/kern ---
install: target `/usr/tests/sys/kern/kern_copyin' is not a directory
usage: install [-bCcpSsUv] [-f flags] [-g group] [-m mode] [-o owner]
[-M log] [-D dest] [-h hash] [-T tags]
[-B suffix] [-l linkflags] [-N dbdir]
file1 file2
install [-bCcpSsUv] [-f flags] [-g group] [-m mode] [-o owner]
[-M log] [-D dest] [-h hash] [-T tags]
[-B suffix] [-l linkflags] [-N dbdir]
file1 ... fileN directory
install -dU [-vU] [-g group] [-m mode] [-N dbdir] [-o owner]
[-M log] [-D dest] [-h hash] [-T tags]
directory ...
*** [_proginstall] Error code 64
make[7]: stopped in /usr/src/tests/sys/kern
1 error
To be transparent, my builder has these lines in make.conf and
src.conf.
make.conf:
KERNCONF=PE1950 DL360G5 GENERIC PER200 PER320 XENGUEST ZFS
.if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*))
.if !defined(NOCCACHE) && exists(/usr/local/libexec/ccache/world/cc)
CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1}
CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1}
.endif
.endif
WITH_CCACHE_BUILD=yes
## DTrace for both base and ports. See
https://wiki.freebsd.org/DTrace/KernelSupport.
STRIP=
CFLAGS+=-fno-omit-frame-pointer
WITH_CTF=1
WITH_BDB6_PERMITTED=yes
WITH_SSP_PORTS=yes
WRKDIRPREFIX=/usr/ports/workdirs
TEX_DEFAULT=texlive
DEFAULT_VERSIONS+=apache=2.4
DEFAULT_VERSIONS+=bdb=6
DEFAULT_VERSIONS+=emacs=nox
DEFAULT_VERSIONS+=firebird=2.5
DEFAULT_VERSIONS+=fpc=3.0.4
DEFAULT_VERSIONS+=gcc=6
DEFAULT_VERSIONS+=ghostscript=agpl
DEFAULT_VERSIONS+=linux=c6_64
DEFAULT_VERSIONS+=lua=5.2
DEFAULT_VERSIONS+=mysql=5.7
DEFAULT_VERSIONS+=perl5=5.26
DEFAULT_VERSIONS+=pgsql=9.6
DEFAULT_VERSIONS+=php=7.1
DEFAULT_VERSIONS+=python=2.7
DEFAULT_VERSIONS+=python2=2.7
DEFAULT_VERSIONS+=python3=3.6
DEFAULT_VERSIONS+=ruby=2.3
DEFAULT_VERSIONS+=samba=4.6
DEFAULT_VERSIONS+=ssl=base
DEFAULT_VERSIONS+=tcltk=8.6
DEFAULT_VERSIONS+=varnish=5
# EOF
src.conf:
WITH_CLANG_EXTRAS=yes
WITH_CLANG_FULL=yes
WITH_CTF=yes
WITH_DEBUG_FILES=yes
WITH_LIBCPLUSPLUS=yes
WITH_LLDB=yes
# EOF
On the "victim", the same files look like:
make.conf:
KERNCONF=PER200
WRKDIRPREFIX=/usr/ports/workdirs
pdeathsig_helper and .debug/pdeathsig_helper.debug placed in /mnt when DESTDIR=/mnt
I noticed two new entries in / after running make installworld today using amd64 stable/11 r90: # LANG=en_US.UTF-8 ls -lT /pdeathsig_helper /.debug/pdeathsig_helper.debug -r--r--r-- 1 root wheel 7528 May 9 12:06:58 2018 /.debug/pdeathsig_helper.debug -r-xr-xr-x 1 root wheel 8576 May 9 12:06:58 2018 /pdeathsig_helper I'm sure these belong in /usr/tests/sys/kern. This must have happened in r333162 or shortly after. See PR 228018, of which I hijacked. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: DDD hangs on start on 11.1-R
On Sat, 3 Mar 2018 18:09+0100, Holm Tiffe wrote: > can anyone get ddd get to work in 11.1-R or stable? I've more or less given up on devel/ddd, since it relies on the old pty subsystem, now replaced by the new pts subsystem, to communicate with gdb. I build custom kernels containing "device pty", but I'm not sure if that directive is being honoured these days. It's a shame, 'cos ddd is very good at visualizing data structures. Maybe it's possible to patch ddd to use pts instead of pty. Going back to 10.x could be a workaround. > It seems that ddd from the ports is hanging while trying to get a > connection to gdb, tried the system gdb and the gdb-8.0.1 from the > ports. > What's happening here? -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: build kernel failure stable11 iwi related
On Thu, 1 Mar 2018 08:03-0800, Eitan Adler wrote: > >> I hope these errors will be corrected shortly. > > Build error is fixed. Sorry for the breakage > > > r330229 is also broken. I had to revert to r330113 to avoid any of the > > recent iwm commits. > > Did r330242 fix the issue for you? Yes, it did. Thank you. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: build kernel failure stable11 iwi related
On Thu, 1 Mar 2018 14:09+0100, Trond Endrestøl wrote: > If you revert to r330229, i.e. svn up -r330229 /usr/src, you should be > able to build a working kernel. > > r330230 added "17" to line 1939 of sys/conf/files breaking iwm(fw), > and I suspect "17" should be "22", or maybe the "D" should be removed. > > r330233 caused the errors you reported. > > I hope these errors will be corrected shortly. r330229 is also broken. I had to revert to r330113 to avoid any of the recent iwm commits. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: build kernel failure stable11 iwi related
On Thu, 1 Mar 2018 10:48+0100, Johan Hendriks wrote:
> I get an builderror on my 11.1 stable machine after the latest svn
> update Revision: 330235
>
>
> --
> >>> stage 3.1: building everything
> --
> cd /usr/obj/usr/src/sys/KRNL; MAKEOBJDIRPREFIX=/usr/obj?
> MACHINE_ARCH=amd64? MACHINE=amd64? CPUTYPE= BUILD_TOOLS_META=.NOMETA
> GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin?
> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font?
> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac CC="cc "
> CXX="c++? "? CPP="cpp "? AS="as" AR="ar" LD="ld" NM=nm? OBJDUMP=objdump
> OBJCOPY="objcopy"? RANLIB=ranlib STRINGS=? SIZE="size"? INSTALL="sh
> /usr/src/tools/install.sh"?
> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin
> make? -m /usr/src/share/mk? KERNEL=kernel all -DNO_MODULES_OBJ
> Building /usr/obj/usr/src/sys/KRNL/if_iwi.o
> In file included from /usr/src/sys/dev/iwi/if_iwi.c:76:
> /usr/src/sys/net80211/ieee80211_input.h:138:19: error: no member named
> 'c_pktflags' in 'struct ieee80211_rx_stats'
> ??? return (!! (rxs->c_pktflags & IEEE80211_RX_F_AMSDU));
> ??? ~~~? ^
> /usr/src/sys/net80211/ieee80211_input.h:138:32: error: use of undeclared
> identifier 'IEEE80211_RX_F_AMSDU'; did you mean 'IEEE80211_S_ASSOC'?
> ??? return (!! (rxs->c_pktflags & IEEE80211_RX_F_AMSDU));
> ? ^~~~
> ? IEEE80211_S_ASSOC
> /usr/src/sys/net80211/ieee80211_proto.h:39:2: note: 'IEEE80211_S_ASSOC'
> declared here
> ??? IEEE80211_S_ASSOC?? = 3,??? /* try to assoc */
> ??? ^
> In file included from /usr/src/sys/dev/iwi/if_iwi.c:76:
> /usr/src/sys/net80211/ieee80211_input.h:154:12: error: no member named
> 'c_pktflags' in 'struct ieee80211_rx_stats'
> ??? if ((rxs->c_pktflags & IEEE80211_RX_F_AMSDU) == 0)
> ~~~? ^
> /usr/src/sys/net80211/ieee80211_input.h:154:25: error: use of undeclared
> identifier 'IEEE80211_RX_F_AMSDU'; did you mean 'IEEE80211_S_ASSOC'?
> ??? if ((rxs->c_pktflags & IEEE80211_RX_F_AMSDU) == 0)
> ?? ^~~~
> ?? IEEE80211_S_ASSOC
> /usr/src/sys/net80211/ieee80211_proto.h:39:2: note: 'IEEE80211_S_ASSOC'
> declared here
> ??? IEEE80211_S_ASSOC?? = 3,??? /* try to assoc */
> ??? ^
> In file included from /usr/src/sys/dev/iwi/if_iwi.c:76:
> /usr/src/sys/net80211/ieee80211_input.h:158:11: error: no member named
> 'c_pktflags' in 'struct ieee80211_rx_stats'
> ??? if (rxs->c_pktflags & IEEE80211_RX_F_AMSDU_MORE) {
> ??? ~~~? ^
> /usr/src/sys/net80211/ieee80211_input.h:158:24: error: use of undeclared
> identifier 'IEEE80211_RX_F_AMSDU_MORE'
> ??? if (rxs->c_pktflags & IEEE80211_RX_F_AMSDU_MORE) {
> ? ^
> /usr/src/sys/net80211/ieee80211_input.h:266:39: error: use of undeclared
> identifier 'rxs'
> ??? if (ieee80211_check_rxseq_amsdu_more(rxs)) {
> ^
> /usr/src/sys/net80211/ieee80211_input.h:268:8: error: use of undeclared
> identifier 'rxs'
> ??? if ((rxs != NULL) && ieee80211_check_rxseq_amsdu(rxs))
> ^
> /usr/src/sys/net80211/ieee80211_input.h:268:52: error: use of undeclared
> identifier 'rxs'
> ??? if ((rxs != NULL) && ieee80211_check_rxseq_amsdu(rxs))
> ^
> 9 errors generated.
> *** Error code 1
>
> Stop.
> make[2]: stopped in /usr/obj/usr/src/sys/KRNL
> .ERROR_TARGET='if_iwi.o'
> .ERROR_META_FILE='/usr/obj/usr/src/sys/KRNL/if_iwi.o.meta'
> .MAKE.LEVEL='2'
> MAKEFILE=''
> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose
> curdirOk=yes'
> _ERROR_CMD='cc? -c -O2 -pipe -fno-strict-aliasing? -g -nostdinc? -I.
> -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL
> -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h?
> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel
> -mno-red-zone -mno-mmx -mno-sse -msoft-float?
> -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector
> -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef
> -Wno-pointer-sign -D__printf__=__freebsd_kprintf__
> -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas
> -Wno-error-tautological-compare -Wno-error-empty-body
> -Wno-error-parentheses-equality -Wno-error-unused-function
> -Wno-error-pointer-sign -Wno-error-shift-negative-value
> -Wno-error-address-of-packed-member? -mno-aes -mno-avx?
> -std=iso9899:1999 -Werror? /usr/src/sys/dev/iwi/if_iwi.c; ctfconvert -L
> VERSION -g
Re: Locale problem updating 10.3 to 11.1
On Mon, 19 Feb 2018 00:02+0100, Eivind Nicolay Evensen wrote: > Hello. > > After upgrading from 10.3 to 11.1 by building source (as of r329364), > I experienced some problems that seems to be related to locale. > > Using > > echo $LANG -- $LC_CTYPE > no_NO.ISO8859-1 -- no_NO.ISO8859-1 That's nb_NO.ISO8859-1. nb for norsk bokmål. > ls emitted question mark for Norwegian characters (æøå), the menu > and title fonts in fvwm2 displayed unknown to me symbols except for > certain capital letters and yet other programs like the worker filemanager > truncated filenames at the first Norwegian letter. > > I had to revert to 10.3 because of this but if anybody has some clues > what may be the reason for this, I'd appreciate it. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: r321601 causes make buildworld to fail on stable/11
On Thu, 27 Jul 2017 13:03+0200, Trond Endrestøl wrote: > On Thu, 27 Jul 2017 11:57+0100, tech-lists wrote: > > > On 27/07/2017 10:33, Trond Endrestøl wrote: > > > r321601 gives me these error messages on stable/11: > > > > > > /usr/src/usr.sbin/acpi/acpidump/acpi.c:1089:6: error: use of undeclared > > > identifier 'ACPI_SRAT_TYPE_GIC_ITS_AFFINITY'; did you mean > > > 'ACPI_SRAT_TYPE_GICC_AFFINITY'? > > > [ACPI_SRAT_TYPE_GIC_ITS_AFFINITY] = "GIC ITS", > > > ^~~ > > > ACPI_SRAT_TYPE_GICC_AFFINITY > > > /usr/src/sys/contrib/dev/acpica/include/actbl1.h:1504:5: note: > > > 'ACPI_SRAT_TYPE_GICC_AFFINITY' declared here > > > ACPI_SRAT_TYPE_GICC_AFFINITY= 3, > > > ^ > > > /usr/src/usr.sbin/acpi/acpidump/acpi.c:1089:41: error: initializer > > > overrides prior initialization of this subobject > > > [-Werror,-Winitializer-overrides] > > > [ACPI_SRAT_TYPE_GIC_ITS_AFFINITY] = "GIC ITS", > > > ^ > > > /usr/src/usr.sbin/acpi/acpidump/acpi.c:1088:38: note: previous > > > initialization is here > > > [ACPI_SRAT_TYPE_GICC_AFFINITY] = "GICC", > > > ^~ > > > > > > Am I missing something? Am acpi.c missing something? > > > > > > > I see this as well on r321611 > > r321600 builds fine. > r321601 does not, and must be amended or reverted. r321619 builds fine. Thank you, Ed M. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: r321601 causes make buildworld to fail on stable/11
On Thu, 27 Jul 2017 11:57+0100, tech-lists wrote: > On 27/07/2017 10:33, Trond Endrestøl wrote: > > r321601 gives me these error messages on stable/11: > > > > /usr/src/usr.sbin/acpi/acpidump/acpi.c:1089:6: error: use of undeclared > > identifier 'ACPI_SRAT_TYPE_GIC_ITS_AFFINITY'; did you mean > > 'ACPI_SRAT_TYPE_GICC_AFFINITY'? > > [ACPI_SRAT_TYPE_GIC_ITS_AFFINITY] = "GIC ITS", > > ^~~ > > ACPI_SRAT_TYPE_GICC_AFFINITY > > /usr/src/sys/contrib/dev/acpica/include/actbl1.h:1504:5: note: > > 'ACPI_SRAT_TYPE_GICC_AFFINITY' declared here > > ACPI_SRAT_TYPE_GICC_AFFINITY= 3, > > ^ > > /usr/src/usr.sbin/acpi/acpidump/acpi.c:1089:41: error: initializer > > overrides prior initialization of this subobject > > [-Werror,-Winitializer-overrides] > > [ACPI_SRAT_TYPE_GIC_ITS_AFFINITY] = "GIC ITS", > > ^ > > /usr/src/usr.sbin/acpi/acpidump/acpi.c:1088:38: note: previous > > initialization is here > > [ACPI_SRAT_TYPE_GICC_AFFINITY] = "GICC", > > ^~ > > > > Am I missing something? Am acpi.c missing something? > > > > I see this as well on r321611 r321600 builds fine. r321601 does not, and must be amended or reverted. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
r321601 causes make buildworld to fail on stable/11
r321601 gives me these error messages on stable/11: /usr/src/usr.sbin/acpi/acpidump/acpi.c:1089:6: error: use of undeclared identifier 'ACPI_SRAT_TYPE_GIC_ITS_AFFINITY'; did you mean 'ACPI_SRAT_TYPE_GICC_AFFINITY'? [ACPI_SRAT_TYPE_GIC_ITS_AFFINITY] = "GIC ITS", ^~~ ACPI_SRAT_TYPE_GICC_AFFINITY /usr/src/sys/contrib/dev/acpica/include/actbl1.h:1504:5: note: 'ACPI_SRAT_TYPE_GICC_AFFINITY' declared here ACPI_SRAT_TYPE_GICC_AFFINITY= 3, ^ /usr/src/usr.sbin/acpi/acpidump/acpi.c:1089:41: error: initializer overrides prior initialization of this subobject [-Werror,-Winitializer-overrides] [ACPI_SRAT_TYPE_GIC_ITS_AFFINITY] = "GIC ITS", ^ /usr/src/usr.sbin/acpi/acpidump/acpi.c:1088:38: note: previous initialization is here [ACPI_SRAT_TYPE_GICC_AFFINITY] = "GICC", ^~ Am I missing something? Am acpi.c missing something? -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: zpool imported twice with different names (was Re: Fwd: ZFS)
On Mon, 15 May 2017 20:11+0200, Nikos Vassiliadis wrote: > Fix the e-mail subject > > On 05/15/2017 08:09 PM, Nikos Vassiliadis wrote: > > Hi everybody, > > > > While trying to rename a zpool from zroot to vega, > > I ended up in this strange situation: > > nik@vega:~ % zfs list -t all > > NAME USED AVAIL REFER MOUNTPOINT > > vega1.83G 34.7G96K /zroot > > vega/ROOT 1.24G 34.7G96K none > > vega/ROOT/default 1.24G 34.7G 1.24G / > > vega/tmp 120K 34.7G 120K /tmp > > vega/usr 608M 34.7G96K /usr > > vega/usr/home136K 34.7G 136K /usr/home > > vega/usr/ports96K 34.7G96K /usr/ports > > vega/usr/src 607M 34.7G 607M /usr/src > > vega/var 720K 34.7G96K /var > > vega/var/audit96K 34.7G96K /var/audit > > vega/var/crash96K 34.7G96K /var/crash > > vega/var/log 236K 34.7G 236K /var/log > > vega/var/mail100K 34.7G 100K /var/mail > > vega/var/tmp 96K 34.7G96K /var/tmp > > zroot 1.83G 34.7G96K /zroot > > zroot/ROOT 1.24G 34.7G96K none > > zroot/ROOT/default 1.24G 34.7G 1.24G / > > zroot/tmp120K 34.7G 120K /tmp > > zroot/usr608M 34.7G96K /usr > > zroot/usr/home 136K 34.7G 136K /usr/home > > zroot/usr/ports 96K 34.7G96K /usr/ports > > zroot/usr/src607M 34.7G 607M /usr/src > > zroot/var724K 34.7G96K /var > > zroot/var/audit 96K 34.7G96K /var/audit > > zroot/var/crash 96K 34.7G96K /var/crash > > zroot/var/log240K 34.7G 240K /var/log > > zroot/var/mail 100K 34.7G 100K /var/mail > > zroot/var/tmp 96K 34.7G96K /var/tmp > > nik@vega:~ % zpool status > >pool: vega > > state: ONLINE > >scan: scrub repaired 0 in 0h0m with 0 errors on Mon May 15 01:28:48 2017 > > config: > > > > NAMESTATE READ WRITE CKSUM > > vegaONLINE 0 0 0 > >vtbd0p3 ONLINE 0 0 0 > > > > errors: No known data errors > > > >pool: zroot > > state: ONLINE > >scan: scrub repaired 0 in 0h0m with 0 errors on Mon May 15 01:28:48 2017 > > config: > > > > NAMESTATE READ WRITE CKSUM > > zroot ONLINE 0 0 0 > >vtbd0p3 ONLINE 0 0 0 > > > > errors: No known data errors > > nik@vega:~ % > > --- > > > > It seems like there are two pools, sharing the same vdev... > > > > After running a few commands in this state, like doing a scrub, > > the pool was (most probably) destroyed. It couldn't boot anymore > > and I didn't research further. Is this a known bug? > > I guess you had a /boot/zfs/zpool.cache file referring to the original zroot pool. Next, the kernel found the vega pool and didn't realise these two pools are the very same. > > Steps to reproduce: > >install FreeBSD-11.0 in a pool named zroot > >reboot into a live-CD Redo the above steps. > >zpool import -f zroot vega Do these four commands instead of a regular import: mkdir /tmp/vega zpool import -N -f -o cachefile=/tmp/zpool.cache vega mount -t zfs vega/ROOT/default /tmp/vega cp -p /tmp/zpool.cache /tmp/vega/boot/zfs/zpool.cache > >reboot again Reboot again. > > > > Thanks, > > Nikos > > > > PS: > > Sorry for the cross-posting, I am doing this to share to more people > > because it is a rather easy way to destroy a ZFS pool. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: VirtualBox-ose kernel module crashes 10-stable
ing symbols from /boot/kernel/nullfs.ko.symbols...done. > Loaded symbols for /boot/kernel/nullfs.ko.symbols > #0 doadump (textdump=) at pcpu.h:219 > 219 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump (textdump=) at pcpu.h:219 > #1 0x8097be03 in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:486 > #2 0x8097c225 in vpanic (fmt=, > ap=) at /usr/src/sys/kern/kern_shutdown.c:889 > #3 0x8097c0b3 in panic (fmt=0x0) > at /usr/src/sys/kern/kern_shutdown.c:818 > #4 0x80d9ce2d in trap_fatal (frame=, > eva=) at /usr/src/sys/amd64/amd64/trap.c:858 > #5 0x80d9caaf in trap (frame=) > at /usr/src/sys/amd64/amd64/trap.c:203 > #6 0x80d81d4c in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:238 > #7 0x81dbb3de in RTSpinlockCreate (pSpinlock=0xf80233354860, > fFlags=4, pszName=0xfe0464bfd310 "") > at > /wrkdirs/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5.1.18/out/freebsd.amd64/debug/bin/src/vboxdrv/r0drv/freebsd/spinlock-r0drv-freebsd.c:78 > #8 0x81d7d591 in supdrvCreateSession (pDevExt=0x81ddc510, > fUser=true, fUnrestricted=false, ppSession=0xfe0464bfd518) > at SUPDrv.c:772 > #9 0x81d9355b in vboxdrvFreeBSDOpenCommon () > at > /wrkdirs/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5.1.18/out/freebsd.amd64/debug/bin/src/vboxdrv/freebsd/SUPDrv-freebsd.c:250 > #10 0x80855a32 in devfs_open (ap=) > at /usr/src/sys/fs/devfs/devfs_vnops.c:1116 > #11 0x80ed8671 in VOP_OPEN_APV (vop=, > a=) at vnode_if.c:469 > ---Type to continue, or q to quit--- > #12 0x80a3bc34 in vn_open_vnode (vp=0xf802d807b3b0, fmode=3, > cred=0xf8031f06f100, td=0xf802aad3b4c0, fp=0xf80020b39320) > at vnode_if.h:196 > #13 0x80a3b803 in vn_open_cred (ndp=0xfe0464bfd870, > flagp=0xfe0464bfd94c, cmode=, > vn_open_flags=, cred=0xfe0464bfd310, > fp=0xf80020b39320) at /usr/src/sys/kern/vfs_vnops.c:268 > #14 0x80a348cf in kern_openat (td=0xf802aad3b4c0, fd=-100, > path=0x80182c1ec , > pathseg=UIO_USERSPACE, flags=3, mode=) > at /usr/src/sys/kern/vfs_syscalls.c:1067 > #15 0x80d9d862 in amd64_syscall (td=0xf802aad3b4c0, traced=0) > at subr_syscall.c:141 > #16 0x80d8203b in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:398 > #17 0x000802cdf8fa in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > > -- end here (output by kgdb) > > As shown in the above, kernel panic was caused by > assertion RTThreadPreemptIsEnabled(NIL_RTTHREAD) > which tests the following expressions: > > 1. curthread->td_critnest is equal to 0, and > 2. IF (interrupt flag) on eflag (or rflag ?) is equal to 1. > > This assertion will be successful only if both of above are true. > > As I read the source of VirtualBox, RTThreadPreemptIsEnabled is > a part of test for preemtiveness which is used to create a spinlock. > However, I'm not sure why assertion RTThreadPreemptIsEnabled is required, > and this was failed on 10.3-STABLE r316132. > > I would appreciate any information. Thanks. emulators/virtualbox-ose needs access to the kernel sources during build. Maybe you should rebuild emulators/virtualbox-ose to match your current source tree. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 11.0, bxe and lagg
On Tue, 21 Feb 2017 10:39+0100, Ingeborg Hellemo wrote: > > I'm in the process of upgrading my 10.3 servers to 11.0. I have stumbled upon > problems with lagg on two boxes. > > They both have QLogic NetXtreme II BCM57800 10GbE network card using the bxe > driver. > > My lagg configuration is unchanged in the process but after upgradring to > 11.0 > lagg is no longer working. > > /etc/rc.conf: > ifconfig_bxe2="up" > ifconfig_bxe3="up" > cloned_interfaces="lagg0" > ifconfig_lagg0="laggproto lacp laggport bxe2 laggport bxe3 129.242.3.9 > netmask > 255.255.255.192" > > > ifconfig lagg0 > lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 > ether . > inet 129.242.3.9 netmask 0xffc0 broadcast 129.242.3.63 > nd options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> > media: Ethernet autoselect > status: active > groups: lagg > laggproto lacp lagghash l2,l3,l4 > laggport: bge2 flags=0<> > laggport: bge3 flags=0<> > > > As you can see the laggport flags are empty where I would expect > flags=1c<ACTIVE,COLLECTING,DISTRIBUTING> > No error messages. The interfaces work ok if I drop using lagg. > > The same configuration has survived the upgrade on boxes using bge > > > Any ideas? Why does lagg0 refer to bge2 and bge3 in the ifconfig output, and not to bxe2 and bxe3? -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kernel installation problem on STABLE-11
On Fri, 3 Feb 2017 07:26+1300, Jonathan Chen wrote: > On 3 February 2017 at 06:21, Sergey Matveychuk <se...@yandex-team.ru> wrote: > > And it looks like it works without COMPILER_TYPE=clang if you buildworld > > before. But I'm not sure. > > /usr/src/UPDATING recommends that buildworld should always be done > before buildkernel. In fact, the top Makefile will enforce that order when both targets are given: .ORDER: buildworld installworld .ORDER: buildworld distributeworld .ORDER: buildworld buildkernel .ORDER: installworld distribution .ORDER: installworld installkernel .ORDER: buildkernel installkernel .ORDER: buildkernel installkernel.debug .ORDER: buildkernel reinstallkernel .ORDER: buildkernel reinstallkernel.debug -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 11 Stable on a Xen :: bridge0 crashing server
On Fri, 20 Jan 2017 14:26-, SK wrote: > Dear List members > > Apologies for cross posting to two other lists -- was not sure which one is > more appropriate for this, as it may be related to stable, xen or > virtualization. > > Here is the situation: > I have a VPS server from a well reputed provider (and they deserve the > reputation), running FreeBSD 11 stable x64 under Xen Full Virtualization > (HVM). I have the xn0 interface which is working fine. I intend to use VIMAGE, > so I compiled the kernel, added cloned_interface="bridge0" and restarted the > server. But as soon as I am attaching the xn0 to bridge0, the kernel is > panicking and the server restarting. > > The provider confirmed that they found similar behaviour on a freshly > installed/provisioned FreeBSD 11 x64 system. > > Further to that, the provider ran some tests, and what they are telling me is > if they install/provision FreeBSD 10 x64, there is no problem with attaching > bridge0 to xn0. Then they updated/upgraded that box to FreeBSD 11 x64, and > that too worked when they attached bridge0 to xn0. However, they are yet to > come back with my request to build a custom kernel with options VIMAGE and try > it out. > > In the meanwhile, I took a crash dump and followed the FreeBSD handbook (not > that it gave me much idea, I'm not a programmer nor am at that level of > skillsets). The dump/debug is available at http://pastebin.com/XuWvJHUZ for > anyone who is interested. > > Just wondering how to go about it. I do need to have bridge0 with xn0 and all > the epairs I'm going to use for my jails. > > Any suggestion/pointer/test-instruction is highly appreciated. The code crashes at line 427 of sys/netinet/if_ether.c: ARPSTAT_INC(txrequests); See https://svnweb.freebsd.org/base/stable/11/sys/netinet/if_ether.c?view=annotate#l427 stable/11 has problems accounting the outgoing octets of any xn interface, although this isn't connected to your case. Just to rule out any uncertainty, try this patch: https://svnweb.freebsd.org/base?view=revision=308126 See PR 213439, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213439 Note, I'm not a developer nor a committer, just a humble sysadmin. -- +---+--------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Strange dtrace warning on running svn, perl and other programs on stable/10 r310494
On Thu, 29 Dec 2016 12:04+0100, Trond Endrestøl wrote: > I keep getting these warnings whenever I run svn, perl, and other > programs. > > WARNING: number of probes fixed does not match the number of defined probes > (16 != 18, respectively) > WARNING: some probes might not fire or your program might crash Upgrading to stable/11 and recompiling all installed ports made the warnings go away. Happy New Year! -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Strange dtrace warning on running svn, perl and other programs on stable/10 r310494
I keep getting these warnings whenever I run svn, perl, and other programs. WARNING: number of probes fixed does not match the number of defined probes (16 != 18, respectively) WARNING: some probes might not fire or your program might crash They also clobber the building of security/vpnc. Some "clever" Perl script is being used to produce a .c file on stdout and a .h file on stderr while building vpnc. Any chance of getting rid of the messages, or at least disabling them? This is on stable/10, r310494. /etc/make.conf contains: STRIP= CFLAGS+=-fno-omit-frame-pointer WITH_CTF=1 WITH_SSP_PORTS=yes This particular system will soon be upgraded to stable/11, r310770. Maybe my troubles will disappear once the transition is complete. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: PKG bootstrap FreeBSD 11.0 / VBox NAT problem
On Fri, 28 Oct 2016 14:15+0200, Tomasz CEDRO wrote:
> Just for the curious. I am testing on VirtualBox (Version 5.1.8
> r111374 (Qt5.5.1), macOS 10.12.1 host). Cannot bootstrap PKG on a host
> with NAT enabled.I have noticed this problem occurs only when NAT is
> enabled in VBox. When I use Bridged interface there is no problem. I
> have noticed that outgoing packet following RST response has invalid
> checksum. That may be VBox NAT problem..? Maybe someone noticed
> similar behavior..
>
> https://www.virtualbox.org/ticket/16126
Upgrading VBox (the hypervisor software) to 5.1.8 last week made
"make -C /usr/ports fetchindex" next to impossible on my FreeBSD
guests.
I was running 5.1.6 of emulators/virtualbox-ose-additions{,-nox11} at
that time. Luckily, I was able to upgrade the latter to 5.1.8 and all
network/NAT problems went away.
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig, | System administrator, |
| Fagskolen Innlandet, | Gjøvik Technical College, Norway, |
| tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, |
| sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. |
+---++
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: leapsecond file
On Mon, 8 Aug 2016 11:11+0900, Randy Bush wrote:
> i get these on all fbsd 10.3 hosts
>
> Aug 7 04:13:06 cache0 ntpd[576]: leapsecond file
> ('/var/db/ntpd.leap-seconds.list'): expired less than 68 days ago
>
> i have
>
> # grep ntp /etc/periodic.conf.local
> # 480.leapfile-ntpd
> daily_ntpd_leapfile_enable="YES"
> daily_ntpd_avoid_congestion="NO"
>
> consulting the net of a thousand lies did not bring enlightenment.
> maybe someone here has a clue bat? thanks.
I use:
daily_ntpd_leapfile_enable="YES"
daily_ntpd_avoid_congestion="YES"
You could try updating the leapsecond file manually:
service ntpd fetch
service ntpd restart
--
+---+----+
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig, | System administrator, |
| Fagskolen Innlandet, | Gjøvik Technical College, Norway, |
| tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, |
| sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. |
+---++
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Recent stable: bsnmpd eats up memory and cpu
On Mon, 2 May 2016 09:10+0200, Trond Endrestøl wrote: > On Mon, 2 May 2016 00:01+0200, Wolfgang Zenker wrote: > > > Hi, > > > > after updating some 10-STABLE systems a few days ago, I noticed that on > > two of those systems bsnmpd started to use up a lot of cpu time, and the > > available memory shrinked until rendering the system unusable. Killing > > bsnmpd stops the cpu usage but does not free up memory. > > Both affected systems are amd64, one having moved from r297555 to > > r298723, the other from r297555 to r298722. Another amd64 system > > that went from r297555 to r298722 appears to be not affected. > > The two affected systems are on an internal LAN segment and there > > is currently no application connecting to snmp on those machines. > > > > What would be useful debugging data to collect in this case? > > I believe I've seen the very same on my systems. All of them got > updated last Friday due to the recent NTP fix. Prior to last Friday, > they all ran stable/10 from early March, r296648-ish. Neither of them > run bsnmpd, but they offer a lot of network services. > > Three of my i386 systems each with 1 GiB of memory ran out of swap > space, Sunday afternoon. > > This night a mail server running i386 with 4 GiB of memory died while > handling mail. From the messages I could glean on /dev/ttyvb (due to > custom logging) before rebooting, is that it's all networking related. > > SpamAssassin and syslogd on the mail server managed to transmit these > lines to the central log host before dying: > > May 2 00:05:17 [HOSTNAME] spamc[63613]: connect to spamd on ::1 > failed, retrying (#1 of 3): Connection refused > May 2 00:05:17 [HOSTNAME] spamc[63613]: connect to spamd on > 127.0.0.1 failed, retrying (#1 of 3): Connection refused > May 2 00:05:18 [HOSTNAME] spamc[63613]: connect to spamd on ::1 > failed, retrying (#2 of 3): Connection refused > May 2 00:05:18 [HOSTNAME] spamc[63613]: connect to spamd on > 127.0.0.1 failed, retrying (#2 of 3): Connection refused > May 2 00:05:19 [HOSTNAME] spamc[63613]: connect to spamd on ::1 > failed, retrying (#3 of 3): Connection refused > May 2 00:05:19 [HOSTNAME] spamc[63613]: connect to spamd on > 127.0.0.1 failed, retrying (#3 of 3): Connection refused > May 2 00:05:19 [HOSTNAME] spamc[63613]: connection attempt to > spamd aborted after 3 retries > > May 2 00:52:17 [HOSTNAME] sm-mta[63740]: u41Mp86h063740: Milter > (spamassassin): error creating socket: No buffer space available > May 2 00:52:17 [HOSTNAME] sm-mta[63739]: u41Mp8r9063739: Milter > (spamassassin): error creating socket: No buffer space available > May 2 00:52:17 [HOSTNAME] sm-mta[63740]: u41Mp86h063740: Milter > (spamassassin): to error state > May 2 00:52:17 [HOSTNAME] sm-mta[63739]: u41Mp8r9063739: Milter > (spamassassin): to error state > > All of the amd64 systems with 4 GiB or 8 GiB of memory are apparently > unaffected. > > Maybe it's time to convert the remaining i386 systems to amd64 > systems, and add some memory while I'm at it. > > The bug is either in the kernel or in libc, or both. You might want to try out the patch created by Mark Johnston: http://lists.freebsd.org/pipermail/freebsd-current/2016-May/061015.html I'm in the process of testing this patch on one i386 stable/10 system and on one amd64 stable/10 system. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: devd(8) complains loudly when DVD player is empty, possibly due to r298134
On Mon, 2 May 2016 11:28-0600, Alan Somers wrote: > "-q" is only really intended for embedded systems that don't use the > standard syslogd or that are extremely concerned about syslogd's pipe > bandwidth and/or CPU usage. Most people should control devd's chattiness > with /etc/syslog.conf. This setting is good for most people. It will log > actions devd takes based on the stuff in /etc/devd/, but not much else. > > !devd > *.>=notice/var/log/devd.log > > And if you're directing every facility to its own file, you might consider > something like this: > > !-devd > user.*/var/log/user.log > > -Alan Thanks for the suggestion. I'll look into it when I get at work. > On Sun, May 1, 2016 at 9:07 AM, Trond Endrestøl < > trond.endres...@fagskolen.gjovik.no> wrote: > > > On Wed, 27 Apr 2016 13:46-0400, Scott Long wrote: > > > > > Thanks for the report. I might be mistaken, but the default system > > > is not configured to direct devd messages to user.info, so I didn’t > > > see this during my development. However, what you’re reporting is > > > definitely annoying, so Warner Losh and I are working on a solution. > > > > > > Scott > > > > I solved the problem by running devd with -q, i.e. devd_flags="-q" in > > /etc/rc.conf. This should probably be the default anyway. > > > > All of my systems (stable/10) have custom logging where each facility > > has its own file. Also *.*;mark.* is sent to /dev/ttyvb and to the > > central log host. /dev/ttyvb was pretty busy on the log host. > > > > Making devd less chatty does have its merits. > > The next servers I buy will probably exclude a DVD player. > > > > Happy hacking. > > > > > > On Apr 27, 2016, at 1:23 PM, Trond Endrestøl < > > trond.endres...@fagskolen.gjovik.no> wrote: > > > > > > > > Hi, > > > > > > > > The symptoms began after upgrading from stable/10 r298033 to stable/10 > > > > r298573. > > > > > > > > Apr 27 18:40:00 [HOSTNAME] devd: Processing event > > > > '!system=CAM subsystem=periph type=error device=cd0 > > > > serial="R8KL6GKC900AFG" cam_status="0xcc" scsi_status=2 scsi_sense="70 > > > > 02 04 01" CDB="00 00 00 00 00 00 " ' > > > > > > > > These messages are just seconds apart: > > > > > > > > Apr 27 18:40:01 [HOSTNAME] devd: Processing event > > > > '!system=CAM subsystem=periph type=error device=pass1 > > > > serial="R8KL6GKC900AFG" cam_status="0xcc" scsi_status=2 scsi_sense="70 > > > > 02 04 01" CDB="00 00 00 00 00 00 " ' > > > > Apr 27 18:40:03 [HOSTNAME] devd: Processing event > > > > '!system=CAM subsystem=periph type=error device=pass1 > > > > serial="R8KL6GKC900AFG" cam_status="0xcc" scsi_status=2 scsi_sense="70 > > > > 02 04 01" CDB="00 00 00 00 00 00 " ' > > > > Apr 27 18:40:05 [HOSTNAME] devd: Processing event > > > > '!system=CAM subsystem=periph type=error device=pass1 > > > > serial="R8KL6GKC900AFG" cam_status="0xcc" scsi_status=2 scsi_sense="70 > > > > 02 04 01" CDB="00 00 00 00 00 00 " ' > > > > > > > > When I put a CD or DVD in the DVD player, the messages stop. As soon > > > > as I eject the disc, they start appearing again. > > > > > > > > Here's the relevant part from dmesg: > > > > > > > > cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 > > > > cd0: Removable CD-ROM SCSI device > > > > cd0: Serial Number R8KL6GKC900AFG > > > > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO > > > > 8192bytes) > > > > cd0: Attempt to query device size failed: NOT READY, Medium not present > > > > - tray closed > > > > > > > > This is on a mid-2012 Dell Latitude E5530 with the stock DVD player. > > > > > > > > Upgrading to stable/10 r298705 doesn't resolve this issue. > > > > > > > > Does anyone else see this? > > > > > > > > Maybe r298134 is to blame: > > > > > > > > stable/10/sys/cam/cam_periph.c > > > > > > > > MFC r298004: > > > > > > > > Add a devctl/devd notification conduit for CAM errors that happ
Re: Recent stable: bsnmpd eats up memory and cpu
On Mon, 2 May 2016 00:01+0200, Wolfgang Zenker wrote: > Hi, > > after updating some 10-STABLE systems a few days ago, I noticed that on > two of those systems bsnmpd started to use up a lot of cpu time, and the > available memory shrinked until rendering the system unusable. Killing > bsnmpd stops the cpu usage but does not free up memory. > Both affected systems are amd64, one having moved from r297555 to > r298723, the other from r297555 to r298722. Another amd64 system > that went from r297555 to r298722 appears to be not affected. > The two affected systems are on an internal LAN segment and there > is currently no application connecting to snmp on those machines. > > What would be useful debugging data to collect in this case? I believe I've seen the very same on my systems. All of them got updated last Friday due to the recent NTP fix. Prior to last Friday, they all ran stable/10 from early March, r296648-ish. Neither of them run bsnmpd, but they offer a lot of network services. Three of my i386 systems each with 1 GiB of memory ran out of swap space, Sunday afternoon. This night a mail server running i386 with 4 GiB of memory died while handling mail. From the messages I could glean on /dev/ttyvb (due to custom logging) before rebooting, is that it's all networking related. SpamAssassin and syslogd on the mail server managed to transmit these lines to the central log host before dying: May 2 00:05:17 [HOSTNAME] spamc[63613]: connect to spamd on ::1 failed, retrying (#1 of 3): Connection refused May 2 00:05:17 [HOSTNAME] spamc[63613]: connect to spamd on 127.0.0.1 failed, retrying (#1 of 3): Connection refused May 2 00:05:18 [HOSTNAME] spamc[63613]: connect to spamd on ::1 failed, retrying (#2 of 3): Connection refused May 2 00:05:18 [HOSTNAME] spamc[63613]: connect to spamd on 127.0.0.1 failed, retrying (#2 of 3): Connection refused May 2 00:05:19 [HOSTNAME] spamc[63613]: connect to spamd on ::1 failed, retrying (#3 of 3): Connection refused May 2 00:05:19 [HOSTNAME] spamc[63613]: connect to spamd on 127.0.0.1 failed, retrying (#3 of 3): Connection refused May 2 00:05:19 [HOSTNAME] spamc[63613]: connection attempt to spamd aborted after 3 retries May 2 00:52:17 [HOSTNAME] sm-mta[63740]: u41Mp86h063740: Milter (spamassassin): error creating socket: No buffer space available May 2 00:52:17 [HOSTNAME] sm-mta[63739]: u41Mp8r9063739: Milter (spamassassin): error creating socket: No buffer space available May 2 00:52:17 [HOSTNAME] sm-mta[63740]: u41Mp86h063740: Milter (spamassassin): to error state May 2 00:52:17 [HOSTNAME] sm-mta[63739]: u41Mp8r9063739: Milter (spamassassin): to error state All of the amd64 systems with 4 GiB or 8 GiB of memory are apparently unaffected. Maybe it's time to convert the remaining i386 systems to amd64 systems, and add some memory while I'm at it. The bug is either in the kernel or in libc, or both. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: devd(8) complains loudly when DVD player is empty, possibly due to r298134
On Wed, 27 Apr 2016 13:46-0400, Scott Long wrote: > Thanks for the report. I might be mistaken, but the default system > is not configured to direct devd messages to user.info, so I didn’t > see this during my development. However, what you’re reporting is > definitely annoying, so Warner Losh and I are working on a solution. > > Scott I solved the problem by running devd with -q, i.e. devd_flags="-q" in /etc/rc.conf. This should probably be the default anyway. All of my systems (stable/10) have custom logging where each facility has its own file. Also *.*;mark.* is sent to /dev/ttyvb and to the central log host. /dev/ttyvb was pretty busy on the log host. Making devd less chatty does have its merits. The next servers I buy will probably exclude a DVD player. Happy hacking. > > On Apr 27, 2016, at 1:23 PM, Trond Endrestøl > > <trond.endres...@fagskolen.gjovik.no> wrote: > > > > Hi, > > > > The symptoms began after upgrading from stable/10 r298033 to stable/10 > > r298573. > > > > Apr 27 18:40:00 [HOSTNAME] devd: Processing event '!system=CAM > > subsystem=periph type=error device=cd0 serial="R8KL6GKC900AFG" > > cam_status="0xcc" scsi_status=2 scsi_sense="70 02 04 01" CDB="00 00 00 00 > > 00 00 " ' > > > > These messages are just seconds apart: > > > > Apr 27 18:40:01 [HOSTNAME] devd: Processing event '!system=CAM > > subsystem=periph type=error device=pass1 serial="R8KL6GKC900AFG" > > cam_status="0xcc" scsi_status=2 scsi_sense="70 02 04 01" CDB="00 00 00 00 > > 00 00 " ' > > Apr 27 18:40:03 [HOSTNAME] devd: Processing event '!system=CAM > > subsystem=periph type=error device=pass1 serial="R8KL6GKC900AFG" > > cam_status="0xcc" scsi_status=2 scsi_sense="70 02 04 01" CDB="00 00 00 00 > > 00 00 " ' > > Apr 27 18:40:05 [HOSTNAME] devd: Processing event '!system=CAM > > subsystem=periph type=error device=pass1 serial="R8KL6GKC900AFG" > > cam_status="0xcc" scsi_status=2 scsi_sense="70 02 04 01" CDB="00 00 00 00 > > 00 00 " ' > > > > When I put a CD or DVD in the DVD player, the messages stop. As soon > > as I eject the disc, they start appearing again. > > > > Here's the relevant part from dmesg: > > > > cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 > > cd0: Removable CD-ROM SCSI device > > cd0: Serial Number R8KL6GKC900AFG > > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > > cd0: Attempt to query device size failed: NOT READY, Medium not present - > > tray closed > > > > This is on a mid-2012 Dell Latitude E5530 with the stock DVD player. > > > > Upgrading to stable/10 r298705 doesn't resolve this issue. > > > > Does anyone else see this? > > > > Maybe r298134 is to blame: > > > > stable/10/sys/cam/cam_periph.c > > > > MFC r298004: > > > > Add a devctl/devd notification conduit for CAM errors that happen at the > > periph level. > > > > Due to not merging the changes to ata_res_sbuf(), this version is a little > > messy. > > > > Sponsored by: Netflix > > > > http://svnweb.freebsd.org/base?view=revision=298134 -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: booting from separate zfs pool
On Thu, 28 Apr 2016 12:44+0500, Eugene M. Zheganin wrote: > Hi. > > So, I'm still struggling with my problem when I cannot boot from a big > zfs 2T pool (I have written some messages about a year ago, the whole > story is too long and irrelevant to retell it, I'll only notice that I > took the path where I'm about to boot from a separate zfs pool closer to > the beginning of the disk). > > I've created such a smaller pool, called it zboot. I've read pjd@ letter > explaining that when FreeBSD sees several bootable pools, it chooses the > first one - that's fine with me, since the new pool partition's number > is smaller than the big one. So, I created zboot, set the mountpoint to > legacy, wrote the content to it's /boot directory (and yes, I did call > the 'make installkernel DESTDIR=/zboot') and rebooted. Are you sure /zboot/boot/zfsloader, /zboot/boot/kernel/kernel, /zboot/boot/kernel/opensolaris.ko, and /zboot/boot/kernel/zfs.ko exists when you manually mount the bootfs as /zboot? What's the bootfs properties on these pools? Run: zpool get bootfs For both pools the bootfs property should probably be unset. I have never unset a bootfs property in my life, but maybe this will work: zpool set bootfs= zboot zpool set bootfs= zroot I have a similar setup in a VM at home due to Oracle VirtualBox in EFI mode only presenting two drives at boot time, where zboot/BOOT/20160428-r298705 is set as the bootfs on the zboot pool, and the mountpoint is set to /bootpool. Further, boot/loader.conf on the small bootfs redirects the kernel to use zroot/ROOT/20160428-r298705 as the rootfs, i.e. vfs.root.mountfrom="zfs:zroot/ROOT/20160428-r298705". The rootfs contains a symlink named boot, pointing to bootpool/boot. "df / /bootpool" will show something similar to this: zroot/ROOT/20160428-r298705 / zboot/BOOT/20160428-r298705 /bootpool > Strage thing happened next - I got > > > Can't find /boot/zfsloader > > FreeBSD/x86 boot > Default: zboot:/boot/kernel/kernel > boot: > | > Can't find /boot/kernel/kernel > > > I booted back from USB stick (that I'm using to boot my machine) and > rechecked these files - everything mentioned here is in it's place. > > Does someone have the idea what I'm doing wrong ? May be this has > something to do with the fact that zboot does contain only the /boot > directory, and not the full rootfs ? > > Thanks. > Eugene. -- +-------+--------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
devd(8) complains loudly when DVD player is empty, possibly due to r298134
Hi, The symptoms began after upgrading from stable/10 r298033 to stable/10 r298573. Apr 27 18:40:00 [HOSTNAME] devd: Processing event '!system=CAM subsystem=periph type=error device=cd0 serial="R8KL6GKC900AFG" cam_status="0xcc" scsi_status=2 scsi_sense="70 02 04 01" CDB="00 00 00 00 00 00 " ' These messages are just seconds apart: Apr 27 18:40:01 [HOSTNAME] devd: Processing event '!system=CAM subsystem=periph type=error device=pass1 serial="R8KL6GKC900AFG" cam_status="0xcc" scsi_status=2 scsi_sense="70 02 04 01" CDB="00 00 00 00 00 00 " ' Apr 27 18:40:03 [HOSTNAME] devd: Processing event '!system=CAM subsystem=periph type=error device=pass1 serial="R8KL6GKC900AFG" cam_status="0xcc" scsi_status=2 scsi_sense="70 02 04 01" CDB="00 00 00 00 00 00 " ' Apr 27 18:40:05 [HOSTNAME] devd: Processing event '!system=CAM subsystem=periph type=error device=pass1 serial="R8KL6GKC900AFG" cam_status="0xcc" scsi_status=2 scsi_sense="70 02 04 01" CDB="00 00 00 00 00 00 " ' When I put a CD or DVD in the DVD player, the messages stop. As soon as I eject the disc, they start appearing again. Here's the relevant part from dmesg: cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI device cd0: Serial Number R8KL6GKC900AFG cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed This is on a mid-2012 Dell Latitude E5530 with the stock DVD player. Upgrading to stable/10 r298705 doesn't resolve this issue. Does anyone else see this? Maybe r298134 is to blame: stable/10/sys/cam/cam_periph.c MFC r298004: Add a devctl/devd notification conduit for CAM errors that happen at the periph level. Due to not merging the changes to ata_res_sbuf(), this version is a little messy. Sponsored by: Netflix http://svnweb.freebsd.org/base?view=revision=298134 -- +-------++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: A gpart(8) mystery on 10.3-RELEASE
On Tue, 5 Apr 2016 15:34+0300, Boris Samorodov wrote: > 05.04.16 12:30, Trond Endrestøl пишет: > > > What am I doing wrong? Can't gpart(8) write both the pmbr and the efi > > image as a single command? Is it an off-by-one error in gpart(8)? > > Should it? Yes, then it would complement the BIOS style invocation: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0 > > uname -a > > FreeBSD 10.3-RELEASE FreeBSD 10.3-RELEASE #0 r297264: Fri Mar 25 02:10:02 > > UTC 2016 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC > > amd64 > > > > gpart create -s gpt ada0 > > ada0 created > > > > gpart add -a 4K -s 800K -t efi ada0 > > ada0p1 added > > > > gpart add -a 4K -s 4G -t freebsd-swap ada0 > > ada0p2 added > > > > gpart add -a 4K -t freebsd-zfs ada0 > > ada0p3 added > > > > gpart show -p ada0 > > => 34 41942973ada0 GPT (20G) > > 34 6 - free - (3.0K) > > 40 1600 ada0p1 efi (800K) > > 1640 8388608 ada0p2 freebsd-swap (4.0G) > >8390248 33552752 ada0p3 freebsd-zfs (16G) > > 41943000 7 - free - (3.5K) > > > > gpart bootcode -b /boot/pmbr -p /boot/boot1.efifat -i 1 ada0 > > gpart: /boot/boot1.efifat: file too big (524288 limit) > > Do you try to get only UEFI boot? Then do not use "-b" option. It is > needed for BIOS boot. UEFI and GPT specify the PMBR as a way of telling legacy software not to meddle with the (P)MBR. I wouldn't expect a new disk to contain anything in disk block 0, thus the (misguided on my part?) need for initializing block 0 as a proper PMBR. > Do you need to get a system with both UEFI and BIOS boot? Then use two > different partitions for UEFI and BIOS booting schemes. I have no need for dual-booting. > > gpart bootcode -b /boot/pmbr ada0 > > bootcode written to ada0 > > This is needed only for BIOS boot and together with "-p /boot/gptboot" > option. > > > gpart bootcode -p /boot/boot1.efifat -i 1 ada0 > > > > Hm, I'm not sure if this is supposed (like: supported) to be done like > this. One may use dd to copy this partition image (boot1.efifat) if > target partition is not less then the file length. > > Otherwise one may format the target efi partition as an msdos-fat one, > create /EFI/BOOT mountpoint and copy boot64x.efi file there. > > Here is a link from another similar thead: > http://www.wonkity.com/~wblock/docs/html/disksetup.html#_booting_with_uefi > > > System is bootable. I guess I upset you all. Case closed. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: A gpart(8) mystery on 10.3-RELEASE
On Tue, 5 Apr 2016 12:07+0200, martin.amb...@tudc.cz wrote: > Trond Endrestøl píše v út 05. 04. 2016 v 11:30 +0200: > > What am I doing wrong? Can't gpart(8) write both the pmbr and the efi > image as a single command? Is it an off-by-one error in gpart(8)? > > uname -a > FreeBSD 10.3-RELEASE FreeBSD 10.3-RELEASE #0 r297264: Fri Mar 25 > 02:10:02 UTC 2016 > r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > > gpart create -s gpt ada0 > ada0 created > > gpart add -a 4K -s 800K -t efi ada0 > ada0p1 added > > gpart add -a 4K -s 4G -t freebsd-swap ada0 > ada0p2 added > > gpart add -a 4K -t freebsd-zfs ada0 > ada0p3 added > > gpart show -p ada0 > => 34 41942973ada0 GPT (20G) > 34 6 - free - (3.0K) > 40 1600 ada0p1 efi (800K) > 1640 8388608 ada0p2 freebsd-swap (4.0G) > 8390248 33552752 ada0p3 freebsd-zfs (16G) > 41943000 7 - free - (3.5K) > > gpart bootcode -b /boot/pmbr -p /boot/boot1.efifat -i 1 ada0 > gpart: /boot/boot1.efifat: file too big (524288 limit) > > gpart bootcode -b /boot/pmbr ada0 > bootcode written to ada0 > > gpart bootcode -p /boot/boot1.efifat -i 1 ada0 > > > System is bootable. > Try "dd if=/boot/boot1.efifat of=/dev/ada0p1" instead. I'm aware of dd(1), but I feel gpart(8) should be able to handle this task, which it sort of does, if you do the -b and the -p parts as separate invocations as demonstrated above. gpart(8) should take the current boot firmware into consideration. If the boot firmware is BIOS, then a limit of 512K (524288 bytes) is fine as that's the current limit for the bootcode in /boot/pmbr. If the boot firmware is (U)EFI, then gpart(8) should allow a -p image of a size less than or equal to the partition's size, while simultaneously writing the PMBR. I.e., contrary to the current documentation for gpart(8)'s bootcode subcommand: The size of the file must be smaller than the size of the partition. -- +-------+--------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
A gpart(8) mystery on 10.3-RELEASE
What am I doing wrong? Can't gpart(8) write both the pmbr and the efi image as a single command? Is it an off-by-one error in gpart(8)? uname -a FreeBSD 10.3-RELEASE FreeBSD 10.3-RELEASE #0 r297264: Fri Mar 25 02:10:02 UTC 2016 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 gpart create -s gpt ada0 ada0 created gpart add -a 4K -s 800K -t efi ada0 ada0p1 added gpart add -a 4K -s 4G -t freebsd-swap ada0 ada0p2 added gpart add -a 4K -t freebsd-zfs ada0 ada0p3 added gpart show -p ada0 => 34 41942973ada0 GPT (20G) 34 6 - free - (3.0K) 40 1600 ada0p1 efi (800K) 1640 8388608 ada0p2 freebsd-swap (4.0G) 8390248 33552752 ada0p3 freebsd-zfs (16G) 41943000 7 - free - (3.5K) gpart bootcode -b /boot/pmbr -p /boot/boot1.efifat -i 1 ada0 gpart: /boot/boot1.efifat: file too big (524288 limit) gpart bootcode -b /boot/pmbr ada0 bootcode written to ada0 gpart bootcode -p /boot/boot1.efifat -i 1 ada0 System is bootable. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problems with unbound
On Tue, 15 Mar 2016 12:28+0100, Andrea Brancatelli wrote: > Hello everybody, > > we're suddenly having problems with unbound on almost all of our servers > and I cannot really understand why. > > To make a long story short, we use this forward.conf: > > root@dbengine-ent-rm-01:/var/unbound # cat /etc/unbound/forward.conf > # This file was generated by local-unbound-setup. > # Modifications will be overwritten. > forward-zone: > name: . > forward-addr: 8.8.8.8 > forward-addr: 8.8.4.4 > > Enabling this: > > auto-trust-anchor-file: /var/unbound/root.key > > in /etc/unbound/unbound.conf gives me this: > > root@dbengine-ent-rm-01:/var/unbound # host update.freebsd.org > ;; connection timed out; no servers could be reached > > simply disabling that line gives me this: > > root@dbengine-ent-rm-01:/var/unbound # host update.freebsd.org > update.freebsd.org is an alias for update5.freebsd.org. > update5.freebsd.org has address 204.9.55.80 > update5.freebsd.org has IPv6 address 2001:4978:1:420::cc09:3750 > update5.freebsd.org mail is handled by 0 . > > What's going on? There's at least two possibilities: 1. Your ISP limits the use of DNS, in particular when DNSSEC is involved, or 2. The Google DNS resolvers doesn't support DNSSEC. I haven't verified the latter, but I would guess Google are competent enough to allow DNSSEC. > root@dbengine-ent-rm-01:/var/unbound # freebsd-version > 10.2-RELEASE-p13 > > Thanks. -- +---+----+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Multiple kernels installed when KERNCONF lists more than one kernel configuration file
On Wed, 6 Jan 2016 13:26-0800, Gleb Smirnoff wrote: > Trond & David, > > can you please test the attached patch. It is against stable/10 and > should restore original behaviour. The patch works for me. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Multiple kernels installed when KERNCONF lists more than one kernel configuration file
Hi, I'm running stable/10, amd64, r293231, and KERNCONF in /etc/src.conf lists three kernel configuration files, E5530, GENERIC, and ZFS, in that order. The former is the preferred kernel, while the other two simply exists to verify GENERIC and GENERIC + ZFS. /boot is a symlink to /bootpool/boot, and /bootpool is a 4 GiB UFS, yes, that's UFS, not ZFS. This system uses EFI, and uses the EFI/UFS boot1.efi bootstrap loader to load the kernel and its modules from the UFS partition, while loader.conf redirects the rootfs to a dataset on the ZFS pool. Consequently, I have: /boot/kernel <-- E5530 /boot/kernel.GENERIC <-- GENERIC /boot/kernel.ZFS <-- ZFS UPDATING has nothing on the subject, but maybe I'm blind after all. Is there a way to prevent installing the other kernels, i.e. GENERIC and ZFS? Maybe it's simply a matter of overriding KERNCONF at the command line while running make installkernel. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
r292973 creates problems for stable/10 kernels and options ZFS
After r292973, it's impossible to build a stable/10 kernel configured with options ZFS: --- kernel.debug --- linking kernel.debug subr_nvlist.o: In function `nvlist_add_nvlist': /usr/src/sys/kern/subr_nvlist.c:1189: multiple definition of `nvlist_add_nvlist' opensolaris_nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/opensolaris_nvpair.c:1144: first defined here subr_nvlist.o: In function `nvlist_add_nvpair': /usr/src/sys/kern/subr_nvlist.c:1061: multiple definition of `nvlist_add_nvpair' opensolaris_nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/opensolaris_nvpair.c:1979: first defined here subr_nvlist.o: In function `nvlist_add_string': /usr/src/sys/kern/subr_nvlist.c:1171: multiple definition of `nvlist_add_string' opensolaris_nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/opensolaris_nvpair.c:1064: first defined here subr_nvlist.o: In function `nvlist_empty': /usr/src/sys/kern/subr_nvlist.c:226: multiple definition of `nvlist_empty' opensolaris_nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/opensolaris_nvpair.c:1210: first defined here subr_nvlist.o: In function `nvlist_exists': /usr/src/sys/kern/subr_nvlist.c:1034: multiple definition of `nvlist_exists' opensolaris_nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/opensolaris_nvpair.c:1797: first defined here subr_nvlist.o: In function `nvlist_free': /usr/src/sys/kern/subr_nvlist.c:1439: multiple definition of `nvlist_free' opensolaris_nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/opensolaris_nvpair.c:561: first defined here subr_nvlist.o: In function `nvlist_next_nvpair': /usr/src/sys/kern/subr_nvlist.c:983: multiple definition of `nvlist_next_nvpair' opensolaris_nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/opensolaris_nvpair.c:1157: first defined here subr_nvlist.o: In function `nvlist_pack': /usr/src/sys/kern/subr_nvlist.c:696: multiple definition of `nvlist_pack' opensolaris_nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/opensolaris_nvpair.c:2351: first defined here subr_nvlist.o: In function `nvlist_prev_nvpair': /usr/src/sys/kern/subr_nvlist.c:999: multiple definition of `nvlist_prev_nvpair' opensolaris_nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/opensolaris_nvpair.c:1186: first defined here subr_nvlist.o: In function `nvlist_remove_nvpair': /usr/src/sys/kern/subr_nvlist.c:1428: multiple definition of `nvlist_remove_nvpair' opensolaris_nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/opensolaris_nvpair.c:704: first defined here subr_nvlist.o: In function `nvlist_size': /usr/src/sys/kern/subr_nvlist.c:448: multiple definition of `nvlist_size' opensolaris_nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/opensolaris_nvpair.c:2340: first defined here subr_nvlist.o: In function `nvlist_unpack': /usr/src/sys/kern/subr_nvlist.c:855: multiple definition of `nvlist_unpack' opensolaris_nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/opensolaris_nvpair.c:2413: first defined here subr_nvlist.o: In function `nvlist_xpack': /usr/src/sys/kern/subr_nvlist.c:601: multiple definition of `nvlist_xpack' opensolaris_nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/opensolaris_nvpair.c:2363: first defined here subr_nvlist.o: In function `nvlist_xunpack': /usr/src/sys/kern/subr_nvlist.c:780: multiple definition of `nvlist_xunpack' opensolaris_nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/opensolaris_nvpair.c:2424: first defined here subr_nvpair.o: In function `nvpair_name': /usr/src/sys/kern/subr_nvpair.c:711: multiple definition of `nvpair_name' opensolaris_nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/opensolaris_nvpair.c:1222: first defined here subr_nvpair.o: In function `nvpair_type': /usr/src/sys/kern/subr_nvpair.c:702: multiple definition of `nvpair_type' opensolaris_nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/opensolaris_nvpair.c:1228: first defined here *** [kernel.debug] Error code 1 Is options ZFS discouraged? I find it better to have a selfcontained kernel for something so important as ZFS, at least when it's the core FS for some of my systems. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-uns
Re: zfs, mc, mcview and files opening
On Tue, 10 Nov 2015 14:58+0500, Eugene M. Zheganin wrote: > my midnight commander is terribly slow at vieweing files with mcview. [snip] > Can some workaround be used ? I blame file(1), it's hopelessly slow. mcview uses file(1) to deduce if it should just display the damn file or run the file through some filter. Maybe an option in mc/mcview to disable the use of file(1) is an acceptable compromise. OTOH, I could be wrong. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: zfs, mc, mcview and files opening
On Tue, 10 Nov 2015 11:05+0100, Trond Endrestøl wrote: > On Tue, 10 Nov 2015 14:58+0500, Eugene M. Zheganin wrote: > > > my midnight commander is terribly slow at vieweing files with mcview. > > [snip] > > > Can some workaround be used ? > > I blame file(1), it's hopelessly slow. mcview uses file(1) to deduce > if it should just display the damn file or run the file through some > filter. Maybe an option in mc/mcview to disable the use of file(1) is > an acceptable compromise. A workaround is to navigate to the file you wish to view. Hit M-! or ESC ! to activate the filter command. Hit the Home key, type in c a t followed by a space and hit enter. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: zfs, mc, mcview and files opening
On Tue, 10 Nov 2015 16:54+0500, Eugene M. Zheganin wrote: > Hi, > > on 10.11.2015 15:05, Trond Endrestøl wrote: > > I blame file(1), it's hopelessly slow. mcview uses file(1) to deduce > > if it should just display the damn file or run the file through some > > filter. Maybe an option in mc/mcview to disable the use of file(1) is > > an acceptable compromise. > Yeah, you seem to be right. /usr/bin/time -h file /var/log/maillog gives > same time of 37-40 seconds to process the file. > The main answer is now why file(1) is that slow ? I tested it on files > of about same size and UFS - there's no lag at all. > > Is it worth to report this in bugzilla ? This PR exists: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148150 You might want to check out stable/10 r290152 onwards, as file 5.25 was recently merged from head. I'm still running stable/10 amd64 r290090, so upgrading to the latest stable/10 might help. I'll see if I can upgrade one my systems later this afternoon. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Merging r286233 to stable/10?
Hi, Would someone please consider merging r286233 to stable/10? -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Merging r286233 to stable/10?
On Sat, 7 Nov 2015 12:12-, Florian Ermisch wrote: > To provide some context for other ppl wondering: My bad. I meant r286223. This one: https://svnweb.freebsd.org/base?view=revision=286223 -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Upgrading FreeBSD/i386 from stable/9 r286222 to stable/10 r286278
Has anyone successfully built stable/10 while running stable/9? I'm subject to PR 194899. Isn't /usr/src/sys/sys considered during make depend, only /usr/include/sys, in that regard? I worked around the capsicum bug by manually copying these files to /usr/include/sys: sys/sys/capsicum.h sys/sys/capability.h sys/sys/caprights.h Afterwards, I replaced /usr/include/sys/capability.h with the one from stable/9. Now make buildworld dies with: === lib/libc (obj,depend,all,install) gcc -O2 -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -I/usr/src/lib/libc/../../contrib/libc-vis -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libmd -I/usr/src/lib/libc/../../contrib/jemalloc/include -I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -DSYSCALL_COMPAT -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libc/gen/strtofflags.c -o strtofflags.o /usr/src/lib/libc/gen/strtofflags.c:65: error: 'UF_ARCHIVE' undeclared here (not in a function) /usr/src/lib/libc/gen/strtofflags.c:67: error: 'UF_HIDDEN' undeclared here (not in a function) /usr/src/lib/libc/gen/strtofflags.c:75: error: 'UF_OFFLINE' undeclared here (not in a function) /usr/src/lib/libc/gen/strtofflags.c:78: error: 'UF_READONLY' undeclared here (not in a function) /usr/src/lib/libc/gen/strtofflags.c:82: error: 'UF_REPARSE' undeclared here (not in a function) /usr/src/lib/libc/gen/strtofflags.c:84: error: 'UF_SPARSE' undeclared here (not in a function) /usr/src/lib/libc/gen/strtofflags.c:86: error: 'UF_SYSTEM' undeclared here (not in a function) *** Error code 1 Maybe I should consider building a newer stable/9 or an earlier stable/10. Any pointers? -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Upgrading FreeBSD/i386 from stable/9 r286222 to stable/10 r286278
On Tue, 4 Aug 2015 12:49+0200, Trond Endrestøl wrote: Has anyone successfully built stable/10 while running stable/9? I'm subject to PR 194899. Isn't /usr/src/sys/sys considered during make depend, only /usr/include/sys, in that regard? False alarm, sorry. Building stable/10 using clang from stable/9 solved my problem. E.g. in /etc/src.conf: CC=clang CXX=clang++ CPP=clang-cpp NO_WERROR= WERROR= -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
KSTACK_PAGES stuck at 2 despite options KSTACK_PAGES=4
stable/10, i386, r286139, 4 GiB RAM, custom kernel loudly claims: ZFS NOTICE: KSTACK_PAGES is 2 which could result in stack overflow panic! Please consider adding 'options KSTACK_PAGES=4' to your kernel config Well, my custom kernel config does contain: options KSTACK_PAGES=4 and options ZFS sysctl kern.conftxt backs up my story: kern.conftxt: options CONFIG_AUTOGENERATED ident VBOX machine i386 cpu I686_CPU cpu I586_CPU cpu I486_CPU makeoptions WITH_CTF=1 makeoptions DEBUG=-g options ZFS options KSTACK_PAGES=4 !! options FDESCFS ... What more does it want? -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
ctfconvert fails for cddl/lib/drti, ctfconvert is missing
During make -j 1 installworld on stable/10, this happened to me on two separate occations: === cddl/lib/drti (install) make[6]: /usr/obj/usr/src/cddl/lib/drti/.depend, 87: ignoring stale .depend for /usr/src/cddl/lib/drti/../../../sys/cddl/compat/opensolaris/sys/cyclic.h clang -O2 -pipe -fno-omit-frame-pointer -I/usr/src/cddl/lib/drti/../../../sys/cddl/compat/opensolaris -I/usr/src/cddl/lib/drti/../../../cddl/compat/opensolaris/include -I/usr/src/cddl/lib/drti/../../../cddl/contrib/opensolaris/head -I/usr/src/cddl/lib/drti/../../../cddl/contrib/opensolaris/lib/libctf/common -I/usr/src/cddl/lib/drti/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/usr/src/cddl/lib/drti/../../../sys/cddl/contrib/opensolaris/uts/common -DPIC -fpic -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-unknown-pragmas ! -c /usr/src/cddl/lib/drti/../../../cddl/contrib/opensolaris/lib/libdtrace/common/drti.c -o drti.o ctfconvert -L VERSION drti.o make[6]: exec(ctfconvert) failed (No such file or directory) *** Error code 1 I run make -j 4 buildworld with -D NO_CLEAN. I had DESTDIR set to a new and empty ZFS BE, so maybe ctfconvert isn't installed in time. /etc/make.conf contains: KERNCONF=ENTERPRISE GENERIC ZFS STRIP= CFLAGS+=-fno-omit-frame-pointer /etc/src.conf contains: CC=clang CXX=clang++ CPP=clang-cpp NO_WERROR= WERROR= WITH_CLANG_EXTRAS=yes WITH_CLANG_FULL=yes WITH_CTF=1 WITH_GCC=yes WITH_GNUCXX=yes WITH_LIBCPLUSPLUS=yes WITH_NAND=yes Running make -k installworld succeeds. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
stable/9 r281817 needs to build an up-to-date make when compiling stable/9 r281849
Hi, One of my systems runs stable/9 r281817. Even with an empty /usr/obj, make buildworld insists on building an up-to-date make when compiling stable/9 r281849. Is this due to a pilot error on my part? -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS pool with 4k sector size
On Thu, 22 Aug 2013 11:40+0400, Michael BlackHeart wrote: Hello, I'd like to know what is the best way to convert my pool from 512b sector size to 4k sector size. Hardware: 2 x2Tb WD Green with 4k physical sector size Model Family: Western Digital Caviar Green (AF, SATA 6Gb/s) Device Model: WDC WD20EARX-00PASB0 Serial Number: WD-WCAZA8280575 LU WWN Device Id: 5 0014ee 206032063 Firmware Version: 51.0AB51 User Capacity: 2 000 398 934 016 bytes [2,00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Device is: In smartctl database [for details use: -P show] ATA Version is: ATA8-ACS (minor revision not indicated) SATA Version is: SATA 3.0, 3.0 Gb/s (current: 3.0 Gb/s) Local Time is: Thu Aug 22 11:33:16 2013 MSK SMART support is: Available - device has SMART capability. SMART support is: Enabled They're running in a mirror pool: storage state: ONLINE scan: resilvered 48K in 0h0m with 0 errors on Thu Jul 25 19:18:01 2013 config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 ada3 ONLINE 0 0 0 ada7 ONLINE 0 0 0 zdb info storage: version: 5000 name: 'storage' state: 0 txg: 1292269 pool_guid: 18442220950447532371 hostid: 708219113 hostname: 'diablo.miekoff.local' vdev_children: 1 vdev_tree: type: 'root' id: 0 guid: 18442220950447532371 create_txg: 4 children[0]: type: 'mirror' id: 0 guid: 4289294206539029185 metaslab_array: 33 metaslab_shift: 34 ashift: 9 asize: 2000394125312 is_log: 0 create_txg: 4 children[0]: type: 'disk' id: 0 guid: 16348588566764560218 path: '/dev/ada3' phys_path: '/dev/ada3' whole_disk: 1 DTL: 95 create_txg: 4 children[1]: type: 'disk' id: 1 guid: 7655198429866445090 path: '/dev/ada7' phys_path: '/dev/ada7' whole_disk: 1 DTL: 97 create_txg: 4 features_for_read: As you see ashift is 9 (512b). I know a common solution with gnop and export-mport pool, but how should I manage mirror this way? Should I create a mirror on gnop-ed devices and then export-import? I'm afraid you're out of luck. You need to backup the data somehow, recreate the pool with ashift=12, and restore the data. A better option would be to buy a couple of new drives, assuming you can connect them to the current system, create a new mirrored pool with ashift=12, and transfer the data using a recursive set of snapshots on the current pool and a ZFS send stream sent to the new pool. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Properties list for zfs in FreeBSD
On Wed, 21 Aug 2013 13:02-, Zenny wrote: Hi: Where can I find a list of properties (-o/-O property=value) for creating a zpool? I meant something like: #zpool create \ -o ashift=12 \ -0 dedup=off -O autoexpand=off -O atime=off \ -O canmount=off \ -O compression=lz4 \ -O normalization=formD \ -O mountpoint=/jail \ tank \ mirror \ /dev/gptid/diskname0 \ /dev/gptid/diskname1 \ cache \ /dev/gptid/diskname2 Thanks! Read zpool(8) for zpool properties, and zfs(8) for zfs properties. Online versions for 9.1-RELEASE: http://www.freebsd.org/cgi/man.cgi?query=zpoolapropos=0sektion=0manpath=FreeBSD+9.1-RELEASEarch=defaultformat=html http://www.freebsd.org/cgi/man.cgi?query=zfsapropos=0sektion=0manpath=FreeBSD+9.1-RELEASEarch=defaultformat=html You can choose other versions of FreeBSD from the web form at the top. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS in jails 9.2-RC1 permission denied
On Fri, 9 Aug 2013 13:35+0300, George Kontostanos wrote: On Fri, Aug 9, 2013 at 8:55 AM, Trond Endrestøl trond.endres...@fagskolen.gjovik.no wrote: On Thu, 8 Aug 2013 19:04+0300, George Kontostanos wrote: On Thu, Aug 8, 2013 at 2:59 PM, Mark Felder f...@freebsd.org wrote: On Thu, Aug 8, 2013, at 6:53, George Kontostanos wrote: Anybody? Can you provide your jail configuration? I think 9.2 introduces the new /etc/jail.conf functionality and perhaps it somehow it broke the way you were doing it previously? If so, the old method is supposed to be work as well... jail_enable=YES jail_list=jail1 jail_jail1_rootdir=/tank/jails/jail1 jail_jail1_hostname=jail1 jail_jail1_interface=em0 jail_jail1_ip=172.16.154.32 jail_jail1_devfs_enable=YES During my experimentation yesterday, I had to add: jail_jail1_parameters=enforce_statfs=1 allow.mount=1 allow.mount.zfs=1 I wish there was a way of executing a command in the host environment _after_ the jail is created, but _before_ exec.start is run from within the jail environment, exec.prestart is run in the host environment before the jail is created and is of no use for attaching a ZFS dataset to a particular jail with the zfs jail command. Until this issue is resolved, I see no other way than manually attaching a ZFS dataset to a jail, and manually running the mount command from within the jail environment. Excellent, this worked like a charm! Does this means that the sysctl parameters are not honored or they have to be also passed in the jail parameters? I guess so. Setting the sysctls in /etc/sysctl.conf doesn't seem to propagate to the jail environments at all in 9.2-BETA2. Thanks! You're welcome, and thanks for pushing me to explore jails and ZFS even further. ;-) Maybe the jail people should erect exec.afterprestart, enabling us to attach ZFS datasets to our jails prior to launching the jails. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS in jails 9.2-RC1 permission denied
On Fri, 9 Aug 2013 14:07+0300, George Kontostanos wrote: On Fri, Aug 9, 2013 at 1:57 PM, Trond Endrestøl trond.endres...@fagskolen.gjovik.no wrote: On Fri, 9 Aug 2013 13:35+0300, George Kontostanos wrote: On Fri, Aug 9, 2013 at 8:55 AM, Trond Endrestøl trond.endres...@fagskolen.gjovik.no wrote: On Thu, 8 Aug 2013 19:04+0300, George Kontostanos wrote: On Thu, Aug 8, 2013 at 2:59 PM, Mark Felder f...@freebsd.org wrote: On Thu, Aug 8, 2013, at 6:53, George Kontostanos wrote: Anybody? Can you provide your jail configuration? I think 9.2 introduces the new /etc/jail.conf functionality and perhaps it somehow it broke the way you were doing it previously? If so, the old method is supposed to be work as well... jail_enable=YES jail_list=jail1 jail_jail1_rootdir=/tank/jails/jail1 jail_jail1_hostname=jail1 jail_jail1_interface=em0 jail_jail1_ip=172.16.154.32 jail_jail1_devfs_enable=YES During my experimentation yesterday, I had to add: jail_jail1_parameters=enforce_statfs=1 allow.mount=1 allow.mount.zfs=1 I wish there was a way of executing a command in the host environment _after_ the jail is created, but _before_ exec.start is run from within the jail environment, exec.prestart is run in the host environment before the jail is created and is of no use for attaching a ZFS dataset to a particular jail with the zfs jail command. Until this issue is resolved, I see no other way than manually attaching a ZFS dataset to a jail, and manually running the mount command from within the jail environment. Excellent, this worked like a charm! Does this means that the sysctl parameters are not honored or they have to be also passed in the jail parameters? I guess so. Setting the sysctls in /etc/sysctl.conf doesn't seem to propagate to the jail environments at all in 9.2-BETA2. Thanks! You're welcome, and thanks for pushing me to explore jails and ZFS even further. ;-) Maybe the jail people should erect exec.afterprestart, enabling us to attach ZFS datasets to our jails prior to launching the jails. I think that the process of attaching a dataset or a pool to a jail has to be done after the JID has been created. The way I attach them is from the host system: #zfs jail JID pool/dataset That's why I propose the exec.afterprestart. This is how I imagine it should work: 1. The operator attempts to create a jail: jail -c somejail 2. The exec.prestart is run within the _host_ environment. It is of no concern regarding attaching ZFS datasets to our jail. 3. The jail is actually created, say, with /jails/somejail (zjails/jails/somejail) as it root. 4. The exec.afterprestart is run within the _host_ environment, and in our case is configured to attach some ZFS datasets, say: zfs jail somejail zjails/jaildata/somejail 5. The exec.start is run within the _jail_ environment, typically running /etc/rc. 6. /etc/fstab within the _jail_ environment contains the necessary information to mount zjails/jaildata/somejail as /jaildata. 7. Everything else remains unchanged. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS in jails 9.2-RC1 permission denied
On Thu, 8 Aug 2013 14:53+0300, George Kontostanos wrote: On Wed, Aug 7, 2013 at 7:26 PM, George Kontostanos wrote: Hi list, With a 9.1 system and the following: /etc/sysctl.conf: security.jail.mount_allowed=1 security.jail.mount_zfs_allowed=1 security.jail.enforce_statfs=1 zfs set jailed=on Pool zfs jail 1 Pool jexec 1 tcsh jail1# zfs create Pool/test1 jail1# zfs list NAME USED AVAIL REFER MOUNTPOINT Pool 223K 19.6G31K /Pool Pool/test1 31K 19.6G31K /Pool/test After upgrading to 9.2-RC1 the same operation results in: jail1# zfs create Pool/test2 cannot create 'Pool/test2': permission denied What am I missing? Thanks -- George Kontostanos --- Anybody? I'm just guessing, but I doubt a jail would be able to create new ZFS filesystems outside its own structure, if at all able. A jail would however be allowed to (un)mount already existing filesystems within its own structure, i.e. Pool/test1. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS in jails 9.2-RC1 permission denied
On Thu, 8 Aug 2013 07:05-0500, Mark Felder wrote: On Thu, Aug 8, 2013, at 6:59, Trond Endrestøl wrote: I'm just guessing, but I doubt a jail would be able to create new ZFS filesystems outside its own structure, if at all able. A jail would however be allowed to (un)mount already existing filesystems within its own structure, i.e. Pool/test1. When I first reviewed his post I clearly confused mounting with creating a new zfs filesystem. Is that even supposed to be permitted in a jail? I almost feel a sysctl disabling that by default would be nice... DoS by zfs filesystem creation/deletion, anyone? I started experimenting with jails last Sunday. There is certainly more to explore and learn. Just a few more hours and I'm heading home to do some lab work. ;-) -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS in jails 9.2-RC1 permission denied
On Thu, 8 Aug 2013 19:04+0300, George Kontostanos wrote: On Thu, Aug 8, 2013 at 2:59 PM, Mark Felder f...@freebsd.org wrote: On Thu, Aug 8, 2013, at 6:53, George Kontostanos wrote: Anybody? Can you provide your jail configuration? I think 9.2 introduces the new /etc/jail.conf functionality and perhaps it somehow it broke the way you were doing it previously? If so, the old method is supposed to be work as well... jail_enable=YES jail_list=jail1 jail_jail1_rootdir=/tank/jails/jail1 jail_jail1_hostname=jail1 jail_jail1_interface=em0 jail_jail1_ip=172.16.154.32 jail_jail1_devfs_enable=YES During my experimentation yesterday, I had to add: jail_jail1_parameters=enforce_statfs=1 allow.mount=1 allow.mount.zfs=1 I wish there was a way of executing a command in the host environment _after_ the jail is created, but _before_ exec.start is run from within the jail environment, exec.prestart is run in the host environment before the jail is created and is of no use for attaching a ZFS dataset to a particular jail with the zfs jail command. Until this issue is resolved, I see no other way than manually attaching a ZFS dataset to a jail, and manually running the mount command from within the jail environment. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Problem with zfsloader on 9.2-BETA2
On Wed, 31 Jul 2013 12:12-0400, J David wrote:
On Wed, Jul 31, 2013 at 5:20 AM, Trond Endrestøl
trond.endres...@fagskolen.gjovik.no wrote:
I'm curious as to why you use da?p1 as the freebsd-zfs partitions.
Those are whole-disk partitions.
Where does the freebsd-boot partition reside? da?p2?
Only the log and cache disks have boot and swap partitions.
What does the gpart show command tell you?
$ gpart show
= 34 63078333 da0 GPT (30G)
34 1281 freebsd-boot (64k)
162 41943042 freebsd-swap (2.0G)
4194466 588839013 freebsd-zfs (28G)
= 34 62499933 da1 GPT (29G)
34 1281 freebsd-boot (64k)
162 41943042 freebsd-swap (2.0G)
4194466 583055013 freebsd-zfs (27G)
=34 1953525101 da2 GPT (931G)
34 222 - free - (111k)
256 19535084951 freebsd-zfs (931G)
1953508751 163849 !6a945a3b-1dd2-11b2-99a6-080020736631 (8.0M)
da3 - da7 are identical to da2.
So maybe it's a little weird that our boot blocks are on our
ZLOG/L2ARC devices, rather than our data devices?
But since gptloader (and the old zfsloader) handle this just fine.
I'll let you know how well I fared.
Thanks!
Due to the limitations of VirtualBox, I had to modify my experiment
slightly. Instead of using 8 virtual drives as I had originally
planned, I had to cut things down to 4 disks and mirrored
configuration rather than raidz2. VirtualBox' BIOS makes only the four
first drives visible to the boot loaders, even on VBox 4.2.16.
I erected GPT on all four drives, all of size 20G. I made da0p1 and
da1p1 into freebsd-boot partitions, both of size 128K, the largest
size currently permitted by the boot loaders. da0p2 and da1p2 was made
into freebsd-swap partitions, each of size 4G. da0p3 and da1p3 became
freebsd-zfs partitions using the remaining free space, 16G. da{2,3}p1
became whole-disk freebsd-zfs partitions.
The pool data was created using this configuration:
zpool create -O checksum=fletcher4 -O mountpoint=legacy -o
cachefile=/tmp/zpool.cache data mirror da2p1 da3p1 log da0p3 cache da1p3
The cache file is probably superfluous by now, but out of old habit I
sticked to it.
The pool was then filled with the ZFS layout I use nowadays:
data/ROOT (legacy)
data/ROOT/20130602-r251259 (inherited)
data/home (/home)
data/tmp (/tmp)
data/usr (inherited)
data/usr/compat (inherited)
data/usr/compat/linux (/usr/compat/linux)
data/usr/local (/usr/local)
data/usr/local/certs (inherited)
data/usr/local/etc (inherited)
data/usr/local/pgsql (inherited)
data/usr/local/www (inherited)
data/usr/obj (/usr/obj)
data/usr/ports (/usr/ports)
data/usr/ports/distfiles (inherited)
data/usr/ports/packages (inherited)
data/usr/ports/workdirs (inherited)
data/usr/src (/usr/src)
data/var (/var)
data/var/backups (inherited)
data/var/crash (inherited)
data/var/db (inherited)
data/var/db/mysql (inherited)
data/var/db/pkg (inherited)
data/var/db/ports (inherited)
data/var/empty (inherited)
data/var/log (inherited)
data/var/mail (inherited)
data/var/named (inherited)
data/var/run (inherited)
data/var/tmp (inherited)
The final mountpoints are shown in brackets, I used temporary
mountpoints rooted at /tmp/zroot during installation from the DVD
image.
Next, I installed 8.4-RELEASE onto data/ROOT/20130602-r251259 and used
the boot blocks from /dist/boot on the DVD, updated the bootfs
property, and rebooted.
I got hold of stable/8, compiled world and kernel, installed this onto
a separate boot environment, data/ROOT/20130801-r253856, a clone of
the previous BE. I updated the boot blocks with pmbr and gptzfsboot
from the new BE, updated the bootfs property, and rebooted. So far, so
good.
Next, I got hold of stable/9, nuked /usr/obj/*, compiled world and
kernel, installed this onto a new BE, data/ROOT/20130801-r253863, a
clone of the preceeding BE, updated the boot blocks from the new BE,
updated the bootfs property, and rebooted. Still worked like a charm.
This experiment could be invalid as I used mirror instead of raidz2,
and because I updated the boot blocks at every step.
I'll try the 8.4-R - 9.2-BETA2 route later this afternoon, and avoid
updating the boot blocks with the ones from 9.2-BETA2. That leaves the
raidz2 configuration unexplored.
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig, | System administrator, |
| Fagskolen Innlandet, | Gjøvik Technical College, Norway, |
| tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, |
| sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00
Re: ZFS: can't read MOS of pool
On Fri, 2 Aug 2013 17:04+0200, ?ukasz W?sikowski wrote: W dniu 2013-07-25 22:23, Trond Endrestøl pisze: Perhaps you should reset the mountpoint property for klawisz, using: zfs set mountpoint=legacy klawisz At the same time you may let klawisz/ROOTFS inherit the mountpoint property from klawisz by running: zfs inherit mountpoint klawisz/ROOTFS Thank you for you reply. I did what you've suggested, now I'm getting: ZFS: i/o error - all block copies unavailable ZFS: can't read object set for dataset u ZFS: can't open root filesystem gptzfsboot: failed to mount default pool klawisz Those KVM VMs are very stubborn with this I won't boot attitude ;) Could there be a bug in the underlying storage system? What filesystem does the VM's virtual harddrives reside on? Could the physical storage media be corrupt? For some reason ZFS expects additional (leaf) vdevs to be present. I've seen similar error messages when an insufficient number of drives were not made visible by the boot firmware, i.e. BIOS. If this VM is important, you should make a snapshot, or make a copy, if you have enough free space. And it might be best to seek advice from someone more versed with the internals of ZFS than I am. :-/ -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Problem with zfsloader on 9.2-BETA2
On Fri, 2 Aug 2013 11:31-0400, J David wrote: On Fri, Aug 2, 2013 at 2:36 AM, Trond Endrestøl trond.endres...@fagskolen.gjovik.no wrote: I'll try the 8.4-R - 9.2-BETA2 route later this afternoon, and avoid updating the boot blocks with the ones from 9.2-BETA2. That leaves the raidz2 configuration unexplored. I figured the easiest way would be to copy the boot blocks from the 8.4-R BE to da0p1 and da1p1, and let the bootfs property remain pointing to the 9.2-BETA2 BE. The 8.4-R stuff showed no problems booting the 9.2-BETA stuff. Thanks for looking into this. Is there anything you can think of that I can do to help establish what is happening on this system? If there is a way to e.g. debug zfsloader to see what exactly it is doing and where it goes awry, I sadly do not know what it is. :( You could put the line verbose_loading=YES in /boot/loader.conf or in /boot/loader.conf.local if zfsloader is lucky enough to read those files. You can get the pool's guid by running: zpool get guid data If you manage to get to zfsloader's OK prompt, you can use the show command and see what zfsloader has gathered so far. If you are lucky, vfs.zfs.boot.primary_pool should be the same value as shown by the zpool get command above. You could also try verbose booting of the kernel. Maybe that can give some clues. Try these suggestions with the currently working/booting system. It would be a good thing to run smartctl on your drives if you haven't already done so. Maybe the S.M.A.R.T. statistics will be helpful. Install sysutils/smartmontools to get smartctl (and smartd). In another thread it was suggested to try zpool scrub from the lastest illumos or nexenta releases. Maybe it's possible to scrub a read-only pool, if only to find out what's wrong. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Problem with zfsloader on 9.2-BETA2
On Wed, 31 Jul 2013 03:49-0400, J David wrote: In order to test ZFS on the upcoming 9.2 release, we upgraded a non-production 8.4 root-on-ZFS fileserver to 9.2-BETA2. The result was a non-bootable system. The first problem was gptzfsboot, but that was our fault? it never got upgraded when we switched to feature flags. So some time with the 8.4 live CD (the 9.x CD's do not boot on this system -- kern/162160 ) solved that. But the system still wouldn't boot, moving on to: ZFS: can't find pool by guid ZFS: can't find pool by guid We got around this by interrupting the stage1 loader and invoking data/root:/boot/zfsloader.old instead. Then we moved the 9.2 zfsloader out of the way and restored the 8.4 loader. So this system only boots with the 9.2 gptzfsboot and the 8.4 zfsloader. To the best of my knowledge, there is nothing broken or out of date with this zpool: $ zpool status pool: data state: ONLINE scan: resilvered 451G in 70h36m with 0 errors on Fri Feb 17 00:26:19 2012 config: NAME STATE READ WRITE CKSUM data ONLINE 0 0 0 raidz2-0ONLINE 0 0 0 da2p1 ONLINE 0 0 0 da3p1 ONLINE 0 0 0 da4p1 ONLINE 0 0 0 da5p1 ONLINE 0 0 0 da6p1 ONLINE 0 0 0 da7p1 ONLINE 0 0 0 logs gpt/slog0 ONLINE 0 0 0 cache gpt/cache1 ONLINE 0 0 0 errors: No known data errors $ zpool upgrade This system supports ZFS pool feature flags. All pools are formatted using feature flags. Every feature flags pool has all supported features enabled. Does anyone know why the 9.2 zfsloader won't load it? Thanks! I'm curious as to why you use da?p1 as the freebsd-zfs partitions. Where does the freebsd-boot partition reside? da?p2? What does the gpart show command tell you? I normally use *p1 for freebsd-boot, *p2 for freebsd-swap and *p3 for freebsd-swap. I know some people who put freebsd-zfs on *p2 and freebsd-swap on *p3. Maybe the partitions are interchangeable after all. As a general rule, I think it's wise to always update the boot blocks whenever you plan to upgrade the pool format or the filesystems. If I have the time later this afternoon, or maybe tomorrow, I will attempt the following on a couple of VMs: 1. Install 8.4-RELEASE with ZFS SPA v28. 2. Upgrade ZFS SPA to v5000. Updating the boot blocks shouldn't be necessary this time. 3. Upgrade by source to 8.4-STABLE and see what happens then. 4. Upgrade by source to 9.2-BETA2, and possibly update the boot blocks using the installed files prior to rebooting, and see what happens then. A second attempt would involve going straight from 8.4-RELEASE to 9.2-BETA2. I'll let you know how well I fared. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS: can't read MOS of pool
On Mon, 22 Jul 2013 18:18+0200, ?ukasz W?sikowski wrote: Hi, I've got a problem with booting zfs-on-root FreeBSD 9.2-PRERELEASE. I'm getting: ZFS: i/o error - all block copies unavailable ZFS: can't read MOS of pool klawisz gptzfsboot: failed to mount default pool klawisz Machine is VM running under KVM on Proxmox 2.3-13. VM has 8 GB of RAM, 400 GB of local storage with SCSI Controller type: Default (lsi). I'm not sure what I did to make this VM unbootable. I've installed 9.2-PRERELEASE, did source based upgrade to r253470, mergemaster, reinstalled bootcode and rebooted. To this point VM was bootable. Then I did installworld from /usr/src to ezjail's basejail (ezjail-admin update -i), did mergemaster for jails, install some ports - none of this should mess with booting. I rebooted VM and got unbootable system. When I boot from liveCD I can import this pool (scrub shows no errors), mount it, chroot to it, and work with it. I just can't get it to boot. Some information about the system: http://pastie.org/private/mtfhkx0wx0vve29xn0plw I've tried to downgrade to r252316 - no luck, system is still unbootable. Any hints how to go from here? I'm only subscribed to freebsd-stable@, but as far as I can tell, no one from freebsd-fs@ nor freebsd-stable@ has yet replied. I'm only replying to freebsd-stable@. First, just some quick questions: Have you by chance upgraded the pool format without upgrading the boot blocks? Or was the pool already at 5000? You didn't mention if you have made any attempt at updating the boot blocks after playing with ezjail-admin. Perhaps you should consider updating the boot blocks once more: 1. Boot from the live CD. 2. Import the pool read-only without mounting any fs: zpool import -f -N -o readonly=on klawisz 3. Mount the root fs read-only: mount -r -t zfs klawisz/ROOTFS /tmp/zroot 4. Update the boot blocks from the files stored in the root fs: gpart bootcode -b /tmp/zroot/boot/pmbr -p /tmp/zroot/boot/gptzfsboot -i 1 ada0 5. Unmount the root fs: umount /tmp/zroot 6. Reboot the system, do NOT export the pool. Hopefully, the updated gptzfsboot stored in ada0p1 will be able to read the MOS. That's all I can think of at the moment. Best of luck. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS: can't read MOS of pool
On Thu, 25 Jul 2013 20:45+0200, ?ukasz W?sikowski wrote: W dniu 2013-07-25 18:40, Trond Endrestøl pisze: Any hints how to go from here? I'm only subscribed to freebsd-stable@, but as far as I can tell, no one from freebsd-fs@ nor freebsd-stable@ has yet replied. I'm only replying to freebsd-stable@. First, just some quick questions: Have you by chance upgraded the pool format without upgrading the boot blocks? Or was the pool already at 5000? You didn't mention if you have made any attempt at updating the boot blocks after playing with ezjail-admin. Perhaps you should consider updating the boot blocks once more: 1. Boot from the live CD. 2. Import the pool read-only without mounting any fs: zpool import -f -N -o readonly=on klawisz 3. Mount the root fs read-only: mount -r -t zfs klawisz/ROOTFS /tmp/zroot 4. Update the boot blocks from the files stored in the root fs: gpart bootcode -b /tmp/zroot/boot/pmbr -p /tmp/zroot/boot/gptzfsboot -i 1 ada0 5. Unmount the root fs: umount /tmp/zroot 6. Reboot the system, do NOT export the pool. Hopefully, the updated gptzfsboot stored in ada0p1 will be able to read the MOS. That's all I can think of at the moment. Best of luck. Thank you for your reply. The pool was created with version 5000. I have updated the boot blocks before (but with exporting pool after). I don't think that ezjail-admin has anything to do with booting. Never ever leave a pool you intend to boot from in the exported state. Period. ;-) At least that was a big no-no when I started using ZFS a couple of years ago. Maybe this has changed since FreeBSD no longer relies on the zpool.cache file. I did as you suggested and it didn't help, still MOS can't be read. I'm pretty sure I can reproduce this problem. I will try to do detailed guide and post it here. Reading through your post once more, http://pastie.org/private/mtfhkx0wx0vve29xn0plw , I noticed the following: 1. The bootfs property is set to klawisz/ROOTFS for the klawisz pool. 2. The mountpoint property is set to / for the klawisz filesystem. 3. The mountpoint property is set to legacy for the klawisz/ROOTFS filesystem. Maybe item 2 is the cause of all this confusion. I see nothing wrong with items 1 and 3. Perhaps you should reset the mountpoint property for klawisz, using: zfs set mountpoint=legacy klawisz At the same time you may let klawisz/ROOTFS inherit the mountpoint property from klawisz by running: zfs inherit mountpoint klawisz/ROOTFS You should also check the mountpoint properties of all the other filesystems you intend to mount automatically. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Incomplete r249912
r249912, MFC r249802, is incomplete. Please fix stable/9/lib/libc/gen/stringlist.c or amend stable/9/include/stringlist.h. The latter is preferred. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Incomplete r249912
On Fri, 26 Apr 2013 08:05-0400, Glen Barber wrote: On Fri, Apr 26, 2013 at 09:15:34AM +0200, Trond Endrestøl wrote: r249912, MFC r249802, is incomplete. Please fix stable/9/lib/libc/gen/stringlist.c or amend stable/9/include/stringlist.h. The latter is preferred. I just fixed this. (Y) ;-) -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: make buildkernel for GENERIC 9-STABLE just hangs, no error
On Wed, 17 Apr 2013 09:10+0200, Olav Grønås Gjerde wrote: I have a weird problem while building the GENERIC 9-STABLE kernel. After around 5 minutes of compile time, the process just hangs on same place. No error. I've tried compiling different commits from this week with the same result. The part in the buildkernel process that hangs is this: MAKE=make sh /usr/src/sys/conf/newvers.sh GENERIC /usr/local/bin/svnversion cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror vers.c ctfconvert -L VERSION -g vers.o linking kernel.debug ctfmerge -L VERSION -g -o kernel.debug + alot of *.o Any suggestions? No trouble compiling world, custom kernel, and GENERIC kernel, as of r249577, running on amd64 stable/9 r248696. Try resynchronizing your source tree, rm -Rf /usr/obj/*, and recompile world and kernel. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Unable to upgrade ZFS pool to feature flags, SPA version 5000, on stable/9 @ r243825
Hi, I installed FreeBSD/amd64 9.1-RELEASE yesterday. I chose to do a manual installation due to the use of ZFS. I checked out stable/9 and recompiled both world and GENERIC kernel. Said kernel and world was installed without any problems. System is still up running, with uname -a revealing r243825. I then decided to upgrade the root pool to feature flags, SPA version 5000, and was not so lucky. # zpool upgrade -a This system supports ZFS pool feature flags. cannot upgrade 'zroot': invalid argument for this pool operation Even the command: zpool upgrade zroot gives the same diagnostic as above. This isn't a critical system at all, but I guess everyone else will run into this snag when attempting to upgrade their ZFS pools. Any clues? -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Unable to upgrade ZFS pool to feature flags, SPA version 5000, on stable/9 @ r243825
On Fri, 18 Jan 2013 09:20+0100, Trond Endrestøl wrote: I then decided to upgrade the root pool to feature flags, SPA version 5000, and was not so lucky. # zpool upgrade -a This system supports ZFS pool feature flags. cannot upgrade 'zroot': invalid argument for this pool operation Pilot error. For some reason I was still running the 9.1-RELEASE kernel. Now the system happily runs 9.1-STABLE @ r245552. Sorry for the noise. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD wiki offline for a bit
On Tue, 8 Jan 2013 09:39+0100, Bas Smeelen wrote: On 01/08/2013 09:32 AM, Alexander Yerenkow wrote: 2013/1/8 Bas Smeelen b.smee...@ose.nl mailto:b.smee...@ose.nl On 01/08/2013 09:08 AM, Alexander Yerenkow wrote: http://wiki.freebsd.org/ZFSTuningGuide Seems not working :) Works here! Hm, could you look at this: ping wiki.freebsd.org http://wiki.freebsd.org PING wfe0.ysv.freebsd.org http://wfe0.ysv.freebsd.org (8.8.178.110) That's strange. When I go to http://wiki.freebsd.org/ZFSTuningGuide it works. But when I go to wiki.freebsd.org I get the same Error 503 It may seem browser cache is playing us some tricks. Opera 12.12 on Windows (yikes) gave me the wiki front page, but as soon as I started clicking on links I haven't touched before, I was presented the 503 page: Error 503 Service Unavailable Service Unavailable Guru Meditation: XID: 931044748 Varnish cache server I launched links on a 9.1-S and directed the browser to http://wiki.freebsd.org/ and was presented with: Error 503 Service Unavailable Service Unavailable Guru Meditation: XID: 931044247 Varnish cache server $ ping wiki.freebsd.org PING wfe0.ysv.freebsd.org (8.8.178.110) 56(84) bytes of data. 64 bytes from wfe0.ysv.FreeBSD.org (8.8.178.110): icmp_req=1 ttl=54 time=160 ms http://wiki.freebsd.org/ZFSTuningGuide Error 503 Service Unavailable Service Unavailable Guru Meditation: XID: 931032464 Varnish cache server -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
