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.

Depends on how you're building. This suggestion dates from the time when
folks usually built to root; the equivalent of "build.sh -D /" nowadays.

Actually, I'm wrong. build.sh -D / isn't the same as what we used to do.
build.sh builds tools, which we didn't used to do. So it's actually much
cleaner than before.

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

For most sub-systems, it's true. We do a lot of work at versioning to make
it so. Some systems though aren't backwards-compatabile. ipf (that we have
in tree) & friends have been one main standout. But there have been other
places where folks have messed up. Or decided that just changing is a
better way to go.

> > 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.

??

> > 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 how did it fail?

> 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.
>
> 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
				Not needed
>  (8) etcupdate
>  (9) reboot
				I usually skip this one
>
> 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 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=/

I just make a release & install from there. etcupdate -b is my friend. :-)

Take care,

Bill