Linked by Nathan Mace on Tue 19th Mar 2002 17:21 UTC
FreeBSD Most tech savvy geeks can work their way through a FreeBSD install, even if they have no prior UNIX experience. However installing an OS and configuring an OS are two totally different things. This article is targeted towards anyone who might be wondering about FreeBSD, but doesn't know what to do with it after they install it. This isn't then end-all be-all of FreeBSD howto's. Just some of the simple stuff. Update: Some of the readers of OSNews have emailed me concerning corrections that need to be made in this article. Dig in (third page) for more.
Permalink for comment
To read all comments associated with this story, please click here.
Some advice
by Per-Arne Holtmon AkÝ on Wed 20th Mar 2002 22:32 UTC

After reading the article and the comments, I felt I had to make a comment too.

First thing is about the way to do an upgrade. While doing just a 'make world kernel KERNCONF=[whatever]' does work, it can be dangerous, especially when we're talking about major version upgrades (i.e., 3.x -> 4.x, 4.x -> 5.x). The described procedure in /usr/src/UPDATING is the recommended way for several reasons, the biggest being binary incompability. I ran into this when I was still a n00b and upgrading from 3.x to 4.x, and I built and installed world before even thinking of the kernel. Oops. It seemed that the 3.x kernel was unable to run 4.x binaries, which I found out the hard way when the installworld crashed half-way, having replaced almost all the critical binaries with 4.x binaries. As said, I still had the old 3.x kernel, and any new binary that I tried to run, crashed with a SIGSEG (#11). After beating the machine around for some hours, I gave up and started to think about what had happened. When I realized that I needed a reinstall to fix the broken machine, I got quite mad, as this was the only computer I had working at the time, and I was sitting on ISDN. Yuck. After downloading the new -RELEASE ISO, I got on and reinstalled, which fixed it.

Consider this as a warning. The safest way IS with an installkernel and consequent reboot to single mode before installworld. I also know some other people who have had the same, not all too great, experience.

The other thing I see mentioned is that you have to re-edit the kernel configuration file each time you cvsup, which is as someone anonymous pointed out, not necessary. You can keep your old kernel configuration file for quite long, although I would recommend checking it every now and then, especially when there are major or minor version upgrades in the progress. A simple way would be to make two copies of the GENERIX file, one which you rename to whatever is you preferrence, the other something like GENERIC.old (or whatever). By doing this, you can use the second, non-modified version of the GENERIC file (GENERIC.old) to diff against the possibly updated official GENERIC file to see what differences there are.

Third and last point is that building world and the respective kernels for the other machines on one fast machine and sharing it through NFS is quite a time-saver, since a dual 1.2GHz Athlon MP will use about 50 minutes on one buildworld and one buildkernel, while a 486 will take a full 24 hours or so. There are some pitfalls here too, the biggest I've encountered is firewalls. If you have a firewall (say ipfw) on the clients that're installing from the NFS server, with a default-to-deny stance in the kernel, you can run into some problems with /sbin/ipfw and the kernel (the new one you just installed) being out-of-sync, which will cause /sbin/ipfw to seg.fault when you're trying to run it. And with a default-to-deny stance, you're pretty much scr****. This is a bit contradictory to what I previously said, but first doing an installkernel, and before the reboot, then do the installworld will go around the particaular problem described above.

One last thing I could mention is that in the default make.conf (/etc/defaults/make.conf) there are some entries starting with SUP_. If you copy these and modify them for your needs, all you need to do when cvsup'ing is 'cd /usr/src && make update', which will update the source tree, the ports tree and the docs tree, in addition to running cvsup on the other optional sup-files. This makes being even more lazy simpler. ;)

Anyway, this comment is getting quite long, so I think I'll call it a day here. I hope someone find my comment useful.