I am upgrading a FreeBSD 8.3-RELEASE system to FreeBSD 9.0-RELEASE using freebsd-update. This is my first time performing a major version upgrade in FreeBSD.

At one point in the process, freebsd-update performs a diff on files which are different then what is expected for the 9.0-RELEASE. It compares the current version on the system with the new changes added from 9.0-RELEASE. I have a modified a couple dozen files under /etc, and I am presented with this diff once per file.

Thus, I am presented with dozens and dozens of diffs which open in a vi window and look like this:

The following file could not be merged automatically: /etc/ntp.conf
Press Enter to edit this file in vi and resolve the conflicts

### vi window opens

<<<<<<< current version
driftfile /etc/ntp/drift
# $FreeBSD: release/9.0.0/etc/ntp.conf 195652 2009-07-13 05:51:33Z dwmalone $
# Default NTP servers for the FreeBSD operating system.
# Don't forget to enable ntpd in /etc/rc.conf with:
# ntpd_enable="YES"
# The driftfile is by default /var/db/ntpd.drift, check
# /etc/defaults/rc.conf on how to change the location.
>>>>>>> 9.0-RELEASE

restrict default notrust nomodify ignore

And it complains about minor version numbers:

--- current version
+++ new version
@@ -1,6 +1,6 @@
-# $FreeBSD: src/gnu/usr.bin/man/manpath/manpath.config,v 2009/04/15 03:14:26 kensmith Exp $
+# $FreeBSD: src/gnu/usr.bin/man/manpath/manpath.config,v 2010/12/21 17:10:29 kensmith Exp $
 # This file is read by manpath(1) to configure the mandatory manpath,
 # optional manpath and to map each path element to a manpath element.
 # The format is:
Does this look reasonable (y/n)? y

And fact it complains about the RCS version string on dozens of files:

--- current version
+++ new version
@@ -1,4 +1,4 @@
-# $FreeBSD: src/etc/amd.map,v 2009/04/15 03:14:26 kensmith Exp $
+# $FreeBSD: release/9.0.0/etc/amd.map 164015 2006-11-06 01:42:11Z obrien $
 /defaults       type:=host;fs:=${autodir}/${rhost}/host;rhost:=${key}
 *               opts:=rw,grpid,resvport,vers=3,proto=tcp,nosuid,nodev
Does this look reasonable (y/n)?

And even complains because I removed the FreeBSD version number from my local (custom) /etc/passwd file:

<<<<<<< current version
# $FreeBSD: release/8.4.0/etc/master.passwd 243948 2012-12-06 11:54:25Z rwatson $
>>>>>>> 8.4-RELEASE
root:*:0:0:Charlie &:/root:/bin/csh
toor:*:0:0:Bourne-again Superuser:/root:
daemon:*:1:1:Owner of many system processes:/root:/usr/sbin/nologin

And so on.

This requires that I manually edit each file and remove the strings like <<<<<<< current version >>>>>>> 9.0-RELEASE and =======, and manually merge these files. As I discovered afterwards, if I don't remove these strings, they end up in the file afterwards. There are dozens of files which differ between 8.3 and 9.0, and I have a dozen local modifications myself.

It appears that freebsd-update is using a diff, sdiff or mergemaster function of some sort, but I can't tell what it is doing exactly.

Processing these files is tedious. Is there a way that I can just say "Accept new version" or "keep old version" or "Your merge is correct"? There has got to be an easier way to deal with these files. I must be missing something.

This isn't a huge problem for one machine, but eventually I'll be doing this dozens of times and I want to find an easier way.

