Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 30 Apr 2002 10:17:55 -0700
From:      "Kevin Oberman" <oberman@es.net>
To:        Mike Meyer <mwm@mired.org>
Cc:        pjklist@ekahuna.com, stable@FreeBSD.ORG
Subject:   Re: Build sequence (was Re: mergemaster theory (was: Re: /etc/defaults/rc.conf theory) ) 
Message-ID:  <20020430171755.2CC015D04@ptavv.es.net>
In-Reply-To: Your message of "Tue, 30 Apr 2002 11:57:44 CDT." <15566.52488.880073.197196@guru.mired.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Tue, 30 Apr 2002 11:57:44 -0500
> From: Mike Meyer <mwm@mired.org>
> 
> In <20020430161355.14FEB5D05@ptavv.es.net>, Kevin Oberman <oberman@es.net> typed:
> > > From: "Philip J. Koenig" <pjklist@ekahuna.com>
> [SNIP]
> > > So I tried the 'accepted' sequence of installing the kernel before 
> > > the world yesterday.
> > > 
> > > One thing I have always done prior to running mergemaster is to set 
> > > the console to 132 columns to make it easier to view long lines and 
> > > to facilitate merging files.  
> > > 
> > > When I was running this new kernel (mismatched to the world) 
> > > vidcontrol was completely broken, none of its commands would work.
> > > (anything I typed got met with something along the lines of "must be 
> > > on virtual console, inappropriate ioctl for device".  This problem 
> > > went away after installing the world.)
> > > 
> > > So I couldn't do anything with the default screen settings.
> > > 
> > > I'd say it's a good example of the kinds of things that can break 
> > > when you do it that way.  So it appears each method has its pluses 
> > > and minuses. (Maybe the ideal would be to test the new kernel then 
> > > revert to the old to build the new system, but that would require a 
> > > 2nd reboot)
> > 
> > It is true that running a new kernel against an old userland may cause
> > several things not essential to installing world or running
> > mergemaster to fail. This is not always the case, but is always a
> > possibility that increases with the time since sources were previously
> > updated.
> 
> What's missed here is that running an old kernel and a new userland is
> more likely to screw things up. After all, the new kernel has to
> maintain backwards compatability with old binaries to some degree to
> keep old packages working, so you can expect most things to work
> properly. Doing it the other way means you may have userland utilites
> looking for kernel functionality that isn't there yet. Both are
> unlikely, but running the new kernel first not only tests it before
> doing something hard to back out, but is slightly safer.

I completely agree! As I said, doing an installworld before booting
the new kernel is an invitation to disaster. But booting the new
kernel and then going back to the old to installworld should be safe
and provide full system functionality when running mergemaster.

I actually liked the other suggestion for using the new vidcontrol (or
any other kernel linked program) for mergmaster after booting the new
kernel. It's safe and avoids a reboot. The required aliases can also
be put into a simple script to make it easier to use them.

R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@es.net			Phone: +1 510 486-8634


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020430171755.2CC015D04>