Date: Tue, 30 Apr 2002 09:13:55 -0700 From: "Kevin Oberman" <oberman@es.net> To: pjklist@ekahuna.com Cc: stable@FreeBSD.ORG Subject: Re: Build sequence (was Re: mergemaster theory (was: Re: /etc/defaults/rc.conf theory) ) Message-ID: <20020430161355.14FEB5D05@ptavv.es.net> In-Reply-To: Your message of "Sun, 28 Apr 2002 01:42:58 PDT." <20020428084259266.AAA791@empty1.ekahuna.com@pc02.ekahuna.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020430161355.14FEB5D05>