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).
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).
