RE: FreeBSD ignoring /etc/rc.conf

Hi Marius, I once had a similar problem. The solution was that one of the many /etc/rc.* (a hunch: check /etc/rc.firewall) is not properly reading /etc/defaults/rc.donf correctly, and this is causing mis-understanding in your box. The /etc/rc.firewall should have at the begining of it the follow

Re: FreeBSD ignoring /etc/rc.conf

"Marius M. Rex" wrote: > > I did run mergemaster, by hand. It went fine. The only files I didn't > completely replace were my site specific files like resolv.conf, hosts, > password, group, inetd.conf and my rc.firewall. > Try running "mergemaster -s" to do a more complete comparison. Jim --

RE: FreeBSD ignoring /etc/rc.conf

Yes, I was missing the 'source' line in my rc.firewall file. But that doesn't change the fact that I have no mouse support, named doesn't come up. No default route... -Nothing- specified in the /etc/rc.conf file occurs at boot. I just ran mergemaster -s that didn't change things

Re: FreeBSD ignoring /etc/rc.conf

"Marius M. Rex" wrote: > > I appreciate the suggestions, but it is a pretty fundamental > problem. I can start most things easily by hand, but it is annoying to > do. > Okay. This is all started during boot by init(). You should be able to restart and log the result by doing: "cd /etc

Correct sequence for keeping a 4.1 system stable.

If these seem like trivial questions please do not flame me, I have never attempted to do this before and do not want to damage a working system! As far as I have researched I need to perform the following actions: 1 get the up to date source (using one of the cvs tools) 2. make buildworld 3.

Re: Correct sequence for keeping a 4.1 system stable.

On Thu, 5 Oct 2000, Jon Paterson wrote: > If these seem like trivial questions please do not flame me, I have never > attempted to do this before and do not want to damage a working system! > > As far as I have researched I need to perform the following actions: > > > 1 get the up to date sour

Re: Correct sequence for keeping a 4.1 system stable.

In message Jon Paterson writes: : If these seem like trivial questions please do not flame me, I have never : attempted to do this before and do not want to damage a working system! >From src/UPDATING: To update from 4.0-RELEASE or later to the

Re: 4.1-RELEASE pccard?

In message <[EMAIL PROTECTED]> Thomas David Rivers writes: : it turns out that `sum' was not 0xff (but 0x51) as it should have : been... but, everything looks just fine to me... (of course, I'm This is odd. My -current box works great for my linksys card, modulo the removal of interrupts on eje

Re: Correct sequence for keeping a 4.1 system stable.

Jon Paterson wrote: > > If these seem like trivial questions please do not flame me, I have never > attempted to do this before and do not want to damage a working system! > > As far as I have researched I need to perform the following actions: > > 1 get the up to date source (using one of th

moh_php4 not compiling, failing at config

I am trying to compile php4 on a FreeBSD -stable, cvsupped last night, and compiled today, with ports collection cvsupped some one hour ago. Also, since I think it should compile (-kthread appears in cc's manpage), I cc'd this to -stable as well as -ports. Here is the output (after make patch, I

Re: Correct sequence for keeping a 4.1 system stable.

On Thu, Oct 05, 2000 at 06:16:47PM +0200, Øystein Skundberg wrote: > On Thu, 5 Oct 2000, Jon Paterson wrote: > > > 6. reboot (and pray!) > > By all means, but it's usually not necessary :) > I hope you are referring to praying. A reboot is always necessary ;) -- 4.4 - The num

Re: agp_if.c

On Thu, Oct 05, 2000 at 12:29 +1100, Gregory Bond wrote: > > Doesn't the old "config; cd; make dep all install" sequence > > work? > > Traps for young players: No this (sometimes) doesn't work. > You need to do "make depend && make all", so that the second > invocation of make picks up the new d

Re: FreeBSD ignoring /etc/rc.conf

On Thu, Oct 05, 2000 at 05:35:40PM +0200, Noor Dawod wrote: > Hi Marius, > > I once had a similar problem. The solution was that one of the many > /etc/rc.* (a hunch: check /etc/rc.firewall) is not properly reading > /etc/defaults/rc.donf correctly, and this is causing mis-understanding > in your