From owner-freebsd-stable@FreeBSD.ORG Sun Nov 11 08:20:48 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A61916A494 for ; Sun, 11 Nov 2007 08:20:48 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id DB32613C48A for ; Sun, 11 Nov 2007 08:20:47 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: (qmail invoked by alias); 11 Nov 2007 08:19:50 -0000 Received: from nat-wh-1.rz.uni-karlsruhe.de (EHLO mobileKamikaze.norad) [129.13.72.169] by mail.gmx.net (mp018) with SMTP; 11 Nov 2007 09:19:50 +0100 X-Authenticated: #5465401 X-Provags-ID: V01U2FsdGVkX1+0v39LvWG0k2XPL9jkNzYCPtNy4PiQjGKye+EHZ2 ZVWI+ek03U1Woy Message-ID: <4736BB24.8010905@gmx.de> Date: Sun, 11 Nov 2007 09:19:48 +0100 From: "[LoN]Kamikaze" User-Agent: Thunderbird 2.0.0.6 (X11/20071101) MIME-Version: 1.0 To: Clint Olsen References: <20071102095628.GA796@0lsen.net> <472AF94B.1020600@gmx.de> <20071104200325.T91647@fledge.watson.org> <20071104211009.GC20861@0lsen.net> In-Reply-To: <20071104211009.GC20861@0lsen.net> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-stable@freebsd.org Subject: Re: Source upgrade from 5.5 to 6.X not safe? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2007 08:20:48 -0000 > In general, is it possible that the installkernel did /not/ complete > correctly before I shut down? Is it ever possible that the machine could > get put into an indeterminate state when doing installkernel on a running > machine? HP-UX used to behave horribly when a binary got clobbered for a > process that was running, but I have no idea how FreeBSD copes with > changing disk images of a running process. If a binary/library that is currently used gets removed/replaced, it will be copied to memory. The process will not even recognize this. Only restarting the process will remove the old version from memory and cause the new one to be used. I thought every OS did it like that, so I'm surprised that there are systems causing problems in this case. For the kernel likewise. The kernel and the loaded modules remain in memory, but of course you cannot load the newly built modules until you have rebooted with the new kernel (because there's no other way to restart a kernel).