Date: Tue, 30 Apr 2002 11:57:44 -0500 From: Mike Meyer <mwm-dated-1020617865.1c7350@mired.org> To: "Kevin Oberman" <oberman@es.net> Cc: pjklist@ekahuna.com, stable@FreeBSD.ORG Subject: Re: Build sequence (was Re: mergemaster theory (was: Re: /etc/defaults/rc.conf theory) ) Message-ID: <15566.52488.880073.197196@guru.mired.org> In-Reply-To: <20020430161355.14FEB5D05@ptavv.es.net> References: <20020428084259266.AAA791@empty1.ekahuna.com@pc02.ekahuna.com> <20020430161355.14FEB5D05@ptavv.es.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. 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?15566.52488.880073.197196>