Re: Hook up idmapd to build in 6-stable?
On Fri, Nov 16, 2007 at 08:31:04PM -0500, Adam McDougall wrote: I am beginning to dabble with NFSv4 client functionality. I noticed idmapd is not built in -stable but it has been in -current since src/sbin/Makefile v. 1.163 (13 months ago). Should it be hooked up to the build? Thanks At the time I was looking at it in -current, idmapd worked fine but the client had serious issues (nothing on an NFSv4 mount could be executed, for instance) which I couldn't track down, so I stopped working with it. I think that hooking up idmapd could be a good thing to do in order to expose those problems, but I'm concerned that it may give the impression that our NFSv4 client is any use, which it appears not to be (at least 13 months ago; apologies if this is not longer the case). Ceri -- That must be wonderful! I don't understand it at all. -- Moliere pgp2eUpLZtP8D.pgp Description: PGP signature
Re: (audit?) Panic in 6.2-PRERELEASE
On Fri, Jan 05, 2007 at 11:19:55AM +, Ceri Davies wrote: For the last two mornings, my system decided to panic() in the exact same place. I have dumps from both but they almost exactly the same. Any pointers on where to go next are welcomed. For the record, this turned out to be a thermal issue. Thanks again to Robert for the time he wasted on this. Ceri -- That must be wonderful! I don't understand it at all. -- Moliere pgp9tpYEi9MdH.pgp Description: PGP signature
Re: (audit?) Panic in 6.2-PRERELEASE
On Sun, Jan 07, 2007 at 11:49:56AM +, Robert Watson wrote:
On Sat, 6 Jan 2007, Ceri Davies wrote:
So far it's happened this morning and yesterday morning. I haven't seen
it before that. I don't know the cause so I can't reproduce it at will,
but the logs don't give any indication. Chances are that it will happen
again tomorrow, but we'll see.
Hmm. It looks like you printf *(td-td_proc-p_fd-fd_ofiles) without
the array index. Could you repeat that, but with the array index --
i.e., td-td_proc-p_fd-fd_ofiles[uap-fd]? Also, it would probably be
useful to print uap-fd. Right now you're printing stdin (index 0), but
if the index is non-0, we want a different file.
Very tactfully put :) Sorry about that.
None of the uap-fd's seem to be valid. In the first case, uap-fd is way
too high for the length of fd_ofiles, which only has 21 elements:
(kgdb) up 8
#8 0xc04c470d in fstat (td=0xc2eeb180, uap=0xd610dc74) at
/usr/src/sys/kern/kern_descrip.c:1075
1075error = kern_fstat(td, uap-fd, ub);
(kgdb) p uap-fd
$1 = 89
(kgdb) p *td-td_proc-p_fd-fd_ofiles[uap-fd]
Cannot access memory at address 0x0
In the second, uap-fd is nonsense:
(kgdb) up 8
#8 0xc04c470d in fstat (td=0xc3109300, uap=0xd617ec74) at
/usr/src/sys/kern/kern_descrip.c:1075
1075error = kern_fstat(td, uap-fd, ub);
(kgdb) p uap-fd
$1 = -1023449232
(kgdb)
Hmm. So, I reviewed audit_arg_file() closely, and after staring at the
code a lot, couldn't see anything obvious in either the socket or the
vnode/fifo case. I did fix one other bug there, however, which can never
actually be exercised in 7-CURRENT, and is fairly unlikely in 6-STABLE, and
will MFC that in a week.
OK, thanks.
Could you try printing *td-td_ar? Maybe this will give us a clue as to
how far it got. In particular, this may be able to more reliably give us
the file descriptor number, which is audited early in the system call. You
might find that 'td' is corrupted in many layers of the stack, keep going
up until you find one where it's good. It may well be that
td-td_ar-k_ar.ar_arg_fd is correct, and might confirm that uap-fd is
correct still. We'd like also to know if ARG_SOCKINFO, ARG_VNODE1, or
ARG_VNODE2 is set in the k_ar.ar_valid_arg field. This may tell us some
more about the file descriptor even though it appears to have vanished.
*td-td_ar is null (0x0) in both cases...
I'm quite worried by the fact that the file descriptor seems not to be
present any more -- this suggests a file descriptor related race of the
sort that is both quite difficult to figure out and also quite a risk.
It's strange that it would only trigger with audit, however--perhaps audit
stretches out the race. Is this an SMP box?
It's certainly looking quite nasty. This system is UP hardware without
options SMP.
Could you print the entire contents of *td-td_proc-p_fd?
First case:
(kgdb) p *td-td_proc-p_fd
$2 = {fd_ofiles = 0xc3441000, fd_ofileflags = 0xc3441100 , fd_cdir =
0xc367f110,
fd_rdir = 0xc2ce2bb0, fd_jdir = 0x0, fd_nfiles = 64, fd_map = 0xc3b65970,
fd_lastfile = 20,
fd_freefile = 16, fd_cmask = 63, fd_refcnt = 1, fd_holdcnt = 1, fd_mtx =
{mtx_object = {
lo_class = 0xc06ad4c4, lo_name = 0xc067c0fd filedesc structure,
lo_type = 0xc067c0fd filedesc structure, lo_flags = 196608, lo_list =
{tqe_next = 0x0,
tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 4, mtx_recurse = 0},
fd_locked = 0,
fd_wanted = 0, fd_kqlist = {slh_first = 0x0}, fd_holdleaderscount = 0,
fd_holdleaderswakeup = 0}
Second case:
(kgdb) p *td-td_proc-p_fd
$2 = {fd_ofiles = 0xc2d23600, fd_ofileflags = 0xc2d23700 , fd_cdir =
0xc31b8660,
fd_rdir = 0xc2ce2bb0, fd_jdir = 0x0, fd_nfiles = 64, fd_map = 0xc2e9c1c0,
fd_lastfile = 20,
fd_freefile = 17, fd_cmask = 63, fd_refcnt = 1, fd_holdcnt = 1, fd_mtx =
{mtx_object = {
lo_class = 0xc06ad4c4, lo_name = 0xc067c0fd filedesc structure,
lo_type = 0xc067c0fd filedesc structure, lo_flags = 196608, lo_list =
{tqe_next = 0x0,
tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 4, mtx_recurse = 0},
fd_locked = 0,
fd_wanted = 0, fd_kqlist = {slh_first = 0x0}, fd_holdleaderscount = 0,
fd_holdleaderswakeup = 0}
If it's at all useful, I can provide access to this system and the
dumps.
Ceri
--
That must be wonderful! I don't understand it at all.
-- Moliere
pgpT6fmVvPA4c.pgp
Description: PGP signature
Re: (audit?) Panic in 6.2-PRERELEASE
On Sun, Jan 07, 2007 at 06:05:39PM +, Robert Watson wrote: On Sun, 7 Jan 2007, Ceri Davies wrote: Could you try printing *td-td_ar? Maybe this will give us a clue as to how far it got. In particular, this may be able to more reliably give us the file descriptor number, which is audited early in the system call. You might find that 'td' is corrupted in many layers of the stack, keep going up until you find one where it's good. It may well be that td-td_ar-k_ar.ar_arg_fd is correct, and might confirm that uap-fd is correct still. We'd like also to know if ARG_SOCKINFO, ARG_VNODE1, or ARG_VNODE2 is set in the k_ar.ar_valid_arg field. This may tell us some more about the file descriptor even though it appears to have vanished. *td-td_ar is null (0x0) in both cases... I'm actually beginning to wonder if this is actually audit-related at all. Something is clearly not right, and the audit code should not actually have been entered at all there. Perhaps we're being mislead by the stack trace corruption into thinking audit is involved. I've wondered the same. I'm quite worried by the fact that the file descriptor seems not to be present any more -- this suggests a file descriptor related race of the sort that is both quite difficult to figure out and also quite a risk. It's strange that it would only trigger with audit, however--perhaps audit stretches out the race. Is this an SMP box? It's certainly looking quite nasty. This system is UP hardware without options SMP. ... If it's at all useful, I can provide access to this system and the dumps. Yeah, I think at this point that would probably be the most helpful thing. OK, you should be able to log in as [EMAIL PROTECTED] with your freefall key. Details in ~rwatson/README once you're logged in. Could you confirm that the kernel.debug you're using definitely matches the version of the kernel in the core dump? Yes, definitely. Thanks again, Ceri -- That must be wonderful! I don't understand it at all. -- Moliere pgpySGWT4f6UY.pgp Description: PGP signature
Re: (audit?) Panic in 6.2-PRERELEASE
On Fri, Jan 05, 2007 at 03:08:57PM +, Ceri Davies wrote: How reproduceable is this? So far it's happened this morning and yesterday morning. I haven't seen it before that. I don't know the cause so I can't reproduce it at will, but the logs don't give any indication. Chances are that it will happen again tomorrow, but we'll see. This prediction didn't bear out; no panic today. Ceri -- That must be wonderful! I don't understand it at all. -- Moliere pgpzhBhLF64gr.pgp Description: PGP signature
Re: (audit?) Panic in 6.2-PRERELEASE
On Sat, Jan 06, 2007 at 12:01:51PM +, Robert Watson wrote: On Fri, 5 Jan 2007, Ceri Davies wrote: On Fri, Jan 05, 2007 at 01:34:04PM +, Robert Watson wrote: On Fri, 5 Jan 2007, Ceri Davies wrote: Much as I would love to trust the contents of ub there, I suspect they can't be trusted. Could you print the contents of *fp in kern_fstat() in both of those stacks? I'd particularly like to know the value of fp-f_type, and then depending on the type, possibly the contents of *(struct vnode *)fp-f_vnode for DTYPE_VNODE/TYPE_FIFO or *(struct socket *)fp-f_data in the case of DTYPE_SOCKET. Can you tell me how to get at *fp given that the stack trace shows fstat() and not kern_fstat()? Sorry if I'm being dumb but I don't know how to step into the kern_fstat() call from fstat(). It could be that the stack is hosed losing the frame, or maybe it's inlined (more likely the former I think, as kern_fstat() is a symbol used elsewhere in the kernel). The best bet may be to use the file descriptor number (uap-fd) to pull the struct file reference out of the process. Something on the order of (td-td_proc-p_fd-fd_ofiles[fd]) should return the right struct file *. OK, got it. They're both sockets, data in the attachments. How reproduceable is this? So far it's happened this morning and yesterday morning. I haven't seen it before that. I don't know the cause so I can't reproduce it at will, but the logs don't give any indication. Chances are that it will happen again tomorrow, but we'll see. Hmm. It looks like you printf *(td-td_proc-p_fd-fd_ofiles) without the array index. Could you repeat that, but with the array index -- i.e., td-td_proc-p_fd-fd_ofiles[uap-fd]? Also, it would probably be useful to print uap-fd. Right now you're printing stdin (index 0), but if the index is non-0, we want a different file. Very tactfully put :) Sorry about that. None of the uap-fd's seem to be valid. In the first case, uap-fd is way too high for the length of fd_ofiles, which only has 21 elements: (kgdb) up 8 #8 0xc04c470d in fstat (td=0xc2eeb180, uap=0xd610dc74) at /usr/src/sys/kern/kern_descrip.c:1075 1075error = kern_fstat(td, uap-fd, ub); (kgdb) p uap-fd $1 = 89 (kgdb) p *td-td_proc-p_fd-fd_ofiles[uap-fd] Cannot access memory at address 0x0 In the second, uap-fd is nonsense: (kgdb) up 8 #8 0xc04c470d in fstat (td=0xc3109300, uap=0xd617ec74) at /usr/src/sys/kern/kern_descrip.c:1075 1075error = kern_fstat(td, uap-fd, ub); (kgdb) p uap-fd $1 = -1023449232 (kgdb) Ceri -- That must be wonderful! I don't understand it at all. -- Moliere pgpKdhWFjvPPl.pgp Description: PGP signature
(audit?) Panic in 6.2-PRERELEASE
For the last two mornings, my system decided to panic() in the exact
same place. I have dumps from both but they almost exactly the same.
Any pointers on where to go next are welcomed.
Here's the first, and I don't see much in there:
[EMAIL PROTECTED] # uname -a
FreeBSD shrike.private.submonkey.net 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #69:
Fri Dec 29 00:25:52 GMT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SHRIKE
i386
[EMAIL PROTECTED] # kgdb /usr/obj/usr/src/sys/SHRIKE/kernel.debug
/var/crash/vmcore.29
kgdb: kvm_nlist(_stopped_cpus):
kgdb: kvm_nlist(_stoppcbs):
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd.
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x53892047
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc05cda7c
stack pointer = 0x28:0xd610dc48
frame pointer = 0x28:0xd610dc60
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 65381 (imapd)
trap number = 12
panic: page fault
Uptime: 5d19h44m40s
Dumping 503 MB (2 chunks)
chunk 0: 1MB (160 pages) ... ok
chunk 1: 503MB (128752 pages) 487 471 455 439 423 407 391 375 359 343 327 311
295 279 263 247 231 215 199 183 167 151 135 119 103 87 71 55 39 23 7
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) where
#0 doadump () at pcpu.h:165
#1 0xc04e85aa in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc04e8840 in panic (fmt=0xc066f61a %s) at
/usr/src/sys/kern/kern_shutdown.c:565
#3 0xc0653ed4 in trap_fatal (frame=0xd610dc08, eva=1401495623)
at /usr/src/sys/i386/i386/trap.c:837
#4 0xc0653c3b in trap_pfault (frame=0xd610dc08, usermode=0, eva=1401495623)
at /usr/src/sys/i386/i386/trap.c:745
#5 0xc0653899 in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -1024544384, tf_esi =
-1024544384, tf_ebp = -703538080, tf_isp = -703538124, tf_ebx = 0, tf_edx =
-703538092, tf_ecx = 4, tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip =
-1067656580, tf_cs = 32, tf_eflags = 66050, tf_esp = -1068742797, tf_ss =
-1022955520}) at /usr/src/sys/i386/i386/trap.c:435
#6 0xc064287a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc05cda7c in audit_arg_auditon () at
/usr/src/sys/security/audit/audit_arg.c:586
#8 0xc04c470d in fstat (td=0xc2eeb180, uap=0xd610dc74) at
/usr/src/sys/kern/kern_descrip.c:1075
#9 0xc0654203 in syscall (frame=
{tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = -1077949408, tf_esi =
135666752, tf_ebp = -1077949448, tf_isp = -703537820, tf_ebx = 135432156,
tf_edx = -1077949112, tf_ecx = 135826416, tf_eax = 189, tf_trapno = 0, tf_err =
2, tf_eip = 675755895, tf_cs = 51, tf_eflags = 662, tf_esp = -1077949732, tf_ss
= 59}) at /usr/src/sys/i386/i386/trap.c:983
#10 0xc06428cf in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200
#11 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) up 8
#8 0xc04c470d in fstat (td=0xc2eeb180, uap=0xd610dc74) at
/usr/src/sys/kern/kern_descrip.c:1075
1075error = kern_fstat(td, uap-fd, ub);
(kgdb) p ub
$1 = {st_dev = 89, st_ino = 1907905, st_mode = 33152, st_nlink = 1, st_uid =
60, st_gid = 60,
st_rdev = 7624272, st_atimespec = {tv_sec = 1167893059, tv_nsec =
-703537996}, st_mtimespec = {
tv_sec = -703537916, tv_nsec = -1024544384}, st_ctimespec = {tv_sec =
43018, tv_nsec = 43018},
st_size = -3021672509244264064, st_blocks = -1067658896, st_blksize = 43018,
st_flags = 4,
st_gen = 3, st_lspare = 0, st_birthtimespec = {tv_sec = -1, tv_nsec = 4}}
(kgdb) p td
$2 = (struct thread *) 0xc2eeb180
(kgdb) p uap-fd
$3 = 89
(kgdb)
The second one seems more promising, in that the fd seems to be rubbish.
[EMAIL PROTECTED] # kgdb /usr/obj/usr/src/sys/SHRIKE/kernel.debug
/var/crash/vmcore.30
kgdb: kvm_nlist(_stopped_cpus):
kgdb: kvm_nlist(_stoppcbs):
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for
Re: (audit?) Panic in 6.2-PRERELEASE
On Fri, Jan 05, 2007 at 12:13:30PM +, Robert Watson wrote: On Fri, 5 Jan 2007, Ceri Davies wrote: For the last two mornings, my system decided to panic() in the exact same place. I have dumps from both but they almost exactly the same. Any pointers on where to go next are welcomed. Here's the first, and I don't see much in there: In principle, kern_fstat() should not call audit_arg_auditon(), so either we're looking at a compile problem or at stack corruption. Am I correct in thinking that this is running on a cyrus server? Correct. Much as I would love to trust the contents of ub there, I suspect they can't be trusted. Could you print the contents of *fp in kern_fstat() in both of those stacks? I'd particularly like to know the value of fp-f_type, and then depending on the type, possibly the contents of *(struct vnode *)fp-f_vnode for DTYPE_VNODE/TYPE_FIFO or *(struct socket *)fp-f_data in the case of DTYPE_SOCKET. Can you tell me how to get at *fp given that the stack trace shows fstat() and not kern_fstat()? Sorry if I'm being dumb but I don't know how to step into the kern_fstat() call from fstat(). #7 0xc05cda7c in audit_arg_auditon () at /usr/src/sys/security/audit/audit_arg.c:586 #8 0xc04c470d in fstat (td=0xc2eeb180, uap=0xd610dc74) at /usr/src/sys/kern/kern_descrip.c:1075 Ceri -- That must be wonderful! I don't understand it at all. -- Moliere pgpoggq1rx9YM.pgp Description: PGP signature
Re: (audit?) Panic in 6.2-PRERELEASE
On Fri, Jan 05, 2007 at 01:34:04PM +, Robert Watson wrote:
On Fri, 5 Jan 2007, Ceri Davies wrote:
Much as I would love to trust the contents of ub there, I suspect they
can't be trusted. Could you print the contents of *fp in kern_fstat() in
both of those stacks? I'd particularly like to know the value of
fp-f_type, and then depending on the type, possibly the contents of
*(struct vnode *)fp-f_vnode for DTYPE_VNODE/TYPE_FIFO or *(struct socket
*)fp-f_data in the case of DTYPE_SOCKET.
Can you tell me how to get at *fp given that the stack trace shows fstat()
and not kern_fstat()? Sorry if I'm being dumb but I don't know how to
step into the kern_fstat() call from fstat().
It could be that the stack is hosed losing the frame, or maybe it's inlined
(more likely the former I think, as kern_fstat() is a symbol used elsewhere
in the kernel). The best bet may be to use the file descriptor number
(uap-fd) to pull the struct file reference out of the process. Something
on the order of (td-td_proc-p_fd-fd_ofiles[fd]) should return the right
struct file *.
OK, got it. They're both sockets, data in the attachments.
How reproduceable is this?
So far it's happened this morning and yesterday morning. I haven't seen
it before that. I don't know the cause so I can't reproduce it at will,
but the logs don't give any indication. Chances are that it will happen
again tomorrow, but we'll see.
Thanks,
Ceri
--
That must be wonderful! I don't understand it at all.
-- Moliere
[EMAIL PROTECTED] # kgdb /usr/obj/usr/src/sys/SHRIKE/kernel.debug
/var/crash/vmcore.29
kgdb: kvm_nlist(_stopped_cpus):
kgdb: kvm_nlist(_stoppcbs):
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd.
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x53892047
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc05cda7c
stack pointer = 0x28:0xd610dc48
frame pointer = 0x28:0xd610dc60
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 65381 (imapd)
trap number = 12
panic: page fault
Uptime: 5d19h44m40s
Dumping 503 MB (2 chunks)
chunk 0: 1MB (160 pages) ... ok
chunk 1: 503MB (128752 pages) 487 471 455 439 423 407 391 375 359 343 327 311
295 279 263 247 231 215 199 183 167 151 135 119 103 87 71 55 39 23 7
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) up 8
#8 0xc04c470d in fstat (td=0xc2eeb180, uap=0xd610dc74) at
/usr/src/sys/kern/kern_descrip.c:1075
1075error = kern_fstat(td, uap-fd, ub);
(kgdb) p *td-td_proc-p_fd-fd_ofiles
$1 = (struct file *) 0xc32f73f0
(kgdb) p*$1
$2 = {f_list = {le_next = 0xc32ddd38, le_prev = 0xc4062048}, f_type = 2, f_data
= 0xc38f62c8,
f_flag = 3, f_mtxp = 0xc2a67154, f_ops = 0xc06b1040, f_cred = 0xc2e4a580,
f_count = 3,
f_vnode = 0x0, f_offset = 0, f_vnread_flags = 0, f_gcflag = 0, f_msgcount =
0, f_seqcount = 0,
f_nextoff = 0, f_label = 0x0}
(kgdb) p $2-f_data
$3 = (void *) 0xc38f62c8
(kgdb) p *(struct socket *)$2-f_data
$4 = {so_count = 1, so_type = 1, so_options = 4, so_linger = 0, so_state = 2,
so_qstate = 0,
so_pcb = 0xc38eaec4, so_proto = 0xc06b8148, so_head = 0x0, so_incomp =
{tqh_first = 0x0,
tqh_last = 0x0}, so_comp = {tqh_first = 0x0, tqh_last = 0x0}, so_list =
{tqe_next = 0x0,
tqe_prev = 0xc2e5087c}, so_qlen = 0, so_incqlen = 0, so_qlimit = 0,
so_timeo = 0,
so_error = 0, so_sigio = 0x0, so_oobmark = 0, so_aiojobq = {tqh_first = 0x0,
tqh_last = 0xc38f6310}, so_rcv = {sb_sel = {si_thrlist = {tqe_next = 0x0,
tqe_prev = 0xc2eeb1b0}, si_thread = 0x0, si_note = {kl_list =
{slh_first = 0x0},
kl_lock = 0xc04cd13c knlist_mtx_lock, kl_unlock = 0xc04cd170
knlist_mtx_unlock,
kl_locked = 0xc04cd1ac knlist_mtx_locked, kl_lockarg = 0xc38f633c},
si_flags = 0},
sb_mtx = {mtx_object = {lo_class = 0xc06ad4c4, lo_name = 0xc068133e
so_rcv,
lo_type = 0xc068133e so_rcv, lo_flags = 196608, lo_list = {tqe_next =
0x0,
tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 4, mtx_recurse = 0},
sb_state = 0,
sb_mb = 0x0, sb_mbtail = 0x0, sb_lastrecord = 0x0, sb_cc = 0, sb_hiwat =
66608, sb_mbcnt = 0,
sb_mbmax = 262144, sb_ctl = 0, sb_lowat = 1
Re: cvs commit: doc/en_US.ISO8859-1/books/handbook/serialcomms chapter.sgml
[ Forwarded from cvs-doc ] On Wed, Aug 23, 2006 at 11:37:19PM +, Giorgos Keramidas wrote: keramida2006-08-23 23:37:19 UTC FreeBSD doc repository Modified files: en_US.ISO8859-1/books/handbook/serialcomms chapter.sgml Log: Expand the section `Setting a Faster Serial Port Speed', to mention ways to set the serial console speed without having to rebuild the boot blocks. Note that for releases before 6.1, though, rebuilding the boot blocks may be the only option. On a related note, is the keyboard multiplexer now good enough for us to ship a /boot.config containing '-P' on the installation images? Ceri -- That must be wonderful! I don't understand it at all. -- Moliere pgppS787Bc0bU.pgp Description: PGP signature
Re: cvs commit: doc/en_US.ISO8859-1/books/handbook/serialcomms chapter.sgml
On Thu, Aug 24, 2006 at 03:20:47PM -0400, John Baldwin wrote: On Thursday 24 August 2006 05:18, Ceri Davies wrote: [ Forwarded from cvs-doc ] On Wed, Aug 23, 2006 at 11:37:19PM +, Giorgos Keramidas wrote: keramida2006-08-23 23:37:19 UTC FreeBSD doc repository Modified files: en_US.ISO8859-1/books/handbook/serialcomms chapter.sgml Log: Expand the section `Setting a Faster Serial Port Speed', to mention ways to set the serial console speed without having to rebuild the boot blocks. Note that for releases before 6.1, though, rebuilding the boot blocks may be the only option. On a related note, is the keyboard multiplexer now good enough for us to ship a /boot.config containing '-P' on the installation images? That's unrelated. -P only does a very simple check to see if a keyboard is present. Many systems with only USB keyboards would fail the check and end up sending their output to the serial console. OK, I had thought that kdbmux would help here. Never mind. We could use -D though, that would let the user break into the loader and adjust console (or use boot -h) to force sysinstall to use the serial console. That smells new, or at least I have never noticed it before! It would help me quiet some people who have complained about having to build custom images to allow a serial installation by the sound of it, though. Ceri -- That must be wonderful! I don't understand it at all. -- Moliere pgpjipoOd6TXY.pgp Description: PGP signature
Re: NSSWITCH errors in /var/log/cron
On 12 Feb 2006, at 00:31, Brandon Fosdick wrote: I have several machines running 6-STABLE that are showing the error listed below in /var/log/cron every few minutes. Google didn't turn up much of relevance, other than the fact that this might be related to disabling NIS. And, in fast, I have NO_NIS=true in /etc/ make.conf on every single box. Is this a bug or a feature? Is it harmful? The error messages are... Feb 11 16:25:00 poseidon /usr/sbin/cron[95789]: (root) CMD (/usr/ libexec/atrun) Feb 11 16:25:00 poseidon cron[95789]: NSSWITCH(nss_method_lookup): nis, group_compat, setgrent, not found Feb 11 16:25:00 poseidon cron[95789]: NSSWITCH(nss_method_lookup): nis, group_compat, endgrent, not found Feb 11 16:25:00 poseidon cron[95789]: NSSWITCH(nss_method_lookup): nis, passwd_compat, endpwent, not found What does your nsswitch.conf look like, and does removing the NIS entries fix it? Ceri -- That must be wonderful! I don't understand it at all. -- Moliere PGP.sig Description: This is a digitally signed message part
Re: Fast releases demand binary updates..
I don't want to get embroiled in this conversation, but I am concerned about the use of GNATS illustrated here. On 12 Jan 2006, at 07:34, Jo Rhett wrote: On Sat, Jan 07, 2006 at 01:05:13PM +0100, Dag-Erling Sm?rgrav wrote: ports/76013 - patch committed after four months ports/76019 - superceded after a month One was committed, the other superceded. The first change only works if the latter is commited. Thus, the port remains broken and we keep using localized patches to fix it. Where does it say that in the PR? The 'superceding port' is a different apache module that has different limitations. There is no reason not to commit the latter and fix this particular port, but I can't convince anyone to do that. I don't know that you tried. Why didn't you followup to the PR and ask for it to be reopened, or point out that there was a problem? ports/76724 - patch committed after a week docs/87445 - immediately adopted by a committer, being worked on I received no e-mail notification of either. My posts about said bugs to the appropriate mailing lists garnered no responses other than put in GNATS We don't have mail logs back that far, so I can't see where that went wrong, but GNATS always send the submitter mail on a state change. You could always have looked at the PR. Oh, how we have wronged you! Please let us know how we may correct this grievous injustice! Nice sarcasm. Doesn't change that these were ignored, Except that we have shown that they were not, of course. Ceri PGP.sig Description: This is a digitally signed message part
Re: /boot/nextboot.conf not deactivated after one boot
On Sat, Jan 07, 2006 at 01:35:34AM +0100, Marius Nuennerich wrote: On Fri, 6 Jan 2006 15:14:41 + Ceri Davies [EMAIL PROTECTED] wrote: On Thu, Jan 05, 2006 at 01:41:33PM +0100, Marius Nuennerich wrote: Hi folks, it seems like /boot/nextboot.conf is neither deleted nor nextboot_enable set to NO on the first line after a reboot. So it isn't a one shot anymore as the manpage claims. System is 6.0-RELEASE. I think this is down to a typo in /etc/rc.d/root; at least I can't find any other reference to /boot/nextkernel in src/. Patch attached (root.diff). It would also be fine imo, if the -k option would be optional and the next kernel defaults to kernel. I'm not sure if getopts can be persuaded to take an optional argument to an option. If not, the attached patch (nextboot.diff) should work for you. I tested both patches and they work as they should. Please commit :) OK, awaiting mentor approval. Thanks for the report and for testing. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgppkpxlK8yDz.pgp Description: PGP signature
Re: rpcbind lingering on IP no longer specified on command line
On Wed, Jan 04, 2006 at 10:46:06PM +0300, Dmitry Morozovsky wrote:
On Wed, 4 Jan 2006, Vivek Khera wrote:
VK I had rpcbind running with on two interfaces like this:
VK
VK rpcbind -h 192.168.100.200 -h 10.0.0.9
VK
VK Now, I changed rpcbind_flags in /etc/rc.conf to just have the first
address,
VK and I restarted rpcbind. the process list from ps shows it is running
like
VK this:
VK
VK rpcbind -h 192.168.100.200
VK
VK Yet nmap on the other address shows rpcbind is still listening on udp
there.
VK How do I stop that?
As I sometimes looked into this, rpcbind (formely portmap) listens on all
described addresses via udp *and* an tcp:*.111 - I tried to dig why is this
but
did not succeed much.
Please test this patch. It's probably a very naive fix, but seems to
work OK.
Ceri
--
Only two things are infinite, the universe and human stupidity, and I'm
not sure about the former.-- Einstein (attrib.)
Index: rpcbind.8
===
RCS file: /usr/home/ncvs/src/usr.sbin/rpcbind/rpcbind.8,v
retrieving revision 1.7
diff -u -r1.7 rpcbind.8
--- rpcbind.8 18 Jan 2005 20:02:43 - 1.7
+++ rpcbind.8 6 Jan 2006 10:35:02 -
@@ -83,7 +83,7 @@
With this option, the name-to-address translation consistency
checks are shown in detail.
.It Fl h Ar bindip
-Specify specific IP addresses to bind to for UDP requests.
+Specify specific IP addresses to bind to.
This option
may be specified multiple times and is typically necessary when running
on a multi-homed host.
@@ -95,14 +95,14 @@
.Dv INADDR_ANY ,
which could lead to problems on a multi-homed host due to
.Nm
-returning a UDP packet from a different IP address than it was
+returning a packet from a different IP address than it was
sent to.
Note that when specifying IP addresses with
.Fl h ,
.Nm
will automatically add
.Li 127.0.0.1
-and if IPv6 is enabled,
+and, if IPv6 is enabled,
.Li ::1
to the list.
.It Fl i
Index: rpcbind.c
===
RCS file: /usr/home/ncvs/src/usr.sbin/rpcbind/rpcbind.c,v
retrieving revision 1.14
diff -u -r1.14 rpcbind.c
--- rpcbind.c 7 Nov 2004 04:32:51 - 1.14
+++ rpcbind.c 6 Jan 2006 10:28:10 -
@@ -209,11 +209,11 @@
struct passwd *p;
if((p = getpwnam(RUN_AS)) == NULL) {
- syslog(LOG_ERR, cannot get uid of daemon: %m);
+ syslog(LOG_ERR, cannot get uid of %s: %m, RUN_AS);
exit(1);
}
if (setuid(p-pw_uid) == -1) {
- syslog(LOG_ERR, setuid to daemon failed: %m);
+ syslog(LOG_ERR, setuid to %s failed: %m, RUN_AS);
exit(1);
}
}
@@ -272,7 +272,8 @@
* XXX - using RPC library internal functions. For NC_TPI_CLTS
* we call this later, for each socket we like to bind.
*/
- if (nconf-nc_semantics != NC_TPI_CLTS) {
+ if (nconf-nc_semantics != NC_TPI_CLTS
+ nconf-nc_semantics != NC_TPI_COTS_ORD) {
if ((fd = __rpc_nconf2fd(nconf)) 0) {
int non_fatal = 0;
@@ -308,7 +309,8 @@
hints.ai_socktype = si.si_socktype;
hints.ai_protocol = si.si_proto;
}
- if (nconf-nc_semantics == NC_TPI_CLTS) {
+ if (nconf-nc_semantics == NC_TPI_CLTS ||
+ nconf-nc_semantics == NC_TPI_COTS_ORD) {
/*
* If no hosts were specified, just bind to INADDR_ANY.
Otherwise
* make sure 127.0.0.1 is added to the list.
@@ -348,7 +350,7 @@
hints.ai_flags = AI_NUMERICHOST;
} else {
/*
-* Skip if we have an AF_INET6 adress.
+* Skip if we have an AF_INET6 address.
*/
if (inet_pton(AF_INET6,
hosts[nhostsbak], host_addr) == 1)
@@ -361,7 +363,7 @@
hints.ai_flags = AI_NUMERICHOST;
} else {
/*
-* Skip if we have an AF_INET adress.
+* Skip if we have an AF_INET address.
*/
if (inet_pton(AF_INET, hosts[nhostsbak],
host_addr) == 1)
pgpcOPKf0MNey.pgp
Description: PGP signature
Re: /boot/nextboot.conf not deactivated after one boot
On Thu, Jan 05, 2006 at 01:41:33PM +0100, Marius Nuennerich wrote:
Hi folks,
it seems like /boot/nextboot.conf is neither deleted nor
nextboot_enable set to NO on the first line after a reboot.
So it isn't a one shot anymore as the manpage claims.
System is 6.0-RELEASE.
I think this is down to a typo in /etc/rc.d/root; at least I can't find
any other reference to /boot/nextkernel in src/. Patch attached
(root.diff).
It would also be fine imo, if the -k option would be optional and the
next kernel defaults to kernel.
I'm not sure if getopts can be persuaded to take an optional argument to
an option. If not, the attached patch (nextboot.diff) should work for
you.
Ceri
--
Only two things are infinite, the universe and human stupidity, and I'm
not sure about the former.-- Einstein (attrib.)
Index: etc/rc.d/root
===
RCS file: /home/ncvs/src/etc/rc.d/root,v
retrieving revision 1.11
diff -u -r1.11 root
--- etc/rc.d/root 2 Dec 2005 21:33:43 - 1.11
+++ etc/rc.d/root 6 Jan 2006 14:37:51 -
@@ -34,8 +34,8 @@
# If we booted a special kernel remove the record
# so we will boot the default kernel next time.
- if [ -e /boot/nextkernel ]; then
- rm -f /boot/nextkernel
+ if [ -e /boot/nextboot.conf ]; then
+ rm -f /boot/nextboot.conf
fi
}
Index: sbin/reboot/nextboot.8
===
RCS file: /home/ncvs/src/sbin/reboot/nextboot.8,v
retrieving revision 1.4
diff -u -r1.4 nextboot.8
--- sbin/reboot/nextboot.8 12 Dec 2002 17:25:56 - 1.4
+++ sbin/reboot/nextboot.8 6 Jan 2006 15:13:24 -
@@ -24,7 +24,7 @@
.\
.\ $FreeBSD: src/sbin/reboot/nextboot.8,v 1.4 2002/12/12 17:25:56 ru Exp $
.\
-.Dd November 4, 2002
+.Dd January 6, 2006
.Dt NEXTBOOT 8
.Os
.Sh NAME
@@ -33,8 +33,8 @@
.Sh SYNOPSIS
.Nm
.Op Fl f
+.Op Fl k Ar kernel
.Op Fl o Ar options
-.Fl k Ar kernel
.Nm
.Fl D
.Sh DESCRIPTION
@@ -68,6 +68,8 @@
This option specifies a kernel directory relative to
.Pa /boot
to load the kernel and any modules from.
+If this option is not provided, defaults to
+.Dq Li kernel .
.It Fl o Ar options
This option
allows the passing of kernel flags for the next boot.
@@ -90,7 +92,7 @@
.Pp
To enable into single user mode with the normal kernel:
.Pp
-.Dl nextboot -o -s -k kernel
+.Dl nextboot -o -s
.Pp
To remove an existing nextboot configuration:
.Pp
Index: sbin/reboot/nextboot.sh
===
RCS file: /home/ncvs/src/sbin/reboot/nextboot.sh,v
retrieving revision 1.1
diff -u -r1.1 nextboot.sh
--- sbin/reboot/nextboot.sh 24 May 2002 04:06:03 - 1.1
+++ sbin/reboot/nextboot.sh 6 Jan 2006 15:13:24 -
@@ -10,10 +10,12 @@
nextboot_file=/boot/nextboot.conf
display_usage() {
- echo Usage: nextboot [-f] [-o options] -k kernel
+ echo Usage: nextboot [-f] [-k kernel] [-o options]
echonextboot -D
}
+kernel=kernel
+
while getopts Dfk:o: argument ; do
case ${argument} in
D)
@@ -40,11 +42,6 @@
exit 0
fi
-if [ xxx${kernel} = xxx ]; then
- display_usage
- exit 1
-fi
-
if [ ${force} = NO -a ! -d /boot/${kernel} ]; then
echo Error: /boot/${kernel} doesn't exist. Use -f to override.
exit 1
pgp042fBvaYVV.pgp
Description: PGP signature
Re: rpcbind lingering on IP no longer specified on command line
On Fri, Jan 06, 2006 at 05:35:28PM +0300, Dmitry Morozovsky wrote: On Fri, 6 Jan 2006, Ceri Davies wrote: CD VK I had rpcbind running with on two interfaces like this: CD VK CD VK rpcbind -h 192.168.100.200 -h 10.0.0.9 CD VK CD VK Now, I changed rpcbind_flags in /etc/rc.conf to just have the first address, CD VK and I restarted rpcbind. the process list from ps shows it is running like CD VK this: CD VK CD VK rpcbind -h 192.168.100.200 CD VK CD VK Yet nmap on the other address shows rpcbind is still listening on udp there. CD VK How do I stop that? CD CD As I sometimes looked into this, rpcbind (formely portmap) listens on all CD described addresses via udp *and* an tcp:*.111 - I tried to dig why is this but CD did not succeed much. CD CD Please test this patch. It's probably a very naive fix, but seems to CD work OK. Well, two objections: - (obvious and dumb ;): three kinds of changes inside: behaviour, style and typo ;-))) Well yeah, but I figured that didn't matter for now. I disagree that the RUN_AS stuff is style though; the previous hardcoded daemon completely takes away the point of the '#define RUN_AS daemon'. If you are referring to my indentation, again that's just a keep the patch simple thing. Anyway... - serious: no way to run on NO_INET6 kernel: [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# pid rpc 83231 ?? Ss 0:00.00 /usr/obj/ar/src.6/usr.sbin/rpcbind/rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# killall rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# pid rpc [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# rpcinfo -p program vers proto port service 104 tcp111 rpcbind 103 tcp111 rpcbind 102 tcp111 rpcbind 104 udp111 rpcbind 103 udp111 rpcbind 102 udp111 rpcbind 104 local111 rpcbind 103 local111 rpcbind 102 local111 rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# killall rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# /usr/obj/ar/src.6/usr.sbin/rpcbind/rpcbind [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# rpcinfo -p rpcinfo: can't contact portmapper: RPC: Port mapper failure - RPC: Success [EMAIL PROTECTED]:/usr/src/usr.sbin/rpcbind# sockstat -4 | grep rpc root rpcbind83332 7 udp4 *:111 *:* root rpcbind83332 8 udp4 *:608 *:* root rpcbind83332 9 tcp4 *:111 *:* That's more annoying. It's not INET6 though; it's because the local transport is also tpi_cots_ord, so /var/run/rpcbind.sock is not getting created. I'll take another go at this over the weekend. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpXkG0Mwshuf.pgp Description: PGP signature
Panics on BETA5
I can reliably panic a fresh install of 6.0-BETA5 on my laptop by
installing the src set from CDROM with sh install.sh all. To be
honest, I believe that the drive on this laptop is on its way out,
but I'm no expert.
Backtraces attached; let me know what else is required.
Ceri
--
Only two things are infinite, the universe and human stupidity, and I'm
not sure about the former.-- Einstein (attrib.)
Script started on Wed Sep 21 20:05:42 2005
# uname -a
FreeBSD 6.0-BETA5 FreeBSD 6.0-BETA5 #0: Mon Sep 19 00:12:45 UTC 2005
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386
# kgdb /boot/kernel/kernel.debug /var/crash/vmcore.0
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd.
Unread portion of the kernel message buffer:
panic: vm_fault: fault on nofault entry, addr: c8c2a000
Uptime: 15m46s
Dumping 190 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 190MB (48624 pages) 174 158 142 126 110 94 78 62 46 30 14
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc0634fe0 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399
#2 0xc0635274 in panic (
fmt=0xc08756e3 vm_fault: fault on nofault entry, addr: %lx)
at /usr/src/sys/kern/kern_shutdown.c:555
#3 0xc0797be4 in vm_fault (map=0xc1043000, vaddr=3368198144,
fault_type=2 '\002', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:277
#4 0xc080196f in trap_pfault (frame=0xca627c44, usermode=0, eva=3368200192)
at /usr/src/sys/i386/i386/trap.c:741
#5 0xc0801605 in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -926767104, tf_esi =
-1051993600, tf_ebp = -899515228, tf_isp = -899515280, tf_ebx = -1051183152,
tf_edx = 368, tf_ecx = 512, tf_eax = -926767104, tf_trapno = 12, tf_err = 2,
tf_eip = -1068704226, tf_cs = 32, tf_eflags = 66050, tf_esp = -1052863744,
tf_ss = 368})
at /usr/src/sys/i386/i386/trap.c:442
#6 0xc07f0eba in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc04cde1e in ata_pio_read (request=0xc15837d0, length=2048)
at cpufunc.h:238
#8 0xc04cca88 in ata_end_transaction (request=0xc15837d0)
at /usr/src/sys/dev/ata/ata-lowlevel.c:396
#9 0xc04bc7eb in ata_interrupt (data=0xc14bda00)
at /usr/src/sys/dev/ata/ata-all.c:323
#10 0xc062100d in ithread_loop (arg=0xc13e4500)
at /usr/src/sys/kern/kern_intr.c:545
---Type return to continue, or q return to quit---
#11 0xc06202c0 in fork_exit (callout=0xc0620ec8 ithread_loop,
arg=0xc13e4500, frame=0xca627d38) at /usr/src/sys/kern/kern_fork.c:789
#12 0xc07f0f1c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208
(kgdb) #
#
# kgdb /boot/kernel/kernel.debug /var/crash/vmcore.1
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd.
Unread portion of the kernel message buffer:
panic: vm_fault: fault on nofault entry, addr: c874a000
Uptime: 4m57s
Dumping 190 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 190MB (48624 pages) 174 158 142 126 110 94 78 62 46 30 14
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb)
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc0634fe0 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399
#2 0xc0635274 in panic (
fmt=0xc08756e3 vm_fault: fault on nofault entry, addr: %lx)
at /usr/src/sys/kern/kern_shutdown.c:555
#3 0xc0797be4 in vm_fault (map=0xc1043000, vaddr=3363086336,
fault_type=2 '\002', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:277
#4 0xc080196f in trap_pfault (frame=0xca627c44, usermode=0, eva=3363088384)
at /usr/src/sys/i386/i386/trap.c:741
#5 0xc0801605 in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -931878912, tf_esi =
-1051993600, tf_ebp = -899515228, tf_isp = -899515280, tf_ebx = -1039338320,
tf_edx = 368, tf_ecx = 512, tf_eax = -931878912, tf_trapno = 12, tf_err = 2,
tf_eip = -1068704226, tf_cs = 32, tf_eflags = 66050, tf_esp = -1052863744,
tf_ss = 368})
at /usr/src/sys/i386/i386/trap.c:442
#6 0xc07f0eba in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7
Re: xf86enableIO error (Feb 2005 Snapshots for FreeBSD available)
On Wed, Feb 16, 2005 at 04:41:14PM +0900, Eitarou Kamo wrote: I got an io error xf86EnableIO: Fatal to open /dev/io for extended I/O when running Xorg -configure. Has this snapshot been fixed this problem? Do you have a /dev/io? Do you have device io in your kernel configuration? Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpSn8yTAmhnB.pgp Description: PGP signature
Re: fsck: broken file system with background check remains broken after bootup
On Tue, Jan 04, 2005 at 08:25:20PM +0900, Rob wrote: An automatic fsck could have fixed the system (I eventually did it manually in single user mode), but the background check left the system broken. So I want to configure 5.3 similar to former 4.10: a full automatic fix of all filesystems at bootup, in case the system was not properly shutdown. How can I do that? Turn off background_fsck. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpTKNUJOmsuS.pgp Description: PGP signature
Re: dump/restore with ufs2
On Thu, Dec 30, 2004 at 09:53:38PM +0100, Roland Smith wrote: On Thu, Dec 30, 2004 at 05:54:25PM +, Ceri Davies wrote: On Tue, Dec 28, 2004 at 01:23:50PM -0500, Brian Szymanski wrote: When I run the following script, I get a warning message, and I'm wondering if it's ignorable or indicates there is a little more work to be done in getting dump/restore happy with ufs2... $ cd /altroot $ dump -L -0 -a -f - /dev/$ROOT | restore -rf - ... warning: ./.snap: File exists Does this mean my snapshots are being overwritten on the target disk? And if so, that's a good thing, right? That's just a warning that .snap already exists in the current directory (which is because it gets created by newfs); the contents will remain unaffected since snapshots are not dumped (I believe). A snapshot _is_ what is being dumped when you use the -L option to dump. See the manual page. I know that. I meant that snapshots are not included in the dump. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpzWBJRtlcXu.pgp Description: PGP signature
Re: dump/restore with ufs2
On Tue, Dec 28, 2004 at 01:23:50PM -0500, Brian Szymanski wrote: When I run the following script, I get a warning message, and I'm wondering if it's ignorable or indicates there is a little more work to be done in getting dump/restore happy with ufs2... $ cd /altroot $ dump -L -0 -a -f - /dev/$ROOT | restore -rf - ... warning: ./.snap: File exists Does this mean my snapshots are being overwritten on the target disk? And if so, that's a good thing, right? That's just a warning that .snap already exists in the current directory (which is because it gets created by newfs); the contents will remain unaffected since snapshots are not dumped (I believe). Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpTWRsW6BDcy.pgp Description: PGP signature
Re: [PATCH] (was: hushlogin attribute)
On Sun, Dec 12, 2004 at 02:21:23PM -0800, Rostislav Krasny wrote: The attached patch of login(1) allows hushlogin and nocheckmail attributes to work from the user's '.login_conf' as well as from the '/etc/login.conf'. It would be a good idea to send-pr this. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpiiquTROFSw.pgp Description: PGP signature
Re: ULE scheduler broken and not documented
On Wed, Dec 08, 2004 at 10:21:02PM +, Nuno Teixeira wrote: Hello to all, I'm runinng RELENG_5 and I noticed that ULE scheduler is broken. Shouldn't this be documented in UPDATING? Yes. I thought it was, but you are correct in asserting that it isn't. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgp4V2nNOidQ9.pgp Description: PGP signature
Re: 4.x can't read 5.x dump?
On Wed, Dec 01, 2004 at 09:40:53PM -0500, Ken Smith wrote: On Thu, Dec 02, 2004 at 10:48:43AM +1000, Joel Hatton wrote: I'm backing up a 5.x machine at the moment with this command: dump -0Lau -b128 -f - /var | gzip -2 | ssh FreeBSD4 dd of=aacd0s1f.gz After the dump finishes, I try to read the file on the 4.x destination: # gzip -dc aacd0s1a.gz | restore -ivf - Verify tape and initialize maps Tape is not a dump tape I can scp the file back to the 5.x machine and it loads just fine, so what gives? This type of failure is somewhat scary for me right now, given that I may have to restore files to another destination that may not be 5.x based. This is, unfortunately, something that you should not expect to work for any *nix variant. The dump mechanism of creating backups creates output that has intimate knowledge of the filesystem so that it can recreate that filesystem exactly as it exists on the disk. As the filesystem itself evolves (has features added to it) the dump programs need to have their data structures change to accomodate the extra information that is now needed. For example if in 4.X there were no ACLs but 5.X added ACLs then the dump program's data structures would need to be changed so it had the ability to store the ACL information in the output, and the restore program would need to be modified to look for that and do the right thing if it finds ACL information. If there had been no filesystem changes between 4.X and 5.X then there would not be any need to change dump, and what you are trying to do would work. But there were filesystem changes between 4.X and 5.X, so dump was changed, and now there is extra stuff in the dump images that the 4.X version of restore doesn't understand. This same general principle holds for all OS's, not just FreeBSD. Should I expect a dump taken from 4.X to be restorable on 5.X though? (I do). Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpktWmj3aUyv.pgp Description: PGP signature
Re: 4.x can't read 5.x dump?
On Fri, Dec 03, 2004 at 09:27:07AM -0500, Ken Smith wrote: On Fri, Dec 03, 2004 at 02:24:15PM +, Ceri Davies wrote: Should I expect a dump taken from 4.X to be restorable on 5.X though? (I do). Yes. Phew. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpAZ96A0iaJk.pgp Description: PGP signature
Re: 4.10 - 5.3 migration; what happens to vinum volumes?
On Tue, Nov 30, 2004 at 11:38:54PM +0100, Willem Jan Withagen wrote: Ceri Davies wrote: On Thu, Nov 25, 2004 at 08:58:36PM +, Ceri Davies wrote: I have a 4.10-STABLE machine that I want to migrate to 5.3-STABLE. Most of the bases are covered, but I'm not sure what to expect for my vinum volumes. I don't have anything esoteric (see attached config), but can I just expect sed -i.bak -e 's/vinum/gvinum/' /etc/fstab to leave me with working volumes? Should I take it that nobody knows, or that nobody wants to say? From what I've seen on the lists, I'd be carefull to go that route yet with doing a full backup of all data. Lets say that gvinum has still rough edges. But then those only get smoothed out by people taking the leap. There have also been raports on succes. So I guess the reason nobody replied is just because there is no consensus. Also look in the GEOM@ archive for several threads on this topic. OK, that's something at least. Obviously I'll take a backup anyway but I'm trying to cut down time anywhere I can, so knowing that I have some chance of it working is something at least. Thanks. For my main fileserver I've stopped at 5.1 at this moment. I need to test more before I go there, but I can't seem to find mucht time lately. It that the customers pay the bills for not playing around. :() Damn those customers and their putting-bread-on-the-table ways ;-) Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpy0431cEvUW.pgp Description: PGP signature
Re: 4.10 - 5.3 migration; what happens to vinum volumes?
On Wed, Dec 01, 2004 at 11:38:38PM +0100, Lukas Ertl wrote: On Thu, 25 Nov 2004 20:58:36 +, Ceri Davies [EMAIL PROTECTED] wrote: I have a 4.10-STABLE machine that I want to migrate to 5.3-STABLE. Most of the bases are covered, but I'm not sure what to expect for my vinum volumes. I don't have anything esoteric (see attached config), but can I just expect sed -i.bak -e 's/vinum/gvinum/' /etc/fstab to leave me with working volumes? Hi Ceri, sorry for the late reply, I don't follow stable@ directly, so if there's any vinum question, please add a cc: to [EMAIL PROTECTED] (those messages will get highlighted so I have a chance to notice them earlier). Thanks Lukas - I'll do that in future then. Your config looks sane enough that it shouldn't be a problem to switch to gvinum. Edit your fstab and put geom_vinum_load=YES into /boot/loader.conf, that's enough. Cool. I'll be taking backups anyway so I'll try it that way; do you want a bug report if it doesn't work? Thanks again, Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpcEuSi64pgb.pgp Description: PGP signature
Re: 4.10 - 5.3 migration; what happens to vinum volumes?
On Thu, Nov 25, 2004 at 08:58:36PM +, Ceri Davies wrote: I have a 4.10-STABLE machine that I want to migrate to 5.3-STABLE. Most of the bases are covered, but I'm not sure what to expect for my vinum volumes. I don't have anything esoteric (see attached config), but can I just expect sed -i.bak -e 's/vinum/gvinum/' /etc/fstab to leave me with working volumes? Should I take it that nobody knows, or that nobody wants to say? # Vinum configuration of shrike.private.submonkey.net, saved at Thu Nov 25 20:54:01 2004 drive vinumdrive2 device /dev/ad0s1d drive vinumdrive0 device /dev/ad0s1h drive vinumdrive3 device /dev/ad1s1d drive vinumdrive1 device /dev/ad1s1h volume userhome volume werehaus plex name userhome.p0 org concat vol userhome plex name userhome.p1 org concat vol userhome plex name werehaus.p0 org striped 512s vol werehaus sd name userhome.p0.s0 drive vinumdrive0 plex userhome.p0 len 52428535s driveoffset 265s plexoffset 0s sd name userhome.p1.s0 drive vinumdrive1 plex userhome.p1 len 52428535s driveoffset 265s plexoffset 0s sd name werehaus.p0.s0 drive vinumdrive2 plex werehaus.p0 len 67166720s driveoffset 265s plexoffset 0s sd name werehaus.p0.s1 drive vinumdrive3 plex werehaus.p0 len 67166720s driveoffset 265s plexoffset 512s Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpJ0TJSG2sru.pgp Description: PGP signature
Re: pkg_add error on STABLE
On Sun, Nov 28, 2004 at 05:21:35AM -0500, Derrick Edwards wrote:
Everytime I try to install a package via pkg_add I get the following
error.
There is not a packages-5-current directory but there is a
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5-stable directory.
How do I fix this?
%pkg_add -r mysqlcc
Error: FTP Unable to get
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5-current/Latest/mysqlcc.tbz:
File unavailable (e.g., file not found, no access)
pkg_add: unable to fetch
'ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5-current/Latest/mysqlcc.tbz'
by URL
See if the attached patch does the right thing.
Ceri
--
Only two things are infinite, the universe and human stupidity, and I'm
not sure about the former.-- Einstein (attrib.)
Index: pkg_install/add/main.c
===
RCS file: /a/FreeBSD/ncvs/src/usr.sbin/pkg_install/add/main.c,v
retrieving revision 1.59.2.1
diff -u -r1.59.2.1 main.c
--- pkg_install/add/main.c 24 Oct 2004 09:42:10 - 1.59.2.1
+++ pkg_install/add/main.c 28 Nov 2004 19:09:07 -
@@ -72,7 +72,8 @@
{ 503000, 503099, /packages-5.3-release },
{ 30, 399000, /packages-3-stable },
{ 40, 499000, /packages-4-stable },
- { 503100, 599000, /packages-5-current },
+ { 502100, 502128, /packages-5-current },
+ { 503100, 599000, /packages-5-stable },
{ 0, 999, /packages-current },
{ 0, 0, NULL }
};
pgp4tovhgTGnb.pgp
Description: PGP signature
Re: pkg_add error on STABLE
On Sun, Nov 28, 2004 at 07:11:06PM +, Ceri Davies wrote: On Sun, Nov 28, 2004 at 05:21:35AM -0500, Derrick Edwards wrote: Everytime I try to install a package via pkg_add I get the following error. There is not a packages-5-current directory but there is a ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5-stable directory. How do I fix this? %pkg_add -r mysqlcc Error: FTP Unable to get ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5-current/Latest/mysqlcc.tbz: File unavailable (e.g., file not found, no access) pkg_add: unable to fetch 'ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5-current/Latest/mysqlcc.tbz' by URL See if the attached patch does the right thing. Or just cvsup. Ken Smith just committed pretty much the same thing. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpqRGxdUlN6N.pgp Description: PGP signature
Re: pkg_add error on STABLE
On Sun, Nov 28, 2004 at 02:30:50PM -0500, Ken Smith wrote: On Sun, Nov 28, 2004 at 07:25:59PM +, Ceri Davies wrote: On Sun, Nov 28, 2004 at 07:11:06PM +, Ceri Davies wrote: On Sun, Nov 28, 2004 at 05:21:35AM -0500, Derrick Edwards wrote: Everytime I try to install a package via pkg_add I get the following error. There is not a packages-5-current directory but there is a ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5-stable directory. How do I fix this? %pkg_add -r mysqlcc Error: FTP Unable to get ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5-current/Latest/mysqlcc.tbz: File unavailable (e.g., file not found, no access) pkg_add: unable to fetch 'ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5-current/Latest/mysqlcc.tbz' by URL See if the attached patch does the right thing. Or just cvsup. Ken Smith just committed pretty much the same thing. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) Yeah, Kris had asked for it. Your patch pointed out something though, you had added another chunk of the HEAD version that I hadn't added (range 502100, 502128,). But I'm not quite sure what to do about that because the packages-5-current directory is gone from the FTP sites. Anyone know for sure? I don't suppose it really matters, as anyone running that version will not have that line anyway, and if they update then they won't be running that version any more. I think that what you committed is enough. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpzikH123O3n.pgp Description: PGP signature
4.10 - 5.3 migration; what happens to vinum volumes?
I have a 4.10-STABLE machine that I want to migrate to 5.3-STABLE. Most of the bases are covered, but I'm not sure what to expect for my vinum volumes. I don't have anything esoteric (see attached config), but can I just expect sed -i.bak -e 's/vinum/gvinum/' /etc/fstab to leave me with working volumes? Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) # Vinum configuration of shrike.private.submonkey.net, saved at Thu Nov 25 20:54:01 2004 drive vinumdrive2 device /dev/ad0s1d drive vinumdrive0 device /dev/ad0s1h drive vinumdrive3 device /dev/ad1s1d drive vinumdrive1 device /dev/ad1s1h volume userhome volume werehaus plex name userhome.p0 org concat vol userhome plex name userhome.p1 org concat vol userhome plex name werehaus.p0 org striped 512s vol werehaus sd name userhome.p0.s0 drive vinumdrive0 plex userhome.p0 len 52428535s driveoffset 265s plexoffset 0s sd name userhome.p1.s0 drive vinumdrive1 plex userhome.p1 len 52428535s driveoffset 265s plexoffset 0s sd name werehaus.p0.s0 drive vinumdrive2 plex werehaus.p0 len 67166720s driveoffset 265s plexoffset 0s sd name werehaus.p0.s1 drive vinumdrive3 plex werehaus.p0 len 67166720s driveoffset 265s plexoffset 512s pgpakW83RCgEl.pgp Description: PGP signature
Re: standard-supfile = stable-supfile with 5.3 ?
On Tue, Nov 09, 2004 at 11:34:55AM -0500, Ken Smith wrote: On Tue, Nov 09, 2004 at 05:15:13PM +0900, Rob wrote: The two files /usr/src/share/examples/cvsup/standard-supfile /usr/src/share/examples/cvsup/stable-supfile both have *default release=cvs tag=RELENG_5 although the first one claims to download CURRENT. And, eh, why is the filename standard-supfile and why not the more obvious current-supfile ? I'm not sure I understand. How was your system brought up to the new release - was it a CD install or cvsup-ed? If cvsup-ed what did you use as the tag during the cvsup? I'm seeing what you expect both in CVS and on a system installed from CD: harlow 1 % cd /usr/share/examples/cvsup/ harlow 2 % grep default release standard-supfile stable-supfile standard-supfile:*default release=cvs tag=RELENG_5_3 stable-supfile:*default release=cvs tag=RELENG_5 harlow 3 % uname -a FreeBSD harlow.cse.buffalo.edu 5.3-RELEASE FreeBSD 5.3-RELEASE #3: Thu Nov 4 16:14:06 EST 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP i386 harlow 4 % The standard-supfile is meant for people who want to track the release branch as Errata/Security updates get applied to it. Hmm. share/examples/cvsup/README says: To maintain the sources for the FreeBSD-current release, use: standard-supfileMain source tree ports-supfile Ports collection To maintain the sources for the FreeBSD-stable release, use: stable-supfile Main source tree This implies that standard-supfile should be changed to track -HEAD. It does make sense that it should track RELENG_X_Y (RELENG_5_3 in this case) though. The stable-supfile is meant for people who want to track the *development* branch, which is not recommended for people who do not have the time to watch over the freebsd-stable mailing list (on occasion mistakes do happen in the development branch and other development work can at times cause glitches people need to be aware of). stable-supfile is correct then; we just need to correct the README. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgprDCcQWlyZ6.pgp Description: PGP signature
Re: -STABLE was stable for long time (Re: FreeBSD: Server or Desktop OS?)
On Mon, Nov 18, 2002 at 01:02:55AM +0100, Thomas Seck wrote: * Marc G. Fournier ([EMAIL PROTECTED]): On Sun, 17 Nov 2002, Thomas Seck wrote: You have chosen to maintain systems which stretch FreeBSD to its limits and uncover bugs lurking in the code. This is great. But you cannot do so on the one hand and refuse to face the administrative work on the other hand. This does not work. You have the freedom to maintain your own release with all the patches and fixes you need. Why don't you do it? Instead you waste your time with complaining (and you waste my time because I have to read it and think about the replies I am going to send)? But, what you miss in here is that picking and choosing which patches to use is useless, as it doesn't take into consideration the interactions of other patches you don't apply ... or the reliance of future patches that would be useful on those patches you don't apply ... if I wanted to pick-n-choose patches, I'd run Linux ... I choose to run FreeBSD because its an Operating System, not a Kernel with a 101 different distributions Basically, you want others to do the developing, testing and patching and keep the complaining part for yourself. Umm, there aren't any patches for Marc to apply. If there were, then this whole discussion wouldn't even be here (because he wouldn't be having problems with -stable in the first place). I also find people telling Marc that he should do some development, or acting as though he is somewhat lacking in clue, is rather amusing. I agree with Marc when he suggests that people shouldn't be performing MFCs that they're not prepared to support; while -current may be for developers, they should keep in mind that -stable and the release branches formed from it are for the users and this should justify more attention than it currently is getting. A number of developers are very good in this area, but not enough, I feel. Ceri -- Remember the fortress of the brethren! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: port forward only account?
On Fri, Apr 12, 2002 at 03:17:58PM +0100, Rasputin wrote: Bit of an odd one this - I have users I want to allow to ssh port forward to localhost on his box from certain IPs, but not to have a shell. What's a suitable shell? It should be able to hold a session open, but not do anything else. ssh -f [-N] ? Ceri -- get the cool shoe shine To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
