On Thu, 19 Jun 2003, William Allen Simpson wrote:

> Johnny Billquist wrote:
> > 
> > You have some other problem than your new kernel (obviously).
> > 
> > Building and installing a new kernel before building userland is highly
> > recommended. 
> 
> Why?  I've asked for a reason.  This appears to be a myth.  There's 
> certainly good reasons *NOT* to do so.

Okay. In all instances where I wrote "building userland", substitute
"installing userland". Those two steps have been done with one operation
for a long time, so that I usually don't bother separating them apart.

Nowadays, people are starting to separate them more, so I guess I should
be more careful with what I write.

As for compiling, it don't matter which kernel you are using. So any
problems you have is hardly because you had a new kernel either. Or are
you claiming that gcc failed because you had a new kernel???

So, what is your good reason not to install a new kernel before building
the new userland???

> >              If you build to some other destination than root, you can
> > build it all at once, but never install the new userland in the runnable
> > location unless you are running the new kernel. That's the big no-no.
> > 
> Everyone agrees.

Yes. And building without installing is never a problem, no matter in
which direction you shoot. So, if you are hung-up only explicitly the
compilation, then the answer is that it don't matter what kernel you are
running when you do a compile. That goes both for new and old kernels.

> > New kernels should always be able to run old executables, 
> 
> We've learned from Bellovin that isn't true today (except vax).

Hmm. When isn't it? I must have missed Bellovin's mail on that.
Oh, and I play with NetBSD on VAX, Alpha, i386 (and some pmax).

> > unless you
> > explicitly configure them not to, or we are talking about some odd
> > exceptions with programs that actually play with kernel datastructures.
> > 
> Apparently, the odd exception is increasingly common.

I haven't seen that it is. Maybe I missed that conclusion. Can you run it
by me again?

> > You obviously managed to boot the new kernel, log in, and start working
> > there. Then it broke somewhere along the way of building the new userland.
> > You should start by checking exactly what happened before jumping to any
> > conclusions...
> > 
> I've only found one clue: the old kernel (June 11) was 1.6T, the new 
> kernel (June 16) was 1.6U.  I hadn't noticed the change before.

So some new significant changes have been done to the kernel. Old binaries
should run just fine. Possible exceptions are programs that use libkvm. No
program in the build process are using that library, that I know of.

> Postmortem on the machine shows everything in the logs looks normal.  
> The build.sh ran to completion, so it wasn't a hardware problem.
> Rebooting the old kernel solved the problem.

What had happened to the machine? You said it still responded to
pings? Could you log in on the console? If build.sh ran to completion the
machine must have been running along just fine. Unless I misunderstood
something, you could no longer run ssh to connect to the machine. If
everything else was working fine then we should be a bit more interested
in what went wrong around ssh, and stop just blaming the kernel.

What happen if you boot the new kernel?

> I conclude that the documentation should be changed to: 
>  (1) build tools
>  (2) build kernel
>  (3) build userland
>  (4) install kernel
>  (5) reboot
>  (6) install userland
>  (7) reboot
>  (8) etcupdate
>  (9) reboot
> 
> And it would be nice to figure out some clever way to install both 
> kernel and userland at the same time, eliminating the window where a 
> new kernel might be incompatible with old userland.

And why, tell me, should building userland matter if it were done before
or after the reboot? We're talking about you running gcc here. It don't
care very much which kernel you are running...

I can't see how your claim of culpability can be true no matter how I try.
Can someone else explain, either to me what I'm missing, or to William
that he really is barking up the wrong tree.

> And it would be REALLY handy to document how to use etcupdate to prepare 
> a copy of the etc changes, and install them during build.sh install=/

Documentation is always good.

	Johnny

Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt@update.uu.se           ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol