freebsd-update vs. csup w/ buildworld

Mausy5043

Mausy5043

I'm confused. I've been searching the web for this but can't find an answer to my problem.

I have a FreeBSD 9.0 virgin system. I did an update of the /usr/src tree using $ sudo csup /etc/sup-src where /etc/sup-src contains:
Code: 
# cat /etc/sup-src
*default tag=RELENG_9_0
*default host=cvsup.nl.freebsd.org
*default prefix=/usr
*default base=/var/db
*default release=cvs delete use-rel-suffix

src-all

I then followed the instructions at the end of par. 25.7.1 of the FreeBSD handbook (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html) to rebuild the world and the GENERIC kernel.
I installed both as per those instructions and rebooted the system. So, now I have:
Code: 
$ uname -a
FreeBSD boson.local 9.0-RELEASE-p4 FreeBSD 9.0-RELEASE-p4 #0: Thu Oct 25 20:05:57 CEST 2012    root(at)boson.local:/usr/obj/usr/src/sys/GENERIC  amd64

Here's where it gets crazy: When I do csup, it gives me a result that I'd expect:
Code: 
$ sudo csup /etc/sup-src
Connected to 82.94.213.215
Updating collection src-all/cvs
Finished successfully

However freebsd-update says something else:
Code: 
$ sudo freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 9.0-RELEASE from update5.FreeBSD.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

The following files are affected by updates, but no changes have
been downloaded because the files have been modified locally:
/var/db/mergemaster.mtree

