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>