From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 19:10:21 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 410DA16A420; Thu, 2 Feb 2006 19:10:21 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE1C543D46; Thu, 2 Feb 2006 19:10:20 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 02 Feb 2006 11:10:21 -0800 Message-ID: <43E2591C.6080501@elischer.org> Date: Thu, 02 Feb 2006 11:10:20 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <200602011341.k11Dfbq1008941@lurza.secnetix.de> <200602011240.11682.jhb@freebsd.org> <43E117F3.9090400@elischer.org> <200602021337.15761.jhb@freebsd.org> In-Reply-To: <200602021337.15761.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 02 Feb 2006 19:10:21 -0000 John Baldwin wrote: >On Wednesday 01 February 2006 15:20, 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. >> >> > >You are already presuming something of an FS as that is where you get your >loader and kernel from. (Well, you could get the kernel from somewhere else >perhaps, but not the loader unless you are using PXE or a CD to boot.) > > I'm not presuming anything about a particular slice, if I can specify another one..