Monthly Archives: January 2007

It’s finally time to upgrade FreeBSD on my main server, and there doesn’t appear to be a ton of information on how to do so using sources. Although I successfully upgraded a FreeBSD workstation using binary methods, I have a mildly customized kernel on the main box, and I generally just prefer to use source/CVS based updates, because that’s how I keep it up to date, anyway.

Step 1: Synchronize the source using a 6.2 cvsup file.

This file resides in /usr/share/examples/cvsup/stable-supfile; the only thing one really needs to do is replace “RELENG_5” with “RELENG_6”, and then run
cvsup -g -h cvsup.freebsd.org /usr/share/examples/cvsup/stable-supfile

Step 2: Make buildworld

Go to /usr/src and type “make -j4 buildworld”. In my case, it died because a file it was trying to build (“lsof”) already existed. I’m not sure why this would be so — perhaps I should have started with “make clean” — but simply deleting the file allowed it to move on and build everything.

The “-j4” part is optional, but it speeds things up by using parallel builds, so I can’t think of a good reason why not to include it.

Step 3: Build the kernel

There are a number of ways to do it, but this works:

make buildkernel KERNCONF=MYKERNEL

It doesn’t look like kernel options have changed all that much, so I’m leaving my 5.5 kernel configuration intact. It appears to build without a hitch.

Step 4: Install the kernel

This part’s easy. “make installkernel KERNCONF=MYKERNEL”

Step 5: Merge configuration files

This doesn’t appear to need to be done in single-user mode, and mostly includes adding the _dhcp user and group, and the audit user. Start by running “mergemaster -p”

Step 6: Reboot into single user mode

Ideally, everything works at this point. If not, you should still have your old kernel to fall back on. You’ll need to mount all your mountpoints in order to take care of the next step.

Step 7: Install files

Also straightforward — “make installworld” from the /usr/src directory. The most likely trouble you’ll run into is having failed to install a required user or group. After this step, reboot.

Step 8: Merge configurations

This is probably the most tedious part of the upgrade, and pretty easy to screw up badly. To start, su – and run “mergemaster”. This will attempt to merge the plethora of config files from your instance and from the new distribution. As a general rule, you’ll want to go ahead and merge anything you haven’t touched, and pay careful attention to anything you have. It’s easy to get on a roll and let it (for example) replace your mail “aliases” file, which, if you’ve neglected to back up, can be a complete mess.

This is made somewhat more tedious by the fact that you have to approve every change, no matter how trivial. I don’t think there’s an easy way around this.The kernel config will have told you where the kernel build directory is, as well as reminded you to do a make cleandepend; make depend. After that, make and make install will get the kernel installed in the proper location.

Step 9: Reboot (again)

That should do it — it worked for me.

For a number of reasons, I’ve kept my AOL email account, but have naturally incorporated it into a single mailbox using fetchmail and AOL’s imap interface. I noticed that fetchmail started doing this all of a sudden:

fetchmail[90687]: Server certificate verification error: unable to get local issuer certificate
fetchmail[90687]: Server certificate verification error: certificate not trusted

After some investigation, it appears that fetchmail is suddenly having trouble negotiating a TLS connection via IMAP. Beats me why — it either didn’t make the attempt before or something has gone funny on the AOL side — but aside from being vaguely annoying, it turns out that the mail still gets through, and these errors effectively mean nothing whatsoever.