And I am not alone. At least one other admin out there has pointed out this problem. The author of Zytrax.com: FreeBSD Update Survival Guide: freebsd-update upgrading minor or major versions also talks about this situation:


  1. When updating to a new release lots of stuff changes (much less so with a minor release). When scripts and configurations files are modified freebsd-update diffs them, loads them into vi and presents them for reconciliation. Since most of the changes are simple version number comment field changes this can be a serious pain (in our case well over 50 files were changed, over 40 were comment only changes). However, be warned - diligence is necessary (no :wq to every file without looking). Further, unless the file is visibly short all the diff marks (:/>>>/) need to be viewed and reconciled. Failure to do this will cause the resulting file to contain the diff indicators and many essential system files will simply croak when loaded (including the password file in our case) resulting in endless hours of fun looking for the files that were modified (guess how we found this out). While there is really no alternative to genuine file changes, having to undergo the edit reconciliation for comment only changes results in a serious shortcoming in the process. Better, perhaps, to move the replaced files into a special location and let the user manually reconcile those of interest. Just how often do you change /etc/periodic/weekly/310.locate?


Looks like these diffs are managed by merge(1), not mergemaster. From the merge(1) manpage:

   A conflict occurs if both file1 and file3 have changes in a common seg-
   ment of lines.  If a conflict is found, merge normally outputs a  warn-
   ing  and brackets the conflict with <<<<<<< and >>>>>>> lines.  A typi-
   cal conflict will look like this:

      <<<<<<< file A
      lines in file A
      lines in file B
      >>>>>>> file B
  • I've done several version upgrades using freebsd-update, and not had this issue. I just tried an 8.3 to 9.0 upgrade, and the number of files that required any manual merging was zero. I don't know what might cause your symptoms. – hmallett Jun 16 '12 at 8:37
  • @hmallett : These are files which we have modified locally. – Stefan Lasiewski Jun 16 '12 at 15:13
  • Really? You've never updated files like /etc/passwd or /etc/resolv.conf? That is where I am seeing this behavior. – Stefan Lasiewski Jan 11 '13 at 0:41

I wasn't getting much response here, so I asked at forums.freebsd.org.

The short answer is: No. There is no easy way to merge these changes using freebsd-update. freebsd-update uses merge(1) to perform the diffs and merging, and merge is not very friendly or flexible.

There are other options, such as sysutils/etcupdate as suggested by kworr. However, I don't see how that can be integrated with freebsd-update.

From what I read, freebsd-update is a convenient way to upgrade FreeBSD, but it fails in other ways. Many FreeBSD admins don't use freebsd-update at all, and prefer the manual way using using the source and mergemaster(8).


I would agree that in many cases, the older way will give less trouble; that is, if you're upgrading from a non-RELEASE "branch", major version upgrades, etc.

But freebsd-update is "da schiz" for keeping a RELEASE-branch system current with security patches (or, in other words, a production machine/server).

Anytime you update from something more than a few months old there are likely some changes to files in /etc --- the older way uses "mergemaster", which is slightly more friendly that merge, but updating merges to /etc/ files that have been modified is always going to be a PITA that requires a good bit of manual intervention. It's just that mergemaster is a tad (only a tad) more "user-friendly".


There's a good thing named sysutils/etcupdate in the ports. It can do a semi-auto three-way merge of your configs requiring minimal involvment.

  • kworr, are you suggesting that I don't use freebsd-update? How would I use etcupdate with freebsd-update? – Stefan Lasiewski Jul 3 '12 at 20:12
  • You don't need to ditch freebsd-update, just make sure you tell it not to MergeChanges. I have no experience with freebsd-update so you better test this update path on any other machine. – kworr Jul 4 '12 at 9:41

From my reading of the handbook, you can set some of this behavior in the configuration file for freebsd-update:

    # Paths which start with anything matching an entry in an UpdateIfUnmodified
    # statement will only be updated if the contents of the file have not been
    # modified by the user (unless changes are merged; see below).
      UpdateIfUnmodified /etc/ /var/ /root/ /.cshrc /.profile

While I've always done updates/upgrades the manual way, I might try this on my test machine to see how it goes.

  • My systems do have that setting (I think it's a default). The trouble is, the files are slightly modified and FreeBSD forces a diff for those (The $ID$ tag is different between 8 -> 9, the root password is set, etc.). It's a known problem that FreeBSD never fixed. Now that we're on FreeBSD 9, this may not be an issue upgrading to 10 if we decide to stay with FreeBSD. – Stefan Lasiewski Jul 19 '15 at 2:02

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.