Re: The great perl script rewite - progress report
On Wed, Jul 31, 2002 at 02:28:46PM +0100, Mark Murray wrote: /usr/bin/afmtodit Kyle Martin [EMAIL PROTECTED] - redo - * /usr/bin/mmroff Lester A Mesa [EMAIL PROTECTED] - redo - * These are part of the Groff distribution. These should be submitted to the Groff maintainers first. [EMAIL PROTECTED] might be a good person to contact. Key - redo == to be rewritten replace == toe be replaced with suitable 'outside' code ^^^ typo here Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg41562/pgp0.pgp Description: PGP signature
IPFW2 may cause incoming connections to hang
I notice reproductible effect on my recent -current remote machine, after 5-7 hours of normal work, I can't connect to this machine via ssh,telnet,pop3 or ftp, but smtp and http continue to work normally. When I turn ipfw2 off, this effect is gone. It was never happened for old ipfw with the same settings. I have simple open firewall type with one deny rule for specific tcp port. Since this is remote machine, I can't login and see what actually happens during this effect. I also notice that if current connection stays across beginning of effect, it continue to work, but new ones hangs. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IPFW2 may cause incoming connections to hang
On Thu, Aug 01, 2002 at 12:11:05PM +0400, Andrey A. Chernov wrote: I notice reproductible effect on my recent -current remote machine, after 5-7 hours of normal work, I can't connect to this machine via ssh,telnet,pop3 or ftp, but smtp and http continue to work normally. When I turn ipfw2 off, this effect is gone. It was never happened for old ipfw with the same settings. I have simple open firewall type with one deny rule for specific tcp port. Since this is remote machine, I can't login and see what actually happens during this effect. I also notice that if current connection stays across beginning of effect, it continue to work, but new ones hangs. could you send me your exact ruleset ? Also, does this happen at specific times (e.g. after some cron task) or not ? cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sshd doesn't log hostname into utmp correctly
Hajimu UMEMOTO [EMAIL PROTECTED] writes: Current sshd doesn't handle actual size of struct sockaddr correctly, and does copy it as long as just size of struct sockaddr. So, sshd deesn't log hostname into utmp correctly. Here is a proposed patch to fix this problem. Please review it. Could you please submit it to [EMAIL PROTECTED]? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
-current upgrade path broken?
Should one be able to do a source upgrade from an old -current (March 10) to the latest? I have been trying, but it breaks in the cross tools section in gnu/usr.bin/cc/cc_int. mkdep fails. There are a lot of warnings that looks like this: # /home/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config/i386/unix.h:70: warning: `TARGET_DEFAULT' redefined /home/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config/i386/i386.h:400: warning: this is the location of the previous definition /home/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config/i386/unix.h:83: warning: `FUNCTION_VALUE_REGNO_P' redefined /home/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config/i386/i386.h:1654: warning: this is the location of the previous definition ## I don't think they cause the failure, but there are so many of them that they are hiding the real stuff. I think what is breaking mkdep is this: # /home/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/varasm.c:598: macro `SELECT_SECTION' used with too many (3) args /home/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/varasm.c:3400: macro `SELECT_SECTION' used with too many (3) args /home/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/varasm.c:4006: macro `SELECT_RTX_SECTION' used with too many (3) args ... mkdep: compile failed *** Error code 1 Stop in /home/src/gnu/usr.bin/cc/cc_int. *** Error code 1 Stop in /home/src/gnu/usr.bin/cc. *** Error code 1 Stop in /home/src. *** Error code 1 Stop in /home/src. *** Error code 1 Stop in /home/src. # John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === usr.bin/sockstat cc1: warnings being treated as errors /usr/home/des/tinderbox/sparc64/src/usr.bin/sockstat/sockstat.c: In function `gather_inet': /usr/home/des/tinderbox/sparc64/src/usr.bin/sockstat/sockstat.c:224: warning: cast increases required alignment of target type /usr/home/des/tinderbox/sparc64/src/usr.bin/sockstat/sockstat.c:234: warning: cast increases required alignment of target type /usr/home/des/tinderbox/sparc64/src/usr.bin/sockstat/sockstat.c: In function `gather_unix': /usr/home/des/tinderbox/sparc64/src/usr.bin/sockstat/sockstat.c:331: warning: cast increases required alignment of target type /usr/home/des/tinderbox/sparc64/src/usr.bin/sockstat/sockstat.c:343: warning: cast increases required alignment of target type /usr/home/des/tinderbox/sparc64/src/usr.bin/sockstat/sockstat.c:359: warning: cast increases required alignment of target type *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src/usr.bin/sockstat. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src/usr.bin. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current upgrade path broken?
I have stumbled to this too, and thought I'm getting crazy. After some hours of investigation, I have found that O'Brien did some repo-surgery there, removed some revisions, and later replaced them with the new stuff (well, new stuff took the same revisions), and now some of your checked out sources (revisions) do not match what's in your CVS repository. rm -rf /usr/src/contrib/gcc and /usr/src/gnu/usr.bin/cc, check them out again, and try again. It worked for me now. I hope that people will learn the lessons from this, and won't be doing such scary things in the future. Peter had some work-arounds to avoid problems like this, were these forced commits over the affected files, I don't remember? On Thu, Aug 01, 2002 at 12:47:38PM +0200, John Hay wrote: Should one be able to do a source upgrade from an old -current (March 10) to the latest? I have been trying, but it breaks in the cross tools section in gnu/usr.bin/cc/cc_int. mkdep fails. There are a lot of warnings that looks like this: # /home/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config/i386/unix.h:70: warning: `TARGET_DEFAULT' redefined /home/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config/i386/i386.h:400: warning: this is the location of the previous definition /home/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config/i386/unix.h:83: warning: `FUNCTION_VALUE_REGNO_P' redefined /home/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config/i386/i386.h:1654: warning: this is the location of the previous definition ## I don't think they cause the failure, but there are so many of them that they are hiding the real stuff. I think what is breaking mkdep is this: # /home/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/varasm.c:598: macro `SELECT_SECTION' used with too many (3) args /home/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/varasm.c:3400: macro `SELECT_SECTION' used with too many (3) args /home/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/varasm.c:4006: macro `SELECT_RTX_SECTION' used with too many (3) args ... mkdep: compile failed *** Error code 1 Stop in /home/src/gnu/usr.bin/cc/cc_int. *** Error code 1 Stop in /home/src/gnu/usr.bin/cc. *** Error code 1 Stop in /home/src. *** Error code 1 Stop in /home/src. *** Error code 1 Stop in /home/src. # John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg41570/pgp0.pgp Description: PGP signature
pkg_add broken by POLA breakage in tar
Revs.1.2-1.3 of tar/src/extract.c break pkg_add (not to mention probably
thousands of user scripts that are no more careful than pkg_add) in
-current and RELENG_4:
% RCS file: /home/ncvs/src/contrib/tar/src/extract.c,v
% Working file: extract.c
% head: 1.4
% branch:
% locks: strict
% access list:
% symbolic names:
% RELENG_4: 1.4.0.2
% TAR_v1_13_25: 1.1.1.1
% FSF: 1.1.1
% keyword substitution: kv
% total revisions: 6; selected revisions: 6
% description:
% ...
%
% revision 1.3
% date: 2002/06/07 06:02:35; author: sobomax; state: Exp; lines: +1 -1
% Disabling automatic --same-owner option when running as uid 0 along with
% the --same-permissions was an overkill, so put it back. This is consistent
% with what our old tar did.
%
% Suggested by: dillon
%
% revision 1.2
% date: 2002/06/07 00:03:23; author: sobomax; state: Exp; lines: +4 -0
% IMO it was a quite ugly idea that if we are running as uid 0 then we can
% safely ignore current umask(2) and assume that permissions should be set
% right like in the archive. Not only it violates POLA, but introduces
^
% huge potential security vulnerability, particularly for ports, where
% many popular archives come with 777 files and dirs.
%
Actually, it is the change violates POLA, and breaks everything that
depends on the historical and still documented behaviour. (The man
page even says that (almost) all permissions are restored even in the
!root case (it says this indirectly by saying that all attributes are
restored if possible and not mentioning the umask or root). The info
page is better.)
This bug showed up as breakage in mutt. mutt uses a setgid utility
named mutt_dotlock to lock /var/mail/*, so it fails to download mail
if mutt_dotlock's setgid bit is lost on extraction. It is probably
another bug that mutt_dotlock attempts to create a temporary file in
/var/mail instead of using flock().
Fixes:
(1) Change pkg_add and thousands of user scripts to use tar -p. This
may reopen security holes closed by respecting the umask.
%%%
Index: extract.c
===
RCS file: /home/ncvs/src/usr.sbin/pkg_install/add/extract.c,v
retrieving revision 1.33
diff -u -2 -r1.33 extract.c
--- extract.c 11 May 2002 04:17:54 - 1.33
+++ extract.c 1 Aug 2002 10:26:10 -
@@ -33,5 +33,5 @@
#define PUSHOUT(todir) /* push out string */ \
if (where_count (int)sizeof(STARTSTRING)-1) { \
- strcat(where_args, |tar --unlink -xf - -C ); \
+ strcat(where_args, |tar --unlink -pxf - -C ); \
strcat(where_args, todir); \
if (system(where_args)) { \
%%%
(2) Restore standard gnu tar behaviour by backing out extract.c revs 1.2-1.3.
%%%
Index: extract.c
===
RCS file: /home/ncvs/src/contrib/tar/src/extract.c,v
retrieving revision 1.4
diff -u -2 -r1.4 extract.c
--- extract.c 3 Jul 2002 12:44:31 - 1.4
+++ extract.c 1 Aug 2002 10:44:34 -
@@ -113,7 +113,5 @@
{
we_are_root = geteuid () == 0;
-#ifndef __FreeBSD__
same_permissions_option += we_are_root;
-#endif
same_owner_option += we_are_root;
xalloc_fail_func = extract_finish;
%%%
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
kernel panic on boot, acpica related?
sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x8:0xc4109ac1 stack pointer = 0x10:0xd6855ce4 frame pointer = 0x10:0xd6855d0c code segment= base0x0, limit 0xf, type 0x16 = DPL 0, pres 1, def 32, gran 1 processor eflags= interrupt enabled, resume, IOPL=0 current process = 21 (irq10:fxp0 sn0+++*) kernel: type 9 trap, code=0 Stopped at 0xc4109ac1: lcall $0xc410,0xa040c410 db trace _end (c158d300,d6855d48,c04897b1,356,0) at 9xc4109ac1 fork_exit (c02ae2c0,c158d300,d6855d48) at fork_exit+0xaf fork_trampoline () at fork_trampoline+0x1a -- Michael Nottebrock The circumstance ends uglily in the cruel result. - Babelfish msg41572/pgp0.pgp Description: PGP signature
Re: -current upgrade path broken?
Yup, you are right, thanks. I remember about the problem, but did not remember the symptoms of it, so didn't put two and two together. :-( I have stumbled to this too, and thought I'm getting crazy. After some hours of investigation, I have found that O'Brien did some repo-surgery there, removed some revisions, and later replaced them with the new stuff (well, new stuff took the same revisions), and now some of your checked out sources (revisions) do not match what's in your CVS repository. rm -rf /usr/src/contrib/gcc and /usr/src/gnu/usr.bin/cc, check them out again, and try again. It worked for me now. I hope that people will learn the lessons from this, and won't be doing such scary things in the future. Peter had some work-arounds to avoid problems like this, were these forced commits over the affected files, I don't remember? ... I don't think they cause the failure, but there are so many of them that they are hiding the real stuff. I think what is breaking mkdep is this: # /home/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/varasm.c:598: macro `SELECT_SECTION' used with too many (3) args /home/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/varasm.c:3400: macro `SELECT_SECTION' used with too many (3) args /home/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/varasm.c:4006: macro `SELECT_RTX_SECTION' used with too many (3) args ... mkdep: compile failed ... John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic on boot, acpica related?
sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x8:0xc4109ac1 stack pointer = 0x10:0xd6855ce4 frame pointer = 0x10:0xd6855d0c code segment = base0x0, limit 0xf, type 0x16 = DPL 0, pres 1, def 32, gran 1 processor eflags = interrupt enabled, resume, IOPL=0 current process = 21 (irq10:fxp0 sn0+++*) kernel: type 9 trap, code=0 Stopped at0xc4109ac1: lcall $0xc410,0xa040c410 db trace _end (c158d300,d6855d48,c04897b1,356,0) at 9xc4109ac1 fork_exit (c02ae2c0,c158d300,d6855d48) at fork_exit+0xaf fork_trampoline () at fork_trampoline+0x1a Hmmm, I don't think so. How about typing unset acpi_load in loader prompt, and see if this panic disappear or still happen? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic on boot, acpica related?
Mitsuru IWASAKI wrote: sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x8:0xc4109ac1 stack pointer = 0x10:0xd6855ce4 frame pointer = 0x10:0xd6855d0c code segment = base0x0, limit 0xf, type 0x16 = DPL 0, pres 1, def 32, gran 1 processor eflags = interrupt enabled, resume, IOPL=0 current process = 21 (irq10:fxp0 sn0+++*) kernel: type 9 trap, code=0 Stopped at0xc4109ac1: lcall $0xc410,0xa040c410 db trace _end (c158d300,d6855d48,c04897b1,356,0) at 9xc4109ac1 fork_exit (c02ae2c0,c158d300,d6855d48) at fork_exit+0xaf fork_trampoline () at fork_trampoline+0x1a Hmmm, I don't think so. How about typing unset acpi_load in loader prompt, and see if this panic disappear or still happen? Hm, right, doesn't go away, slightly different panic now ... Fatal trap 1, but basically same spot. Regards, -- Michael Nottebrock The circumstance ends uglily in the cruel result. - Babelfish msg41575/pgp0.pgp Description: PGP signature
Unable to boot -current for last week
All,
Starting about a week ago, -current started refusing to boot on my TOS 5005-S504.
Depending on the config I use, it hard locks at boot in one of two places: either when
loading the fxp driver, or when probing the pci bus. And I do mean hard. I can't break
to debug, nothing. A power cycle is the only option. Since this is a legacy free
laptop, I'm not able to attach a console, so I'm pretty much hunting in the dark. I am
however, still able to boot the GENERIC from DP1. I was also wondering if anyone had
bothered to create an absolute minimal kernel config, and if so, would you send it to
me to try? Then I can start adding back to see where it breaks.
At any rate, the last cvs code that booted on this box was from around July 24th.
Thanks,
Rob
èR{.nÇ+·¬zwfj)m¢f£¢·hkyàRàÂ+aº{.nÇ+·ç±×.®·§¶)í
æèw* ¶¦zË
Bug in setlocale()
Hi,
we have a bug in setlocale(), it writes past
static char new_categories[_LC_LAST][ENCODING_LEN + 1];
in the do-while loop around line 159.
I get this backtrace
---snip---
(gdb) bt
#0 0x2816c9bc in kill () from /usr/lib/libc.so.4
#1 0x281af744 in abort () at /usr/src/lib/libc/../libc/stdlib/abort.c:73
#2 0x28171d8b in setlocale (category=0,
locale=0x8d88459 font\,\n\n\A new online catalog will be created based on the
configuration you have specified into the CommerceLauncher.\,\n\Et nyt on-line
katalog vil blive oprettet baseret paring; konfigurationen du...)
at /usr/src/lib/libc/../libc/locale/setlocale.c:159
#3 0x2823715a in XS_POSIX_setlocale (cv=0x8459d44) at POSIX.xs:3250
#4 0x80a3313 in Perl_pp_entersub () at pp_hot.c:2618
#5 0x809d41a in Perl_runops_debug () at run.c:53
#6 0x805bb01 in S_run_body (oldscope=1) at perl.c:1466
#7 0x805b828 in perl_run (my_perl=0x8105030) at perl.c:1393
#8 0x805903a in main (argc=3, argv=0xbfbffbc4, env=0xbfbffbd4)
at perlmain.c:52
#9 0x8058f21 in _start ()
---snip---
on a 4.6-p1 system (current seems to contain the same code) with this
modification:
---snip---
(gdb) up 2
#2 0x28171d8b in setlocale (category=0,
locale=0x8d88459 font\,\n\n\A new online catalog will be created based on the
configuration you have specified into the CommerceLauncher.\,\n\Et nyt on-line
katalog vil blive oprettet baseret paring; konfigurationen du...)
at /usr/src/lib/libc/../libc/locale/setlocale.c:159
159 if (_LC_LAST == i) abort();
(gdb) list
154 } else {
155 for (i = 1; r[1] == '/'; ++r);
156 if (!r[1])
157 return (NULL); /* Hmm, just slashes... */
158 do {
159 if (_LC_LAST == i) abort();
160 len = r - locale ENCODING_LEN ? ENCODING_LEN
: r - locale;
161 (void)strncpy(new_categories[i], locale, len);
162 new_categories[i][len] = '\0';
163 i++;
---snip---
Yes, I know, locale isn't set to anything valid.
I don't know if this is exploitable (is there a length check somewhere
for the involved env vars? If not we are in trouble), but at least it's
a nasty buffer overflow (it overwrites parts of getpwent.c:__hashpw() on
this particular machine and causes a segfault in getpwuid()).
Bye,
Alexander.
--
The three Rs of Microsoft support: Retry, Reboot, Reinstall.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: -current upgrade path broken?
On Thu, Aug 01, 2002 at 03:16:35PM +0300, Ruslan Ermilov wrote: I have stumbled to this too, and thought I'm getting crazy. After some hours of investigation, I have found that O'Brien did some repo-surgery there, removed some revisions, and later replaced them with the new stuff (well, new stuff took the same revisions), and now some of your checked out sources (revisions) do not match what's in your CVS repository. Since you did not provde details I don't know exactly what you are talking about or when this repo surgery was to have taken place. But yes, Peter did back out some revs several months ago. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic on boot, acpica related?
On Thu, Aug 01, 2002 at 10:14:34PM +0900, Mitsuru IWASAKI wrote: Hmmm, I don't think so. How about typing unset acpi_load in loader prompt, and see if this panic disappear or still happen? Where is it documented what to do to stop the autoloading of acpi.ko? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: location of setkey in /etc/rc.d/ipsec
Hi,
On Thu, 1 Aug 2002 10:45:08 -0700
David O'Brien [EMAIL PROTECTED] said:
obrien On Thu, Aug 01, 2002 at 01:40:55AM +0900, Hajimu UMEMOTO wrote:
makonnen Thanks for spotting this. I think the following patch might be better.
Thanks! I've just committed your version.
obrien We probably should have decided if setkey should have been moved to
obrien /sbin first. Is it reasonable to run setkey before /usr is mounted?
Yes, I think it is reasonable. ipsec setup is done before mounting
NFS. So, setkey cannot be executed on NFS mounted /usr.
If there is no objection, I'll move setkey into /sbin.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
portupgrade problem
Since yesterday I've been getting the following error when running the command `portsclean -DDi': Detecting unreferenced distfiles... (eval):9:in `chdir': No such file or directory - \/usr/ports/Mk/bsd.port.mk\, line 1621: warning: duplicate script for target \.BEGIN\ ignored\n\/usr/ports/Mk/bsd.port.mk\, line 1622: warning: duplicate script for target \.BEGIN\ ignored\n/usr/ports/distfiles (Errno::ENOENT) from (eval):9:in `chdir' from /usr/local/sbin/portsclean:555:in `scan_distfiles' from /usr/local/sbin/portsclean:213:in `distclean' from /usr/local/sbin/portsclean:140:in `main' from /usr/local/sbin/portsclean:66:in `initialize' from /usr/local/sbin/portsclean:66:in `new' from /usr/local/sbin/portsclean:66:in `main' from /usr/local/sbin/portsclean:672 I don't run the command very often, so I'm not sure when it broke. Pete... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sshd doesn't log hostname into utmp correctly
Hajimu UMEMOTO [EMAIL PROTECTED] writes: des Could you please submit it to [EMAIL PROTECTED]? Yes, I'll sent it. Can I commit it to FreeBSD repo.? No, please wait and see what the OpenSSH developers say. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sshd doesn't log hostname into utmp correctly
Hi,
On 01 Aug 2002 11:05:46 +0200
Dag-Erling Smorgrav [EMAIL PROTECTED] said:
des Hajimu UMEMOTO [EMAIL PROTECTED] writes:
Current sshd doesn't handle actual size of struct sockaddr correctly,
and does copy it as long as just size of struct sockaddr. So, sshd
deesn't log hostname into utmp correctly.
Here is a proposed patch to fix this problem. Please review it.
des Could you please submit it to [EMAIL PROTECTED]?
Yes, I'll sent it.
Can I commit it to FreeBSD repo.?
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: pkg_add broken by POLA breakage in tar
Bruce Evans wrote:
Revs.1.2-1.3 of tar/src/extract.c break pkg_add (not to mention probably
thousands of user scripts that are no more careful than pkg_add) in
-current and RELENG_4:
Are you sure? My own investigation at the time of the commit showed
that old tar shipped with FreeBSD, was adjusting permissions of
extracting files when running as uid 0 according to current umask
settings, so that IMO 1.2-1.3 actually restored POLA, not broke it.
-Maxim
% RCS file: /home/ncvs/src/contrib/tar/src/extract.c,v
% Working file: extract.c
% head: 1.4
% branch:
% locks: strict
% access list:
% symbolic names:
% RELENG_4: 1.4.0.2
% TAR_v1_13_25: 1.1.1.1
% FSF: 1.1.1
% keyword substitution: kv
% total revisions: 6; selected revisions: 6
% description:
% ...
%
% revision 1.3
% date: 2002/06/07 06:02:35; author: sobomax; state: Exp; lines: +1 -1
% Disabling automatic --same-owner option when running as uid 0 along with
% the --same-permissions was an overkill, so put it back. This is consistent
% with what our old tar did.
%
% Suggested by: dillon
%
% revision 1.2
% date: 2002/06/07 00:03:23; author: sobomax; state: Exp; lines: +4 -0
% IMO it was a quite ugly idea that if we are running as uid 0 then we can
% safely ignore current umask(2) and assume that permissions should be set
% right like in the archive. Not only it violates POLA, but introduces
^
% huge potential security vulnerability, particularly for ports, where
% many popular archives come with 777 files and dirs.
%
Actually, it is the change violates POLA, and breaks everything that
depends on the historical and still documented behaviour. (The man
page even says that (almost) all permissions are restored even in the
!root case (it says this indirectly by saying that all attributes are
restored if possible and not mentioning the umask or root). The info
page is better.)
This bug showed up as breakage in mutt. mutt uses a setgid utility
named mutt_dotlock to lock /var/mail/*, so it fails to download mail
if mutt_dotlock's setgid bit is lost on extraction. It is probably
another bug that mutt_dotlock attempts to create a temporary file in
/var/mail instead of using flock().
Fixes:
(1) Change pkg_add and thousands of user scripts to use tar -p. This
may reopen security holes closed by respecting the umask.
%%%
Index: extract.c
===
RCS file: /home/ncvs/src/usr.sbin/pkg_install/add/extract.c,v
retrieving revision 1.33
diff -u -2 -r1.33 extract.c
--- extract.c 11 May 2002 04:17:54 - 1.33
+++ extract.c 1 Aug 2002 10:26:10 -
@@ -33,5 +33,5 @@
#define PUSHOUT(todir) /* push out string */ \
if (where_count (int)sizeof(STARTSTRING)-1) { \
- strcat(where_args, |tar --unlink -xf - -C ); \
+ strcat(where_args, |tar --unlink -pxf - -C ); \
strcat(where_args, todir); \
if (system(where_args)) { \
%%%
(2) Restore standard gnu tar behaviour by backing out extract.c revs 1.2-1.3.
%%%
Index: extract.c
===
RCS file: /home/ncvs/src/contrib/tar/src/extract.c,v
retrieving revision 1.4
diff -u -2 -r1.4 extract.c
--- extract.c 3 Jul 2002 12:44:31 - 1.4
+++ extract.c 1 Aug 2002 10:44:34 -
@@ -113,7 +113,5 @@
{
we_are_root = geteuid () == 0;
-#ifndef __FreeBSD__
same_permissions_option += we_are_root;
-#endif
same_owner_option += we_are_root;
xalloc_fail_func = extract_finish;
%%%
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: pkg_add broken by POLA breakage in tar
Maxim Sobolev wrote:
Bruce Evans wrote:
Revs.1.2-1.3 of tar/src/extract.c break pkg_add (not to mention probably
thousands of user scripts that are no more careful than pkg_add) in
-current and RELENG_4:
Are you sure? My own investigation at the time of the commit showed
that old tar shipped with FreeBSD, was adjusting permissions of
extracting files when running as uid 0 according to current umask
settings, so that IMO 1.2-1.3 actually restored POLA, not broke it.
Need evidence? Here it is:
# cvs co -D 10 months ago src/gnu/usr.bin/tar
[...]
# cd src/gnu/usr.bin/tar
# make
[...]
# mkdir foo
# touch foo/bar
# chmod 777 foo
# chmod 777 foo/bar
# ./tar cvf foo.tar foo
foo/
foo/bar
# rm -rf foo
# ./tar xvf foo.tar
foo/
foo/bar
root@notebook# ls -l | grep foo
drwxr-xr-x 2 root wheel 512 1 âþú 19:01 foo/
-rw-r--r-- 1 root wheel 10240 1 âþú 19:01 foo.tar
root@notebook# ls -l foo
total 0
-rwxr-xr-x 1 root wheel 0 1 âþú 19:01 bar*
# umask
0022
#
-Maxim
-Maxim
% RCS file: /home/ncvs/src/contrib/tar/src/extract.c,v
% Working file: extract.c
% head: 1.4
% branch:
% locks: strict
% access list:
% symbolic names:
% RELENG_4: 1.4.0.2
% TAR_v1_13_25: 1.1.1.1
% FSF: 1.1.1
% keyword substitution: kv
% total revisions: 6; selected revisions: 6
% description:
% ...
%
% revision 1.3
% date: 2002/06/07 06:02:35; author: sobomax; state: Exp; lines: +1 -1
% Disabling automatic --same-owner option when running as uid 0 along with
% the --same-permissions was an overkill, so put it back. This is consistent
% with what our old tar did.
%
% Suggested by: dillon
%
% revision 1.2
% date: 2002/06/07 00:03:23; author: sobomax; state: Exp; lines: +4 -0
% IMO it was a quite ugly idea that if we are running as uid 0 then we can
% safely ignore current umask(2) and assume that permissions should be set
% right like in the archive. Not only it violates POLA, but introduces
^
% huge potential security vulnerability, particularly for ports, where
% many popular archives come with 777 files and dirs.
%
Actually, it is the change violates POLA, and breaks everything that
depends on the historical and still documented behaviour. (The man
page even says that (almost) all permissions are restored even in the
!root case (it says this indirectly by saying that all attributes are
restored if possible and not mentioning the umask or root). The info
page is better.)
This bug showed up as breakage in mutt. mutt uses a setgid utility
named mutt_dotlock to lock /var/mail/*, so it fails to download mail
if mutt_dotlock's setgid bit is lost on extraction. It is probably
another bug that mutt_dotlock attempts to create a temporary file in
/var/mail instead of using flock().
Fixes:
(1) Change pkg_add and thousands of user scripts to use tar -p. This
may reopen security holes closed by respecting the umask.
%%%
Index: extract.c
===
RCS file: /home/ncvs/src/usr.sbin/pkg_install/add/extract.c,v
retrieving revision 1.33
diff -u -2 -r1.33 extract.c
--- extract.c 11 May 2002 04:17:54 - 1.33
+++ extract.c 1 Aug 2002 10:26:10 -
@@ -33,5 +33,5 @@
#define PUSHOUT(todir) /* push out string */ \
if (where_count (int)sizeof(STARTSTRING)-1) { \
- strcat(where_args, |tar --unlink -xf - -C ); \
+ strcat(where_args, |tar --unlink -pxf - -C ); \
strcat(where_args, todir); \
if (system(where_args)) { \
%%%
(2) Restore standard gnu tar behaviour by backing out extract.c revs 1.2-1.3.
%%%
Index: extract.c
===
RCS file: /home/ncvs/src/contrib/tar/src/extract.c,v
retrieving revision 1.4
diff -u -2 -r1.4 extract.c
--- extract.c 3 Jul 2002 12:44:31 - 1.4
+++ extract.c 1 Aug 2002 10:44:34 -
@@ -113,7 +113,5 @@
{
we_are_root = geteuid () == 0;
-#ifndef __FreeBSD__
same_permissions_option += we_are_root;
-#endif
same_owner_option += we_are_root;
xalloc_fail_func = extract_finish;
%%%
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: sshd doesn't log hostname into utmp correctly
Hi,
On 01 Aug 2002 17:18:23 +0200
Dag-Erling Smorgrav [EMAIL PROTECTED] said:
des Hajimu UMEMOTO [EMAIL PROTECTED] writes:
des Could you please submit it to [EMAIL PROTECTED]?
Yes, I'll sent it.
Can I commit it to FreeBSD repo.?
des No, please wait and see what the OpenSSH developers say.
Okay, I just sent my previous patch (+ fix for utmpx part) to
[EMAIL PROTECTED]
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
RE: Comments on Release Building for -current
On Wed, 31 Jul 2002, John Baldwin wrote: On 31-Jul-2002 Chris Knight wrote: ... the mfsroot floppy contents were too large ... the kern floppy contents were too large ... the fixit floppy contents were too large ... Oof. It's like our binaries are suddenly very bloated. Did this start very recently (like in the past few days?) Perhaps -mcpu=pentiumpro bloats things and we should use NO_CPU_FLAGS when building crunches, etc. -mcpu=pentiumpro causes huge bloatage here (+400K text for a 2000K text kernel IIRC). I quickly turned it off here. We might also want to use -Os instead of -O when building the kernels and crunches as well. I'm surprised -Os [-falign...] isn't already the default for crunches. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pkg_add broken by POLA breakage in tar
Maxim Sobolev wrote:
Maxim Sobolev wrote:
Bruce Evans wrote:
Revs.1.2-1.3 of tar/src/extract.c break pkg_add (not to mention probably
thousands of user scripts that are no more careful than pkg_add) in
-current and RELENG_4:
Are you sure? My own investigation at the time of the commit showed
that old tar shipped with FreeBSD, was adjusting permissions of
extracting files when running as uid 0 according to current umask
settings, so that IMO 1.2-1.3 actually restored POLA, not broke it.
OK, further investigation shows that the problem is likely that unlike
the old one, the new tar doesn't preserve suid/sgid bits on
extraction, and it is what probably needs to be fixed instead.
Need evidence? Here it is:
# cvs co -D 10 months ago src/gnu/usr.bin/tar
[...]
# cd src/gnu/usr.bin/tar
# make
[...]
# mkdir foo
# touch foo/bar
# chmod 777 foo
# chmod 777 foo/bar
# ./tar cvf foo.tar foo
foo/
foo/bar
# rm -rf foo
# ./tar xvf foo.tar
foo/
foo/bar
root@notebook# ls -l | grep foo
drwxr-xr-x 2 root wheel 512 1 âþú 19:01 foo/
-rw-r--r-- 1 root wheel 10240 1 âþú 19:01 foo.tar
root@notebook# ls -l foo
total 0
-rwxr-xr-x 1 root wheel 0 1 âþú 19:01 bar*
# umask
0022
#
-Maxim
-Maxim
% RCS file: /home/ncvs/src/contrib/tar/src/extract.c,v
% Working file: extract.c
% head: 1.4
% branch:
% locks: strict
% access list:
% symbolic names:
% RELENG_4: 1.4.0.2
% TAR_v1_13_25: 1.1.1.1
% FSF: 1.1.1
% keyword substitution: kv
% total revisions: 6; selected revisions: 6
% description:
% ...
%
% revision 1.3
% date: 2002/06/07 06:02:35; author: sobomax; state: Exp; lines: +1 -1
% Disabling automatic --same-owner option when running as uid 0 along with
% the --same-permissions was an overkill, so put it back. This is consistent
% with what our old tar did.
%
% Suggested by: dillon
%
% revision 1.2
% date: 2002/06/07 00:03:23; author: sobomax; state: Exp; lines: +4 -0
% IMO it was a quite ugly idea that if we are running as uid 0 then we can
% safely ignore current umask(2) and assume that permissions should be set
% right like in the archive. Not only it violates POLA, but introduces
^
% huge potential security vulnerability, particularly for ports, where
% many popular archives come with 777 files and dirs.
%
Actually, it is the change violates POLA, and breaks everything that
depends on the historical and still documented behaviour. (The man
page even says that (almost) all permissions are restored even in the
!root case (it says this indirectly by saying that all attributes are
restored if possible and not mentioning the umask or root). The info
page is better.)
This bug showed up as breakage in mutt. mutt uses a setgid utility
named mutt_dotlock to lock /var/mail/*, so it fails to download mail
if mutt_dotlock's setgid bit is lost on extraction. It is probably
another bug that mutt_dotlock attempts to create a temporary file in
/var/mail instead of using flock().
Fixes:
(1) Change pkg_add and thousands of user scripts to use tar -p. This
may reopen security holes closed by respecting the umask.
%%%
Index: extract.c
===
RCS file: /home/ncvs/src/usr.sbin/pkg_install/add/extract.c,v
retrieving revision 1.33
diff -u -2 -r1.33 extract.c
--- extract.c 11 May 2002 04:17:54 - 1.33
+++ extract.c 1 Aug 2002 10:26:10 -
@@ -33,5 +33,5 @@
#define PUSHOUT(todir) /* push out string */ \
if (where_count (int)sizeof(STARTSTRING)-1) { \
- strcat(where_args, |tar --unlink -xf - -C ); \
+ strcat(where_args, |tar --unlink -pxf - -C ); \
strcat(where_args, todir); \
if (system(where_args)) { \
%%%
(2) Restore standard gnu tar behaviour by backing out extract.c revs 1.2-1.3.
%%%
Index: extract.c
===
RCS file: /home/ncvs/src/contrib/tar/src/extract.c,v
retrieving revision 1.4
diff -u -2 -r1.4 extract.c
--- extract.c 3 Jul 2002 12:44:31 - 1.4
+++ extract.c 1 Aug 2002 10:44:34 -
@@ -113,7 +113,5 @@
{
we_are_root = geteuid () == 0;
-#ifndef __FreeBSD__
same_permissions_option += we_are_root;
-#endif
same_owner_option += we_are_root;
xalloc_fail_func = extract_finish;
%%%
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe
Re: pkg_add broken by POLA breakage in tar
My recollection matches what Bruce says (and I have been using unix since when version 7 was the latest and greatest). At least the SUN OS 5.6 man page I could locate online says this: The o function modifier is only valid with the x function. p Restore the named files to their original modes, and ACLs if applicable, ignoring the present umask(1). This is the default behavior if invoked as super-user with the x function letter specified. If super-user, SETUID and sticky information are also extracted, and files are restored with their original owners and permissions, rather than owned by root. This superuser behavior is what allows one to use tar as an archiving program. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pkg_add broken by POLA breakage in tar
Bakul Shah wrote: My recollection matches what Bruce says (and I have been using unix since when version 7 was the latest and greatest). At least the SUN OS 5.6 man page I could locate online says this: The o function modifier is only valid with the x function. p Restore the named files to their original modes, and ACLs if applicable, ignoring the present umask(1). This is the default behavior if invoked as super-user with the x function letter specified. If super-user, SETUID and sticky information are also extracted, and files are restored with their original owners and permissions, rather than owned by root. This superuser behavior is what allows one to use tar as an archiving program. Well, OK, now I am really confused. So what should we be bound to? To the POLA (old GNU tar in 4.6-release and downward was not fully preserving permissions unless -p is specified, even when invoked by root)? Or to what other systems do? Bruce, what do you think? -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Comments on Release Building for -current
On Fri, Aug 02, 2002 at 02:57:44AM +1000, Bruce Evans wrote: I'm surprised -Os [-falign...] isn't already the default for crunches. -Os is -O2 except for those optimizations which bloat. We don't trust -O2 and thus maybe should not -Os. Hopefully we have found all our bad in-line ASM and -O2 will work for FreeBSD now. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Comments on Release Building for -current
In the last episode (Aug 01), David O'Brien said: On Fri, Aug 02, 2002 at 02:57:44AM +1000, Bruce Evans wrote: I'm surprised -Os [-falign...] isn't already the default for crunches. -Os is -O2 except for those optimizations which bloat. We don't trust -O2 and thus maybe should not -Os. Hopefully we have found all our bad in-line ASM and -O2 will work for FreeBSD now. There is still a libc printf bug at -O2. It causes numbers to be printed with and : characters occasionally. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Comments on Release Building for -current
On 01-Aug-2002 Bruce Evans wrote: On Wed, 31 Jul 2002, John Baldwin wrote: On 31-Jul-2002 Chris Knight wrote: ... the mfsroot floppy contents were too large ... the kern floppy contents were too large ... the fixit floppy contents were too large ... Oof. It's like our binaries are suddenly very bloated. Did this start very recently (like in the past few days?) Perhaps -mcpu=pentiumpro bloats things and we should use NO_CPU_FLAGS when building crunches, etc. -mcpu=pentiumpro causes huge bloatage here (+400K text for a 2000K text kernel IIRC). I quickly turned it off here. Ok. I'll make some patches to use NO_CPU_CFLAGS and NO_CPU_COPTFLAGS when building stuff to go on the crunches as well as -Os. We might also want to use -Os instead of -O when building the kernels and crunches as well. I'm surprised -Os [-falign...] isn't already the default for crunches. Bruce -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pkg_add broken by POLA breakage in tar
On Thu, 1 Aug 2002, Maxim Sobolev wrote: Maxim Sobolev wrote: Maxim Sobolev wrote: Bruce Evans wrote: Revs.1.2-1.3 of tar/src/extract.c break pkg_add (not to mention probably thousands of user scripts that are no more careful than pkg_add) in -current and RELENG_4: Are you sure? My own investigation at the time of the commit showed Oops, apparently not ... that old tar shipped with FreeBSD, was adjusting permissions of extracting files when running as uid 0 according to current umask settings, so that IMO 1.2-1.3 actually restored POLA, not broke it. OK, further investigation shows that the problem is likely that unlike the old one, the new tar doesn't preserve suid/sgid bits on extraction, and it is what probably needs to be fixed instead. Need evidence? Here it is: ... Sorry, I didn't test it at runtime. I don't really like either changing the Gnu/historical behaviour for root or preserving set*id bits while not preserving other attributes, but since this seems have 10 years of precedence in FreeBSD it doesn't break POLA. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
possieble bug in chsh chfn
Desription: unauthorized write access to /etc directory using chfn/chsh commands in FreeBSD 5.0-CURRENT. Contributing factors: In FreeBSD 5.0, it is possible to fill up the whole partition by using chfn/chsh commands. Normally, users have quotas set up on directories that are allowed to be written for them, e.g. home directory, /tmp, /var/tmp, etc. Let's say, a user has quotas set up this way: % quota -u rado Disk quotas for user rado (uid 1001): Filesystem usage quota limit grace files quota limit grace /home 66760 50 553481 0 0 /tmp 135193 26 285417 0 0 ... There's normally no need to set up quotas for other partitions (such as /, /usr, ...) because ordinary users have no permissions to write/change the files in that directories, e.g. in / or /etc. Symptoms: Our experience with the chsh/chfn commands shows that when a user changes his/her finger information/shell, these commands invoke vi editor with a temporary file stored in /tmp. Imagine that a user's quota exceeded his/her limit for /tmp. Our ordinary user did this by filling up /tmp partition with many large files. chfn/chsh commands then stored their temporary files in /etc directory with given user's permissions, e.g.: % id happy uid=2006(happy) gid=58(st1999) groups=58(st1999) % quota -u happy ... /tmp 21995* 2 22000 7days 6 0 0 ... (We can see that the disk quota exceeded in /tmp for user happy) % ls -ld /etc drwxr-xr-x 20 root wheel 22016 Aug 1 19:22 /etc % ls -l /etc | grep happy -rw--- 1 happy st1999157278362 Aug 1 19:19 pw.BEMwxq -rw--- 1 happy st1999 154 Aug 1 19:22 pw.KxGCF3 -rw--- 1 happy st1999157278362 Aug 1 19:19 pw.iW7Pmt -rw--- 1 happy st1999157278362 Aug 1 19:20 pw.rhJq0s -rw--- 1 happy st1999157278374 Aug 1 19:16 pw.tpPLK4 Now it is possible for such a user to fill up the root partition without having a permission set on /, e.g. with % cat /dev/zero /etc/pw.KxGCF3 Workaround: Our workaround is to either set up a quotas for a root partition or disable chsh/chfn commands. Important Notices: 1. chpass, ypchpass, ypchfn, and ypchsh commands seem to be also affected by the symptoms described above because they are just hard links... :) 2. When experimenting with a chpass command, it caused a segmentation fault when used with -a argument because of a NULL pointer comparation in chpass.c, line 169: (no getpw* (3) library call invoked!!!) if ((pw-pw_fields _PWF_SOURCE) == _PWF_NIS) % id happy uid=2006(happy) gid=58(st1999) groups=58(st1999) % chpass -a q Segmentation fault chpass doesn't seem to be locally exploitable. Some changes to a source code are needed for normal operation. Credits: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- -- bye R.R.K.K. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Any estimate for -DP2 date?
I've been reading -current for a while and waiting for an island of relative stability to show up, ideally -DP2, so that I can install it on my own home systems and start exploring the new release track. I doubt I'm going to be able to contribute much to the kernel dev, which is why I'm not already tracking day by day, but I thought I might be able to test compatibility and stability for various apps I'm familiar with in advance of the 5.0 release, and offer feedback on that front. It's clear from the list that we are not yet relatively stable enough for -DP2, regardless of the date. Does anyone have a good gut feel for when that might arrive? -- Clifton -- Clifton Royston -- LavaNet Systems Architect -- [EMAIL PROTECTED] What do we need to make our world come alive? What does it take to make us sing? While we're waiting for the next one to arrive... - Sisters of Mercy To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic on boot, acpica related?
Terry Lambert wrote: Michael Nottebrock wrote: I tweaked my BIOS to assign a different irq (9) to the NIC and now the kernel boots and runs my old userland quite nicely. The old kernel ran perfectly well with the NIC on irq10 ... strange. None of your other postings identified the devices also on IRQ10. If I had to guess... USB? Almost everything. sym0, csa0, bktr0, atapci1, drm0 ... and USB, but since I can only change IRQs per 'pin', fxp0 still shares its IRQ with USB now. :] Regards, -- Michael Nottebrock The circumstance ends uglily in the cruel result. - Babelfish msg41610/pgp0.pgp Description: PGP signature
Re: kernel panic on boot, acpica related?
Michael Nottebrock wrote: I tweaked my BIOS to assign a different irq (9) to the NIC and now the kernel boots and runs my old userland quite nicely. The old kernel ran perfectly well with the NIC on irq10 ... strange. None of your other postings identified the devices also on IRQ10. If I had to guess... USB? Almost everything. sym0, csa0, bktr0, atapci1, drm0 ... and USB, but since I can only change IRQs per 'pin', fxp0 still shares its IRQ with USB now. :] I know it's work, but it'd probably be worthwhile to track down which device(s), when sharing the same IRQ, cause the problem, so that it can be fixed, instead of the next person having to work around it, too. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Wierd routing Problems
Apparently, On Fri, Aug 02, 2002 at 12:02:28AM +0200, Sten said words to the effect of; I am currently running Current on an u60 and it seems to be running quite nicely minus some gotchas and not yet working ports. Thanks for the hard work. I do however have one pretty strange problem. Some apps cant seem to route properly, aka they cant reach remote hosts because routing lookups bork. The box has a ipv4 default gateway, propper subnetmask, I tried kernels without ipv6 ( didnt help ). The problem only shows up with certain apps. I haven't noticed much out of the ordinary, but I don't use the programs you mention. I would suspect this is a 64bit and/or endian-ness problem somewhere; someone mentioned a while ago that ncftp doesn't work on alpha either. Jake Par expample ntpd from system : newpeer: 62.250.7.101-213.196.8.44 mode 3 vers 4 poll 6 10 flags 1 1 ttl 0 key peer_clear: at 0 assoc ID 0 key_expire: at 0 newpeer: 127.0.0.1-127.127.1.0 mode 3 vers 4 poll 6 6 flags 21 1 ttl 0 key report_event: system event 'event_restart' (0x01) status 'sync_alarm, sync_unspec, 1 event, event_unspec' (0xc010) auth_agekeys: at 1 keys 1 expired 0 key_expire: at 1 key_expire: at 1 expire_all: at 1 key expire: at 1 next 65536 transmit: at 10 62.250.7.101-213.196.8.44 mode 3 refclock_transmit: at 11 127.127.1.0 refclock_receive: at 11 127.127.1.0 peer LOCAL(0) event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014) refclock_sample: n 1 offset 0.00 disp 0.01 jitter 0.00 Versus ntpd on stable : snip newpeer: 213.196.8.44-194.109.6.65 mode 3 vers 4 poll 6 10 flags 1 1 ttl 0 key transmit: at 4 213.196.8.44-193.79.237.14 mode 3 receive: at 4 213.196.8.44-193.79.237.14 mode 4 code 1 peer 193.79.237.14 event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014) clock_filter: n 1 off 0.005574 del 0.010882 dsp 7.937531 jit 0.61, age 0 ( looks like the transmit: routing wanders of into the woods :) Ncftp2/3 seem to bork in a somewhat similar way : Hi. No need to log in; I'm an anonymous ftp server. Logged in to ftp.openwall.com. ncftp / ls List failed. ncftp / quit Could not bind the data socket: Can't assign requested address I was wondering if this a known problem, feel free to slap me with a large trout if this is a local config problem. Thanks in advance for any help. -- Sten Spans What does one do with ones money, when there is no more empty rackspace ? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-sparc in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Bug in setlocale()
On Thu, Aug 01, 2002 at 15:43:56 +0200, Alexander Leidinger wrote: Hi, we have a bug in setlocale(), it writes past static char new_categories[_LC_LAST][ENCODING_LEN + 1]; in the do-while loop around line 159. Thanx, fixed. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
