Re: pf - strange behavior
On Sun, Aug 20, 2006 at 05:09:33AM +0200, openbsd misc wrote: On 8/19/06, openbsd misc [EMAIL PROTECTED] wrote: Hello, nobody has an answer for that? :/ Or was my explanation not english enough? =) Please let me know if something is ambiguous. Regards Hagen Volpers Hi, Hello, I do not know about pf, but maybe I can help anyway. Did you investigate why these two states look different? all icmp 192.168.122.128:512 - 193.99.144.85 0:0 all icmp 192.168.122.16:512 - 84.60.163.18:34545 - 193.99.144.85 0:0 That's exacly my question. ;-) These states should not be different, but they are... Also, have you tried looking at the state table _after_ restarting the pings? Does it look the same or different? Yes. It looks different (like the other line) if you wait for 10 seconds (udp timeout) before starting the ping again. I think this behavior is not correct (or my pf.conf isn't). I wasn't able to figure out why this happens. I had these problems on a WRAP system (i386). This probably is not the problem, but have you checked /etc/rc for the rules loaded by default before /etc/pf.conf is loaded? If something there created state... -- Darrin Chandler| Phoenix BSD Users Group [EMAIL PROTECTED] | http://bsd.phoenix.az.us/ http://www.stilyagin.com/ |
Re: 3.9 freeze
Pedro Martelletto wrote: I cannot declare that the problem is solved... but I had no more freezes since I'm using a custom GENERIC kernel with doubled NKMEMPAGES_MAX and maxusers, both with the i386 and the amd64 machines. But consider that this happened only 7 and 10 days ago... It has been approximately a month now. How have your boxes been doing? They both (i386 and amd64) had not a single freeze any more. Bye. -- ___ __ |- [EMAIL PROTECTED] |ederico Giannici http://www.neomedia.it ___
Re: Apache chroot and /usr/lib/apache/
On Fri, Aug 18, 2006 at 08:00:57PM -0400, Christopher D. Palmer wrote: From: Frederic Motte [EMAIL PROTECTED] Sent: Friday, August 18, 2006 8:42 AM 'apachectl restart' works fine in chroot environment for me using 3.9 STABLE. Might your problem be: From apachectl(8) for restart command ... If httpd runs chrooted (default in OpenBSD) and 3rd party modules are loaded, restart may fail due to path consistency. Completely stop and start the daemon instead. That's the point ! With 3rd party modules, Apache systematicaly die and you have to retart it again. Then Apache was down for longer than it should, you may not pay attention to it and it is unusable in scripts (for example in monitoring scripts). Ok, you sould customise your Apache installation and fix it, but still.. By the way, `apachectl restart` do a config test to make sure apache doesn't die, so why not making sure Apache can restart without dying for another predictable reason ? Kind regards -- Frederic Motte [EMAIL PROTECTED]
select(2) performance and optimal timeout choice?
Hi All, I think I've found the real cause of those error messages. The peer socket functions give out those errors, and it all boils down to one function: select(2). The timeout value passed to select(2) in one case is 3 and in the other is 10 seconds. Even though these values seem large enough, under relatively high load (e.g. 120 web page requests using firefox, or when there are many dante instances), I get 3-4 such errors. When I raise both of these timeouts to 30 seconds, and under the same test conditions, I get no errors at all. To verify my theory, if I reduce both of them to just 1 second, I get 6-7 such errors, as I expected. So, I'm almost sure that select(2) timeout is the cause of such errors. The fact that DG 2.9.7.5 cannot handle such errors (they are not ignorable in my case) is another subject for discussion perhaps, but I'm trying to find a way to improve the performance of select(2). What are the factors effecting its performance? The machines I'm using are in the ranks of P4 3.2GHz, DDR400 1GB RAM, 7200rpm 80GB SATA HD. How should one choose timeout values for select(2)? How can I performance tune OpenBSD in this case? Should I run DG at a higher priority? (I'll submit these findings to DG also, but it seems these timeout values are OK with Linux. Or perhaps, the only processes running on their Linux are DG. I have many other processes too. So I wanted to ask misc@ first.) Thanks, On Sat, 2006-08-19 at 13:53 +0300, Soner Tari wrote: Hi All, I think that this problem is related with DG (or its interactions with OpenBSD), and I have already posted the following emails to the DG maillist, but I could not receive any replies. So I assume that most DG 2.9.7.5 users run it on Linux, and they don't have this problem. Therefore, I hope there are people on this list running DG 2.9.7.5 on OpenBSD 3.9. The summary of the issue is that I get the following errors in messages: dansguardian: Error accepting. (Ignorable) dansguardian: Error reading ipc. (Ignorable) When these errors occur for all the child processes (max 120 in config file), DG stops all web access. Apparently, they are not ignorable.
Re: pf - strange behavior
On 8/19/06, openbsd misc [EMAIL PROTECTED] wrote:
On 8/19/06, openbsd misc [EMAIL PROTECTED] wrote:
Hello,
nobody has an answer for that? :/ Or was my explanation not
english
enough? =) Please let me know if something is ambiguous.
Regards
Hagen Volpers
Hi,
Hello,
I do not know about pf, but maybe I can help anyway. Did you
investigate why these two states look different?
all icmp 192.168.122.128:512 - 193.99.144.85 0:0
all icmp 192.168.122.16:512 - 84.60.163.18:34545 - 193.99.144.85
0:0
That's exacly my question. ;-) These states should not be different,
but they are...
Also, have you tried looking at the state table _after_ restarting
the
pings? Does it look the same or different?
Yes. It looks different (like the other line) if you wait for 10
seconds
(udp timeout) before starting the ping again.
Okay, so clearly the answer is here.
The one that works is being set up to redirect through 84.60.163.18 (I
assume this is your router?). The one that doesn't is sending directly
to the outside world.
Hello,
as you can see both should be kept by the same rules:
# cat /etc/pf.conf
ext_if=pppoe0
int_if=sis1
set block-policy return
set skip on lo
scrub in
nat on $ext_if from !($ext_if) - ($ext_if:0)
block in
pass out keep state
antispoof quick for { lo $int_if }
pass in on $ext_if inet proto tcp from any to ($ext_if) port { 22 }
flags S/SA keep state
pass in inet proto icmp all icmp-type echoreq keep state
pass in quick proto { tcp, udp } from { 192.168.122.0/24 } to
192.168.122.2 port { 53 }
pass quick on $int_if
The public ip address you mentioned is the one on pppoe interface. There
are no other entries that could make any changes (I wrote the rc script
on my own =)).
I don't know what that printout means! It's not documented in the
manpage. Probably have to check the source to see what it is... Here
that source is, from /sbin/pfctl/pf_print_state.c:
void
print_state(struct pf_state *s, int opts)
{
struct pf_state_peer *src, *dst;
struct protoent *p;
int min, sec;
if (s-direction == PF_OUT) {
src = s-src;
dst = s-dst;
} else {
src = s-dst;
dst = s-src;
}
printf(%s , s-u.ifname);
if ((p = getprotobynumber(s-proto)) != NULL)
printf(%s , p-p_name);
else
printf(%u , s-proto);
if (PF_ANEQ(s-lan.addr, s-gwy.addr, s-af) ||
(s-lan.port != s-gwy.port)) {
print_host(s-lan, s-af, opts);
if (s-direction == PF_OUT)
printf( - );
else
printf( - );
}
print_host(s-gwy, s-af, opts);
if (s-direction == PF_OUT)
printf( - );
else
printf( - );
print_host(s-ext, s-af, opts);
printf();
if (s-proto != IPPROTO_ICMP src-state PFOTHERS_NSTATES
dst-state PFOTHERS_NSTATES) {
/* XXX ICMP doesn't really have state levels */
const char *states[] = PFOTHERS_NAMES;
printf( %s:%s\n, states[src-state],
states[dst-state]);
}
It would seem that, for some reason, on the one that doesn't work,
PF_ANEQ(s-lan.addr, s-gwy.addr, s-af fails (and presumably the
other test in that if fails because ICMP lacks ports). Yeah. Um, still
confused. Too bad PF_ANEQ is a macro, so not in the manpages. Perhaps
grep the tree for it?
Unfortunately I'm not a developer... :(
-Nick
Regards
Hagen Volpers
Re: pf - strange behavior
On 8/20/06, openbsd misc [EMAIL PROTECTED] wrote:
On 8/19/06, openbsd misc [EMAIL PROTECTED] wrote:
On 8/19/06, openbsd misc [EMAIL PROTECTED] wrote:
Hello,
nobody has an answer for that? :/ Or was my explanation not
english
enough? =) Please let me know if something is ambiguous.
Regards
Hagen Volpers
Hi,
Hello,
I do not know about pf, but maybe I can help anyway. Did you
investigate why these two states look different?
all icmp 192.168.122.128:512 - 193.99.144.85 0:0
all icmp 192.168.122.16:512 - 84.60.163.18:34545 -
193.99.144.85
0:0
That's exacly my question. ;-) These states should not be
different,
but they are...
Also, have you tried looking at the state table _after_
restarting
the
pings? Does it look the same or different?
Yes. It looks different (like the other line) if you wait for 10
seconds
(udp timeout) before starting the ping again.
Okay, so clearly the answer is here.
The one that works is being set up to redirect through
84.60.163.18 (I
assume this is your router?). The one that doesn't is sending
directly
to the outside world.
Hello,
as you can see both should be kept by the same rules:
This is the router machine?
Yes, it is.
# cat /etc/pf.conf
ext_if=pppoe0
int_if=sis1
set block-policy return
set skip on lo
scrub in
nat on $ext_if from !($ext_if) - ($ext_if:0)
block in
pass out keep state
antispoof quick for { lo $int_if }
pass in on $ext_if inet proto tcp from any to ($ext_if) port { 22 }
flags S/SA keep state
pass in inet proto icmp all icmp-type echoreq keep state
pass in quick proto { tcp, udp } from { 192.168.122.0/24 } to
192.168.122.2 port { 53 }
pass quick on $int_if
The public ip address you mentioned is the one on pppoe interface.
There
are no other entries that could make any changes (I wrote the rc
script
on my own =)).
misc@ might yell at you for this. I think it's neat, and I like how
OpenBSD is so simple and clean that I understand I could do that
completely. However, rc does a lot of stuff, and it's best not to
tamper with. It also invokes side scripts like netstart. Use rc.local
and rc.local.conf instead.
I thought that I had a problem in my rc script, too. The installation
bases on flashdist. That's why I'm not able to put back the old rc
script (to many commands are missing). The point is, that two
machines are treated different. I don't think that is problem can
be found in my rc script. I copied the stuff from netstart and the
pf start is identical to rc script.
I think there can be only two reasons for this:
- a bug
- a missconfiguration in my pf.conf
Try putting the old rc back and see if it fixes things. If it does,
great. If you still have some time maybe go through and diff it to
your version and figure out what changed.
The key point I found in the source was this:
if (PF_ANEQ(s-lan.addr, s-gwy.addr, s-af) ||
(s-lan.port != s-gwy.port)) {
print_host(s-lan, s-af, opts);
if (s-direction == PF_OUT)
printf( - );
else
printf( - );
}
Because it is that which causes the intermediate host to be printed
for the state which works.
It would seem that, for some reason, on the one that doesn't work,
PF_ANEQ(s-lan.addr, s-gwy.addr, s-af fails (and presumably
the
other test in that if fails because ICMP lacks ports). Yeah. Um,
still
confused. Too bad PF_ANEQ is a macro, so not in the manpages.
Perhaps
grep the tree for it?
Unfortunately I'm not a developer... :(
Neither am I. I found this by going to http://www.openbsd.org,
clicking Getting Source-Web and finding the code for pfctl. I
don't have a working OpenBSD system right now to check out the source
on, and I was hoping you could. See
http://www.openbsd.org/anoncvs.html
Or do you mean I don't know C?
Yes, I do... =)
-Nick
Regards
Hagen Volpers
Re: Kernel never loads completely
On 8/20/06, francisco [EMAIL PROTECTED] wrote: On the off chance you haven't already done this, verify that the floppies are good (via a good `fdformat /dev/rfd0c` before and `cmp /dev/rfd0c /path/to/floppy39.fs` after). I've had similar hangs due to bad media. On 8/20/06, Jeff Quast [EMAIL PROTECTED] wrote: have you reset cmos? Thanks guys. I reset the cmos and I've checked these floppies. My laptop boots fine from them and the machine in question boots from Redhat and DOS floppies. One post I found mentions A20 issues but I'm not much of hardware person to understand the referenced materials and there weren't any solutions anyway. This little project I'm doing is turning into PITA. Thanks, Greg On Sat, 19 Aug 2006, Greg Thomas wrote: On 8/19/06, Greg Thomas [EMAIL PROTECTED] wrote: I have an old, unused since OpenBSD 3.4 Athlon XP 1800+ that I just replaced the mobo on because the previous mobo wouldn't boot with a LSI MegaRAID 150-6 installed. I haven't yet tried other OSes but so far with the 3.4 system on the harddrive and any OpenBSD boot floppy it hangs here: booting hd0a:/bsd: 4466772 Any ideas? Bad memory? With the mobo I received new Kingston memory but have no other DDR stuff to test with at the moment. I found some ancient Redhat floppies along with a DOS floppy and they boot fine. In addition to the 3.4 on the harddrive I've tried 3.7, 3.9, and snapshot floppies all with the same result. Greg
Sigaltstack and pthreads (again)
I too am having problems using sigaltstack() in pthreads application. Otto's quote earlier this year of the Single Unix Specification http://www.sigmasoft.com/~openbsd/archives/html/openbsd-bugs/2006-03/msg00129.html Use of this function by library threads that are not bound to kernel-scheduled entities results in undefined behavior. http://www.unix.org/single_unix_specification/ does not make sense to me. Reading from the man 3 pthreads: Thread stacks Each thread has (or should have) a different stack, whether it be provided by a user attribute, or provided automatically by the system. If a thread overflows its stack, unpredictable results may occur. System-allocated stacks (including that of the initial thread) are typically allocated in such a way that a SIGSEGV signal is delivered to the process when a stack overflows. Signals handlers are normally run on the stack of the currently executing thread. Hence, if you want to handle the SIGSEGV signal, you should make use of sigaltstack(2) or sigprocmask(2). How are you suppose to handle SIGSEGV when a thread blows its stack, if you cannot set the alternate stack for the SIGSEGV handler in the first place? There appears to be a contradiction here in the documentation. Are pthreads not kernel scheduled entities? -- Anthony C Howe Skype: SirWumpusSnertSoft +33 6 11 89 73 78 AIM: SirWumpusSendmail Milter Solutions http://www.snert.com/ ICQ: 7116561 http://www.snertsoft.com/
Re: Sigaltstack and pthreads (again)
On 8/20/06, Anthony Howe [EMAIL PROTECTED] wrote: I too am having problems using sigaltstack() in pthreads application. Otto's quote earlier this year of the Single Unix Specification http://www.sigmasoft.com/~openbsd/archives/html/openbsd-bugs/2006-03/msg00129.html Use of this function by library threads that are not bound to kernel-scheduled entities results in undefined behavior. Note that it says library threads. http://www.unix.org/single_unix_specification/ does not make sense to me. Reading from the man 3 pthreads: Thread stacks Each thread has (or should have) a different stack, whether it be provided by a user attribute, or provided automatically by the system. If a thread overflows its stack, unpredictable results may occur. System-allocated stacks (including that of the initial thread) are typically allocated in such a way that a SIGSEGV signal is delivered to the process when a stack overflows. Signals handlers are normally run on the stack of the currently executing thread. Hence, if you want to handle the SIGSEGV signal, you should make use of sigaltstack(2) or sigprocmask(2). How are you suppose to handle SIGSEGV when a thread blows its stack, if you cannot set the alternate stack for the SIGSEGV handler in the first place? I don't what happens when a thread other than the main blows its stack. But anyway, if you setup the alternate stack from the ain thread you should have no problems. (It may be true for other threads but I don't know.) There appears to be a contradiction here in the documentation. Are pthreads not kernel scheduled entities? The current pthreads implementation is all in userland. -- Anthony C Howe Skype: SirWumpusSnertSoft +33 6 11 89 73 78 AIM: SirWumpusSendmail Milter Solutions http://www.snert.com/ ICQ: 7116561 http://www.snertsoft.com/ -- What is your function in life? - Killer
Re: Sigaltstack and pthreads (again)
Arnaud Bergeron wrote: Use of this function by library threads that are not bound to kernel-scheduled entities results in undefined behavior. Note that it says library threads. The distinction is lost on me. I thought threads are a kernel things even if the API appears in another library. How are you suppose to handle SIGSEGV when a thread blows its stack, if you cannot set the alternate stack for the SIGSEGV handler in the first place? I don't what happens when a thread other than the main blows its stack. But anyway, if you setup the alternate stack from the ain thread you should have no problems. (It may be true for other threads but I don't know.) Hmm. I was under the impression that the alternate signal stack was per process, not per thread, therefore you need only set it once in main()? -- Anthony C Howe Skype: SirWumpusSnertSoft +33 6 11 89 73 78 AIM: SirWumpusSendmail Milter Solutions http://www.snert.com/ ICQ: 7116561 http://www.snertsoft.com/
Re: Kernel never loads completely
Greg Thomas wrote: I have an old, unused since OpenBSD 3.4 Athlon XP 1800+ that I just replaced the mobo on because the previous mobo wouldn't boot with a LSI MegaRAID 150-6 installed. I haven't yet tried other OSes but so far with the 3.4 system on the harddrive and any OpenBSD boot floppy it hangs here: booting hd0a:/bsd: 4466772 That's not booting from the floppy. If that's what you are getting, your system isn't trying to boot from the floppy, it keeps going to the HD. Bad floppy, bad cable, bad setting ... (I could also read unstated things into what you are saying, but that's not at all wise) Any ideas? Bad memory? With the mobo I received new Kingston memory but have no other DDR stuff to test with at the moment. 3.4 had the old boot loader that didn't like changing disk geometries. Changing the MoBo could cause issues, though I don't recall that exact symptom. Could also be a HD damaged in handling... If the floppy is really trying to boot and it is hanging at that point, I'd be suspicious of a hardware problem. That's so early in the boot process, the only thing running is the boot loader. The 3.4 boot loader and the 3.9/4.0 boot loader have very little in common, so if BOTH are failing in the same way, you got either a really odd piece of HW or a broken piece of HW. Nick.
anyone tried a matrox dualhead2go?
Hello, Is someone using a matrox dualhead2go under openbsd and x11? or Does someone know if it works under openbsd and x11? thank you kind regards didier
Re: Sigaltstack and pthreads (again)
Arnaud Bergeron wrote: Hmm. I was under the impression that the alternate signal stack was per process, not per thread, therefore you need only set it once in main()? Of course, you set it only once. I meant that you should set it in main() as you said rather than in another thread. Then again, I'm not an expert on signal stacks. Well I did set it in main() and it fails, which is probably due to the userland pthread nature of the current implementation. Oh hum. Yet another #ifdef in my code. -- Anthony C Howe Skype: SirWumpusSnertSoft +33 6 11 89 73 78 AIM: SirWumpusSendmail Milter Solutions http://www.snert.com/ ICQ: 7116561 http://www.snertsoft.com/
Re: Sigaltstack and pthreads (again)
On 8/20/06, Anthony Howe [EMAIL PROTECTED] wrote: There appears to be a contradiction here in the documentation. Are pthreads not kernel scheduled entities? no, they are not.
SFS
is anyone using SFS ( http://www.fs.net/sfswww/ )? anybody got opinions on it, especially from a security standpoint? cheers, jake
Re: can not prioritize the main swap device in fstab
Hi LeVA, I have two disk drives, and each of them has a swap partition. I would like to swap to both of them, but firstly to the other disk, which is not used during the running of the system, thus making the swapping less painful (the drives are on separate ide channels/cables). The swap partition which is on the disk which has the root partition gets always priority 0, so I thought that I should add this to my fstab: /dev/wd1b none swap sw,priority=0 0 0 /dev/wd0b none swap sw,priority=1 0 0 But after reboot, both of the swap partitions gets priority 0. I can change the wd0b's priority to 1 after the boot, but is this the proper way of doing this, and one can not define the main swap partition's priority in fstab? On bootup, swap configuration using fstab(5) is done by swapctl(8) from rc(8). But, as far as i have seen on 3.9-stable and earlier systems, the GENERIC kernel adds the b partition of the root disk as a swap partition even before spawning init(8), i.e. long before /sbin/init can invoke /etc/rc, at least if that partition looks like a swap partition. Thus, when /etc/rc gets to the line `swapctl -A -t blk`, the swap partition is already active. You can verify this assertion by commenting out *all* swap lines from /etc/fstab, rebooting and typing [EMAIL PROTECTED] $ swapctl -l Device 512-blocks UsedAvail Capacity Priority swap_device 524160 241544 28261646%0 (Er, well, i *really* ought to get more RAM for idefix, it is not that expensive any more.) You see that the swap device is quoted as swap_device. As far as i understand, that's what the kernel will call it if it was activated during kernel booting, before spawning /sbin/init. Now, if a swap device is already active, `swapctl -a -p` does not change its priority, only `swapctl -a -c` does so: [EMAIL PROTECTED] # swapctl -l Device 512-blocks UsedAvail Capacity Priority swap_device 524160 246088 27807247%0 [EMAIL PROTECTED] # swapctl -a -p 1 /dev/wd0b [EMAIL PROTECTED] # swapctl -l Device 512-blocks UsedAvail Capacity Priority swap_device 524160 246088 27807247%0 [EMAIL PROTECTED] # swapctl -c -p 1 /dev/wd0b [EMAIL PROTECTED] # swapctl -l Device 512-blocks UsedAvail Capacity Priority swap_device 524160 246088 27807247%1 This is perhaps not perfectly documented in the man pages - one might add If _arg_ is already enabled, nothing is changed, in particular not the priority after If cmd is SWAP_ON, the arg parameter is used as a pathname of a file to enable swapping to. The misc parameter is used to set the priority of this swap device in swapctl(2) and If the device is already contained in the list, nothing is changed, in particular not its priority after The -a option requires that a path also be in the argument list. The path is added to the kernel's list of swap devices using the swapctl(2) system call in swapctl(8). Jason? =;-) In any case, that's how it works. The kernel adds your wd0b before rc(8), rc(8) only does `swapctl -a`, not `swapctl -c`, so your nice entry in /etc/fstab gets ignored. My suggestion would be to add `swapctl -c -p 1 /dev/wd0b` to rc.local(8). But don't forget about it when reconfiguring your disks, or document it at the proper place in case of multiple admins. I do *not* suggest to compile a custom kernel containing something like config bsd root on wd0a swap on wd1b in its configuration file. In case you forget *that* and change your disk setup, you will be quite surprised. On top of that, if you encounter problems with a custom kernel, most people won't even try to help you because they assume you have just broken your kernel. As far as i understand config(8) and boot_config(8), you cannot modify the swap device used by an existing kernel after typing 'boot -c' at the boot prompt or `config -e -o /bsd.new /bsd` from the running system. Yours, Ingo -- Ingo Schwarze [EMAIL PROTECTED]
x86 Apple MacBook dmesg(8) and sysctl(8) output request.
Hello, Can someone with Apple MacBook send me off-list `dmesg' and `sysctl hw' output from OpenBSD (prefered -current). Thanks in advance. ps. I'm not on misc@ -- best regards q#
Rebuilding for stable.
Hello everyone, I've order and received the OpenBSD 3.9 disks. I've read through the majority of the documentation at least once and two or three times in certain sections. I've installed the OS about 4 times as dry runs and I'm preparing for the final OS load for a production box. After I've run the CD installation, I've created a task list for upgrading it to OpenBSD 3.9-stable (I'm not experienced enough for current yet). I've decided I don't want build any ports and instead use packages for adding third-party software. This is the current task list I ran during the last install and it works, but I know there is a bunch of stuff in there that relates to ports and I want to strip that out. # Install source tree from CD mount /dev/cd0a /mnt cd /usr/src; tar xzf /mnt/src.tar.gz cd /usr; tar xzf /mnt/XF4.tar.gz tar xzf /mnt/ports.tar.gz umount /mnt # Get updated source from OpenBSD CVS. cd /usr/src cvs -d [EMAIL PROTECTED]:/cvs -q up -rOPENBSD_3_9 -Pd # Get updated ports from OpenBSD CVS. cd /usr/ports cvs -d [EMAIL PROTECTED]:/cvs -q up -rOPENBSD_3_9 -Pd # Rebuilding the kernel cd /usr/src/sys/arch/i386/conf /usr/sbin/config GENERIC cd /usr/src/sys/arch/i386/compile/GENERIC make clean make depend make # Rebooting with the new kernel cd /usr/src/sys/arch/i386/compile/GENERIC cp /bsd /bsd.old cp bsd /bsd reboot # Rebuilding the binaries rm -rf /usr/obj/* cd /usr/src make obj cd /usr/src/etc env DESTDIR=/ make distrib-dirs cd /usr/src make build Now here is a list that I think strips out the stuff only applicable to ports. Could you tell me if I have indeed stripped all the ports stuff? Also, and more importantly, did I strip out something that I shouldn't have? # Install source tree from CD mount /dev/cd0a /mnt cd /usr/src; tar xzf /mnt/src.tar.gz cd /usr; tar xzf /mnt/XF4.tar.gz umount /mnt # Get updated source from OpenBSD CVS. cd /usr/src cvs -d [EMAIL PROTECTED]:/cvs -q up -rOPENBSD_3_9 -Pd # Rebuilding the kernel cd /usr/src/sys/arch/i386/conf /usr/sbin/config GENERIC cd /usr/src/sys/arch/i386/compile/GENERIC make clean make depend make # Rebooting with the new kernel cd /usr/src/sys/arch/i386/compile/GENERIC cp /bsd /bsd.old cp bsd /bsd reboot I hope I've done my due diligence in researching this before bring it to the list. I pretty much understand what's going on but something I just can't figure out. Thanks in advance. Eric Stewart e.stewart [at] mac [dot] com
