FreeBSD Build Process

After the patches for the Heartbleed were issued for FreeBSD, I thought I should include them, even though I don't use SSL on the websites. Just before the rebuild, I noticed that the /etc/src.conf file was not correct. It was missing the modules for iwi and iwifw, required for the backup laptop, cobalt. so, I added the necessary module names to the MODULES_OVERRIDE line and issued the usual

  make -j 4 buildworld && make -j4 buildkernel KERNCONF=GENERIC

Buildworld completed successfully, but the buildkernel phase failed with:

  -- @ ---
  @ -> /usr/src/sys
  --- .depend ---
  rm -f .depend
  CC='cc ' mkdep -f .depend -a   -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_O\
  PTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/GENERIC -std=iso9\
  899:1999   /usr/src/sys/modules/syscons/green/../../../dev/syscons/green/green_\
  saver.c
  ===> iwifw (depend)
  --- depend ---
  ===> iwifw/iwi_bss (depend)
  --- iwi_bss.c ---
  awk -f @/tools/fw_stub.awk iwi_bss:iwi_bss:300 -miwi_bss -ciwi_bss.c  -lintel_i\
  wi
  awk: can't open file @/tools/fw_stub.awk
  source line number 1 source file @/tools/fw_stub.awk
  context is
  >>>  <<<
  *** [iwi_bss.c] Error code 2

Running this step manually worked OK. Hmm, this must be one of those circumstances when /usr/obj needs to be nuked. But that would mean I had to re-run buildworld (four hours). Perhaps I could just remove the contents of /usr/obj/usr/src/sys/* to avoid that delay?

Yes, the allowed the buildkernel to complete successfully. However, make installworld failed when trying to install the contents of /boot/i386. So, not everything under sys is built during the buildkernel phase. I figure if I had just deleted the contents of "/usr/obj/usr/sys/GENERIC/* I would have got away with it. As it was, a complete re-run of the build process was required (although this time, I did use -D NO_CLEAN).

SVN revision numbers

I checked the SVN revision displayed by uname -a and was surprised to find it was higher (r265158) than the revision in which the Heartbleed fixes had been made (r265124). Here's the output from svnlite info /usr/sys:

  Working Copy Root Path: /usr/src
  URL: svn://svn.freebsd.org/base/releng/10.0
  Relative URL: ^/releng/10.0
  Repository Root: svn://svn.freebsd.org/base
  Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
  Revision: 265158
  Node Kind: directory
  Schedule: normal
  Last Changed Author: delphij
  Last Changed Rev: 265124
  Last Changed Date: 2014-04-30 05:04:42 +0100 (Wed, 30 Apr 2014)

So why is Revision higher than Last Change Rev? This has been noticed by other people. I quote:

> Did so, too. It's so frustrating, I mean, I compile kernel and world
> since 6.0 and never had similar issues. What makes me a bit nervous is
> that this happens on two different machines. And why is the revision
> (r244992) of the kernel ident higher than the release revision
> (r243710[1])?

Let me use the output of svn info from stable/9 as an example:

root at enterprise:/usr/src # svn info
Path: .
Working Copy Root Path: /usr/src
URL: svn://svn.ximalas.info/freebsd/base/stable/9
Repository Root: svn://svn.ximalas.info/freebsd/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 245035
Node Kind: directory
Schedule: normal
Last Changed Author: pfg
Last Changed Rev: 245025
Last Changed Date: 2013-01-04 05:03:21 +0100 (Fri, 04 Jan 2013)

The uname string of the kernel includes the revision number contained 
in the Revision line as shown above. svn keeps global revision numbers 
unlike cvs which uses revision number per each file.

All of FreeBSD base source code resides in one giant repository. Thus 
changes made in, say, /base/head, i.e. -CURRENT, affects other 
"branches", say, /base/releng/9.1.

It would make more sense if the uname string referred to the Last 
Changed Rev line.

I agree, so I submitted a defect report and patch (incomplete of course) to the FreeBSD PR system.

The patch is pretty simple, but it is missing similar changes for a system with full svn or git.

  --- newvers_orig.sh     2014-05-01 09:13:28.000000000 +0100
  +++ newvers.sh  2014-05-01 11:00:40.000000000 +0100
  @@ -110,12 +110,11 @@
  if [ -z "${svnversion}" ] && [ -x /usr/bin/svnliteversion ] ; then
          /usr/bin/svnliteversion $(realpath ${0}) >/dev/null 2>&1
          if [ $? -eq 0 ]; then
  -               svnversion=/usr/bin/svnliteversion
  +               svnversion="/usr/bin/svnliteversion -c"
          else
                  svnversion=
          fi
   fi
  -
   for dir in /usr/bin /usr/local/bin; do
          if [ -x "${dir}/p4" ] && [ -z ${p4_cmd} ] ; then
                p4_cmd=${dir}/p4
  @@ -133,7 +132,7 @@
   if [ -n "$svnversion" ] ; then
          svn=`cd ${SYSDIR} && $svnversion 2>/dev/null`
          case "$svn" in
  -       [0-9]*) svn=" r${svn}" ;;
  +       [0-9]*) svn=" r${svn#*:}" ;;
          *)      unset svn ;;
          esac
  fi

Using the -c switch to svnliteversion causes the Last Changed Rev to be returned, but prefixed with the OS version, e.g. "10:256124", so that is stripped off,

I'm not too hopeful the change will be made; there are five open PRs against newvers.sh (although to be fair, it looks like some have been implemented, even though the PRs are open).