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.
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:
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.
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 firstname.lastname@example.org