> From: Philip Tait <Philip.Tait@phxase.allied.com>
>
> Mauricio Tavares wrote:
>
> > At 08:34 AM 9/17/99 -0700, Philip Tait  wrote:
> > >So are you saying that if I gunzip diskimage.gz, and burn it onto a CD-R
> > >(somehow), it should be bootable if loaded in (say) an RRD42?
> > >
> >         But, if that is the case, wouldn't we still need a CD burning software (I
> > am thinking here people would be using PCs and Macs to burn the CDs, since
> > those platforms are more commonly found) that can burn a CD in the proper
> > (High Sierra?  ISO 9660 with what extensions?) format?
>
> Actually, that does not seem to be a problem - see
> http://www.netbsd.org/Sites/cdroms.html#bob_nestor
>
> Bob says he is willing to burn bootable NetBSD/pmax CDs, if the NetBSD/pmax
> community will tell him how to produce the image.  I think it would be a step
> forward for NetBSD/pmax, and that we should take him up on the offer.  All we need
> is for one of the gurus to tell us how to make the CD diskimage.

To do this right will require a rethink of pmax/stand and other boot issues.
Both alpha and pmax boot the same way (block # and len in sector 0) but
alpha has this huge array of bootblocks and boot programs, whereas pmax
has remarkably minimal boot code and no boot installers at all.  (The boot
block sector 0 is just hard-coded into a boot program .S file and the MI
sbin/disklabel installs it, without even a single pmax #ifdef.)

The pmax approach is impressive in its austerity, and it certainly conserved
developer effort, but it means there is *no way* to make the pmax bootable
from the iso9660 official NetBSD CD.

If NetBSD can handle an FFS on a CD (possibly with 2k frags) then the answer
to your question is a pmax-only CD, done just like a scsi hard drive, except
maybe for the 2k frags. If NetBSD can't, then there is no way that I can see.
(Oh, and you put the install kernel in /netbsd, not GENERIC, obviously.)

If anyone is looking at expanding the pmax/stand support, I have some
observations:

	* because the pmax sector 0, unlike the alpha one, takes an *array*
	  of block #/len values, a unified boot program that lives in the
	  FFS is possible.

	* OTOH, the unified program has two drawbacks:
		1. restore(8) and cp(1) will change block #'s, and require
		   an installboot(8) rerun. LFS is another problem.
		2. by using up sector 0 with the array, you can stomp on
		   info needed by multiboot CD's (e.g., pmax+sparc+alpha)
	  
	  The two-stage alpha support now finds /boot by name in CD9660,
	  FFS, or LFS. There is also a unified alpha boot program for
	  cases like the new libsa ustarfs that feature contiguous
	  layouts.

As far as burning it under M$ Winblows goes, see:

	http://www.netbsd.org/Ports/alpha/faq.html#bootablecd

(Note: this faq.html section has just changed, check back in a few hours when
the web server resyncs.)

	ross.harvey@computer.org