From owner-cvs-all Fri Jan 8 05:06:35 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA20503 for cvs-all-outgoing; Fri, 8 Jan 1999 05:06:35 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA20498; Fri, 8 Jan 1999 05:06:31 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.1/8.9.1) id OAA97088; Fri, 8 Jan 1999 14:05:36 +0100 (CET) (envelope-from des) To: Peter Wemm Cc: Julian Elischer , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 References: <199901080729.PAA40072@spinner.netplex.com.au> From: Dag-Erling Smorgrav Date: 08 Jan 1999 14:05:35 +0100 In-Reply-To: Peter Wemm's message of "Fri, 08 Jan 1999 15:29:03 +0800" Message-ID: Lines: 15 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk Peter Wemm writes: > As a concession to Julian, he does have a point. If we installed the new > kernel in (say) /boot/kernel (or /modules/kernel) where the bootloader will > find it but the old bootblocks will not, there is no chance that people > will blow their feet off by replacing /kernel with something that is > unbootable. In that scenario, the worst that can happen if they don't > upgrade bootblocks is that they will reboot and get their old kernel again. Then we'd have to fix the new boot blocks to look for the kernel in the right place, and everyone using the "new, but not new enough" boot blocks would be fucked. You call that a solution? DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message