From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 22:04:54 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAA0F16A420; Wed, 1 Feb 2006 22:04:54 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DB1543D5F; Wed, 1 Feb 2006 22:04:42 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k11M4bKL035456; Wed, 1 Feb 2006 15:04:37 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43E1307D.9030907@samsco.org> Date: Wed, 01 Feb 2006 15:04:45 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <200602011341.k11Dfbq1008941@lurza.secnetix.de> <200602011240.11682.jhb@freebsd.org> <43E117F3.9090400@elischer.org> In-Reply-To: <43E117F3.9090400@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org, Oliver Fromme Subject: Re: nextboot (was Re: boot block differences between 4.x and 6.x ?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2006 22:04:55 -0000 Julian Elischer wrote: > John Baldwin wrote: > >> On Wednesday 01 February 2006 08:41, Oliver Fromme wrote: >> >> >>> Julian Elischer wrote: >>> > Oliver Fromme wrote: >>> > > [...] >>> > > I think the most visible changes in the boot blocks was >>> > > UFS2 support and the removal of nextboot(8) support. >>> > >>> > which I hope to put back because we continue to need it. >>> >>> I agree that it's needed. It's a very useful feature. >>> >>> > (The new nextboot being dependent on the root filesystem still >>> being ok >>> > which is unacceptable to most embedded devices I've worked on, and why >>> > we still use the old bootblocks on all systems shipped.). >>> >>> >>>> From my point of view, the biggest problem with the old >>> >>> >>> nextboot was the fact that it ignored loader(8) and tried >>> to load the kernel directly. While that might work under >>> certain conditions, it's not good in general. >>> >>> Therefore I think that a new nextboot implementation >>> should be implemented in loader itself. Since loader(8) >>> doesn't (and shouldn't) support writing to UFS2, the >>> state information should be written to an unused area in >>> block 2 on the disk, or something similar. In fact, one >>> byte is sufficient: It can be used as an index into a >>> table (ASCII text file), e.g. /boot/nextboot.conf. >>> >>> Would that be feasible to implement? >>> >> >> >> /boot/loader already does nextboot and does it by using UFS writing >> (which it does implement and use on archs whose disk drivers support >> writing such as i386) to overwrite (but not extend) /boot/nextboot.conf. >> >> > > which is exactly the feature that I wanted to avoid with the original > nextboot(8). > Do NOT get any where-to-boot-from info from the possibly suspect > filesystem. > Do NOT write back to the "possibly-suspect-filesystem". > > The original nextboot was BIOS specific and not portable which is why > the new one > has some good points (portable), but it didn't rely on correctness of the > bootblock FS code or an intact first FS. > It doesn't allocate new blocks or alter metadata. It only modifies existing data blocks. It is no more unsafe than mounting an unclean filesystem while bgfsck is running, and actually is a whole lot more safe than that. Scott