Search

Desktop FreeBSD Part 8: Updating the Core System

By Ed Hurst |Oct 5, 2007 at 23:58:1

So, how are you liking FreeBSD? Do you believe it's something you work with, live with day after day? If you find you've gotten used to it, maybe the time has come to get more acquainted with one of the best features of FreeBSD: It's relatively painless to update the entire system by rebuilding it from code. The emphasis is not so much slavishly chasing the cutting edge of BSD technology. Instead, our focus will be on security updates and optimization.

One of the major selling points with FreeBSD is security. How silly it would be if we didn't do the minimum necessary to insure it stays secure. FreeBSD coders are some of the best on earth, but if perfect software could be written, no one could afford it. From time to time, flaws are discovered after the product is released. Fixes are often released within 24 hours of discovering a flaw, when it comes to core system files. Ported add-on packages may take longer. The core system fixes are seldom offered as a new package built and ready to download. You will have to download a patch, apply it and rebuild the flawed binaries from source. Occasionally, a flaw will affect the whole system base and will require rebuilding the whole thing.

Which brings us to the issue of optimization: Rebuilding the system base is a good idea in the first place, simply because it offers the best opportunity to make your system run as well as it can. When you install FreeBSD from a CD-ROM, you are getting generic binaries with the lowest level of optimization. Virtually everyone who tries a rebuild will swear it makes things better. The effects of optimizing become obvious in two ways. One, when the system is being optimized, successive rebuilds take less and less time. On most hardware I've tested, it's still rather dramatic for at least the first three times. Second, when you later update your desktop from source, it runs quite a bit faster. It is especially noticeable on something like KDE.

While this sounds like a major task fraught with risk, it really is quite simple. The good folks of FreeBSD have made it so easy. Even when one considers doing an upgrade using a slow dialup connection, you can be sure the time factor is reasonable, and the results well worth it.

Most recently I ran this procedure on an AMD K8 system running in 32-bit mode. However, I've worked with far slower hardware back in the 4.x days, and the effects were still worth the time and trouble. At each step of the way, I took the defaults whenever possible. Please note that the only tweaking I chose to do was in /etc/make.conf, selecting to optimize on "k8" as the CPUTYPE, because my CPU is a Sempron-64. By reading the notes in the file above that line, you can determine the best match to your processor. Further, I added a line for optimizations in the way C code is compiled, with the line CFLAGS= -O2 -pipe. Most likely you will first have to copy that file from /usr/share/examples/etc/make.conf to /etc and edit. Naturally you'll have to be logged in as root to alter system files.

Here is the process, step by step.

1. Note csup is bundled in by default. Log in as root and navigate to /usr/src/share/examples/cvsup. There you will see several files which you can copy and modify for use. Our interest here is the file stable-supfile. Copy it to /usr/src and open in your favorite text editor. Two main items here. Go down to where you see:

*default host=CHANGE_THIS.FreeBSD.org

You need to change this to a mirror that is presumably near you so that you can get a fast and strong connection. The list of mirrors can be found at /usr/share/doc/en/books/handbook/cvsup.html near the bottom of the page. The list shows about 18 mirrors for the US alone. If you know how to use the ping command, you can time the response to find the one CVSup server which will serve you quickest. Most of the time, it should be sufficient to look for the one geographically closest, by using the host command to identify where each mirror was hosted. Mine ended up with:

*default host=cvsup17.us.FreeBSD.org

A few lines down, I made sure there was one like this:

*default release=cvs tag=RELENG_6

This keeps me up to date with the latest code for the 6.x branch of FreeBSD; as of this writing the latest stable version is 6.2. Save the file and close. From the same source of example files, copy the refuse file over to /usr/sup (create the directory the first time). This file keeps you from downloading a horde of listings for language-oriented packages you probably won't use. Check to make sure you approve of what's refused in the file, then save and close.

2. Be sure you are connected to the Internet, but run csup as root. Simply type on the commandline:

csup -g -L 2 stable-supfile

This runs on the CLI completely. By adding the switches in the middle of that line, you get a chance to see some details of the operation. Once connected successfully, you'll see a bunch of lines stating what's happening. Watch, if you have time. On dialup, it's common to be finished in 20 minutes or less, downloading the difference between the source files one version and another.

3. When finished, the command line will return with a message about being successful. Dialup users drop your connection to the Internet at this point. Now is a good time to close down applications, shut down the X server, and work in the console. This will allow your system to devote maximum resources to the work of rebuilding. On the console, log out of your user account and login as root.

Navigate back to /usr/src. Issue the command:

