OSNews

Finally, to finish the upgrade we have to compile a new kernel. Now cd into the /usr/src/sys/i386/conf directory. In a default install there should be a LINT and a GENERIC file. The GENERIC file is the conf file for the system’s default kernel; we need to make a copy of it. I copied mine like this "cp GENERIC NATHAN", you can name your copy anything you want. After that you need to edit your kernel to add any options you might need or remove ones you don't need. The kernel conf file contains some comments about what each option does, however for more detailed information look in the LINT file. Don't edit the GENERIC file, as every time you cvsup the source tree that file gets replaced with the newer GENERIC file and you would loose your changes. After you have finished editing your file, run "config NATHAN" or whatever you named your file. The config program parses the file and makes sure that there are no typos or other errors. If for some reason you would need to add debugging info into the kernel run the config program with the -g flag. A kernel with debugging code results in a larger kernel, you probably don't need it unless your hacking kernel code. After config runs it will instruct you to cd into the ../../compile/NATHAN directory. Once you are in that directory, run "make depend", which makes sure that you have everything thing needed to compile the kernel, it's recommended by the config program, however it's not required. After that finishes simply run "make", which actually compiles the kernel, once that completes type "make install" which will install the kernel in /kernel. It renames the existing /kernel to /kernel.old, and installs the new one as /kernel. If there is a /kernel.old from a previous compile, it gets overwritten. After that, all that is left to do is reboot!

If for some reason the new kernel will not boot, drop down to the boot loader prompt like we did when booting into single user mode. Except this time, type "boot /kernel.old", which will boot the "old" or previous working kernel.

UPDATE!
Some of the readers of OSNEWS have emailed me concerning corrections that need to be made in this article. The next few paragraphs explain what is changed, and why. Please take note that anything said here should be used in place of anything said above.

1)In the "ports" section I explained that in order to update an installed package via portupgrade that you have to type "pkg_info | grep *name*" to get the "proper" name of the package. I used vim as the example there, and I will here. Instead of having to type out "portupgrade vim-6.0.85", you can just type "portupgrade vim". This way is much easier, and much simpler. Please note that in order for either of these methods to work, your package database has to be free of all stale dependencies. If it isn't you will just get an error from portupgrade telling you to run "pkgdb -F" manually.

2)Worthy of mention is "portupgrade -ar". Until this afternoon I didn't know this even existed! What the -ar does is tell portupgrade to upgrade all installed packages recursively. Which in a nutshell means, upgrade all of my installed apps, and anything that they depend on fuction. As always, you should cvsup your port's tree to get the latest version before running portupgrade.

On a server it might not be a good idea to blindly upgrade you apps, but the -ar flags save a lot of time on computers that are used as desktops, or anywhere else that you want the absolute latest version of everything.

3)In the above article I stated that "You should track the -STABLE tree for your production servers, as the -STABLE tree is updated with bug fixes and security patches." THIS IS WRONG! The -STABLE tree is a development stage just like -CURRENT. Code that has been tested in -CURRENT is patched and then put into -STABLE for more testing. Think of -CURRENT as alpha quality code, and -STABLE as beta quality. For production servers, the FreeBSD handbook recommends that you use the -RELEASE snapshots. The -RELEASE snapshots are recommended for production servers that must be as stable as possible. When the next -RELEASE version comes out, you can then edit your cvsup tags to obtain the -RELEASE source code and follow the routine for upgrading via source.

I should note however that both my desktop and server have been running the -STABLE tree for several months. Neither of them have ever had any problems from the effects of running -STABLE. However for critical servers that can't go down, run -RELEASE.

4)According to the Handbook, the proper way of building a new kernel is as follows:

cd /usr/src
make buildkernel KERNELCONF=*MYKERNEL*
make installkernel KERNELCONF=*MYKERNEL*

where *MYKERNEL* is whatever you named your edited copy of GENERIC.

This is for installing a new kernel along with a new "system". As in you should only follow these steps if you have cvsup'd(or updated your source some other way) and have completed the buildworld process. If you are simply compiling a new kernel to add a feature, use the "old" method of config, make, make install. That method is used only when you have *NOT* cvsup'd your source. It would appear that the old way of doing it still works regardless of whether or not you've cvsup'd because that is the way I have done it for almost a year. But the documentation recommends that we use the new way, so we will. Here is a link to the handbook, scroll down towards the bottom for more info on compiling the kernel.

I would like to thank the reader(s) that emailed me concerning the errors in my article. I'd also like to apologize to the readers, I try to not make mistakes like this, but I'm only human so sometimes they slip though.

Links of Interest
FreeBSD Handbook
A comparison of -STABLE and -CURRENT
Freshport.org
FreeBSD list of ports
FreeBSD Diary

If you have suggestions and ideas for future FreeBSD-related articles that you would like to see on OSNews, please let me know by emailing me directly.

About the Author:
Nathan Mace is currently a senior enrolled at the University of Charleston, West Virginia, majoring in Computer Information Systems. He is interested in all types of operating systems, expecially Unix-type OSes such as Linux, *BSD's, and commercial Unices. Nathan can be reached at mace_nathan@uchaswv.edu

1. "CVSup, Mounting CDROMs, Init"
2. "The Ports System, Part I"
3. "The Ports System, Part II"