From owner-freebsd-hackers  Wed Jul  3 14:14:29 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id OAA25955
          for hackers-outgoing; Wed, 3 Jul 1996 14:14:29 -0700 (PDT)
Received: from ref.tfs.com ([206.245.251.1])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA25945
          for <hackers@freebsd.org>; Wed, 3 Jul 1996 14:14:25 -0700 (PDT)
Received: (from julian@localhost) by ref.tfs.com (8.7.5/8.7.3) id OAA01694 for hackers@freebsd.org; Wed, 3 Jul 1996 14:14:03 -0700 (PDT)
Date: Wed, 3 Jul 1996 14:14:03 -0700 (PDT)
From: Julian Elischer <julian@ref.tfs.com>
Message-Id: <199607032114.OAA01694@ref.tfs.com>
To: hackers@freebsd.org
Subject: New (BIOS) bootblock ?feature?
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


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