On 11/11/06, Alan Barrett <apb@cequrux.com> wrote:
> On Sat, 11 Nov 2006, Julio M. Merino Vidal wrote:
> > [ Please CC me any replies. ]
>
> > 2) Remove the size constraints in bootfloppy-big.  This prevents using
> >   the image with El-Torito but still allows its use in other situations
> >   (as mentioned in the previous point).  Then, this image could be
> >   usable for the "new" ISO images.  Seems to be the cleanest
> >   approach.
>
> Yes please.  Also increase the FLOPPYMAX=n limits, as and when
> necessary, in the bootfloppy sets that are intended to be used with
> actual floppies.

That happens already, isn't it?  (And anyway, why do we have to set a
limit?  That only brings problems periodically when the images
overflow.)

> > The only problem with these is that they cannot be extended to include
> > also the installation sets... can they?
>
> Why not?  We have an infrastructure for building release floppies that
> include the installation sets and a bootable kernel with embedded
> ramdisk.  Why would we lose that if we increase the kernel+ramdisk size
> and change from El Torito floppy emulation to a hard disk emulation or
> no emulation?

I was talking about the CD images that will be part of the release
tree generated by, e.g. distrib/i386/cdroms/bootcd-com.  That will
generate a ~10MB image that does not include the sets, and an end user
cannot easily modify it to include them.

Is it easy to build El Torito hard disk CDs?  (Haven't done this in
the past so I have no idea.)  If we ship the 'boot' program and the
installation kernel, can the end user build his own image easily?
Then my point is moot.

Note that I'm always thinking of a system with no sources, which is
(or should be!) a very typical situation (specially prior
installation).

Cheers,



-- 
Julio M. Merino Vidal <jmmv84@gmail.com>
The Julipedia - http://julipedia.blogspot.com/