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

This is different from the cvs guide

[RLiegh]

in the handbook how?

Just in case ...

[boarder8925]

In case the site's Slashdotted ...

Google cache of article
Google cache of .pdf file

That's the easy solution?

[cperciva]

If cvsup && buildworld && installworld is the easy solution, I wonder what he considers this to be:

freebsd-update fetch
freebsd-update install


Yeah, ok, FreeBSD Update is only about tracking the release branch. But really, this story just covers the standard technique which people have been using for... well, longer than I've been using FreeBSD.

too many dependencies

[hak1du]

Given the amount of software I have on my Linux box, I think a BSD/Gentoo-like build process just wouldn't be practical for me.

The underlying problem is really that C/C++ code has so much information compiled into each object file: even common, minor changes may require huge amounts of recompilation. While we practice abstraction and encapsulation at the source level, at the binary level, it is still mostly lacking.

The choice shouldn't been between huge amounts of recompilation from source (Gentoo, BSD) or laborious hand-packging and version tracking (Debian, RedHat, etc.), this needs to be addressed by changing the underlying software infrastructure. Let's hope we'll move more towards JITs, dynamic binding, dynamic typing, and component-based software. Then we can finally get away from these massive recompilations and version hell.

Re:too many dependencies

[josepha48]

"Given the amount of software I have on my Linux box, I think a BSD/Gentoo-like build process just wouldn't be practical for me."

No kidding. My NetBSD box taks hours to compile all these packages. If all you want to do is upgrade xscreensaver, all you have to type is make update ( or is it upgrade ). But what happens in the background is that it probably has newer requirements, like an updated gtk, which depends on pango updates, and that depends on .. and so on and so on, and then suddenly updating one program becomes updateing the WHOLE gnome desktop and compiling from sources. On an old 233Mhz that is a long time. But hey NetBSD and FreeBSD install on on old 233Mhz with only 64Megs of RAM, Redhat doesn't, ( debian does though ).

I agree "The choice shouldn't been between huge amounts of recompilation ..." but I can't see having the whole GUI using JITs. Also most of these programs use dynamic binding.

See the problem is that the maintainers of these packages, upgrade the requirements of the packages based on new features in these packages or just because it is the latest in the release tree and assumed to have less bugs. IE. xscreensaver probably would have compiled fine in teh above example with the gtk onn my system, but the Makefile for it has a requires gtk 2.2.x+ or something like that in it which it then checks to see if it is installed on the system. It should really have done, if gtkversion == 2.0 compile with gtk 2.0, and leave our whatever features that it is missing. Chances are there are none that require gtk 2.2 and 2.0 wont work just fine. However if it was gtk = 1.2 then update. A better example is programs that still use gtk 1.2. Is there really a difference between gtk 1.2.10 and 1.2.10nb2? Probably not enough that you are required to upgrade all the programs on the system. They should add an option, and call it make update_all which updates ALL the dependancies and then the default behavior should be make update just this one program. That's what the problem is with this compile stuff. I use Linux, NetBSD, FreeBSD, Windows, Sun, and Mac. They all have their plusses and minuses. It really depends on what you think is important.

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:cvsup in C?

[CoolVibe]

There's also cvsync, which is a good cvsup alternative, written in C.

Re:Gentoo has this..

[UnseenEnigma]

The only issue with gentoo is the lack of a central binary repository like the redhat channels system (official anyway - chinstrap is decent for those willing to stray). It was discussed at great length several months ago and decided not to be created despite having the backend infrastructure already in place. The great advantage of gentoo, and in a way the failure of bsd (and pretty much every commercial linux) is the ability to choose complex compile and build options with ease. For this same reason and the fact a binary repository could never handle a fraction of the possibilities it was never created :(. If however you consider implementing gentoo in a work environment with say 10-100 systems they could all be set to use a central compile server to your organisation or/and through distcc compile kickass fast! Although installs of gentoo are a pain (hopefully better if the installer gets built) it is by far the easiest to update, and customise of any linux. And (big + for me) none of the bs of no or modified media players, browsers, burner software etc of suse, redhat or mandrake because of cautios legal practises. I've been finding more and more things i like about the portage system the more i use it. Any new reasonably popular package seems to make it on the tree in less than a day. If their is a piece of software that isnt on the tree u need (happened to me once) u can either find or make a ebuild and submit it for inclusion in the tree My Conclusions Ms Windows - ah get it away from me!!!! Evil Redhat/Suse/Mandrake - Better but canabalises some stuff and out of date packages The BSD Trio - Stable, fast, easy update, and faster update due to binary Gentoo - Stable, fast, easy update and more customizable due to all source (usually)

Issue #3?November 9, 2003

[beefdart]

I was scanning this... Got 1/2 way through and was wondering if he stole it, cause I swore i read it somewhere.

Then I realized: Issue #3?November 9, 2003

How the hell is this news? I love FreeBSD, its all I use. the only thing dead about it is bsd.slashdot.org

Re:Anonymous Coward's Guide to Updating Debian

[rsax]

Yes APT is great. It's easy to use and requires less effort than the FreeBSD upgrade process but it's too bad Debian stable is so hopelessly out of date. FreeBSD isn't. It's a stable operating system with upto date third party software delivered using the ports system. I've said this before and I'll say it again since this Debian comparison has been brought up.... I hear this argument from Debian advocates a lot: "Do you want a stable server or do you want bleeding edge?" Well with FreeBSD I get stable servers and still have packages that aren't a year or two [or sometimes more] old...... it is possible. And before anyone recommends that I run Debian testing instead please remember that the Debian Security team claim that they don't support anything besides the stable releases. I could use a Debian stable system and then mix match packages from unstable or testing and risk instability in the end or higher maintenance due to no security alerts from one source but then why not use FreeBSD instead in the first place?

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.

Why is his method special?

[hayds]

When I first saw the headline about "painlessly updating", I thought this might be a great article about some new innovative way to update. Its not really anything new or interesting though, the whole article is basically saying: "cd /usr/src && make world && make kernel && mergemaster will update you system"

Not wanting to sound rude, but no shit sherlock! Yes, this is a painless way to update your system. It is also the way to update your system, as is very well spelled out in the excellent FreeBSD Handbook so I'm not sure why it warrants an article....

Maybe its just me but I think an article about portupgrade or something would have been more useful.

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