Date: Wed, 3 Jul 1996 14:14:03 -0700 (PDT) From: Julian Elischer <julian@ref.tfs.com> To: hackers@freebsd.org Subject: New (BIOS) bootblock ?feature? Message-ID: <199607032114.OAA01694@ref.tfs.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607032114.OAA01694>