Date: Fri, 11 Oct 2002 11:08:22 -0700 From: Tim Kientzle <kientzle@acm.org> To: stable@FreeBSD.ORG, Jamie Heckford <jamie@jamiesdomain.org.uk> Subject: Re: Compiling a New Kernel Message-ID: <3DA71396.6070009@acm.org> References: <bulk.23103.20021011102232@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Bizarre.... how could it be different/not work if you have
> cvsup'd all of your sources including sys/ tree at exactly
> the same time, and compile your kernel just after the
> installworld?
I only recently figured out the reasons behind the recommended
sequence, so maybe I can now explain them to someone else.
Problem: You're currently running an old system, consisting
of old kernel, old world, and old configuration files.
You have source code for a new system and want to compile
and install it over the old system.
Issues:
* The old compiler might not be able to compile
the new kernel. (Compiler upgrades do happen.)
So, new kernel should be built with new compiler.
In particular, new compiler must be built before
new kernel is built.
* The new world might rely on new kernel features.
So, new kernel must be installed before new world
is installed.
These first two issues are the basis for the
core buildworld/buildkernel/installkernel/installworld
sequence that I'll describe in a moment.
* Old world might not run correctly on new kernel,
so installing new world must happen immediately
upon installing new kernel.
* Some configuration changes must be done before
new world is installed, but others might break
the old world. Hence, two different configuration
upgrade steps are needed.
Hence, the recommended sequence:
1) make buildworld
This first compiles the new compiler and
a few related tools, then uses the new compiler
to compile the rest of the new world. Result
ends up in /usr/obj
2) make buildkernel
Unlike the older config MYKERNEL/make sequence,
this uses the _new_ compiler residing in
/usr/obj. This protects you against compiler/kernel
mismatches.
2a) cp src/sys/${MACHINE_ARCH}/conf/GENERIC.hints /boot/device.hints
If transitioning from 4.x to CURRENT,
the kernel needs a new 'device.hints' file
on disk. Not needed if upgrading to 4.7.
3) make installkernel
Place the new kernel onto the disk,
along with related modules and a few
other tidbits.
4) Reboot to single user mode.
Single user mode minimizes problems from
updating software that's already running.
It also minimizes any problems from
running old world on a new kernel.
(Curiously, moving from 4.x to CURRENT,
you're still running the old kernel here,
because the new kernel is in a different
place and the boot loader hasn't been
updated yet.)
5) mergemaster -p
This does some initial configuration file updates
in preparation for the new world.
5a) rm -rf /usr/include/g++
If transitioning from 4.x to CURRENT,
the old C++ header files don't always
get correctly updated. Deleting the old
ones addresses this.
6) make installworld
Copies the world from /usr/obj
You now have a new kernel and new world on disk.
7) mergemaster
Now you can update the remaining configuration files,
since you have a new world on disk.
8) reboot
A full machine reboot is needed now
to load the new kernel and new world
with new configuration files.
Note that if you're upgrading from, say,
4.6.2 to 4.7, then this procedure may not
be absolutely necessary, since you're
unlikely to run into serious mismatches
between compiler/kernel/world/configuration.
But, when upgrading across major releases,
people who don't follow this procedure
should expect some problems.
Yes, this procedure has evolved over time
as the developers have found it impossible
to completely prevent certain kinds of
mismatch problems. Hopefully, the current
procedure will remain stable for a long time
(except for minor details such as steps
2a and 5a above, which may not be necessary
by the time 5.0 actually is done.)
Note that upgrading from 3.x or earlier
is a bit trickier; read UPDATING carefully.
Hope this helps,
Tim Kientzle
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DA71396.6070009>