Re: r228700 can't dhclient em0

On Tue, Dec 20, 2011 at 11:15:20PM +0400, Gleb Smirnoff wrote:
>   Doug,
> 
> On Tue, Dec 20, 2011 at 12:38:53AM -0800, Doug Barton wrote:
> D> > I saw this too, when my kernel and userland were out of sync (e.g. just
> D> > after installing a new kernel, and before installworld).  I suspect it
> D> > is caused by the changes in r228571, which cause old ifconfig and
> D> > dhclient to not recognize any interfaces.  I'm not 100% sure though...
> D> 
> D> I tried replacing both ifconfig and dhclient with the versions that were
> D> built along with the new kernel, and that didn't work.
> 
> This shouldn't happen. If you did 'make buildworld buildkernel', then
> your world in objdir would have binaries compiled with includes from
> source tree, not from /usr/include, thus compatible with new kernel.
> 
> 'make buildworld buildkernel' always produces compatible kernel and
> worlds.
> 
> However, if you did 'cd /usr/src/sbin/ifconfig && make all install' then
> that didn't work, since used headers from /usr/include.
> 
> D> The traditional (and documented) upgrade process for many years has been
> D> to boot the new kernel, make sure it's Ok, then update world. Obviously
> D> something different is needed this time, so it needs an UPDATING entry
> D> (assuming that all this is not just a bug).
> 
> The documented one says 'Reboot into single user mode' and then install
> new world. This path was not broken, since single user mode doesn't
> imply network support.

While this is the documented path, it's not actually been required
except in edge cases for ages (the last I can remember is a.out->elf).
It's been long enough that I don't think we can really make people do
it except for a short period of time in HEAD.  I believe it's
unacceptable for a release to release upgrade.

> The undocumented brave way 'make installkernel installworld && reboot'
> works also, without any problems.

At least until someone screws up something else and you now can't use
kernel.old either.  This is somewhat ok for HEAD users, but I think we
should try harder to avoid this sort of situation.

-- Brooks