If memory serves me right, Jeff Love wrote: > >Of course, if you installed the new system before building the new > >kernel, you would not have hit this problem, but you are living > >dangerously when you install the new world and try to run with the old > >kernel. > > > That is exactly how I've been doing it for years. 'cd /usr/src', 'make > buildworld', 'make installworld', 'cd sys/i386/conf', 'rm -rf > ../../compile/mykernel', 'config mykernel', 'cd ../../compile/mykernel', > 'make depend', 'make', 'make install', do manual merge, reboot. > > This has never failed, except when I've used mergemaster, which can make > a mess of things easily. > How would this method differ from using 'make buildkernel > KERNCONF=/usr/src/sys/i386/conf/mykernel' and 'make installkernel > KERNCONF=/usr/src/sys/i386/conf/mykernel' ? Both methods install the new > kernel on a running machine.
"make buildkernel" uses the compiler toolchain that was compiled by a previous "make buildworld". "config / make depend / make" uses the the toolchain that is currently installed on the running system. If you're updating across certain types of changes to the toolchain, you need to use the buildkernel target. You'll probably ask, "Why can't I do buildworld / installworld / config?" In a lot of instances you can, *except* when the userland depends on features of the new kernel. People get bit there too. As has been pointed out ad nauseum on this list, in many cases you can get away various short-cuts. But if you run into problems, the first thing that a lot of people (including myself) will say is "go follow the instructions in src/UPDATING". These instructions were written by people who understand all the bizarre edge cases that can happen during upgrading. Bruce.
msg50104/pgp00000.pgp
Description: PGP signature
