From owner-freebsd-hackers  Wed Jul  3 19:42:53 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id TAA19318
          for hackers-outgoing; Wed, 3 Jul 1996 19:42:53 -0700 (PDT)
Received: from sierra.zyzzyva.com (ppp0.zyzzyva.com [198.183.2.50])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA19293
          for <hackers@freebsd.org>; Wed, 3 Jul 1996 19:42:47 -0700 (PDT)
Received: from zyzzyva.com (localhost [127.0.0.1]) by sierra.zyzzyva.com (8.7.5/8.6.11) with ESMTP id VAA25101; Wed, 3 Jul 1996 21:42:35 -0500 (CDT)
Message-Id: <199607040242.VAA25101@sierra.zyzzyva.com>
To: Julian Elischer <julian@ref.tfs.com>
cc: hackers@freebsd.org
Subject: Re: New (BIOS) bootblock ?feature? 
In-reply-to: julian's message of Wed, 03 Jul 1996 14:14:03 -0700.
         <199607032114.OAA01694@ref.tfs.com> 
X-uri: http://www.zyzzyva.com/
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 03 Jul 1996 21:42:35 -0500
From: Randy Terbush <randy@zyzzyva.com>
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


Sounds like these would be very useful additions.


> 
> do we want to integrate this?
> Since I originally ported the bootblocks to freeBSD, I haven't done much
> with them.. This is my first real  return to the area..
> 
> I have been askled to make the following patches to the bootblocks,
> together with a user-level program to control it......
> 
> The patches are now complete and working, so I want to know if the gang
> thinks I should integrate them to our sources or whether my client should
> just keep them separate..
> 
> Programmable one-time  bootstring.. (or many time)
> 
> block 2 (usually untouched if you are using an fdisk block and have not used
> the first cylinder (as DOS does) is examined for a magic number, 
> and if it matches, is examined for the default bootstring
> e.g. 2:sd(1,d)/kernel.goofy
> 
> if the "WRITEBACK" option is used, then this string is zero'd out
> of block 2 after being read, meaning that should this boot fail,
> it will not be tried again the same.
> 
> the second block can contain as many strings (zero separated, each with
> a 2 byte magic header ('D','N' ) as can be fit in, with a '0xff'
> indicating the end of the strings.
> 
> thus:
> 
> nextboot -f /dev/rwd0 kernel kernel kernel kernel.bak \
> 	wd(0,d)/kernel wd(0,d)/kernel \
> 	wd(0,d)/kernel.bak wd(1,a)/kernel 
> 
> will try successively each of those kernels  on each successive boot.
> note: they are NOT tried successively if they do not exist within the
> same boot..
> if a kernel does not exist, then after one attempt,
> the bootblock will revert to /kernel, as it does now.
> 
> if the WRITEBACK feature is not enabled, then the first entry is used
> only, as the system doesn't know it has already used it.
> 
> reason for existance..:
> 
> 
> 1/ remote booting an experimental kernel..
> 2/ upgrading to a different (newer) root partition, but with a fallback
> if the install was bad.
> 3/ place a dummy bsd part on wd0 and redirect the default boot to sd2
> where the real bsd part is?
> 
> The theory is that the rc script writes the new block back again if and only
> if the boot succeeded.. if it didn't then the rc will not have been able to
> touch it, and the next string will be used when the system reboots.
> 
> anyway, the install program will not normally install on a block that doesn't
> have the magic number already, and will require a special flag
> to pre-place the magic number on block 2. It will (possibly)
> examing block 1 to ensure that there are no fdisk partitions using block 2.
> 
> thoughts?
> 
> julian