The following files will be updated as part of updating to 9.0-RELEASE-p4:
/boot/kernel/kernel
/boot/kernel/kernel.symbols
/lib/libcrypt.so.5
/lib/libcrypto.so.6
/rescue/[
/rescue/atacontrol
/rescue/atmconfig
/rescue/badsect
/rescue/bsdlabel
/rescue/bunzip2
/rescue/bzcat
/rescue/bzip2
/rescue/camcontrol
/rescue/cat
/rescue/ccdconfig
/rescue/chflags
/rescue/chgrp
/rescue/chio
/rescue/chmod
/rescue/chown
/rescue/chroot
/rescue/clri
/rescue/cp
/rescue/csh
/rescue/date
/rescue/dd
/rescue/devfs
/rescue/df
/rescue/dhclient
/rescue/disklabel
/rescue/dmesg
/rescue/dump
/rescue/dumpfs
/rescue/dumpon
/rescue/echo
/rescue/ed
/rescue/ex
/rescue/expr
/rescue/fastboot
/rescue/fasthalt
/rescue/fdisk
/rescue/fsck
/rescue/fsck_4.2bsd
/rescue/fsck_ffs
/rescue/fsck_msdosfs
/rescue/fsck_ufs
/rescue/fsdb
/rescue/fsirand
/rescue/gbde
/rescue/geom
/rescue/getfacl
/rescue/glabel
/rescue/gpart
/rescue/groups
/rescue/gunzip
/rescue/gzcat
/rescue/gzip
/rescue/halt
/rescue/head
/rescue/hostname
/rescue/id
/rescue/ifconfig
/rescue/init
/rescue/ipf
/rescue/kenv
/rescue/kill
/rescue/kldconfig
/rescue/kldload
/rescue/kldstat
/rescue/kldunload
/rescue/ldconfig
/rescue/link
/rescue/ln
/rescue/ls
/rescue/lzcat
/rescue/lzma
/rescue/md5
/rescue/mdconfig
/rescue/mdmfs
/rescue/mkdir
/rescue/mknod
/rescue/mount
/rescue/mount_cd9660
/rescue/mount_msdosfs
/rescue/mount_nfs
/rescue/mount_ntfs
/rescue/mount_nullfs
/rescue/mount_udf
/rescue/mount_unionfs
/rescue/mt
/rescue/mv
/rescue/newfs
/rescue/newfs_msdos
/rescue/nos-tun
/rescue/pgrep
/rescue/ping
/rescue/ping6
/rescue/pkill
/rescue/ps
/rescue/pwd
/rescue/rcorder
/rescue/rcp
/rescue/rdump
/rescue/realpath
/rescue/reboot
/rescue/red
/rescue/rescue
/rescue/restore
/rescue/rm
/rescue/rmdir
/rescue/route
/rescue/routed
/rescue/rrestore
/rescue/rtquery
/rescue/rtsol
/rescue/savecore
/rescue/sed
/rescue/setfacl
/rescue/sh
/rescue/spppcontrol
/rescue/stty
/rescue/swapon
/rescue/sync
/rescue/sysctl
/rescue/tail
/rescue/tar
/rescue/tcsh
/rescue/tee
/rescue/test
/rescue/tunefs
/rescue/umount
/rescue/unlink
/rescue/unlzma
/rescue/unxz
/rescue/vi
/rescue/whoami
/rescue/xz
/rescue/xzcat
/rescue/zcat
/rescue/zfs
/rescue/zpool
/sbin/init
/usr/bin/dig
/usr/bin/host
/usr/bin/nslookup
/usr/bin/nsupdate
/usr/bin/openssl
/usr/lib/libcrypt.a
/usr/lib/libcrypt_p.a
/usr/lib/libcrypto.a
/usr/lib/libcrypto_p.a
/usr/lib/libssl.a
/usr/lib/libssl.so.6
/usr/lib/libssl_p.a
/usr/lib32/libcrypt.a
/usr/lib32/libcrypt.so.5
/usr/lib32/libcrypt_p.a
/usr/lib32/libcrypto.a
/usr/lib32/libcrypto.so.6
/usr/lib32/libcrypto_p.a
/usr/lib32/libssl.a
/usr/lib32/libssl.so.6
/usr/lib32/libssl_p.a
/usr/sbin/ddns-confgen
/usr/sbin/dnssec-dsfromkey
/usr/sbin/dnssec-keyfromlabel
/usr/sbin/dnssec-keygen
/usr/sbin/dnssec-revoke
/usr/sbin/dnssec-settime
/usr/sbin/dnssec-signzone
/usr/sbin/lwresd
/usr/sbin/named
/usr/sbin/named-checkconf
/usr/sbin/named-checkzone
/usr/sbin/named-compilezone
/usr/sbin/named-journalprint
/usr/sbin/rndc-confgen
/usr/src/secure/lib/libcrypt/crypt-des.c
/usr/src/sys/amd64/amd64/trap.c
/usr/src/sys/conf/newvers.sh
/usr/src/sys/netinet/tcp_input.c
/usr/src/sys/netinet6/in6.c
/usr/src/sys/netinet6/ip6_input.c

This confuses me. I thought freebsd-update was all about binaries. And since I built them from the most recent sources I'd expect them to be identical or better compared to what freebsd-update is offering. Also, I'd expect only updates on binaries that have more recently shown to have security-issues. What about the .c files then?
Could somebody try to explain this to me?

Also, should I install those updates or ignore freebsd-update altogether?
 
Mausy5043 said:
This confuses me. I thought freebsd-update was all about binaries.
Click to expand...

From /etc/freebsd-update.conf:
Code: 
# Components of the base system which should be kept updated.
Components src world kernel
Note the src component.
 
Mausy5043 said:
OK. So, there's a .conf-file :-)

That explains that. But why does csup not find these?
Click to expand...

When I use freebsd-update to install the sources it proposes need to be updated (only the component src is selected for this example) and then I run csup, csup will rollback those changes:

Code: 
$ sudo freebsd-update fetch install
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 9.0-RELEASE from update5.FreeBSD.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

The following files will be updated as part of updating to 9.0-RELEASE-p4:
/usr/src/secure/lib/libcrypt/crypt-des.c
/usr/src/sys/amd64/amd64/trap.c
/usr/src/sys/conf/newvers.sh
/usr/src/sys/netinet/tcp_input.c
/usr/src/sys/netinet6/in6.c
/usr/src/sys/netinet6/ip6_input.c
Installing updates... done.

$ sudo csup -h cvsup.freebsd.org /etc/sup-src
Connected to 72.233.193.64
Updating collection src-all/cvs
 Checkout src/secure/lib/libcrypt/crypt-des.c
 Checkout src/sys/amd64/amd64/trap.c
 Checkout src/sys/conf/newvers.sh
 Checkout src/sys/netinet/tcp_input.c
 Checkout src/sys/netinet6/in6.c
 Checkout src/sys/netinet6/ip6_input.c
Finished successfully
:\

So, my real question is, what would be the best way to keep my system's sources up-to-date? freebsd-update or csup?
And what is the advised way to keep the binaries up-to-date? (freebsd-update or csup with buildworld/buildkernel?

I hope you understand my confusion.
 
I've been thinking about this for a while and this is how I now think this all fits together conceptually. Please feel free to correct me:

Any given FreeBSD system (I'm disregarding X-based systems, as I'm not using a GUI. But I gather that the below will also be valid for systems with Xorg installed.) contains three parts that one may need to keep up-to-date:

  1. The kernel
  2. The world (userland)
  3. Ports & packages

To start with the last one: ports & packages can be kept up-to-date using portaudit -Fda to find security issues that need to be fixed ASAP and portsnap fetch update for all other updates. Using portmaster to administer the updates.

The kernel and world, in the case of a GENERIC kernel/system, can be patched using freebsd-update fetch install. Usually a reboot is required to "activate" the patches.

Finally, in the case of a custom built kernel and/or world, csup is the tool of choice. This requires a buildworld / buildkernel etc. procedure to get those patches installed.

Right?
 
I have leaned toward binary installations when possible of packages/ports - there are some issues but the compilation time for a large X application and its associated dependencies can take quite some time and headache - pkgng looks promising but is still in the works.

For world and kernel, i like compiling. it's fairly easy to do, not too time-consuming, and I rarely have issues with anything breaking. i also run a custom kernel, though, so I reckon it is up to you. Also, if you have any system-specific flags set in your /etc/make.conf that are relevant you will probably want to compile from source.

I have been using CVS source gets and compiled world and kernel from source for about 15 years and it just works for me.
 
You must log in or register to reply here.
Back
Top