Skip site navigation (1)Skip section navigation (2)
Date:      30 Apr 2002 11:12:36 -0600
From:      John-David Childs <freebsd@nterprise.net>
To:        stable@freebsd.org
Subject:   Re: Build sequence (was Re: mergemaster theory (was: Re: /etc/defaults/rc.conf theory) )
Message-ID:  <1020186756.11357.76.camel@lohr.digitalglobe.com>
In-Reply-To: <20020430161355.14FEB5D05@ptavv.es.net>
References:  <20020430161355.14FEB5D05@ptavv.es.net>

next in thread | previous in thread | raw e-mail | index | archive | help
FWIW: I've been doing compilation builds (i.e. STABLE) since 2.X days
(actually did a source upgrade from 2.X-3.X a few years back but that
was painful enough that I refused to do it for 3.x-4.x ;-)  and my
process has been:

cvsup
read /usr/src/README
read /usr/src/UPDATING
buildworld
cp /usr/src/sys/i386/conf/LINT /usr/src/sys/i386/conf/LINT.<DATE>
diff .../LINT ../LINT.<previous cvsup run>
edit /usr/src/sys/i386/conf/<KERNEL> with any new desired LINT options 

(yes, I start with LINT and remove rather than starting with GENERIC and
adding, YMMV).  Takes a lot longer, teaches a little more about kernel
hacking if you RTFSC, but isn't for everyone and fails a lot more often
than doing it the other way around ;-)

buildkernel KERNCONF=<KERNEL>
installkernel KERNCONF=<KERNEL>

installworld
mergemaster (mostly for MAKEDEV and passwd/group mods)
reboot (single user, if desired, but extremely rare)
mergemaster (if desired,necessary because I didn't allow something
	the first time)
reboot (only if I ran mergmaster again)

Yes, I'm a bad toad and I usually do/did installworld right after
installkernel, in multi-user mode.  I do this while running script, so I
can find any files which might not have been installed (due to chflags,
etc).  My assumption has always been that the old/existing binary is
loaded in memory (either real or swap), and thus changing the on-disk
binary out from underneath it is safe for all programs which don't run
from disk periodically. All customer daemons (sendmail, pop, imap,
named, httpd, radius, etc) on my boxes are custom built (in /usr/local)
and thus unaffected. 

By doing things this way, I can usually keep downtime on any one box to 
under 5 minutes/upgrade.  This is perhaps not the "right" way to do
things, but it's the way I've been doing it for at least seven years and
old habits are hard to break...especially in the case(s) where you have
to do these upgrades remotely w/o a serial console <yeah, tell me about
it>

On Tue, 2002-04-30 at 10:13, Kevin Oberman wrote:
> > From: "Philip J. Koenig" <pjklist@ekahuna.com>
> > Date: Sun, 28 Apr 2002 01:42:58 -0700
> > 
> > On 24 Apr 2002, at 13:49, I wrote: 
> > 
> > > On 24 Apr 2002, at 11:23, Kevin Oberman boldly uttered: 
> > > 
> > > > > > On Tue, 23 Apr 2002, Philip J. Koenig wrote:
> > > 
> > > > > My usual sequence is:
> > > > > 
> > > > > [multi-user]
> > > > > - cvsup
> > > > > - buildworld
> > > > > - buildkernel
> > > > > 
> > > > > [restart into single-user, since shutting down to single-user can
> > > > > cause problems with ie kern securelevel]
> > > > > - mount filesystems, swap, run adjkerntz -i
> > > > > - installkernel
> > > > > - installworld
> > > > > - mergemaster
> > > > > - final cleanup/backup
> > > > > - reboot
> > > > > 
> > > > > Reason being I've always read/been told that this is standard 
> > > > > practice because changing system files while in multi-user mode can 
> > > > > cause various problems.  I always thought mergemaster had to come 
> > > > > after the install step.
> > > > 
> > > > This is NOT standard practice. You need to do the installkernel before the
> > > > reboot. Either do this immediately after the buildkernel or just
> > > > make kernel which is the same as "make buildkernel installkernel".
> > > > 
> > > > If you reboot before installing hte kernel, you are NOT confirming that
> > > > the new kernel will run.
> > > > cvsup
> > > > buildworld
> > > > buildkernel
> > > > installkernel
> > > > reboot new kernel
> > > > mount -a -t ufs
> > > > installworld
> > > > mergemaster
> > > > reboot or exit
> > > 
> > > You are correct - I diverge from the usual recommendation in that I 
> > > usually install the kernel with the world.  In the past I actually 
> > > found that worked better for me, although in the future I may re-
> > > evaluate that.
> > 
> > 
> > 
> > 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.
> 
> Certainly your suggestion of checking the new kernel first and then
> reverting to kernel.old to run mergemester and and installworld seems
> reasonable, of a bit more time consuming.
> 
> 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




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?1020186756.11357.76.camel>