I have a very old FreeBSD server at work.

atlas:~>uname -mprs FreeBSD 6.4-RELEASE-p8 i386 i386

I'd like to update it. I'm quite familiar and comfortable with the "make world" methods. I've just never used it for a system that was 1.5 years out of date.

What do you feel would be the upgrade method with the lowest risk? I can think of using freebsd-update and cvsup/make-world. I can go straight to the newest version or I can go to the newest 6.x version and then go to 7.x and then to 8.x. That "stepping stone" method seems safest, but also uses a lot of time.

Thoughts? Is freebsd-update able to go through so many versions at the same time? How about cvsup/make-world?

Thanks in advance!

  • Nevermind. I looked it up. Sorry. I should have done that first. I'd be happy to accept an answer I received if it worked. So far, not a single answer to a question I posted has been a working solution. One sent me in a new direction, but ended up being verifiably false. The rest were ideas that I either already tried and ruled out or not even on-topic. I don't want to accept an answer and end up misleading someone who finds my "endorsement" of that answer. Jul 15 '11 at 12:11
  • 2
    @DataScavender: I did not check your other questions, but "The rest were ideas that I either already tried and ruled out" makes me to believe that the questions were not put well - i.e. they are missing what was tried already, and didn't work. You may consider reading the classics: catb.org/~esr/faqs/smart-questions.html (specifically catb.org/~esr/faqs/smart-questions.html#beprecise)
    – Sunny
    Jul 15 '11 at 14:44
  • @Sunny: Thanks for the URLs. My big issue is that I usually have tried so many things (many of which are complex and/or lengthy) that I couldn't list them all. Jul 15 '11 at 22:54

The upgrade method with the lowest risk is to build a new machine, copy your data over, test, and cut over when you're sure it works.

The next lowest risk is to do the same thing using virtual machines, then when you know the upgrade works in a virtual environment back up all of your data, re-install the server with the new OS and all the applications you will require (via ports or packages), and then restore your data.

The third lowest risk option is to back up your data, cvsup to the next major version (e.g. you're currently running 6.x so you would cvsup to a release on the 7.x branch) and perform the steps in /usr/src/UPDATING. Repeat as necessary until you hit the version you intend to run in production.
If you want to do this you should clone your current environment in a virtual machine and test the upgrade path: It is exceedingly likely that things will break during the upgrade process.

The fourth lowest risk option is to do the third lowest risk option, minus the backups.
We can call this the "High risk" or "if-you-do-this-on-a-production-box-you-should-probably-be-fired" option.

Once you have dragged your environment up to the release you want to run you need to commit to tracking releases on a regular basis - If you neglect updates and let the environment fall this far behind again you will wind up having to do this all over in 2 years.

  • 1
    I agree about regular updates. My upgrade woes aren't a sysadmin issue. They're from management / institutional culture. I need at least 6 approvals (no exaggeration) before making a shutdown and those people tend to not reply to my requests. Then they tend to kill the few outage requests that are approved. Usually at the last minute. Lately, I've been building redundancies (e.g. 2nd web proxy & an Open Directory replica) to make it easier to do upgrades. When I first started using FreeBSD, outage time was easy to get. User/management expectations changed around 3-5 years ago. :( Jul 15 '11 at 22:42
  • I should have said this first: Thank you. The through reply was really appreciated. I do have backups. Redundant backups, in fact. (Tapes and a disk-to-disk-to-offsite Barracuda system.) I've started setting up a VMware environment to test the upgrade, too. Jul 15 '11 at 22:45
  • @DataScavenger - That kind of management/institutional culture issue IS a sysadmin issue: In situations like that you need to start writing memos and scheduling meetings in which you paint a bleak scenario of critical service failures, long outages, and evil h4x0rz pounding at the gates in order to get reasonable maintenance windows. Make noise until the institution realizes that one or two days every quarter hurts less than their current policy. (I know this is easier said than done, but it's often necessary)
    – voretaq7
    Jul 18 '11 at 15:04

Question is already answered, I just wanted to add some tips.

  1. If you have fully backed up system and it has mirror - you can break the mirror, upgrade, test, re-add devices to mirror. It can be risky, but IMHO ability to rollback any mess worth it.
  2. Also to minimize risk of breaking some packages dependencies you should add COMPAT_FREEBSD6 option to your kernel and install compat6x port
  3. Newer versions of FreeBSD have ZFS, so you can create a clone before an update.
  • The point about COMPAT_FREEBSD6 is a very good reminder. Thanks for that one. I don't have a mirror or ZFS. However, I do dump the entire filesystem to a tape every weekday. Between that a a boot CD, I should be able to recover from a disaster. Thanks again! Jul 26 '11 at 22:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.