> -----Original Message-----
> From: David O'Brien [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 21, 2001 8:41 PM
> To: Matt Simerson
> Cc: [EMAIL PROTECTED]
> Subject: Re: 4.3-BETA world crashing 4.2-RELEASE kernel ?
>
> First let me say to anyone reading the email I am replying to:
>
> don't do this
>
> On Wed, Mar 21, 2001 at 12:58:04PM -0700, Matt Simerson wrote:
> > # cd /usr/src
> > # make buildkernel KERNEL=<KERNEL_CONFIG_FILE_NAME>
> > # cd /usr/src; make buildworld
> > # make installworld
> > # make installkernel
> > # mergemaster
> > # reboot
>
> The order or "make buildworld" and "make buildkernel" are 100% totally
> BACKWARDS.
Actually, they aren't backwards. You've gone and snipped the parts of my
original message that show that the commands are being executed at the same
time. If either fails (for one reason or another as may happen) then I'll be
able to plainly see why the build failed and correct it or go about fixing
it manually.
> Lets explain why: There are times when the kernel source is changed to
> use constructs of newer compiler/assembler/linker tools. Thus the kernel
> will not build with an older set of tools. The what "make buildkernel"
> does is use the tools (ie, those built from the most up to date sources)
> that are built during "make buildworld" to compile a new kernel. Thus
> "make buildworld" must PROCEED "make buildkernel".
Maybe I'm understanding you incorrectly here but according to what you just
said, a "make buildkernel" will fail unless you have a set of
compiler/assembler/linker tools in /usr/obj that were built from the make
buildworld process. This is inaccurate at best and I suspect it's just plain
wrong. I can "rm -r /usr/obj/*", "cd /usr/src; make clean", and then "make
buildkernel KERNEL=<BLAH>" and it will succeed and build a happy little
fully functionaly kernel. I've done this hundreds of times with success.
So, I guess I'm not understanding your logic here. Would you care to explain
further why this doesn't work?
> Second, the install order above is not the conservative, careful
> approach. One should issue "make installkernel && reboot" after the
> "make buildkernel" to ensure the new kernel works
> sufficiently well.
Maybe that's _YOUR_ method for installing but it's not necessarily the best
one. Kernel's are not guaranteed to be backwards compatible and I've
installed a shiny new kernel that worked just fine and allowed my machine to
come up single user but because of some rude change in /etc/rc, ipfw, or any
of a number of places the machine couldn't make it to multi-user and allow
me to get back in (via the network). When most of your servers are in a
data-center 50 miles away and the rest are thousands of miles away, you'd
rather not spend the next two hours talking a NOC monkey through a 10 minute
process (if you have console). I prefer to do everything possible to make
sure the system is going to boot correctly the first time and let me regain
access. Success at building and installing the kernel, world, AND running
mergemaster gives me a reasonably good chance that when I issue the reboot,
it'll come up nice and happy.
Second, if I'm going through the bother of compiling a buildworld it's
because I want the latest version of world on my system. If there are some
problems with the new kernel, I'm not going to revert back to world.old.
I'll fix whatever is screwed up with kernel and proceed.
Last, but not least, is that I don't have a warm body near all of my
servers. I often want to do the make buildworld & kernel, installworld &
kernel, and mergemaster and NOT reboot. Then I'll pop an email off to a warm
body nearby and, at his leisure, have him give it a CTRL-ALT-DEL on the
console and watch it to make sure it comes back up.
> If not, one can always fall back to ``kernel.old''.
One can fall back to kernel.old regardless. Even if I happen to have
world.new installed, kernel.old will still work. There may be issues but if
there is, they are surely no worse than running kernel.new with world.old.
So, which is worse, the cart without a horse or a horse without a cart?
> Since there is no
> ``world.old''; after one does the "make installworld" backup tapes are
> the only way of taking the system back to its previous state.
I don't know many people who do buildworlds just for fun. If I'm doing a
buildworld it's because I want the newer world installed. If I'm doing it on
a server, it's because I've tested it on a dev box and I know it works the
way I want. At that point, I have no reason to fall back to the previous
world.
Matt
> --
> -- David ([EMAIL PROTECTED])
> GNU is Not Unix / Linux Is Not UniX
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
