Date: Wed, 5 Aug 2015 15:55:51 -0400 (EDT) From: doug@safeport.com To: freebsd-questions@FreeBSD.ORG Subject: Re: freebsd-update 9.1 --> 9.3 Message-ID: <alpine.BSF.2.00.1508051545390.28235@bucksport.safeport.com>
next in thread | raw e-mail | index | archive | help
On Tue, 4 Aug 2015, doug wrote:
> First this is on a test system so no harm [or not], no foul.
>
> I started with an ISO for 9.1, added the security changes and then tried to
> update 9.1 --> 9.2. I was given a non-ending series of files in /etc (with no
> local changes) to merge. I did half-a-dozen or before stopping the process
> and doing a rollback.
>
> I have two questions:
>
> (1) uname -a shows:
>
> FreeBSD chaos.boltsys.com 9.2-RELEASE-p15 FreeBSD 9.2-RELEASE-p15 #0:
> Mon Nov 3 20:31:29 UTC 2014
> root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
>
> while 336 of 354 file show releng/9.1 and none have 9.2. So is it 9.1
> with a false indicator or is it messed up? The system is running the
> GENERIC kernel.
>
> (2) Section 24.2.1. The Configuration File - from the handbook says
>
> "... The file merge process is a series of diff(1) patches similar
> to mergemaster(8), but with fewer options. Merges are either accepted,
> open an editor, or cause freebsd-update to abort. When in doubt,
> backup /etc and just accept the merges."
>
> How is this done with freebsd-update? The format of the files presented
> must be changed.
I have done this (9.1-->9.2) three times after this and can not duplicate the
conditions where /etc was not updated, so I conclude user error.
There is no way (I am pretty sure) to avoid manually editing each file that the
update process presents. In upgrading to 9.2 /usr/lib32 was dropped. This is
corrected by adding world/lib32 to freebsd-update.conf. On my last update I
tested the src procedures procedures to remove obsolete files. All worked in
that nothing was done, the files had been removed and /usr/lib32 was correctly
updated with its obsolete files removed by freebsd-update.
Next I am doing 9.2-->9.3. This gets:
freebsd-update install
Installing updates...install: ///usr/src/contrib/bind9/libtool.m4 exists but is
not a directory
install: ///usr/src/contrib/bind9/libtool.m4/libtool.m4: Not a directory
install: ///usr/src/contrib/bind9/libtool.m4/ltoptions.m4: Not a directory
install: ///usr/src/contrib/bind9/libtool.m4/ltsugar.m4: Not a directory
install: ///usr/src/contrib/bind9/libtool.m4/ltversion.m4: Not a directory
Completing this upgrade requires removing old shared object files. Please
rebuild all installed 3rd party software (e.g., programs installed from the
ports tree) and then run "/usr/sbin/freebsd-update install" again to finish
installing updates.
As I am testing on base base system with no ports or anything other than what
was installed by requesting src and lib32 on a from scratch install there is, by
definition, no 3rd party stuff. So that leaves some repackaging of bind but I
could find nothing in README, UPDATING or associated links on this. A post from
Aug 2014 suggests
rm /usr/src/contrib/bind9/libtool.m4 && mkdir -p /usr/src/contrib/bind9/libtool.m4
mkdir -p /usr/src/share/man/man{4,9}
Having access to a 9.3 system I know is correct, I found libtool.m4 is indeed a
file in 9.2 and a directory in 9.3. On my system the file had been removed and
../share/man had the required directories so creating the directory libtool.m4
only worked for me.
My question is, assuming the guy from the Netherlands was not a bind
developer/expert how did he know this?? Knowing the answer I will know what to
try the next time this error occurs, but I did not get it in real time, nor is
it mentioned in the man page or handbook AFAICT. So RTFM does not work.
_____
Douglas Denault
http://www.safeport.com
doug@safeport.com
Voice: 301-217-9220
Fax: 301-217-9277
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1508051545390.28235>