From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 19:44:20 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 50FAC16A423 for ; Thu, 2 Feb 2006 19:44:20 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 945B943D68 for ; Thu, 2 Feb 2006 19:44:15 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 7582684 for multiple; Thu, 02 Feb 2006 14:44:43 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k12Ji2PY003692; Thu, 2 Feb 2006 14:44:03 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Julian Elischer Date: Thu, 2 Feb 2006 14:44:55 -0500 User-Agent: KMail/1.9.1 References: <200602011341.k11Dfbq1008941@lurza.secnetix.de> <200602021337.15761.jhb@freebsd.org> <43E2591C.6080501@elischer.org> In-Reply-To: <43E2591C.6080501@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602021444.57395.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1270/Thu Feb 2 07:47:37 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 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:44:20 -0000 On Thursday 02 February 2006 14:10, Julian Elischer wrote: > 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.. The current nextboot stuff in the loader requires that /boot/loader is running (duh) and you have to have a place to get /boot/loader from. The same place you get /boot/loader from is the same place you are going to get /boot/nextboot.conf from (due to the way loader works). Thus, if you do it in loader(8) at all, you are assuming some minimal functionality about teh FS /boot/loader resides in, so requiring the same minimum for /boot/nextboot.conf is not really a stretch. The one exception to this is if you PXE boot and are using NFS to download the kernel then it will fetch nextboot.conf over NFS rather than using the tftp the BIOS used to download pxeboot (/boot/loader). -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org