Date: Thu, 26 Apr 2001 13:52:23 -0800 From: Beech Rintoul <akbeech@anchoragerescue.org> To: Bryce Newall <data@dreamhaven.org>, FreeBSD Questions List <freebsd-questions@freebsd.org> Subject: Re: 3.5.1 --> 4.3 upgrade troubles Message-ID: <01042613522301.13770@galaxy.anchoragerescue.org> In-Reply-To: <Pine.BSF.4.33.0104261422020.817-100000@ds9.dreamhaven.org> References: <Pine.BSF.4.33.0104261422020.817-100000@ds9.dreamhaven.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 26 April 2001 13:27, Bryce Newall wrote:
> Hello,
>
> I am attempting to upgrade a system from 3.5.1-STABLE to 4.3-STABLE.
> Following the directions, I am trying to build the world using "make
> -DNOPERL -DNOSUIDPERL buildworld". Very early in the compilation, it
> bombs out with the following: (please forgive the paste)
>
> c++ -I/usr/obj/usr/src/i386/usr/include/g++ -O -pipe
> -I/usr/obj/usr/src/i386/usr/include
> -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib
> -I/usr/src/gnu/usr.bin/gperf -c
> /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/new.cc
> /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/new.cc:80: warning:
> `catch', `throw', and `try' are all C++ reserved words
> /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/new.cc: In function
> `void operator delete(void *)':
> /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/new.cc:82:
> declaration of `operator delete(void *)' throws different exceptions...
> <internal>:82: ...from previous declaration here
> *** Error code 1
>
> I did make sure to remove the existing /usr/obj directory before starting
> buildworld. I seem to recall running into something like this once
> before, but I cannot remember the solution. It probably has to do with
> trying to use 3.x libraries instead of 4.x, but I'm not sure.
>
> Any advice will be breatly appreciated! Thanks in advance,
>
From /usr/src/UPDATE:
> To update from 3.x to 4.x stable
--------------------------------
***********************************************************
READ -STABLE ARCHIVES FOR THE LAST WEEK OR TWO BEFORE
STARTING THIS PROCESS. UPDATING MAY LAG BEHIND A LITTLE
A GOTCHAS ARE OFTEN REPORTED IN FREEBSD-STABLE@FREEBSD.ORG
BEFORE BEING INCLUDED HERE. IF YOU ARE GOING TO DO REMOTE
MACHINES, MAKE SURE THAT THE EXACT VERSION YOU ARE UPDATING
THEM TO WORKS ON LOCAL MACHINES BEFORE PROCEEDING.
***********************************************************
<see notes below> [3]
cd /usr/src
<see notes below> [2]
make buildworld -DNOPERL
<follow directions to build/install a kernel>
cd /usr/src/sbin/mknod
make install
<follow rebuild disk /dev entries above> [1]
reboot
<in single user>
cd /usr/src
cd gnu/usr.bin/texinfo/install-info
make install
cd ../../../..
ldconfig -R /usr/obj/usr/src/lib/libc
make installworld -DNOPERL [5]
mergemaster [4]
reboot
<multi-user>
[1] You may need to switch from wd to ad ala 19991210. In
addition, you should disable any third party modules such as
vmware so that you don't crash your system on reboot.
[2] If you have any of the following in your /etc/make.conf,
please comment them out before following these instructions
and then do a make buildworld + make installworld after you
are back to <multi-user> above:
MAKE_KERBEROS4
[3] Update to 4.x-stable sources. Make sure that you get all
the parts. If you are using cvsup files that are older than a
couple of months, be sure they have all the components listed
in /usr/share/examples/cvsup. Crypto and secure are now
required.
[4] This step is optional, but is generally a good idea. If
you wish to use many of the new features in 4.x, you must do
this anyway.
To update from 4.0-RELEASE or later to the most current
4.x-STABLE
----------
make buildworld
make buildkernel KERNCONF=YOUR_KERNEL_HERE
make installkernel KERNCONF=YOUR_KERNEL_HERE
reboot (in single user) [1]
make installworld
mergemaster
reboot
[1] You can often get away without doing this step as the
system will be properly updated. During the running of the
installworld, however, system components may break and other
oddities may happen. Don't do this on systems that aren't
otherwise quiet as unpredictable results may happen. If in
doubt, reboot into single user. For remote installs, keep
a separate kernel around and use a serial console if at all
possible.
Hope this helps,
Beech
-------------------------------------------------------------------
Beech Rintoul - IT Manager - Instructor - akbeech@anchoragerescue.org
/"\ ASCII Ribbon Campaign | Anchorage Gospel Rescue Mission
\ / - NO HTML/RTF in e-mail | P.O. Box 230510
X - NO Word docs in e-mail | Anchorage, AK 99523-0510
/ \ -----------------------------------------------------------------
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01042613522301.13770>