Painlessly Update FreeBSD

boarder8925 writes "Over at BSDnews, Steve Wingate has written an article on how to easily update FreeBSD. Wingate begins his article by saying, "One of the greatest advantages that *BSD has over other Unix variants is the cvsup/make world process. Unlike most Linux distributions it isn't necessary to wait months for a new version to be released for you to upgrade your system. The cvsup/make world process allows you to update your system at any time. I'm going to show you how to make the process as painless as possible." The article discusses the following: installing CVSup, choosing a cvsup server, configuring make.conf, and, finally, performing the upgrade. The piece is also available as a .pdf file."

Comments

Just in case ...

[boarder8925]

In case the site's Slashdotted ...

Google cache of article
Google cache of .pdf file

Re:cvsup in C?

[cperciva]

Anybody know if cvsup will ever be rewritten in C instead of Modula-2 or whatever the heck that is?

Yes. It is being done, and there is (mostly) working code.

Re:"unlike most linux distributions"?

[hayds]

Yes, linux has always had software to update software to the latest official release. What he is saying is that with BSD you can update the system to the latest software too, without waiting for the next version.

In other words, on RedHat or Debian, I can update to the latest apache pretty easily with apt or rpm. Same on BSD. But on BSD I can also easily download and install the very latest updates to the kernel and base system straight from the official CVS without having to wait for binary updates to come. In Linux distros, binary updates to core packages in the base system are often not released (unless they are security related of course) until the next version of the distro. On BSD the latest is always available for download.

Re:Recommended step

[cos(x)]

Actually, for 'mergemaster -p' to do what it's intended to do, you need to have the current source code downloaded already. So, you would need to exchange the order of this command and 'make update':

alias rebuild 'cd /usr/src && make update && mergemaster -p && make world && make kernel && mergemaster'

It's more risky than following the handbook.

[TheLink]

The article is actually riskier IMO.

Firstly: he doesn't track the RELENG_4_9 branch, he tracks the STABLE branch (RELENG_4 - e.g. the latest of whatever is considered stable for Release 4) - which is more likely to break working stuff than the RELENG_4_9 branch which is FreeBSD 4.9 that has just the updates for security problems. Yes many ppl don't have problems with RELENG_4, but if your job and reputation is on the line - only use it if RELENG_4_9 doesn't work (hardware, required features etc).

Secondly: He skips the mergemaster -p step.

The way I recommend is what's been in the FreeBSD handbook for years:
Step 1: Synchronize your source Use cvsup. It's better. And track the RELENG branch.
e.g. cvsup mycustomcvsupfile
Where mycustomcvsup is like the stable-supfile but with the following tag instead of RELENG_4:
*default release=cvs tag=RELENG_4_9

Step 2: Building and Installing world

optional step before:
cp /etc/defaults/make.conf /etc/make.conf
edit /etc/make.conf accordingly (compile options, whether ports openssl/openssh overwrites the base openssl/openssh etc)

Then
make buildworld
make buildkernel KERNCONF=YOURKERNELNAME
make installkernel KERNCONF=YOURKERNELNAME
reboot and go to single user mode
mergemaster -p
(preliminary mergemaster stuff if things are too different between your config and what the new FreeBSD stuff is)
make installworld
mergemaster
(to merge what's new in /etc and stuff to what your local custom config is like)
reboot

***multiple machines.
Here's where you might do things differently.

Read this for some background: tracking for multiple machines

Now once you built everything, you don't have to rebuild it on a different machine if you are using a compatible architecture. For example you specify a 686 CPU in your make.conf and kernel config, you can only reuse it on stuff which supports 686 class CPUs.

I didn't bother with the NFS part (not applicable for some situations) - I just did the synchronize of src and ports and did the build on a fast machine with a fast connection.

The default was 4-stable which tracks the current stable source of Release 4. For production machines I recommend tracking RELENG releases and not STABLE.

Then build the kernel and sources.
cd /usr/src
make buildkernel KERNCONF=kernelformachineA
make buildkernel KERNCONF=kernelformachineB
make buildkernel KERNCONF=kernelformachineC
make buildworld
cd /usr/
Then tarball the results: tar -zcvf src.tar.gz src && tar -zcvf obj.tar.gz obj && tar -zcvf ports.tar.gz ports

Then I copied the tarballs (via CDR) to the slow machine which did not have a cvsup connection (not allowed by firewall policy etc)

Then installed the results on the machine.
cd /usr
rm -rf src obj ports
tar -zxvf src.tar.gz && tar -zxvf ports.tar.gz && tar -zxvf obj.tar.gz

Then I ensured that the /etc/make.conf was correct etc.
Then: make installkernel KERNCONF=therelevantkernel && make installworld.

Note: to save the trouble of building desired ports software on the slow machine you have to make packages on the fast machine.
e.g.
cd /usr/ports/blahblah/softwarename
make package
---
You should also check out freebsd-update.

freebsd-update is more like binary updating of stuff affected by security issues.

Redhat is simpler on one hand and more complex on the other- sure you can ftp all the rpms and run a freshen. But it's harder to be sure everything is really consistent