Re: cbb attach failed
From: KT Sin [EMAIL PROTECTED] Subject: Re: cbb attach failed Date: Sun, 15 Dec 2002 13:29:42 +0800 Message-ID: [EMAIL PROTECTED] If your CURRENT is pretty recent, please add into your /boot/loader.conf hw.pci.allow_unsupported_io_range=1 and then reboot. it works file. thanks a lot. regards, To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rcng script bugs
[ cc'ed imp@ since the second one concerns changes he recently made ]
On Sat, Dec 14, 2002 at 02:24:12PM -0800, Galen Sampson wrote:
17c17
pidfile=/var/run/${name}.pid
---
pidfile=/var/run/${name}/pid
in order to match the default named.conf file.
Yes, definitely a bug. I had changed my named.conf so I didn't notice
this. However, I think your solution is just as broken as the current
code. While it would work if the user doesn't change the default
pid path, it wouldn't work for people who do change it (like me).
I think the way to solve it is with a named_pidfile variable in
defaults/rc.conf that defaults to /var/run/named/pid. What are people's
thoughts on this? Secondly, the change would have to go into the
'FreeBSD' case-clause in order not to mess up the NetBSD case.
/etc/rc.d/network1:
When using a diskless configuration this file took the interface offline,
preventing the machine from booting. I noticed that a change has been added to
check if an interface is up and skip configuring it if it is. Instead of using
grep it is possible to use ifconfig's -d option (see man page) to only list
interfaces marked as down. This is my change for /etc/rc.d/network1
140c140
network_interfaces=`ifconfig -l -d`
---
network_interfaces=`ifconfig -l`
148a149,153
if ifconfig ${ifn} | grep -s UP, /dev/null 21; then
# Interface is already up, so ignore it.
continue;
fi
Warner,
He's working off the first set of changes you made but it seems
that in the diskless case you may have to reconfigure more
than just lo0.
Cheers.
--
Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9
msg48762/pgp0.pgp
Description: PGP signature
Re: rcng script bugs
[ ok, really cc him this time]
On Sun, Dec 15, 2002 at 01:02:51AM -0800, Mike Makonnen wrote:
[ cc'ed imp@ since the second one concerns changes he recently made ]
On Sat, Dec 14, 2002 at 02:24:12PM -0800, Galen Sampson wrote:
17c17
pidfile=/var/run/${name}.pid
---
pidfile=/var/run/${name}/pid
in order to match the default named.conf file.
Yes, definitely a bug. I had changed my named.conf so I didn't notice
this. However, I think your solution is just as broken as the current
code. While it would work if the user doesn't change the default
pid path, it wouldn't work for people who do change it (like me).
I think the way to solve it is with a named_pidfile variable in
defaults/rc.conf that defaults to /var/run/named/pid. What are people's
thoughts on this? Secondly, the change would have to go into the
'FreeBSD' case-clause in order not to mess up the NetBSD case.
/etc/rc.d/network1:
When using a diskless configuration this file took the interface offline,
preventing the machine from booting. I noticed that a change has been added to
check if an interface is up and skip configuring it if it is. Instead of using
grep it is possible to use ifconfig's -d option (see man page) to only list
interfaces marked as down. This is my change for /etc/rc.d/network1
140c140
network_interfaces=`ifconfig -l -d`
---
network_interfaces=`ifconfig -l`
148a149,153
if ifconfig ${ifn} | grep -s UP, /dev/null 21; then
# Interface is already up, so ignore it.
continue;
fi
Warner,
He's working off the first set of changes you made but it seems
that in the diskless case you may have to reconfigure more
than just lo0.
Cheers.
--
Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9
--
Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9
msg48763/pgp0.pgp
Description: PGP signature
Re: 80386 out of GENERIC
On Sun, Dec 15, 2002 at 12:18:21AM -0500, Craig Reyenga wrote: Sorry for butting in, but my $.02 is that 386's are old enough that FreeBSD, or any other OS for that matter, shouldn't wait up for them. Why not? An OS in itself should not require a lot of CPU power. They've gotten to the point where they are basically useless except for running older software, which was likely written for them anyways. They are not useless, and if new software has problems running on them it is mostly because a lot of new software is big and bloated without any good reason except for lazy/incompetent programmers. If I had a 386 that I wanted FreeBSD on, I'd crack open the old FreeBSD 3.5 install CD's, assuming it even had a cdrom drive. I understand why people care about supporting older hardware. Reasons such as cost, and the ability to allow code bloat to _really_ manifest itself come to mind. However, a 386 is just too old for words and should be running older software with less features. Less features and more security problems. Considering that security fixes normally don't get applied to the 3.x branch any longer one might want to be a bit careful running that on a computer connected to the Net. Eventually I assume that 4. will be similarily abandoned which means that you will have to run 5.x to have a secure system. Personally I strongly disagree with the notion that hardware that is a mere 10 years old (like some '386s) should be considered too old for words. The only remotely good reason I have heard for removing support for 386 in the default configuration is that having it in would pessimize performance too much for more modern CPUs. How valid that reason is I cannot judge, but I guess it is possible. (And just FYI, my 386 box is happily running 4.7-stable at the moment without any problems and I will probably consider updating it to 5.x when security fixes are no longer automatically applied to 4.x.) -Craig - Original Message - From: Terry Lambert [EMAIL PROTECTED] To: M. Warner Losh [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, December 14, 2002 23:55 Subject: Re: 80386 out of GENERIC M. Warner Losh wrote: One problem with most 386 boxes is that they have very little memory. sysinstall is a big, bloated pig dog these days that takes more RAM than most 386 boxes have. This is true also for many 486 boxes too. So even if 386 stuff were in the default kernel, you'd likely have other issues in making sysinstall work and have to do custom hacking... Add to this that Bosko's workaround for the CPU bug with PSE/PGE includes loading the kernel at 4M rather than 1M. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
On Sun, 15 Dec 2002, Erik Trulsson wrote: The only remotely good reason I have heard for removing support for 386 in the default configuration is that having it in would pessimize performance too much for more modern CPUs. How valid that reason is I cannot judge, but I guess it is possible. Could someone enlighten me as to why we don't leave 386 support in for the boot kernel so the floppies will at least boot? Note that performance shouldn't be an issue when installing. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
In message [EMAIL PROTECTED], Nate Lawson wri tes: On Sun, 15 Dec 2002, Erik Trulsson wrote: The only remotely good reason I have heard for removing support for 386 in the default configuration is that having it in would pessimize performance too much for more modern CPUs. How valid that reason is I cannot judge, but I guess it is possible. Could someone enlighten me as to why we don't leave 386 support in for the boot kernel so the floppies will at least boot? Note that performance shouldn't be an issue when installing. Because few if any 80386 computers have the ram it takes to run sysinstall. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. 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 /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sun Dec 15 10:09:17 GMT 2002 -- === ipfilter cc1: warnings being treated as errors /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot': /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:542: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:557: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs1': /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1002: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs2': /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1278: warning: cast to pointer from integer of different size *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ia64 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/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sun Dec 15 04:07:46 PST 2002 -- === xe /home/tinderbox/ia64/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:482: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:520: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:590: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:593: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/dev/acpica/acpi_powerres.c:272: warning: `acpi_pwr_deregister_consumer' defined but not used /home/tinderbox/ia64/src/sys/dev/acpica/acpi_powerres.c:210: warning: `acpi_pwr_deregister_resource' defined but not used cc1: warnings being treated as errors /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot': /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c:542: warning: cast to pointer from integer of different size /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c:557: warning: cast to pointer from integer of different size /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs1': /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c:1002: warning: cast to pointer from integer of different size /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs2': /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c:1278: warning: cast to pointer from integer of different size *** Error code 1 Stop in /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/sys/GENERIC. *** Error code 1 Stop in /home/tinderbox/ia64/src. *** Error code 1 Stop in /home/tinderbox/ia64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
arla 0.35.11 on FreeBSD 5.0-RC1
Hi,
I tried to compile arla 0.35.11 on FreeBSD 5.0-RC1. Fisrt I got
following error:
checking for udev2dev in kernel... yes
checking for snprintf in kernel... yes
checking for nosys in kernel... yes
checking for sys_nosys in kernel... no
checking for sys_lkmnosys in kernel... no
checking for cache_purgevfs in kernel... yes
checking for vfs_name_hash in kernel... no
checking for memcpy in kernel... yes
checking if vnode_if.h needs to be built... configure: error: unable to find any
vnode_if script
So I have linked
-su-2.05b# ln -s /sys/i386/compile/EVENSTAR/vnode_if.h /usr/include/vnode_if.h
Then configre and make proceeds until it stops on error shown
below my siganture. Can anybody help?
Thanks very much,
Petr
PS: I know I'm sendin almost the same mail as last time but it's
quite important for me to get it solved.
Petr Holub
CESNET z.s.p.o. Supercomputing Center Brno
Zikova 4 Institute of Compt. Science
160 00 Praha 6, CZMasaryk University
Czech Republic Botanicka 68a, 60200 Brno, CZ
e-mail: [EMAIL PROTECTED] phone: +420-5-41512213
e-mail: [EMAIL PROTECTED]
SUBDIRS='bsd'; for i in $SUBDIRS; do (cd $i make all); done
for i in /usr/include/sys/vnode_if.h vnode_if.h; do if test -r $i; then awk
^struct vop_[a-z]*_args/ { printf(#define HAVE_%s 1\n, toupper(substr($2,1,l
gth($2)-5))); }' $i xfs_vopdefs.h; break; fi; done
mkdir xfs
mkdir: xfs: File exists
*** Error code 1 (ignored)
test -d xfs ( test -f xfs/xfs_vopdefs.h || ln -s ../xfs_vopdefs.h xfs/xfs_v
defs.h )
touch stamp-xfs_vopdefs.h
gcc -c -DHAVE_CONFIG_H -I. -I. -I../../include -I./../../include -I./../inc
de -I/usr/athena/include -DXFS_DEBUG -DINET6 -g -Wall -Wmissing-prototypes -
ointer-arith -Wbad-function-cast -Wmissing-declarations -Wnested-externs -O
KERNEL -D_KERNEL -DVFS_KLD -DKLD_MODULE -I/sys/arch -I/sys -I. -Wno-unused xfs
eb.c
gcc -c -DHAVE_CONFIG_H -I. -I. -I../../include -I./../../include -I./../inc
de -I/usr/athena/include -DXFS_DEBUG -DINET6 -g -Wall -Wmissing-prototypes -
ointer-arith -Wbad-function-cast -Wmissing-declarations -Wnested-externs -O
KERNEL -D_KERNEL -DVFS_KLD -DKLD_MODULE -I/sys/arch -I/sys -I. -Wno-unused xfs
essage.c
In file included from /sys/sys/systm.h:45,
from xfs/xfs_locl.h:137,
from xfs_message.c:34:
/usr/include/machine/atomic.h: In function `atomic_load_acq_ptr':
/usr/include/machine/atomic.h:371: warning: cast does not match function type
In file included from xfs/xfs_locl.h:137,
from xfs_message.c:34:
/sys/sys/systm.h: At top level:
/sys/sys/systm.h:171: warning: built-in function `bzero' declared as non-funct
n
In file included from xfs_message.c:34:
xfs/xfs_locl.h:291:29: xfs/xfs_vopdefs.h: No such file or directory
xfs_message.c: In function `xfs_message_installroot':
xfs_message.c:67: structure has no member named `v_flag'
xfs_message.c:67: `VROOT' undeclared (first use in this function)
xfs_message.c:67: (Each undeclared identifier is reported only once
xfs_message.c:67: for each function it appears in.)
xfs_message.c: In function `xfs_message_installnode':
xfs_message.c:92: warning: passing arg 3 of `vget' from incompatible pointer t
e
xfs_message.c: In function `xfs_message_installdata':
xfs_message.c:174: warning: passing arg 3 of `vget' from incompatible pointer
pe
xfs_message.c:195: warning: passing arg 6 of `NDINIT' from incompatible pointe
type
xfs_message.c:202: warning: passing arg 3 of `VOP_UNLOCK' from incompatible po
ter type
xfs_message.c: In function `xfs_message_invalidnode':
xfs_message.c:320: warning: passing arg 3 of `vrecycle' from incompatible poin
r type
xfs_message.c: In function `gc_vnode':
xfs_message.c:428: warning: implicit declaration of function `simple_lock'
xfs_message.c:443: warning: implicit declaration of function `simple_unlock'
*** Error code 1
Stop in /usr/tmp/ics/arla-0.35.11/xfs/bsd.
*** Error code 1
Stop in /usr/tmp/ics/arla-0.35.11/xfs.
*** Error code 1
Stop in /usr/tmp/ics/arla-0.35.11.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
[no subject]
subscribe freebsd-current 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 /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sun Dec 15 16:09:34 GMT 2002 -- === ipfilter cc1: warnings being treated as errors /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot': /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:542: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:557: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs1': /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1002: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs2': /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1278: warning: cast to pointer from integer of different size *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
[EMAIL PROTECTED] wrote: Because few if any 80386 computers have the ram it takes to run sysinstall. Was sysinstall around when 386 was new? Just curious what's changed since then to make it bigger. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
Was sysinstall around when 386 was new? No, and neither was FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
currentstable jail problem
Hi,
I've got a problem with jail(2), that affects both -STABLE and
-CURRENT (Tested on a 4.7-RELEASE and on a CURRENT updated the 12/14/2002,
both on i386)
I've found a reference to this problem in PR kern/26506, but it's 1,5years
old and it's still not fixed, and I think I've also found a problem in the
patch provided with the PR (see the explanation of this 2nd problem just
before my patch)
I) Description of the original problem
In a jail, when you open an UDP socket, then use sendto() several times to
send UDP packets, only the first sendto() works, the others fail with
EINVAL.
The problem occurs only when you don't bind() the socket before sendto()
(and therefore let the kernel set the source port)
Here is a sample program to demonstrate this. It will work fine outside
jail(2) but it will fail with err msg sendto: Invalid argument inside a
jail.
#include sys/types.h
#include sys/socket.h
#include netinet/in.h
#include arpa/inet.h
#include stdio.h
#include unistd.h
int main(void) {
struct sockaddr_in pom;
int s,r;
s = socket(PF_INET, SOCK_DGRAM, 0);
pom.sin_family = AF_INET;
pom.sin_addr.s_addr = inet_addr(123.123.123.123);
pom.sin_port = htons(4242);
sendto(s, test, 4, 0, (struct sockaddr *) pom, sizeof(pom));
r = sendto(s, test, 4, 0, (struct sockaddr *) pom, sizeof(pom));
if (r == -1) {
perror(sendto);
close(s);
exit(1);
}
printf(All is OK\n);
close(s);
exit(0);
}
I've attempted to find out why this problem occurs. (These investigations
were done on a 4.7-RELEASE, with the 4.7-RELEASE source, because I didn't
have a box with -CURRENT available, but the bug exists also on -CURRENT) :
sendto() will eventually call udp_output() (sys/netinet/udp_usrreq.c)
udp_output() will call in_pcbconnect()
If we are in a jail, and the socket's local IP is INADDR_ANY,
in_pcbconnect() will call in_pcbbind() to assign the prison IP address
(and a localport between 1024 and 5000) to our not-yet-bound socket.
in_pcbconnect() returns, the packet is sent, etc...
Then this bit of code in udp_output() resets inp-inp_laddr to its old value
(which, in our case, is INADDR_ANY):
if (addr) {
in_pcbdisconnect(inp);
inp-inp_laddr = laddr; /* XXX rehash? */
splx(s);
}
So when sendto() returns, the local IP of the socket is set to
INADDR_ANY, and the local port is set, between 1024 and 5000.
When you call the next sendto(), the following thing occurs:
Because we are in a jail and the socket's local IP is still to INADDR_ANY,
in_pcbconnect() calls in_pcbbind(), and in_pcbbind() fails because the local
port IS set:
if (inp-inp_lport || inp-inp_laddr.s_addr != INADDR_ANY)
return (EINVAL);
This does not occur outside jail(2) because when the local port is already
set, in_pcbbind() is not called by in_pcbconnect, and the local IP is set by
another way, later in in_pcbconnect():
if (inp-inp_laddr.s_addr == INADDR_ANY) {
if (inp-inp_lport == 0) {
error = in_pcbbind(inp, (struct sockaddr *)0, p);
if (error)
return (error);
}
inp-inp_laddr = ifaddr-sin_addr;
}
I've attempted to fix the problem by modifying in_pcbconnect(), so it will
not call in_pcbbind() anymore if we're in a jail and local IP is not set.
Instead it will check with ifa_ifwithaddr() if the prison IP address is
available, and assigning it to inp-inp_laddr (the same way we do outside a
jail)
II) Description of the problem that the PR kern/26506 patch introduces:
The patch provided in the PR kern/26506 has a problem: If the prison IP is
an alias for an interface, the sendto() sends the packets coming from the
primary IP of the interface, and not the alias.
III) My attempt at solving the problem :)
I'm not very experienced with FreeBSD kernel programming, so I'm not sure
that's the right way to fix it, but anyway here's the patch for
sys/netinet/in_pcb.c: (tested on 4.7-RELEASE)
---
--- in_pcb.c.oldSun Dec 15 00:09:00 2002
+++ in_pcb.cSun Dec 15 12:56:27 2002
@@ -505,9 +505,10 @@
sa.sin_addr.s_addr = htonl(p-p_prison-pr_ip);
sa.sin_len=sizeof (sa);
sa.sin_family = AF_INET;
- error = in_pcbbind(inp, (struct sockaddr *)sa, p);
- if (error)
- return (error);
+ if (TAILQ_EMPTY(in_ifaddrhead)) /* XXX same as in_pcbbind() */
+ return (EADDRNOTAVAIL);
+ if (ifa_ifwithaddr((struct sockaddr *) sa) == 0)
+ return (EADDRNOTAVAIL);
}
/*
Re: 80386 out of GENERIC
In message [EMAIL PROTECTED], walt writes: [EMAIL PROTECTED] wrote: Because few if any 80386 computers have the ram it takes to run sysinstall. Was sysinstall around when 386 was new? Just curious what's changed since then to make it bigger. sysinstall arrived in the 486 days. Lots of junk has been added since, but I think most of the bloating is from added kernel stuff, IPv6, PCcard, PCI, USB and so on. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
su(1) problem on -current
On a laptop running current, I have a problem using the su program multiple times (nested). I have two accounts, I'll call them auser and buser. I use auser for my everyday activities; it has no special privileges. buser is a member of the wheel group. I don't make auser a member of wheel because that grants some extra rights (such as reading select log files) that I don't want my normal account to have. The following works as expected: (log in as auser) $ id uid=1002(auser) gid=1002(auser) groups=1002(auser) $ su - su: Sorry $ (log in as buser) $ id uid=1001(buser) gid=1001(buser) groups=1001(buser), 0(wheel) $ su - Password: # Okay, that all works fine. The problem appears when I try to do what worked on STABLE, and up until about 3-4 months ago, worked on current as well. (log in as auser) $ id uid=1002(auser) gid=1002(auser) groups=1002(auser) $ su - buser Password: $ id uid=1001(buser) gid=1001(buser) groups=1001(buser), 0(wheel) $ su - su: Sorry $ So, even though I'm in the wheel group after the first su, it won't let me su to root (doesn't even prompt for password). It seems to make no difference whether I use the -l option to su or not. Is this PAM related? I'm currently using sudo as a workaround, but IMHO this looks like a bug to me. Thanks, Craig To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
In message: [EMAIL PROTECTED] Matthew Dillon [EMAIL PROTECTED] writes: : :I disagree with committing this hack; keep it as a local mod if you must. : : : :As to the problem; don't wait for Luigi to fix the ABI problems, do it : :yourself. Good things happen when folks are PO'd and won't settle for the : :status quo. : : : :Sam : : I'm sorry you disagree, but it doesn't change my position. I am not : in the business of rewriting other people's APIs. If it means so much : to you, YOU go and fix it. No? Then don't complain about my fix. It's : no skin off your nose and it will prevent a lot of future headaches, : especially if the RC system makes it nice and friendly. I don't like the patch from a security standpoint. It makes it to easy to turn off a firewall. If you want to be that stupid about security, you should just make the default be 'accept all' and be done with it. I'm opposed to this patch unless you can get the security officer to sign off on it. The defaults are there for a reason so that we fail 'safe' from a security point of view. The real fix is to fix the abi problems. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
:I don't like the patch from a security standpoint. It makes it to :easy to turn off a firewall. If you want to be that stupid about :security, you should just make the default be 'accept all' and be done :with it. I'm opposed to this patch unless you can get the security :officer to sign off on it. The defaults are there for a reason so :that we fail 'safe' from a security point of view. : :The real fix is to fix the abi problems. : :Warner This is complete BULLSHIT, Warner. This patch exists precisely so the firewall can be turned on in secure mode. It does not make it any easier to turn off then adding a rule: ipfw add 2 allow all from any to any So don't give me this bullshit about the patch being a security issue. YOU KNOW IT ISN'T. Now you are forcing me to go to core. It's absolutely ridiculous and you know it. Goddamn it, next time I won't even bother posting if all I get is this sort of crap. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
: :The real fix is to fix the abi problems. : :Warner Doh!!Thanks for volunteering to fix the ABI problems. No? You don't want to do it? Gee, I saw that one coming a mile away! THEN DON'T COMPLAIN. This is not a fucking security issue. This is a patch that solves a major irritation, nothing more, nothing less, except some people can't stand an 8-line fix to the problem apparently. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ia64 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/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sun Dec 15 10:07:13 PST 2002 -- === xe /home/tinderbox/ia64/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:482: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:520: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:590: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:593: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/dev/acpica/acpi_powerres.c:272: warning: `acpi_pwr_deregister_consumer' defined but not used /home/tinderbox/ia64/src/sys/dev/acpica/acpi_powerres.c:210: warning: `acpi_pwr_deregister_resource' defined but not used cc1: warnings being treated as errors /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot': /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c:542: warning: cast to pointer from integer of different size /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c:557: warning: cast to pointer from integer of different size /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs1': /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c:1002: warning: cast to pointer from integer of different size /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs2': /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c:1278: warning: cast to pointer from integer of different size *** Error code 1 Stop in /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/sys/GENERIC. *** Error code 1 Stop in /home/tinderbox/ia64/src. *** Error code 1 Stop in /home/tinderbox/ia64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
Hi, On Sun, Dec 15, 2002 at 10:26:22AM -0800, Matthew Dillon wrote: This is complete BULLSHIT, Warner. This patch exists precisely so the firewall can be turned on in secure mode. It does not make it any easier to turn off then adding a rule: ipfw add 2 allow all from any to any So don't give me this bullshit about the patch being a security issue. YOU KNOW IT ISN'T. Now you are forcing me to go to core. It's absolutely ridiculous and you know it. Goddamn it, next time I won't even bother posting if all I get is this sort of crap. How about sending the patch to the Technical Review Board, trb@ instead. Thanks. Cheers, -- Anders. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
:How about sending the patch to the Technical Review Board, trb@ instead. : :Thanks. : :Cheers, : :-- :Anders. Getting bored sitting on your buns? It's already gone to core and, frankly, I think core is the proper forum now that Warner has declared it a security issue (when it obviously isn't. How easy is it to do an ipfw add 2 allow all from any to any? It's ludicrous to call it a security issue). I really don't mind people disagreeing, but I do mind it when people believe that the proper solution is for Matt Dillon to spend a man week fixing a major API that he didn't write instead of comitting an 8 line patch that deals with the issue well enough so sysads don't have to pull their hair out every time it happens. As I said before, I have no problem with the patch being removed once the API is fixed, but I am NOT the guy who should be rewriting the API and, frankly, it is inappropriate for anyone to suggest that I should be if they themselves are not willing to sit down in front of a keyboard and come up with a committable solution of their own. So far all I've heard are utterly trivial complaints from people who aren't willing to code up a solution themselves. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
On Sun, 15 Dec 2002 10:26:22 -0800 (PST) Matthew Dillon [EMAIL PROTECTED] wrote: Hi, must...resist... So don't give me this bullshit about the patch being a security issue. YOU KNOW IT ISN'T. No, Warner has a point, that patch is simply bandaid (albeit a good one). Now you are forcing me to go to core. It's absolutely ridiculous and you know it. Goddamn it, next time I won't even bother posting if all I get is this sort of crap. I know I'm gonna get flamed for this, but you know what's ridiculous? All the flamage you've brought up on the issue. You're a great hacker Matt, just keep it easy and don't take it so personal. Cheers, -- Miguel Mendez - [EMAIL PROTECTED] GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk Of course it runs NetBSD! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
:This is complete BULLSHIT, Warner. Your attitude it totally unacceptible. Learn to play well with others, or get the fuck out of the project. I am *NOT* blocking you. I'm telling you you need to get the SO's sign off to make sure that there isn't a security issue because the current defaults were set by the so. If you don't like that, then I suggest that you get over yourself and find someplace else to play. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
In message: [EMAIL PROTECTED] Matthew Dillon [EMAIL PROTECTED] writes: : : : :The real fix is to fix the abi problems. : : : :Warner : : Doh!!Thanks for volunteering to fix the ABI problems. No? You : don't want to do it? Gee, I saw that one coming a mile away! : THEN DON'T COMPLAIN. GET OVER YOURSELF. YOUR CONTIRBUTES ARE NOT GREAT ENOUGH THAT I WILL TOLERATE THIS BULLSHIT ANYMORE. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
: :In message: [EMAIL PROTECTED] :Matthew Dillon [EMAIL PROTECTED] writes: :: : :: :The real fix is to fix the abi problems. :: : :: :Warner :: :: Doh!!Thanks for volunteering to fix the ABI problems. No? You :: don't want to do it? Gee, I saw that one coming a mile away! :: THEN DON'T COMPLAIN. : :GET OVER YOURSELF. YOUR CONTIRBUTES ARE NOT GREAT ENOUGH THAT I WILL :TOLERATE THIS BULLSHIT ANYMORE. : :Warner Bullshit is exactly what it is Warner, but I'm not the one spouting it. When all is said and done, this patch is utterly trivial and doesn't hurt anyone. I have said on multiple occassions that it can be removed when the API is fixed, but I am not willing to wait for the API to be fixed because the API has been an open issue for, what, a year now? More? If you want to fix the API then you should go and fix it. I should have just comitted the damn thing rather then ask for a review on the mailing list. I should know better by now. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
: ::This is complete BULLSHIT, Warner. : :Your attitude it totally unacceptible. Learn to play well with :others, or get the fuck out of the project. : :I am *NOT* blocking you. I'm telling you you need to get the SO's :sign off to make sure that there isn't a security issue because the :current defaults were set by the so. If you don't like that, then I :suggest that you get over yourself and find someplace else to play. : :Warner This is not a security issue. Why do you think it is? How is 'ipfw unbreak' any different from 'ipfw add 2 allow all from any to any'? (Other then the fact that unbreak is immune from API changes). Have you even bothered to read the patch? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
: ::This is complete BULLSHIT, Warner. : :Your attitude it totally unacceptible. Learn to play well with :others, or get the fuck out of the project. Really? You think I should learn to play well with others? You think it's appropriate to request that I spend a man week rewriting an API? You really do? You think it's appropriate to bring up a bogus security issue when its obvious that no security issue exists, abusing your power in that manner is playing well with others? This is Warner of core? When people say and do reasonable things I am a reasonable guy. When people say and do unreasonable things then I fight tooth and nail. It's that simple. If you don't like it, then tough. There is nothing unreasonable about this patch. NOTHING. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
In message: [EMAIL PROTECTED]
Matthew Dillon [EMAIL PROTECTED] writes:
:
: :
: ::This is complete BULLSHIT, Warner.
: :
: :Your attitude it totally unacceptible. Learn to play well with
: :others, or get the fuck out of the project.
: :
: :I am *NOT* blocking you. I'm telling you you need to get the SO's
: :sign off to make sure that there isn't a security issue because the
: :current defaults were set by the so. If you don't like that, then I
: :suggest that you get over yourself and find someplace else to play.
: :
: :Warner
:
: This is not a security issue. Why do you think it is? How is
: 'ipfw unbreak' any different from 'ipfw add 2 allow all from any to any'?
: (Other then the fact that unbreak is immune from API changes).
:
: Have you even bothered to read the patch?
Yes, I have. It potentially has security implications because it is a
security part of the system. That's why I think it would be valuable
to get the SO's input on what you are doing. I've read the patch. It
makes it possible with one ioctl to turn off the firewall to allow you
to use the system. That needs careful reviewed.
In fact, it has one flaw. You'll find on lines
/*
* Disallow modifications in really-really secure mode, but still allow
* the logging counters to be reset.
*/
if (sopt-sopt_name == IP_FW_ADD ||
(sopt-sopt_dir == SOPT_SET sopt-sopt_name != IP_FW_RESETLOG)) {
#if __FreeBSD_version = 500034
error = securelevel_ge(sopt-sopt_td-td_ucred, 3);
if (error)
return (error);
#else /* FreeBSD 4.x */
if (securelevel = 3)
return (EPERM);
#endif
}
which you haven't changed. This strikes me as a danger operation to
allow in high security mode, so there likely needs to be some changes
assocaited with the above lines (like an || sopt-sopt_name ==
IP_FW_UNBREAK in the above). Otherwise, an attacker would be able to
turn off the ipfw stuff at a high security level.
I'm not trying to get in your way Matt, I'm just saying that there
needs to be a little discussion on this kludge if you aren't going to
fix the real, underlying problem, ok?
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
In message: [EMAIL PROTECTED] Matthew Dillon [EMAIL PROTECTED] writes: : When people say and do reasonable things I am a reasonable guy. When : people say and do unreasonable things then I fight tooth and nail. : It's that simple. If you don't like it, then tough. There is nothing : unreasonable about this patch. NOTHING. I've answered this in other email, but you need to expand the check at the top of ipfw_ctl to include this new message as one of the ones that is disallowed at high security levels. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
Matthew Dillon wrote: [ useless drivel removed ] There's still a TODO list for 5.0. It was even mailed out to developers@ this morning. If you have time to spare in your day, please focus your attention to that right now. Also, fixing the ipfw2 abi is probably a good item to put on the list for getting 5.x to 5-STABLE. Please don't waste time with band-aids that will make people forget that ipfw2 needs attention. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
:Also, fixing the ipfw2 abi is probably a good item to put on the list :for getting 5.x to 5-STABLE. Please don't waste time with band-aids :that will make people forget that ipfw2 needs attention. : :Scott This is a reasonable line of argument but my opinion is that it hasn't been fixed for a long time now and unless someone decides they really want to tackle the issue soon it isn't going to be fixed for a long time to come, and we shouldn't continue to create a major hassle for developers and sysads that hit up against the issue. I mean, hey, if someone asked me to rename the command from 'ipfw unbreak' to 'ipfw somelonggobblygookthatyouhavetocutandpaste' I'm willing to do that too :-) But we need either the API fixed or this hack and, right now, the only person willing to do anything is me and my buddy Hack. If someone stood up and said I will take on fixing the API but it will take a month then that's fine with me, I would not feel that I would have to commit this now. But so far nobody has stood up and said that. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic with recent CURRENT (1 hour ago)
There was a problem with snapshots that lead to incomplete checking by background fsck which in turn could lead to the problem that you were seeing (i.e., repeated failures until fsck was run manually). This problem was fixed with version 1.54 of ufs/ffs/ffs_snapshot.c which was checked in on Dec 14, 2002. Please verify that you are running with this version. If you had this problem after that conversion please contact me directly so I can try and work out more of the details. Kirk McKusick =-=-=-=-=-= Date: Sat, 14 Dec 2002 21:47:20 +0100 (CET) From: Martin Blapp [EMAIL PROTECTED] To: Kirk McKusick [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: Panic with recent CURRENT (1 hour ago) X-ASK-Info: Confirmed by User Hi Kirk, Panic message was: Block already free. I had to fsck -y manually, but nothing special was found and fixed. The machine rebooted over and over and paniced always at the same place. This shouln't happen I guess. #10 0xc02f055b in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:503 #11 0xc03f9a8a in ffs_blkfree (fs=0xcc27b800, devvp=0xcc284384, bno=370040, size=16384, inum=1400) at /usr/src/sys/ufs/ffs/ffs_alloc.c:1771 #12 0xc0408fcf in indir_trunc (freeblks=0xcc586500, dbn=1481056, level=0, lbn=45068, countp=0xe6928c10) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2603 #13 0xc0408f94 in indir_trunc (freeblks=0xcc586500, dbn=1480064, level=1, lbn=4108, countp=0xe6928c10) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2599 #14 0xc0408a75 in handle_workitem_freeblocks (freeblks=0xcc586500, flags=0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2469 #15 0xc0405c9a in process_worklist_item (matchmnt=0x0, flags=0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:745 #16 0xc04059e0 in softdep_process_worklist (matchmnt=0x0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:624 #17 0xc034337e in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1749 #18 0xc02dcc14 in fork_exit (callout=0xc0343090 sched_sync, arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:872 Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
On Sun, 15 Dec 2002 10:26:22 -0800 (PST), Matthew Dillon [EMAIL PROTECTED] said: Now you are forcing me to go to core. It's absolutely ridiculous and you know it. Goddamn it, next time I won't even bother posting if all I get is this sort of crap. All the better, if you refuse to be civil to your fellow developers. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
:I've answered this in other email, but you need to expand the check at
:the top of ipfw_ctl to include this new message as one of the ones
:that is disallowed at high security levels.
:
:Warner
Here's a new patch. But there isn't much of a point if we do not
also disallow ipfw DELETE and FLUSH. And the pipe config commands
as well as anything else that changes the firewall state. Firewalls
are there to protect the systems behind them. I think deleting the
rule that, say, prevents spoofing is as bad as adding a rule that
allows everything through :-(
-Matt
Matthew Dillon
[EMAIL PROTECTED]
Index: sbin/ipfw/ipfw.8
===
RCS file: /home/ncvs/src/sbin/ipfw/ipfw.8,v
retrieving revision 1.116
diff -u -r1.116 ipfw.8
--- sbin/ipfw/ipfw.826 Nov 2002 19:51:40 - 1.116
+++ sbin/ipfw/ipfw.814 Dec 2002 22:17:17 -
@@ -21,6 +21,9 @@
.Cm flush
.Nm
.Op Fl q
+.Cm unbreak
+.Nm
+.Op Fl q
.Brq Cm delete | zero | resetlog
.Op Cm set
.Op Ar number ...
@@ -179,6 +182,16 @@
and
.Cm resetlog
commands.
+.Pp
+When upgrading your kernel and userland you may wind up in a situation
+where
+.Nm
+is unable to add rules due to a kernel/userland mismatch. If you depend
+on NFS as your install source this can result in a no-win situation.
+You can use the
+.Cm unbreak
+command to flush and install a simple pass-through rule that will allow
+you to get your network up and running so you can resolve the problem.
.Pp
Also, each rule belongs to one of 32 different
.Em sets
Index: sbin/ipfw/ipfw2.c
===
RCS file: /home/ncvs/src/sbin/ipfw/ipfw2.c,v
retrieving revision 1.18
diff -u -r1.18 ipfw2.c
--- sbin/ipfw/ipfw2.c 26 Nov 2002 22:53:14 - 1.18
+++ sbin/ipfw/ipfw2.c 14 Dec 2002 22:08:11 -
@@ -3307,6 +3307,30 @@
printf(Flushed all %s.\n, do_pipe ? pipes : rules);
}
+static void
+unbreak()
+{
+ if (!do_force !do_quiet) { /* need to ask user */
+ int c;
+
+ printf(Are you sure? [yn] );
+ fflush(stdout);
+ do {
+ c = toupper(getc(stdin));
+ while (c != '\n' getc(stdin) != '\n')
+ if (feof(stdin))
+ return; /* and do not flush */
+ } while (c != 'Y' c != 'N');
+ printf(\n);
+ if (c == 'N') /* user said no */
+ return;
+ }
+ if (setsockopt(s, IPPROTO_IP, IP_FW_UNBREAK, NULL, 0) 0)
+ err(EX_UNAVAILABLE, setsockopt(IP_FW_UNBREAK));
+ if (!do_quiet)
+ printf(Flushed all rules and installed a pass-through.\n);
+}
+
static int
ipfw_main(int ac, char **av)
{
@@ -3398,6 +3422,8 @@
delete(ac, av);
else if (!strncmp(*av, flush, strlen(*av)))
flush();
+ else if (!strncmp(*av, unbreak, strlen(*av)))
+ unbreak();
else if (!strncmp(*av, zero, strlen(*av)))
zero(ac, av);
else if (!strncmp(*av, resetlog, strlen(*av)))
Index: sys/netinet/in.h
===
RCS file: /home/ncvs/src/sys/netinet/in.h,v
retrieving revision 1.73
diff -u -r1.73 in.h
--- sys/netinet/in.h29 Oct 2002 16:46:13 - 1.73
+++ sys/netinet/in.h14 Dec 2002 21:32:07 -
@@ -393,6 +393,7 @@
#defineIP_FW_ZERO 53 /* clear single/all firewall counter(s) */
#defineIP_FW_GET 54 /* get entire firewall rule chain */
#defineIP_FW_RESETLOG 55 /* reset logging counters */
+#defineIP_FW_UNBREAK 56 /* flush and install a pass-thru rule */
#defineIP_DUMMYNET_CONFIGURE 60 /* add/configure a dummynet pipe */
#defineIP_DUMMYNET_DEL 61 /* delete a dummynet pipe from chain */
Index: sys/netinet/ip_fw2.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_fw2.c,v
retrieving revision 1.20
diff -u -r1.20 ip_fw2.c
--- sys/netinet/ip_fw2.c15 Dec 2002 09:44:02 - 1.20
+++ sys/netinet/ip_fw2.c15 Dec 2002 19:36:54 -
@@ -2457,7 +2457,7 @@
* Disallow modifications in really-really secure mode, but still allow
* the logging counters to be reset.
*/
- if (sopt-sopt_name == IP_FW_ADD ||
+ if (sopt-sopt_name == IP_FW_ADD || sopt-sopt_name == IP_FW_UNBREAK ||
(sopt-sopt_dir == SOPT_SET sopt-sopt_name != IP_FW_RESETLOG)) {
#if __FreeBSD_version = 500034
error = securelevel_ge(sopt-sopt_td-td_ucred, 3);
@@ -2535,6 +2535,7 @@
break;
case IP_FW_FLUSH:
+
Re: ipfw userland breaks again.
: :On Sun, 15 Dec 2002 10:26:22 -0800 (PST), Matthew Dillon :[EMAIL PROTECTED] said: : : Now you are forcing me to go to core. It's absolutely ridiculous and : you know it. Goddamn it, next time I won't even bother posting if all : I get is this sort of crap. : :All the better, if you refuse to be civil to your fellow developers. : :-GAWollman If people are reasonable with me, I am reasonable right back. If people are unreasonable, they shouldn't expect me to be reasonable in response. It's really that simple. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
swapoff code comitted.
David Schultz's swapoff code has been comitted. It should be regarded as being highly experimental (and it still needs to be vetted for VM locking changes and other recent changes in -current). A considerable amount of testing has been done already but -current is a moving target. I am tentitively planning on MFCing the code in a few weeks (some time after christmas) but it will depend on my schedule. If someone else wants to take on that work I will would be happy to act as a reviewer. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
On Sun, 15 Dec 2002 11:41:26 -0800 (PST), Matthew Dillon [EMAIL PROTECTED] said: If people are reasonable with me, I am reasonable right back. If people are unreasonable, they shouldn't expect me to be reasonable in response. It's really that simple. As a FreeBSD developer, you are expected to be civil to your fellow developers at all times, as stated in the committers' rules. If you can't manage that, please find another project. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: su(1) problem on -current
On Sun, 15 Dec 2002, Craig Boston wrote: On a laptop running current, I have a problem using the su program multiple times (nested). (log in as auser) $ id uid=1002(auser) gid=1002(auser) groups=1002(auser) $ su - buser Password: $ id uid=1001(buser) gid=1001(buser) groups=1001(buser), 0(wheel) $ su - su: Sorry $ So, even though I'm in the wheel group after the first su, it won't let me su to root (doesn't even prompt for password). It seems to make no difference whether I use the -l option to su or not. Is this PAM related? Confirmed. in su.c it seems that pam_authenticate is returning PAM_AUTH_ERR, when it presumably should not be doing so. that's about all I can figure out, PAM is not an area I'm familiar with. 4.x does not have this problem. Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
On Sun, 15 Dec 2002, Matthew Dillon wrote: Here's a new patch. But there isn't much of a point if we do not also disallow ipfw DELETE and FLUSH. And the pipe config commands as well as anything else that changes the firewall state. Firewalls are there to protect the systems behind them. I think deleting the rule that, say, prevents spoofing is as bad as adding a rule that allows everything through :-( One other avenue would be to stick a temporary check for ABI compat in installworld before overwriting ipfw. Or for the next few releases, build both ipfw1 and ipfw2 and install both (say, symlinking ipfw - ipfw2 by default). You could fall back to ipfw1 if ipfw2 returns an error code in rc scripts. I'd prefer this kind of hack in the install/rc process, not in a new API. Regarding civility to developers, there are a ton of frustrating things in any project. I think civility should be the response given to both reasonable and unreasonable people. If they are unreasonable, giving a reasonable response just makes them look bad. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: su(1) problem on -current
On Sun, Dec 15, 2002 at 08:00:55PM +, Gavin Atkinson wrote: Confirmed. in su.c it seems that pam_authenticate is returning PAM_AUTH_ERR, when it presumably should not be doing so. Try getting rid of the auth_as_self in /etc/pam.d/su for the pam_wheel module. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
FBSD 5.0RC1 install oddity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, whe I posted this problem to comp.unix.bsd.freebsd.misc it was suggested to me I should report it to this e-mail addres. I can't yet use send-pr, which was suggtested too, as my FreeBSD installation is not finished yet. This is the oddity I noticed: During installation of FreeBSD 5.0RC1 at some point I was asked if I wanted to configure a network interface, and was proposed to use wi0 which is the wireless lan card. I choose that and was then asked if I want to use DHCP which I agreed to. Problem: After that question the install programm immediatly tries to contact the DHCP server, which cannot work, as informations like the WEP key to use etc. were asked for/supplied so that the wireless card could be properly set up to communicate. I hope this information can help you, and apologize for not having been able to submit a proper report using send-pr. claudio - -- Claudio Nieder, Kanalweg 1, CH-8610 Uster, Tel +41 79 357 6743 yahoo messenger: claudionieder aim: claudionieder icq:42315212 mailto:[EMAIL PROTECTED]http://www.claudio.ch -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9/OTNKS3qZW4vY9IRAhd+AJ0WwMlWT0ECFpU17nloRStOuhQ0OQCePPpi ENdOkVKH0JytJashpFqYKHE= =d+M8 -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
What it comes down to is what developers are willing to do. My contribution is 'ipfw unbreak'. If someone else has a solution that they are willing to work on and commit in the next four weeks, then fine. But if nobody is willing to work on and commit another solution in the next four weeks then I should be able to commit my solution now, which really isn't all that bad hack or not. Any build-related solution would have to be handled by both installworld and installkernel. Consider the fact that most developers, when working on -current, install the kernel far more often then they install the world. An API check during the installkernel would work almost as well for my own purposes as 'ipfw unbreak'. It doesn't provide a failsafe but it does handle the most common installation case. Note that this solution may not be quite as simple as it appears, since -current may be built on a -stable box so compiling up an out-of-date ipfw is not entirely trivial. My current solution is on the table. I see no others on the table at the moment. -Matt :One other avenue would be to stick a temporary check for ABI compat in :installworld before overwriting ipfw. Or for the next few releases, build :both ipfw1 and ipfw2 and install both (say, symlinking ipfw - ipfw2 by :default). You could fall back to ipfw1 if ipfw2 returns an error code in :rc scripts. I'd prefer this kind of hack in the install/rc process, not :in a new API. : :Regarding civility to developers, there are a ton of frustrating things in :any project. I think civility should be the response given to both :reasonable and unreasonable people. If they are unreasonable, giving a :reasonable response just makes them look bad. : :-Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0 dangerous dumps (showstopper?)
Ok. so
On Fri, 13 Dec 2002, Julian Elischer wrote:
On Fri, 13 Dec 2002, Nate Lawson wrote:
On Fri, 13 Dec 2002, Julian Elischer wrote:
On Fri, 13 Dec 2002, Peter Wemm wrote:
Julian Elischer wrote:
looking at the code in src/sys/i386/i386/dump_machdep.c,
we see:
78 dumplo = di-mediaoffset + di-mediasize - Maxmem *
(off_t)PAGE_SIZE;
79 dumplo -= sizeof kdh * 2;
80 i = di-dumper(di-priv, kdh, 0, dumplo, sizeof kdh);
81 if (i)
82 printf(\nDump failed writing header (%d)\n, i);
83 dumplo += sizeof kdh;
84 i = 0;
It looks like the following test should go after line 77
if (di-mediasize ((Maxmem * (off_t)PAGE_SIZE) +
(sizeof kdh * 2) + (16*1024)) {
/* 16K is an arbitrary buffer
* in case the swap part is
* the first part
*/
printf(\nDump failed. Partition too small.\n);
return;
}
Assuming I can make similar patches for the other architectures,
should this be committed?
how does it make its way to RELENG_5_0?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
walt wrote: [EMAIL PROTECTED] wrote: Because few if any 80386 computers have the ram it takes to run sysinstall. Was sysinstall around when 386 was new? Just curious what's changed since then to make it bigger. The sheer number of new drivers, for one thing. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] You are as old as you feel. Then I broke a few medical records. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Problems connecting locally
Hi, after updating my -CURRENT today (sun dec 15) I can no longer connect to my local cvs and sshd. cvs returns: Connection closed by 217.208.105.23 cvs [commit aborted]: end of file from server (consult above messages if any) and ssh returns: Connection closed by 217.208.105.23 Both these worked flawlessly before the update, the previous version I was running on was about 2 weeks old. The thing is, if I try to connect from remote I have no problems accessing both cvs and ssh. And apache seems unaffected, I can access my webserver both locally and remotely. I have not modified my fiewall since the upgrade, but just in case, it looks like this: 00050 divert 8668 ip from any to any via rl0 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 01050 deny ip from any to any dst-port 139 via rl0 01100 deny ip from any to any dst-port 587 via rl0 01150 deny ip from any to any dst-port 783 via rl0 01200 deny ip from any to any dst-port 901 via rl0 01250 deny ip from any to any dst-port 1024 via rl0 65000 allow ip from any to any 65535 deny ip from any to any //David Holm To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FBSD 5.0RC1 install oddity
At 9:23 PM +0100 2002/12/15, Claudio Nieder wrote: Problem: After that question the install programm immediatly tries to contact the DHCP server, which cannot work, as informations like the WEP key to use etc. were asked for/supplied so that the wireless card could be properly set up to communicate. I ran into this same problem when I was trying to install FreeBSD-4.6.2-RELEASE. I think that the solution is actually to flip to a different page in the sysinstall program and provide the additional options that you need. Unfortunately, although I think I stumbled into this solution, I couldn't tell you how to replicate it. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: FBSD 5.0RC1 install oddity
At 9:23 PM +0100 2002/12/15, Claudio Nieder wrote: Problem: After that question the install programm immediatly tries to contact the DHCP server, which cannot work, as informations like the WEP key to use etc. were asked for/supplied so that the wireless card could be properly set up to communicate. I ran into this same problem when I was trying to install FreeBSD-4.6.2-RELEASE. I think that the solution is actually to flip to a different page in the sysinstall program and provide the additional options that you need. Unfortunately, although I think I stumbled into this solution, I couldn't tell you how to replicate it. -- Brad Knowles, [EMAIL PROTECTED] I have noticed several oddities surrounding the dhclient, as well. It seems that my network card is not initalizing early enough in the boot process for me to acquire a dhcp lease. Since I'm not getting a lease this was causing cascade problems with Apache, SSH, etc. However, I have found that setting the crontab to run @reboot and fire off dhclient seems to work for at least acquiring the IP address.This has the effect of firing off dhclient much later on in the boot process (after cron loads). Perhaps this will help you as well. I add as a note that this does not appear to be a complete solution since I am still fighting the cascade issues, most notably with SSH. Thanks, Ms. Jimi Thompson Those who are too smart to engage in politics are punished by being governed by those who are dumber. - Plato To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
On Saturday, 14 December 2002 at 20:55:05 -0800, Terry Lambert wrote: M. Warner Losh wrote: One problem with most 386 boxes is that they have very little memory. sysinstall is a big, bloated pig dog these days that takes more RAM than most 386 boxes have. This is true also for many 486 boxes too. So even if 386 stuff were in the default kernel, you'd likely have other issues in making sysinstall work and have to do custom hacking... Add to this that Bosko's workaround for the CPU bug with PSE/PGE includes loading the kernel at 4M rather than 1M. I'm not sure I understand you. i386's have a 32 bit address space, and long ago we loaded at 0xf000 (3.75M). Then we dropped it to 0xc000 (3M). 4M is the end of the address space. Are you talking about something else? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
On Saturday, 14 December 2002 at 20:53:05 -0800, Terry Lambert wrote: Alex wrote: It means that you can not install FreeBSD on a 386 unless you have a 486+ machine that can compile a new FreeBSD system and have a way to get that version to the 386. Yes, this is true. Several of us were annoyed by the change, which appeared at the time to have been done solely to handle the fact that the newly installed device /dev/random sucked too much CPU time to work on a 386. That's an interesting apparition. In fact, it was done because the locking primitives for i386 are so different from those for later machines that they would significantly slow down all i[3]86 kernels. Since that's the vast majority, it doesn't make sense. I suppose it would be a good idea to include an alternatvie i386 kernel on the CD-ROM. There may be a space issue, of course. How many people participating in this thread have an i386 with at least 12 MB of memory and intended to try 5.0 on it? How many of those don't have a machine to bootstrap off? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: swapoff code comitted.
On Sun, Dec 15, 2002 at 11:46:55AM -0800, Matthew Dillon wrote: David Schultz's swapoff code has been comitted. It should be regarded as being highly experimental (and it still needs to be vetted for VM locking changes and other recent changes in -current). A considerable amount of testing has been done already but -current is a moving target. I am tentitively planning on MFCing the code in a few weeks (some time after christmas) but it will depend on my schedule. If someone else wants to take on that work I will would be happy to act as a reviewer. -Matt Matthew Dillon [EMAIL PROTECTED] How about renaming swapon(8) into swapctl(8) after this function enhancement? This name reflects it's purpose much better and would be consistent with the other BSDs. - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg48813/pgp0.pgp Description: PGP signature
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 /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sun Dec 15 22:11:11 GMT 2002 -- === ipfilter cc1: warnings being treated as errors /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot': /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:542: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:557: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs1': /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1002: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs2': /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1278: warning: cast to pointer from integer of different size *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Problems connecting locally
I ran truss on both cvs and ssh and they stop at the following points: cvs: open(/home/avatar/.cvsignore,0x0,0666) ERR#2 'No such file or directory' access(/home/avatar/.cvswrappers,0)ERR#2 'No such file or directory' pipe() = 3 (0x3) pipe() = 5 (0x5) vfork() = 14645 (0x3935) close(3) = 0 (0x0) close(6) = 0 (0x0) fcntl(0x4,0x2,0x1) = 0 (0x0) fcntl(0x5,0x2,0x1) = 0 (0x0) getdtablesize() = 7322 (0x1c9a) fcntl(0x4,0x3,0x0) = 2 (0x2) fcntl(0x5,0x3,0x0) = 2 (0x2) __sysctl(0xbfbffa08,0x2,0x281cb29c,0xbfbffa04,0x0,0x0) = 0 (0x0) break(0x80d5000) = 0 (0x0) fstat(4,0xbfbff850) = 0 (0x0) break(0x80d9000) = 0 (0x0) write(4,0x80d5000,372) = 372 (0x174) fstat(5,0xbfbff8a0) = 0 (0x0) break(0x80dd000) = 0 (0x0) ssh: socket(0x2,0x1,0x0) = 3 (0x3) . . . open(/home/avatar/.ssh/known_hosts,0x0,0666) = 4 (0x4) fstat(4,0xbfbfca00) = 0 (0x0) read(0x4,0x8076000,0x1000) = 4096 (0x1000) read(0x4,0x8076000,0x1000) = 4096 (0x1000) read(0x4,0x8076000,0x1000) = 1212 (0x4bc) close(4) = 0 (0x0) write(3,0x807,16)= 16 (0x10) write(3,0x807,48)= 48 (0x30) select(0x4,0x806c360,0x0,0x0,0x0)= 1 (0x1) read(0x3,0xbfbfd900,0x2000) = 48 (0x30) write(3,0x807,64)= 64 (0x40) select(0x4,0x806c360,0x0,0x0,0x0)= 1 (0x1) read(0x3,0xbfbfd8f0,0x2000) = 80 (0x50) stat(/home/avatar/.ssh/identity,0xbfbff6d0)ERR#2 'No such file or directory' stat(/home/avatar/.ssh/id_rsa,0xbfbff6d0) ERR#2 'No such file or directory' stat(/home/avatar/.ssh/id_dsa,0xbfbff6d0) ERR#2 'No such file or directory' write(3,0x807,96)= 96 (0x60) //David On Sunday 15 December 2002 22:44, David Holm wrote: Hi, after updating my -CURRENT today (sun dec 15) I can no longer connect to my local cvs and sshd. cvs returns: Connection closed by 217.208.105.23 cvs [commit aborted]: end of file from server (consult above messages if any) and ssh returns: Connection closed by 217.208.105.23 Both these worked flawlessly before the update, the previous version I was running on was about 2 weeks old. The thing is, if I try to connect from remote I have no problems accessing both cvs and ssh. And apache seems unaffected, I can access my webserver both locally and remotely. I have not modified my fiewall since the upgrade, but just in case, it looks like this: 00050 divert 8668 ip from any to any via rl0 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 01050 deny ip from any to any dst-port 139 via rl0 01100 deny ip from any to any dst-port 587 via rl0 01150 deny ip from any to any dst-port 783 via rl0 01200 deny ip from any to any dst-port 901 via rl0 01250 deny ip from any to any dst-port 1024 via rl0 65000 allow ip from any to any 65535 deny ip from any to any //David Holm 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: swapoff code comitted.
: :How about renaming swapon(8) into swapctl(8) after this function enhancemen= :t? :This name reflects it's purpose much better and would be consistent with the :other BSDs. : :- Christian I think that's an excellent idea. We would have to do some rewriting to add the expected options but it would not be too difficult to do. Mainly just grunt work. e.g. the NetBSD swapctl command is this: swapctl -A [-p priority] [-t blk|noblk] -D dumpdev -U [-t blk|noblk] -a [-p priority] path -c -p priority path -d path -l | -s [-k] -z swapon -a | path And the OpenBSD swapctl command is this: swapctl -A [-p priority] [-t blk|noblk] swapctl -a [-p priority] path swapctl -c -p priority path swapctl -d path swapctl -l | -s [-k] swapon -a | path We would simply ignore priority since we don't support it, nor would we need a -t option since we do not have buffered block devices any more or a -c option since, again, we do not have priorities. I would keep 'swapoff' in anycase. It's an obvious command and like swapon could simply wind up being a hardlink to swapctl. I am not volunteering to do this, at least not right now. I have too big a stack of things that still need to be committed, but if someone else would like to tackle this I think it would be a nice little project for a developer with some free time to waste and I would be happy to review and test the work. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Re[2]: 80386 out of GENERIC
On Sat, 14 Dec 2002, [EMAIL PROTECTED] wrote: FreeBSD still runs on all 386 family CPUs, the only difference is that if you want to run it on a 80386 you need to enable an option in your kernel config file. It will out of the box run on 486 and anything later. It means that you can not install FreeBSD on a 386 unless you have a 486+ machine that can compile a new FreeBSD system and have a way to get that version to the 386. Too bad. Harsh, but understandable. How difficult would the following be to develop, in your opinion? A boot disk image (like the sets of images on the website tm) that will boot on 386's as well as more modern CPU's that can newfs and disklabel your drives, download the source, and let you compile from that point. That way you don't need to transfer from one box to another, and you get the compiled install you want right away. I'd maybe like ot help with something like this but my abilities and experience are somewhat limited :-) It shouldn't really be that hard should it? You just need the boot disks, with utilities that are: newfs disklabel ifconfig something to download with (fetch? wget?) something to compile with - which can be downloaded with the source all precompile so the do work on all x86 CPU's. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
5.0-RC1 install: disklabel editor
For some reason, I can't find a way to create a swap partition using the disklabel editor - other than by using Auto Defaults - and then I can't see any way to adjust the size of the resulting swap partition. This never was a problem with 4.x as far as I can remember...? (After first discovering this, I figured maybe if I left the pre-existing b partition as none, the install scripts would be smart enough to use it as swap. No way. And after the scripts complained, and I had been back through the disklabel editor again, installation failed with Error mounting /mnt/dev/ad0s3f on /mnt/usr: No such file or directory while the other console said newfs:/mnt/dev/ad0s3f: No such file or directory After which it went ahead and installed anyway, only to fill up the root file system, of course. But this problem went away when I tried again after a reboot, so that is a minor issue.) - Harald To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
5.0-RC1: suspend trouble
The main reason I decided to try 5.0-RC1 on my brand new Dell Inspiron 4150 is a minor problem with suspending the machine under 4.7: After wakeup, the fan runs full speed and will not settle until I reboot. However, with 5.0-RC1 the machine just freezes if I try suspending it. Theres is no reaction until I hit the power button, which shuts it down immediately. Sorry, I am not sure how to get any more detailed information to debug this. Let me know what I can do to obtain such information, but fast - for I will probably go back to 4.7, at least for the next couple of weeks (I need stability while away during Christmas). I attach a copy of /var/run/dmesg.boot, in case it helps. - Harald ACPI debug layer 0x0 debug level 0x0 Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-RC1 #1: Mon Dec 16 01:06:09 CET 2002 root@odin:/usr/src/sys/i386/compile/ODIN Preloaded elf kernel /boot/kernel/kernel at 0xc0529000. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 1695007260 Hz CPU: Pentium 4 (1695.01-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf27 Stepping = 7 Features=0xbfebf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,b31 real memory = 268312576 (255 MB) avail memory = 255082496 (243 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled acpi0: DELL CPi R on motherboard evevent-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 evevent-0625: *** Info: GPE Block1 defined as GPE16 to GPE31 Using $PIR table, 11 entries at 0xc00fbb90 Timecounter ACPI-fast frequency 3579545 Hz acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_acad0: AC adapter on acpi0 acpi_cmbat0: Control method Battery on acpi0 acpi_cmbat1: Control method Battery on acpi0 acpi_lid0: Control Method Lid Switch on acpi0 acpi_button0: Power Button on acpi0 acpi_button1: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: Intel 82845 host to AGP bridge mem 0xe800-0xebff at device 0.0 on pci0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) uhci0: Intel 82801CA/CAM (ICH3) USB controller USB-A port 0xbf80-0xbf9f irq 11 at device 29.0 on pci0 usb0: Intel 82801CA/CAM (ICH3) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci2: ACPI PCI bus on pcib2 xl0: 3Com 3c905C-TX Fast Etherlink XL port 0xec80-0xecff mem 0xf8fffc00-0xf8fffc7f irq 11 at device 0.0 on pci2 xl0: Ethernet address: 00:08:74:96:75:08 miibus0: MII bus on xl0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto cbb0: TI1420 PCI-CardBus Bridge at device 1.0 on pci2 cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 pcib2: slot 1 INTA is routed to irq 11 cbb1: TI1420 PCI-CardBus Bridge at device 1.1 on pci2 cardbus1: CardBus bus on cbb1 pccard1: 16-bit PCCard bus on cbb1 pcib2: slot 1 INTA is routed to irq 11 pci2: network at device 3.0 (no driver attached) isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH3 ATA100 controller port 0xbfa0-0xbfaf,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: multimedia, audio at device 31.5 (no driver attached) pci0: simple comms at device 31.6 (no driver attached) atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 npx0: math processor on motherboard npx0: INT 16 interface orm0: Option ROMs at iomem 0xcf800-0xc,0xcf000-0xcf7ff,0xc-0xcefff on isa0 pmtimer0 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick
5.0-RC1: compat4x
Shouldn't libposix1e.so.2 have been part of the compat4x package? I came across at least one program that uses it. - Harald To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RC1: suspend trouble
On Mon, 16 Dec 2002, Harald Hanche-Olsen wrote: The main reason I decided to try 5.0-RC1 on my brand new Dell Inspiron 4150 is a minor problem with suspending the machine under 4.7: After wakeup, the fan runs full speed and will not settle until I reboot. However, with 5.0-RC1 the machine just freezes if I try suspending it. Theres is no reaction until I hit the power button, which shuts it down immediately. If it's any consolation, I have had the same problem on my ibm thinkpad for a long time. -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
5.0-RC1: No /dev/card0
Despite the following lines in dmesg... cbb0: TI1420 PCI-CardBus Bridge at device 1.0 on pci2 cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 cbb1: TI1420 PCI-CardBus Bridge at device 1.1 on pci2 cardbus1: CardBus bus on cbb1 pccard1: 16-bit PCCard bus on cbb1 ...no /dev/card0 (or /dev/card1) appears, and so pccardc and pccardd fail. Shouldn't this be automatic, or did I miss something? - Harald To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
5.0-RC1: X server crash
(This is the last of my current batch of 5.0-RC1 problems.) Yeah, I know, X server problems ought to be reported to the XFree maintainers. Is there any interest for details of it here? The synopsis: The X server crashes under 5.0-RC1 where it runs fine with the exact same configuration under 4.7-RELEASE. It says Fatal server error: Caught signal 10. Server aborting and then dmesg output says it dies with signal 6 and dumping core. But I can't find any core dump lying around anywhere. I'll forward XFree86.0.log and config files if anybody here wants them, but in the interest of keeping unwanted list traffic down, I'll lay low until anybody requests this data. I'll include this line though: (--) PCI:*(1:0:0) ATI Radeon Mobility M7 LW rev 0, Mem @ 0xe000/27, 0xfcff/16, I/O @ 0xc000/8 The machine is a Dell Inspiron 4150. - Harald To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
BDE drive encryption practices and techniques?
I plan to deploy GBDE in an environment in which the absolute maximum of the system that can reasonably be kept encrypted on disk will be kept in an encrypted format. The system has the following requirements: 1) It must remain possible to administer the host over ssh. This includes rebooting the host. 2) /home must be encrypted. 3) The machine is not required to permit non-root login or accept mail until root has mounted the encrypted partitions over ssh. Furthermore, performance requirements are not an issue. Assume plenty of CPU and RAM. 4) /var/mail must be encrypted. 5) /var/log/maillog must be encrypted. 6) /var/log/messages should be encrypted, however, syslog must be able to write messages to the log from boot. (These two combined requirements may at first seem mutually exclusive, though this may not actually be the case, perhaps the log could be buffered to a memory device and written to /var/log/messages once /var becomes available). 7) Once the encrypted partitions are mounted, the rest of the services should start up automatically as they would have if all partitions had been mounted initially. 8) It sure would be nice if everything in /usr not required to boot the system were encrypted. Is anybody here working on a similar configuration? Do you have any suggestions how to best accomplish some or all of these requirements? Sample modifications to rc.*? Thanks in advance, --Lucky To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RC1: compat4x
On Mon, Dec 16, 2002 at 03:37:58AM +0100, Harald Hanche-Olsen wrote: Shouldn't libposix1e.so.2 have been part of the compat4x package? I came across at least one program that uses it. There are numerous libraries missing from compat4x. A worse problem is that several 4.x shared libs have the same version number as 5.x libs (e.g., libm.so.2). -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
fatal: ssh_msg_send: write
Anyone else having issues with sshd on current? Dec 15 23:23:24 stuff sshd[843]: fatal: ssh_msg_send: write debug1: next auth method to try is keyboard-interactive Connection closed by 192.168.1.66 debug1: Calling cleanup 0x804bed0(0x0) __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fatal: ssh_msg_send: write
At 08:31 PM 12/15/2002 -0800, David Yeske wrote: Anyone else having issues with sshd on current? Dec 15 23:23:24 stuff sshd[843]: fatal: ssh_msg_send: write Yup, on a userland I built today. I see a few sshd commits yesterday, relating to pam. Probably broke thereabouts... ? -- Christopher Schulte http://www.schulte.org/ Do not un-munge my @nospam.schulte.org email address. This address is valid. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
Greg 'groggy' Lehey wrote: Add to this that Bosko's workaround for the CPU bug with PSE/PGE includes loading the kernel at 4M rather than 1M. I'm not sure I understand you. i386's have a 32 bit address space, and long ago we loaded at 0xf000 (3.75M). Then we dropped it to 0xc000 (3M). 4M is the end of the address space. Are you talking about something else? The load is at physical 4M. It avoids the 4K/4M page switch, and has two side effects which make it work without DISABLE_PSE et al. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: recent openssh problem
From: Giorgos Keramidas [EMAIL PROTECTED] Subject: Re: recent openssh problem Date: Fri, 13 Dec 2002 20:18:51 +0200 On 2002-12-13 08:34, Terry Lambert [EMAIL PROTECTED] wrote: Daniel O'Connor wrote: On Fri, 2002-12-13 at 15:53, CHOI Junho wrote: % ssh -2 -N -f -L 9595:remote-host:25 remote-host bind: Can't assign requested address I usually use it to forward SMTP to remote host. Is there any change to system or openssh upgrade? Before upgrading, my -current box was built on 25 Nov. It worked silently before. Does lo0 have 127.0.0.1 as it's address? Probably not. The recent rc.network commit brok this, and lo0 gets no address assigned to it. Hmmm, how certain are we of this? I just cvsup'ed and build everything again. The change in rc.network looks very similar to the update of etc/rc.d/network1 and with rc_ng=YES in my rc.conf all looks fine here :-/ root@gothmog[20:16]/root# ifconfig lo0 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet 127.0.0.1 netmask 0xff00 root@gothmog[20:16]/root# uname -v FreeBSD 5.0-CURRENT #1: Fri Dec 13 19:28:32 EET 2002 Yes, lo0 has no assigned address... I gave 127.0.0.1 to lo0 manually and it works again. I am upgrading my system to see if it is fixed. Thanks everybody, -- CHOI Junho http://www.kr.FreeBSD.org/~cjh cjh at kr.FreeBSD.org FreeBSD Project cjh at FreeBSD.orgWeb Data Bank cjh at wdb.co.kr Key fingerprint = 1369 7374 A45F F41A F3C0 07E3 4A01 C020 E602 60F5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: swapoff code comitted.
On Sun, Dec 15, 2002 at 02:47:51PM -0800, Matthew Dillon wrote: : :How about renaming swapon(8) into swapctl(8) after this function enhancemen= :t? :This name reflects it's purpose much better and would be consistent with the :other BSDs. : :- Christian I think that's an excellent idea. We would have to do some rewriting to add the expected options but it would not be too difficult to do. Mainly just grunt work. e.g. the NetBSD swapctl command is this: swapctl -A [-p priority] [-t blk|noblk] -D dumpdev -U [-t blk|noblk] -a [-p priority] path -c -p priority path -d path -l | -s [-k] -z swapon -a | path And the OpenBSD swapctl command is this: swapctl -A [-p priority] [-t blk|noblk] swapctl -a [-p priority] path swapctl -c -p priority path swapctl -d path swapctl -l | -s [-k] swapon -a | path We would simply ignore priority since we don't support it, nor would we need a -t option since we do not have buffered block devices any more or a -c option since, again, we do not have priorities. I would keep 'swapoff' in anycase. It's an obvious command and like swapon could simply wind up being a hardlink to swapctl. I am not volunteering to do this, at least not right now. I have too big a stack of things that still need to be committed, but if someone else would like to tackle this I think it would be a nice little project for a developer with some free time to waste and I would be happy to review and test the work. -Matt I'll look into that when some of my current work is done. Maybe it's worth an entry in PHK's JKH TODO list for now. - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg48830/pgp0.pgp Description: PGP signature
Re: 5.0-RC1: suspend trouble
On Sun, Dec 15, 2002 at 06:39:52PM -0800, Doug Barton wrote: On Mon, 16 Dec 2002, Harald Hanche-Olsen wrote: The main reason I decided to try 5.0-RC1 on my brand new Dell Inspiron 4150 is a minor problem with suspending the machine under 4.7: After wakeup, the fan runs full speed and will not settle until I reboot. However, with 5.0-RC1 the machine just freezes if I try suspending it. Theres is no reaction until I hit the power button, which shuts it down immediately. If it's any consolation, I have had the same problem on my ibm thinkpad for a long time. -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? Suspend works ok on my Thinkpad R32. Which version do you have? - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg48831/pgp0.pgp Description: PGP signature
VESA support on IBM ThinkPad A21m
I used a laptop(IBM ThinkPad A21m,ATI Mobile p video card),with the FreeBSD 5.0-current installed. I added the follow line to the kernel config file: options VESA options SC_PIXEL_MODE After rebooting the laptop with the new kernel, to alter the revolution, I tried to use the follow command : vidcontrol -g 100x37 VESA_800x600 . I got some error: vidcontrol: cannot activate raster display:Operation no supported by device How to fix this problem? __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
