Re: resolvconf script overwrites entries in resolv.conf - RDNSS/DNSSL related
Hi,
On Mon, 8 Aug 2011 07:55:11 -0400
J.R. Oldroyd f...@opal.com said:
Is there any chance that you could create a patch for 8.2 based on the
commits in HEAD?
That would be great!
fbsd Better would be to ask hrs@ to MFC his commits to 8-stable.
hrs@ posted MFC candidate patch for review. Please refer the thread
started from:
http://lists.freebsd.org/pipermail/freebsd-net/2011-June/029070.html
The patches you will find in the thread are:
http://people.freebsd.org/~hrs/rfc6106_stable8_20110612-1.diff
http://people.freebsd.org/~ume/resolvconf-releng_8.diff
You may be interested in the thread from the following as well:
http://lists.freebsd.org/pipermail/freebsd-net/2011-June/029091.html
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
u...@mahoroba.org ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: awk(1) segfaults when building kernel modules
On Wed, Aug 10, 2011 at 10:12:11PM +0400, Test Rat wrote:
`make -s buildkernel' seems to contain lots of segfaults after recent
update of one-true-awk in r224731. It chokes on sys/conf/kmod_syms.awk.
The case can be reduced to
$ awk 'BEGIN { delete ARGV[1] } END { print ARGV[1] }' blah
[...]
Should be fixed in r224776; please confirm.
Cheers,
--
Ruslan Ermilov
r...@freebsd.org
FreeBSD committer
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: awk(1) segfaults when building kernel modules
Ruslan Ermilov r...@freebsd.org writes:
On Wed, Aug 10, 2011 at 10:12:11PM +0400, Test Rat wrote:
`make -s buildkernel' seems to contain lots of segfaults after recent
update of one-true-awk in r224731. It chokes on sys/conf/kmod_syms.awk.
The case can be reduced to
$ awk 'BEGIN { delete ARGV[1] } END { print ARGV[1] }' blah
[...]
Should be fixed in r224776; please confirm.
Confirmed, it no longer crashes with either above example or when
building kernel modules.
--
FreeBSD 9.0-BETA1 r224776M amd64
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD-9.0-BETA1-i386-bootonly
Hi. No need, I think. There is a message box: Error while fetching ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/i386/9.0-BETA1/base.txz: File unavailable (e.g., file not found, no access) Regards, Vans. 10.08.2011, в 18:48, Chris Brennan xa...@xaerolimit.net написал(а): On 8/10/2011 10:44 AM, N V wrote: Hi. Tried to use FreeBSD-9.0-BETA1-i386-bootonly.iso in VirtualBox to test. Installation stops after trying to fetch files from ftp. Attached screenshot is informative, I think. Seems to use i386/ twice for some reason. Regards, Vans. Your screenshot didn't make it to the list, can you upload it and provide us with a link to it instead? -- Chris Brennan -- A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting frowned upon? http://xkcd.com/84/ | http://xkcd.com/149/ | http://xkcd.com/549/ GPG: D5B20C0C (6741 8EE4 6C7D 11FB 8DA8 9E4A EECD 9A84 D5B2 0C0C) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: can't pxeboot BETA1
Hi, These instructions are not official, but they are what I have been using to set up PXE boot using an NFS root file system: http://people.freebsd.org/~rodrigc/pxe/freebsd_pxe.txt -- Craig Rodrigues rodr...@crodrigues.org On Wed, Aug 10, 2011 at 7:13 PM, Elliot Finley efinley.li...@gmail.com wrote: trying to pxeboot according to this page http://www.freebsdwiki.net/index.php/Installing_FreeBSD_with_netboot, but instead using 9.0-BETA1 doesn't work. can't mount root from ufs:/dev/md0 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD-9.0-BETA1-i386-bootonly
On Aug 11, 2011, at 10:28 AM, Vans va...@yandex.ru wrote: Hi. No need, I think. There is a message box: Error while fetching ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/i386/9.0-BETA1/base.txz: File unavailable (e.g., file not found, no access) Regards, Vans. 10.08.2011, в 18:48, Chris Brennan xa...@xaerolimit.net написал(а): On 8/10/2011 10:44 AM, N V wrote: Hi. Tried to use FreeBSD-9.0-BETA1-i386-bootonly.iso in VirtualBox to test. Installation stops after trying to fetch files from ftp. Attached screenshot is informative, I think. Seems to use i386/ twice for some reason. Regards, Vans. Your screenshot didn't make it to the list, can you upload it and provide us with a link to it instead? mirrorselect is using both uname -m and uname -p instead of just uname -m. That's why things don't work. Thanks, -Garrett___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD-9.0-BETA1-i386-bootonly
On 08/11/11 12:28, Vans wrote: Hi. No need, I think. There is a message box: Error while fetching ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/i386/9.0-BETA1/base.txz: File unavailable (e.g., file not found, no access) The 9.0-BETA1 ISOs cannot be used for network installations pending changes to the layout of the FTP servers to accommodate architectures with multiple CPU types per machine type (e.g. powerpc64, ARM, and MIPS) that were introduced in 9.0. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [bsdgrep] --exclude-dir doesn't work
Em 2011.08.09. 14:43, Test Rat escreveu: It seems fnmatch(3) args were accidentally swapped. Try $ bsdgrep -Fr --exclude-dir '*.svn*' grep_ usr.bin/grep | bsdgrep -c svn 72 Thanks! I'll commit this, too. Gabor ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: issues with bsdgrep and lang/go
Em 2011.08.10. 5:02, Jason Hellenthal escreveu: So has the maintainer of bsdgrep updated it yet so these things do not happen ?, if not (and apparently not) I don't understand why you are explicitly defaulting your gnugrep to a broken bsdgrep. This was a known problem a few months back and I for one have not seen updates on that yet. I don't remember of this bug but I may have missed it. Could you tell me where did you see it? I'm very thankful to Alexander for using the buggy BSD grep because he helped fixing a bug. Criticizing is the easiest option but probably not the best. Gabor Kovesdan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: issues with bsdgrep and lang/go
Em 2011.08.10. 22:09, Alexander Best escreveu: well i'd like to help the author of bsdgrep to improve it. testing it and then going back to gnu grep, because bsdgrep still has bugs isn't going to help much. by using it i'd like to trip over these kind of bugs and report them. but you're right...the author hasn't really paid a lot of attention to bsdgrep, lately.:( i guess that's a problem when you have an open os, where everybody can do as much or as little as it pleases him.;) I do! In this year's Summer of Code I'm working on the regex code. A good and efficient regex support is important for a fast and clean BSD grep. The ultimate goal is to get rid of both GNU grep and libgnuregex. I'm sorry if I temporarily neglected some bug reports. Gabor ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: issues with bsdgrep and lang/go
Em 2011.08.09. 13:27, Test Rat escreveu: Try below workaround. It also makes empty GREP_COLOR behave like gnugrep(1). Thanks a lot, you were so quick that I haven't had a chance to look at it yet. I'll commit the patch soon. Also, thanks to Alexander for using BSD grep and reporting bugs. Gabor Kovesdan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[bsdgrep] fgrepcomp(), ignore case and segfault with unicode locale
A quick test
$ env -i bsdgrep -Fi without_nls usr.bin/grep/grep.c
$ env -i gnugrep -Fi without_nls usr.bin/grep/grep.c
#ifndef WITHOUT_NLS
#ifndef WITHOUT_NLS
#ifndef WITHOUT_NLS
shows that bsd fgrep already fails to ignore case. And if you throw
a few more options to the mix it'd crash, e.g.
$ env -i LC_CTYPE=en_US.UTF-8 TERM=xterm bsdgrep --color -Fir without_nls
usr.bin/grep/
[...]
Program received signal SIGSEGV, Segmentation fault.
0x000801007ff2 in memchr (s=0x61167a, c=10, n=18446744073707490297) at
/usr/src/lib/libc/string/memchr.c:48
48 if (*p++ == (unsigned char)c)
(gdb) bt
#0 0x000801007ff2 in memchr (s=0x61167a, c=10, n=18446744073707490297)
at /usr/src/lib/libc/string/memchr.c:48
#1 0x000801007b03 in __sfvwrite (fp=0x801247770, uio=0x7fffd8f0) at
/usr/src/lib/libc/stdio/fvwrite.c:170
#2 0x000801007698 in fwrite (buf=0x608c03, size=18446744073709551606,
count=1, fp=0x801247770)
at /usr/src/lib/libc/stdio/fwrite.c:95
#3 0x00405498 in printline (line=0x7fffdb70, sep=58,
matches=0x7fffd990, m=9)
at /usr/src/usr.bin/grep/util.c:500
#4 0x00404f51 in procline (l=0x7fffdb70, nottext=0) at
/usr/src/usr.bin/grep/util.c:381
#5 0x0040489f in procfile (fn=0x80140b600
usr.bin/grep/nls/es_ES.ISO8859-1.msg) at /usr/src/usr.bin/grep/util.c:239
#6 0x004044d7 in grep_tree (argv=0x7fffdd30) at
/usr/src/usr.bin/grep/util.c:163
#7 0x00403ea9 in main (argc=5, argv=0x7fffdd10) at
/usr/src/usr.bin/grep/grep.c:689
(gdb) bt f
#0 0x000801007ff2 in memchr (s=0x61167a, c=10, n=18446744073707490297)
at /usr/src/lib/libc/string/memchr.c:48
p = (const unsigned char *) 0x80 Error reading address 0x80:
Bad address
#1 0x000801007b03 in __sfvwrite (fp=0x801247770, uio=0x7fffd8f0) at
/usr/src/lib/libc/stdio/fvwrite.c:170
len = 18446744073709516159
p = 0x61167a
iov = (struct __siov *) 0x7fffd8f0
w = 880
s = 880
nl = 0x611679 \n
nlknown = 0
nldist = 0
#2 0x000801007698 in fwrite (buf=0x608c03, size=18446744073709551606,
count=1, fp=0x801247770)
at /usr/src/lib/libc/stdio/fwrite.c:95
n = 18446744073709551606
uio = {uio_iov = 0x7fffd8e0, uio_iovcnt = 1, uio_resid = -35457}
iov = {iov_base = 0x608c03, iov_len = 18446744073709551606}
#3 0x00405498 in printline (line=0x7fffdb70, sep=58,
matches=0x7fffd990, m=9)
at /usr/src/usr.bin/grep/util.c:500
a = 99
i = 9
n = 1
#4 0x00404f51 in procline (l=0x7fffdb70, nottext=0) at
/usr/src/usr.bin/grep/util.c:381
matches = {{rm_so = 0, rm_eo = 11}, {rm_so = 11, rm_eo = 22}, {rm_so
= 22, rm_eo = 33}, {rm_so = 33, rm_eo = 44}, {
rm_so = 44, rm_eo = 55}, {rm_so = 55, rm_eo = 66}, {rm_so = 66, rm_eo =
77}, {rm_so = 77, rm_eo = 88}, {rm_so = 88,
rm_eo = 99}, {rm_so = 21131328, rm_eo = 8}, {rm_so = -9696, rm_eo =
32767}, {rm_so = 16101362, rm_eo = 8}, {rm_so = 21131328,
rm_eo = 8}, {rm_so = 16103767, rm_eo = 0}, {rm_so = 37, rm_eo = 0},
{rm_so = 8, rm_eo = 0}, {rm_so = -9632, rm_eo = 32767}, {
rm_so = -8944, rm_eo = 32767}, {rm_so = -9664, rm_eo = 32767}, {rm_so =
16103767, rm_eo = 8}, {rm_so = 6327289, rm_eo = 0}, {
rm_so = 437, rm_eo = 0}, {rm_so = -9584, rm_eo = 10}, {rm_so = 6327200,
rm_eo = 0}, {rm_so = -9776, rm_eo = 0}, {
rm_so = 6327290, rm_eo = 0}, {rm_so = -9536, rm_eo = 32767}, {rm_so =
4204252, rm_eo = 0}, {rm_so = -9584, rm_eo = 32767}, {
rm_so = 6327200, rm_eo = 0}, {rm_so = -9352, rm_eo = 32767}, {rm_so =
21004392, rm_eo = 8}}
pmatch = {rm_so = 88, rm_eo = 99}
st = 99
i = 1
c = 1
m = 9
r = 0
#5 0x0040489f in procfile (fn=0x80140b600
usr.bin/grep/nls/es_ES.ISO8859-1.msg) at /usr/src/usr.bin/grep/util.c:239
f = (struct file *) 0x801408068
sb = {st_dev = 745804815, st_ino = 171971, st_mode = 33188, st_nlink
= 1, st_uid = 1001, st_gid = 1001,
st_rdev = 4294967295, st_atim = {tv_sec = 1292381124, tv_nsec = 0}, st_mtim
= {tv_sec = 1280426577, tv_nsec = 0}, st_ctim = {
tv_sec = 1292381124, tv_nsec = 165601426}, st_size = 526, st_blocks = 2,
st_blksize = 4096, st_flags = 0, st_gen = 0,
st_lspare = 0, st_birthtim = {tv_sec = 1292381124, tv_nsec = 165601426}}
ln = {off = 0, len = 89,
dat = 0x608ba0 $ $FreeBSD: head/usr.bin/grep/nls/es_ES.ISO8859-1.msg
210622 2010-07-29 18:02:57Z gabor $\n$\n$set 1\n$quote \\n1 \(entrada
estdar)\\n2 \no se puede leer el fichero comprimido bzip2\\n3 \opci
desconocid...,
file = 0x801427040 usr.bin/grep/nls/es_ES.ISO8859-1.msg, line_no = 1}
s = 32768
c = 0
t = 8
#6 0x004044d7 in grep_tree (argv=0x7fffdd30) at
SVN - CVS exporter issue?
I'm not seeing any of today's SVN src updates flow through to CVS/CSUP. Is it broken? imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Loading drivers via kldload
Hi All, While loading PCIe based HBA drivers via kldload, does FreeBSD expect a valid (i.e., non-zero) PCI subsystem Vendor and Device IDs? Thanks, David Somayajulu This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SVN - CVS exporter issue?
On Thu, Aug 11, 2011 at 07:26:36PM -0400, Michael Butler wrote: I'm not seeing any of today's SVN src updates flow through to CVS/CSUP. Is it broken? Could it be because of r224768? I vaguely recall that svn mv bothers whatever it is that converts from svn - cvs. Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: [patch] Problem with two NIC on same NET (in_scrubprefix: err=17, new prefix add failed)
Hi, I've started my work with not point-to-point interfaces and I've found two problems. The first one - snip When I've done more investigation, it looks similar to http://svnweb.freebsd.org/base?view=revisionrevision=201543 So, I propose the following patch. I agree with your fix. As you've noted, I made the r201543 patch in IPv6 almost 2 years ago. Turned out I had a note-to-self to verify if there are other similar problems at the time but busy day job took me away ... The second one - submitted patch and description is bellow: http://www.freebsd.org/cgi/query-pr.cgi?pr=159603 I agree with your fix. snip I have no problem with loopback routes when I work with not point-to-point interfaces as I can NOT set same source address on them. However, if the interface is going down and up, then loopback route is deleted without checking IFA_RTSELF flag (it must be consistent! especially in kernel) and re-added regardless of useloopback setting. So, at least, a loopback route is installed even if useloopback is NOT allowed! I hope the question does not offend you, but you do know the history behind IFA_RTSELF loopback route for each interface address, right ? The interface address loopback route is used for reaching the interface address within the system after the L2/L3 separation redesign, that's why useloopback setting is inapplicable. The check in various code paths may have a bit of consistency issue, but useloopback setting does not apply here. After that I've continued with point-to-point interfaces on same net, i.e. I've work with un-numbered interfaces. Firstly, I could not set parallel links on them. The fix is following and is already commmitted: http://www.freebsd.org/cgi/query-pr.cgi?pr=159600 I had a second look at it after some sleep, I agree with your fix. The bigger problem was with loopback routes on un-numbered interfaces. In in_ifinit(), when un-numbered interface is setting loopback route, then refcount on existing route is incremented and IFA_RTSELF flags is set on its address. This is done if and only if useloopback is set and interface is not IFF_LOOPBACK. It is OK. The rest is hacked somehow and I don't know why. The loopback route for the IFA should be installed unconditionally. So the check in in_ifinit() for V_useloopback needs to be removed. In in_ifscrubprefix() which is used either when address is being deleted or interface is going down, I found first inconsistence. Refcount on existing route is decremented always (in both cases), but the route is deleted only when address is being deleted. That's by design. Futhermore, IFA_RTSELF flag is NOT cleared when refcount is decremented! The fix and behavour is following: http://www.freebsd.org/cgi/query-pr.cgi?pr=159601 I agree with your fix. snip In the view of this inconsistence, I understand a next one in rip_ctlinput(). When interface is going up, then loopback route is being deleted and re-added regardless of IFA_RTSELF flag and useloopback setting. If un-numbered interfaces are used, then it damages refcount on existing loopback route!! I will fix that. If useloopback IS NOT set and IFA_RTSELF IS set, then loopback route is deleted, but with correct refcount game. And if useloopback is SET and IFA_RTSELF IS NOT set and interface IS NOT IFF_LOOPBACK, then loopback route is added, but again with correct refcount game too. It (with previous patch) should ensure IFA_RTSELF and loopback route consistence. No, see above, the IFA_RTSELF route should be unconditionally. I agree with you about the consistency issue and will fix it. snip Unless you have a really good reason, other than code inspection, and have a set of test cases, please leave this code alone for now. I have good reason, but I can hack kernel just for me only in worse scenario. However, I always try to minimalize the hacks count. You can hack the kernel however you see fit, but when you are ready for a patch commit, please provide sufficient context and problem description, and test cases whenever possible to make the code review process effective. snip I understand, but I use my own DHCP client. Well, I try to look at it, but maybe, someone else can test it. Again, my only point is, since these areas are core to the networking kernel, please test as many scenarios as possible, more than just your specific setup. (I made this mistake myself sometimes.) In any case, thank you very much for your fixes. -- Qing ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
upgrade to 9.0-BETA1 with geom_mirror fails
Hi all, I was originally running 8.2 on my NAS at home -- later 8-STABLE for ZFS -- and decided to see how 9.0-BETA1 fairs on it due to seeing some changes coming in 9.0 that would be favorable. After installing the kernel and trying to reboot into it I discovered it doesn't like my geom_mirror that I use for / and swap. It gives this error: geom_mirror integrity check failed It can't mount the / device then (/dev/mirror/gm0a) so it asks me to choose a disk to boot from. When listing the disks with ? it shows all physical disks but the only geom device is gm0 -- none of the slices are listed. Any idea how to fix this? If I boot up an 8-STABLE or 8.2R kernel it has no issues with my mirror. Thanks, Mark ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
