Date: Thu, 22 Mar 2001 12:51:00 -0700 From: "Matt Simerson" <mpsimerson@hostpro.com> To: "'freebsd-hackers@freebsd.org'" <freebsd-hackers@freebsd.org> Cc: "'David O'Brien'" <obrien@freebsd.org> Subject: RE: 4.3-BETA world crashing 4.2-RELEASE kernel ? Message-ID: <8D18712B2604D411A6BB009027F6449801B4B542@0SEA01EXSRV1>
next in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: David O'Brien [mailto:obrien@freebsd.org] > Sent: Wednesday, March 21, 2001 8:41 PM > To: Matt Simerson > Cc: freebsd-hackers@freebsd.org > Subject: Re: 4.3-BETA world crashing 4.2-RELEASE kernel ? > > First let me say to anyone reading the email I am replying to: > > don't do this > > On Wed, Mar 21, 2001 at 12:58:04PM -0700, Matt Simerson wrote: > > # cd /usr/src > > # make buildkernel KERNEL=<KERNEL_CONFIG_FILE_NAME> > > # cd /usr/src; make buildworld > > # make installworld > > # make installkernel > > # mergemaster > > # reboot > > The order or "make buildworld" and "make buildkernel" are 100% totally > BACKWARDS. Actually, they aren't backwards. You've gone and snipped the parts of my original message that show that the commands are being executed at the same time. If either fails (for one reason or another as may happen) then I'll be able to plainly see why the build failed and correct it or go about fixing it manually. > Lets explain why: There are times when the kernel source is changed to > use constructs of newer compiler/assembler/linker tools. Thus the kernel > will not build with an older set of tools. The what "make buildkernel" > does is use the tools (ie, those built from the most up to date sources) > that are built during "make buildworld" to compile a new kernel. Thus > "make buildworld" must PROCEED "make buildkernel". Maybe I'm understanding you incorrectly here but according to what you just said, a "make buildkernel" will fail unless you have a set of compiler/assembler/linker tools in /usr/obj that were built from the make buildworld process. This is inaccurate at best and I suspect it's just plain wrong. I can "rm -r /usr/obj/*", "cd /usr/src; make clean", and then "make buildkernel KERNEL=<BLAH>" and it will succeed and build a happy little fully functionaly kernel. I've done this hundreds of times with success. So, I guess I'm not understanding your logic here. Would you care to explain further why this doesn't work? > Second, the install order above is not the conservative, careful > approach. One should issue "make installkernel && reboot" after the > "make buildkernel" to ensure the new kernel works > sufficiently well. Maybe that's _YOUR_ method for installing but it's not necessarily the best one. Kernel's are not guaranteed to be backwards compatible and I've installed a shiny new kernel that worked just fine and allowed my machine to come up single user but because of some rude change in /etc/rc, ipfw, or any of a number of places the machine couldn't make it to multi-user and allow me to get back in (via the network). When most of your servers are in a data-center 50 miles away and the rest are thousands of miles away, you'd rather not spend the next two hours talking a NOC monkey through a 10 minute process (if you have console). I prefer to do everything possible to make sure the system is going to boot correctly the first time and let me regain access. Success at building and installing the kernel, world, AND running mergemaster gives me a reasonably good chance that when I issue the reboot, it'll come up nice and happy. Second, if I'm going through the bother of compiling a buildworld it's because I want the latest version of world on my system. If there are some problems with the new kernel, I'm not going to revert back to world.old. I'll fix whatever is screwed up with kernel and proceed. Last, but not least, is that I don't have a warm body near all of my servers. I often want to do the make buildworld & kernel, installworld & kernel, and mergemaster and NOT reboot. Then I'll pop an email off to a warm body nearby and, at his leisure, have him give it a CTRL-ALT-DEL on the console and watch it to make sure it comes back up. > If not, one can always fall back to ``kernel.old''. One can fall back to kernel.old regardless. Even if I happen to have world.new installed, kernel.old will still work. There may be issues but if there is, they are surely no worse than running kernel.new with world.old. So, which is worse, the cart without a horse or a horse without a cart? > Since there is no > ``world.old''; after one does the "make installworld" backup tapes are > the only way of taking the system back to its previous state. I don't know many people who do buildworlds just for fun. If I'm doing a buildworld it's because I want the newer world installed. If I'm doing it on a server, it's because I've tested it on a dev box and I know it works the way I want. At that point, I have no reason to fall back to the previous world. Matt > -- > -- David (obrien@FreeBSD.org) > GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8D18712B2604D411A6BB009027F6449801B4B542>