make buildworld

This took my system an hour the first time. Naturally, your mileage may vary. If there are going to be any problems, this is where you are most likely to see them. However, they are extremely rare. If it fails, you'll get an error notice that you can copy and paste in a message asking for help. The Handbook page makeworld.html will provide the necessary details. As long as you have not installed anything from a failed buildworld, you can simply resume using your system as before.

What happens is that a script will tell your computer to rebuild the newest version of the basic C libraries, install themselves, then build again for optimization, and install themselves again. Then the rest of the system is built.

4. Of course, you'll need to update the kernel, too. But since nothing new has been installed, you can't use the Handbook instructions for building a kernel the normal way. You have to use the script:

make buildkernel

This took 15 minutes for me, but was faster when I went back and built a custom kernel from the update. For now, we won't do customizations. Let's just stick with the trusted generic kernel, because you'll need to keep an updated generic kernel on hand for emergencies.

5. When building is finished, and there's no problems, run the command:

make installkernel

The installation should be pretty quick. When it's finished is the time to reboot and see if everything works with the new kernel. Go ahead and run the X server, use your peripherals such as soundcards, CD drives, etc. When you are satisfied all is well, close all the applications and drop back to the console mode.

6. Next, drop down out of regular run mode into single mode. On FreeBSD, this is very easy; simply type:

shutdown now

By leaving out the switches for shutdown, such as -h (halt) or -r (reboot), you are telling shutdown to go into single mode. This means you are pulled back out of the system, as it were, running only the absolute minimum. The reason we do this it that it's not wise to have programs running while replacing them. Now it's safe to install your new base system:

cd /usr/src
make installworld

This will take a few minutes. When it's finished, we have one more step before running our new system.

7. Invoke mergemaster from the commandline so that you can compare all our old config files with the new defaults. Often a system update will include changes to the layout of the config files, and the old ones may not work properly in the new system. Mergemaster will show you the differences line-by-line using minus (-) for what the old looks like, and plus (+) to indicate how the new one is different. Read the prompts on the screen and decide what you want to change. For the most part, I've always accepted the changes offered, unless it's a file I've changed manually. I keep a written record of changes I make to the various config files on my system in case I miss one at this point, but with care you can figure out how to merge a new file with your customizations. Naturally, I'll check the manpages and read the comments in the config files in case there's a new option I like, or an old one is removed.

Now we're done and ready for the first test run:

reboot

In a couple of minutes, I was back up. The X server started a little faster, and everythinge else was snappier.

Next time you install a system, especially with a recent release, consider just getting the base system installed, then running the buildworld process (minus update) to optimize everything before going any further. The primary difference this makes is that anything you compile afterwards will compile quite a bit faster, because the system libraries already have been optimized.

Ed Hurst is associate editor of Open for Business.

Article Path: Home: Computers and Technology: Linux and BSD on the Desktop: FreeBSD: Desktop FreeBSD Part 8: Updating the Core System

Trackback URL: http://www.ofb.biz/safari/trackback/439.html Share It: Facebook Digg

reboot must be done BEFORE ‘installworld’!!!

The value of this article is questionable. It is not 100% correct and it can even drive new users away from FreeBSD. It would be better to link to The FreeBSD Handbook which contains a better and full and up-to-date instructions on the update procedure.

The value of this article is essentially /dev/zero

New users would likely want to use “freebsd-update” for updating their system (new users usually use GENERIC kernel).

“When you install FreeBSD from a CD-ROM, you are getting generic binaries with the lowest level of optimization.”

Bullshit, default build CFLAGS for RELEASE in FreeBSD are:
-O2 -fno-strict-aliasing -pipe

“Further, I added a line for optimizations in the way C code is compiled, with the line CFLAGS= -O2 -pipe.”

A line? One simple LINE? WOW man, pure respect.

Default FreeBSD CFLAGS are: -O2 -fno-strict-aliasing -pipe so you did NOTHING here.

Most of speed is gained by setting CPUTYPE variable in /etc/make.conf which adds -march ${CPU} to CFLAFS.

Look how REAL optimization for FreeBSD looks like:
http://vermaden.rox.pl/tmp/make.conf

“OFB’s Ed Hurst presents how the power of the FreeBSD operating system can be harnessed for the desktop. Using understandable instructions and relevant tips, Ed provides the tools for mere mortals to enjoy BSD’s fabled stability.”

LMAO!

Enjoy Ed

Why do you wrote such pitious misleading articles by the way?

Does it make you happy or something?

