[[ I'll reply to a few messages with one ]]

Allen Briggs <briggs@ninthwonder.com> wrote:
 
> > I really hate flag-day syndrome.
>
> I don't think this is a much of a flag day issue if implemented as:
> 
>         look for boot.
>         if file and loadable, use it
>         else
>                 if directory, change to directory
>                 look for boot_$machine

I just tried a different tack:

	if load("boot/pmax") fails
		if load("boot") fails
			die

I was lazy and didn't check if the libsa code could actually open and
read a directory, and we also end up using (what should be) a more
recent second stage boot if it exists.  When /boot is a file, I just get
a "open rz()boot/pmax: 20" error (20 is ENOTDIR), and then it happily
loads /boot.

> One big question is, I suppose, can this be squeezed into the
> first-stage bootblocks that don't store block numbers?

Currently the alpha bootblocks are compiled such that the libsa ufs.c
doesn't descend into directories.  Adding the directory descent stuff to
my test pmax code (based on the current alpha bootblocks) added another
176 bytes to the total size of the first stage bootblocks.  Adding the
check for "boot/pmax" then "boot" chewed another 64 bytes.  There's
still another 304 bytes left over.  Heaps :-)

> The only "flag day" part I can see is if you update the second-stage
> boot blocks, removing the old ones, without updating the first-stage.
> Possible, certainly (few things aren't ;-), but not too likely.

Agreed.


Robert Elz wrote:

>     From:        "Eduardo E. Horvath" <eeh@one-o.com>
> 
>   | OTOH, if this is
>   | ISO9660 fs it won't work anyway since it only groks bsdffs filesystems.
> 
> There's no reason you can't put a ufs/ffs/bsd (call it what you like)
> filesystem on a CD, I do it frequently.   This kind of technique ought to
> be useful on any media that might contain useful stuff for multiple
> architectures.  CDs are the obvious example, but there could be others.

Indeed - I don't know of any bootable CDs for the pmax that _aren't_ ufs
based.  Hopefully this will change very soon :-)

> It might not make a lot of sense to go to all this work for your standard
> root disc - that would mean an extra several blocks of i/o for every boot
> after all, ...

You mean the /boot/ directory stuff?  I think the world might be a
saner place if we try to standardise the boot sequence rather than
make exceptions based on filesystem type...

>   | Now, presuming we really go this way and have different names for each
>   | bootloader, how do we store a bootblock for each architecture on a single
>   | CDROM?

For the pmax at least, I'm looking at having installboot(8) taking an
optional offset for locating the first stage, which on a CD would either
be after the end of the ISO9660 partition (if such a concept exists) or
point to a contiguous file in the ISO9660 filesystem.  Note that I've
never played with ISO9660 filesystems so I'm still on a learning curve
here.

> CDs seems to not have anything one would call s atandard boot method - 
> certainly just reading the first blocks from the cd and executing them
> isn't common (though I think that's what alphas do, more or less).
> Joliet (x86 type boots) extract a pointer to a magic file which they
> expect to be a floppy image (most commonly).  Suns expect the CD to have
> a disklabel type label, then the boot for different architectures is
> selected by the partition ('a' is not used, and conventionally contains
> a 9660 format image, 'b' 'c' 'd' ... are the boot images for various
> different architectures).
> 
> Just being able to find a 2nd stage boot loader in a name which
> depends upon the architecture is not going to be enough to allow a CD
> to be made which will boot on every system type around, there will almost
> certainly be some architectures that manage to have boot styles from CD
> that conflict with others.   But it will certainly allow the number of
> CDs needed to be bootable on everything to become less than one per
> architecture.

I can't remember exactly on how many architectures Ross's 1.4 (or was it
1.4.1) CD booted from, but I'm pretty sure that at least sparc, alpha
and i386 were on the list.  It appears that it shouldn't be too hard to
add pmax to that list.

Simon.