Date: Thu, 22 Mar 2001 12:55:02 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Matt Simerson <mpsimerson@hostpro.com> Cc: "David O'Brien" <obrien@FreeBSD.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@FreeBSD.org> Subject: RE: 4.3-BETA world crashing 4.2-RELEASE kernel ? Message-ID: <XFMail.010322125502.jhb@FreeBSD.org> In-Reply-To: <8D18712B2604D411A6BB009027F6449801B4B542@0SEA01EXSRV1>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22-Mar-01 Matt Simerson wrote: >> 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? Hmm, maybe because you've been lucky to have done it wrong? Case in point: for 4.1 release, we upgraded to a new set of binutils (assembler, linker, etc.). Because the old asssembler was so broken, the new assembler could not compile the old code that had hacks in it to work around the bugs in the old assembler. Thus, if you tried to build a kernel without building world with the new assembler, the compile would fail. Thus, one needs to do the buildworld first to ensure the tools to compile the kernel are up to date. Please go read the archives if you want more of the hairy details. The process David described (which is the one that is in src/UPDATING) is the one that is supported. Other methods may work some of the time, but they won't work all of the time, and if it breaks for you it is your fault for not following the rather clear instructions that have been provided. :) >> 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 Breakges of this time or very rare, and only in -current that I can remember. In fact, the only bad ones I've seen are when struct ucred changes causing mountd to start doing stupid things, but that has been permamently fixed in -current. However, as other people have pointed out, it is much easier to boot kernel.old if your new kernel is hosed and use that stable kernel to fix either the new kernel or the new world as appropriate. Really, if you wish to blow your own foot off that is fine, but do be aware that a) you shouldn't tell others to blow their feet off, and b) if you blow your own feet off it's your fault. :) In fact, if you are careful, you will note that src/UPDATING recommends that you do the installworld and /etc update in single user mode, not multiuser, which would avoid the problems you have seen with new kernels and old worlds. >> 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. You don't run -current much it seems. :) (Not that I blame you, it is not for production machines.) The procedure described is the most robust one that has been come up with thus far. It has the greatest chance of success, though it is also somewhat painful (installworld in single user for example). You can do it differently if you wish (I do), but realize that if you do, you are on your own. -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.010322125502.jhb>