The man’s written an article hoping to help people. Perhaps he may have made some mistakes, and you’re right to post corrections, but no need to flame. Have some common courtesy.

mergemaster is the most painful part of a FreeBSD upgrade. 20 minutes of paging through files most of which I’ve never touched.

It could be made much less painful by putting most of those files into /etc/defaults/ and then letting the user put his overrides into a file of the same name in /etc/ (or /usr/local/etc/). Just as we do with rc.conf. Throw in a mergemaster option to mean “update everything in /etc/defaults/ without asking me” and everyone should be happy. (Which is to say, the curious and the masochists could still page through every updated, default config’ file.)

“Yikes
The man’s written an article hoping to help people. Perhaps he may have made some mistakes, and you’re right to post corrections, but no need to flame. Have some common courtesy”

My thoughts exactly, If anything is going to deter newcommers to FreeBSD it’s this kind of negative attitude.

@kace

“mergemaster is the most painful part of a FreeBSD upgrade. 20 minutes of paging through files most of which I’ve never touched.”

from man mergemaster:

-i
Automatically install any files that do not exist in the destination directory.

-U
Attempt to auto upgrade files that have not been user modified.

so generally you always use:

(…)
# mergemaster -p
# make installworld
# mergemaster -iU
(…)

which makes everything faster.

There is also -a option which you may like:

-a
Run automatically. This option will leave all the files that differ from the installed versions in the temporary directory to be dealt with by hand. If the temproot directory exists, it creates a new one in a previously non-existent directory.

Come on… the guy did his best, now you only need to post corrections so the author can clean his article. No need to flame. Even books from the gurus have erratas

Basicly, don't be an asshole to flame the author..

Well, there are flaws for sure. If nothing else, it’s somewhat out of date, since this was written around the release of 6.1, and there was already some new stuff I didn’t know. Chances are some edits will be made soon.

However, you can all rest easy knowing this is probably the last BSD article I’ll be doing for awhile. My interests have taken new directions. As for the flamers, they are part of the great background noise on the Net. An awful lot of folks love computers passionately, and these things really matter to them. On the other hand, perhaps it’s true they do so because they don’t get along with people too well. It takes all kinds…

Just a thought, having read this article whilst looking for help. I found it

I came across Vermaden's posting of his super-make.conf.
It looks like great stuff and as a newbie I'm keen to learn where such things like "WITHOUT_PROFILE= yes" come from in his/her version of make.conf.

In the Freebsd documentation, the nearest I can find is the "NO_PROFILE= true" variable.

It would be nice if "Vermaden" did us all a favour and either documented his / her discoveries - or added them to the Openbsd documentation ... with appropriate credits of course.

Thanks to you both.

Owen

@Owen

Generally WITH_*=yes/WITHOUT_*=yes is for FreeBSD Ports, while NO_*=yes is for FreeBSD Base System, also just to mention something like YES_*=yes does not exist.

About NO_*, on FreeBSD 6.x or earlier these base system KNOBS are described in [man 5 make.conf], on FreeBSD 7 and later on [man 5 src.conf].

also check /usr/share/examples/etc/make.conf for more data.

About WITH*/WITHOUT_*, most popular KNOBS are stored in /usr/ports/KNOBS, but many ports use their non standard KNOBS, like WITHOUT_MOZILLA for example, so before installing some port, you just check what KNOBS it has as options:

# cd /usr/ports/category/port
# grep WITH Makefile

and then use these KNOBS:

# make WITHOUT_MOZILLA=yes install clean

or

# make -DWITHOUT_MOZILLA install clean

also to get all possible KNOBS use this command:
egrep -r -o “WITH_[A-Z]+” /usr/ports | cut -d: -f 2 | egrep -v “^[
]*$” | sort | uniq

reading files from /usr/ports/Mk/ will also give you many interesting things.

about make.conf, also check these links:
http://wiki.bsd-crew.de/index.php/Make.conf_Optimal_nutzen
http://wiki.bsdforen.de/howto/make.conf_optimieren

use http://translator.google.com if you do not know german.

also searching for: freebsd make.conf
will give you many interesting results.

I think thats it about make.conf

Heh, when did FreeBSD users became like Gentoo Ricers?

Name:
Location:
Homepage:
E-mail:
Subject:
Remember my information

UPDATED: BSD on the Desktop

By Ed Hurst

In an extensive multi-part report, OFB's Ed Hurst presents how the power of the FreeBSD operating system can be harnessed for the desktop. Using understandable instructions and relevant tips, Ed provides the tools for mere mortals to enjoy BSD's fabled stability.

Write for OFB