From owner-freebsd-current Sun Sep 27 00:25:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA23828 for freebsd-current-outgoing; Sun, 27 Sep 1998 00:25:32 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA23809 for ; Sun, 27 Sep 1998 00:25:22 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.1/8.9.1/Spinner) with ESMTP id PAA11807; Sun, 27 Sep 1998 15:24:31 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199809270724.PAA11807@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: John Birrell cc: Studded@dal.net, current@FreeBSD.ORG Subject: Re: Upgrade documentation (Was: Re: Make world error on -current elf) In-reply-to: Your message of "Sun, 27 Sep 1998 07:52:39 +1000." <199809262152.HAA21507@cimlogic.com.au> Date: Sun, 27 Sep 1998 15:24:30 +0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Birrell wrote: > Peter Wemm wrote: > > I am still not quite comfortable with the 3.0-CURRENT -> elf conversion > > process. > > > > The instructions there and the Makefile.upgrade rules push towards an > > unneded recompile and reboot of a kernel in order to complete the process. > > > > Any 3.0-CURRENT kernel from about July 1997 (over a year old) will run an > > ELF world quite happily. IMHO, defaulting to unecessarily replacing the > > user's customized kernel with a generic one is bad karma. > > I doubt that you've tested that. Sure, it may be able to load elf format > executables, but there have been so many other changes that affect > compatibility between user-land and the kernel. My approach to this sort > of thing is: "if it's not tested, then it doesn't work". The upgrade > procedure is for the 95% of people who need a procedure that "just works". > Of the other 5%, most are prepared to install a current kernel prior to > doing the upgrade. Well, actually I have tested it, and it does work. I did clean up my old kernels a few weeks ago so I don't have any Really Old kernels anymore. Remember, this system has been running ELF since mid last year. I know the old kernels don't have any real trouble because I keep a pile of them for testing with the SMP code. A kernel from Jan 26 this year (9 months old). (It happens even be an ELF kernel image rather than a.out, but that doesn't matter in this case. My system has had bootblocks that load ELF and a.out). pwroot@beast[2:53pm]~-100# uname -a FreeBSD beast.netplex.com.au 3.0-CURRENT FreeBSD 3.0-CURRENT #101: Mon Jan 26 22:22:39 WST 1998 peter@beast.netplex.com.au:/home/src/sys/compile/BEAST i386 pwroot@beast[2:53pm]~-102# l /kernel.sane2 1248 -r-xr-xr-x 1 root wheel 1264063 Jan 26 1998 /kernel.sane2* pwroot@beast[2:54pm]~-103# sysctl kern.bootfile kern.bootfile: /kernel.sane2 pwroot@beast[2:56pm]~-104# file /kernel.sane2 /kernel.sane2: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, not stripped The world is a couple of days old. It works fine. I happen to have this kernel because (from memory) it's the last one prior to John's set of major VM changes late January. Incidently, I had to back out the /dev/sd0a <-> /dev/sd0s1a mount device changes for / in /etc/fstab. I'm not sure how this works.. Will a 3.x system deal with an old-style 'sd0a' or 'wd0a' line in /etc/fstab? > Changing the kernel compatibility test would introduce the possibility > that things might not work correctly when the user reboots. This is a > serious issue because it can hose people. I don't want to have to deal > with the support problems that would cause. As it stands, a lot of > people have used the current procedure to upgrade, even in the midst of > major changes to current. I suspect this is because the people doing it at the time were running right up to the edge and there weren't many people that fell afoul of the 3.0-CURRENT <-> 3.0-BETA changes. I don't object to telling people to rebuild their kernel, but using 'GENERICupgrade' automatically and rebooting immediately after the 'make install' of that kernel is wrong. The online instructions in the makefile should say clearly: - the process is finished and all that is left is a kernel rebuild and reboot. (So it's clear nothing is being lost from the conversion process if Ctrl-C) - systems <= 2.2 may not be able to run the current ELF system binaries to do a reboot, so it's probably a good idea to let the rebuild/reboot continue. - that if you're running a reasonably current kernel you probably don't need a new kernel, but it's still a good idea to do it. Pressing ctrl-C and rebuilding it yourself and doing a reboot is best. - The kernel config files need to be updated for 3.0, they can't just do a config/make/make install, so be careful. At the moment it decides "It's got to be done, if you don't it's on your own neck". For 3.0-current, this isn't correct, and it doesn't give info about what the risks or problems are. We don't force the user to upgrade their kernel at the end of a 'make world'. For a 3.0-CURRENT system, a 'make aout-to-elf' is just a glorified 'make world'. The fact that the system binary format changes is irrelevant because 3.0-CURRENT can run both binaries already. I wouldn't mind seeing a seperate 'kernel installed, press return to reboot' after the install process. I'm sorry to keep griping about this, but it does bother me. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message