--veXX9dWIonWZEC6h
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Nov 11, 2006 at 04:16:56PM +0100, Julio M. Merino Vidal wrote:
> Hello,
>=20
> [ Please CC me any replies. ]
>=20
> The bootfloppy-big installation disk image is every now and then
> giving problems due to its size limit.  This is set to 2.88MB to allow
> its use in El-Torito floppy disk emulation bootable ISO images.
>=20
> The limit prevents the addition of new features (such as full LFS
> support).  But it also causes build failures from time to time due to
> the addition of non-optional features that keep enlarging e.g. the
> kernel.
>=20
> We now have the ability to build bootable ISO images that use
> El-Torito hard disk emulation, hence not having any size constraints.
> The problem is that we cannot take advantage of them due to the limit
> in bootfloppy-big.  I see several solution:
>=20
> 1) Remove the bootfloppy-big image altogether.  This won't happen
>   because people still wants it (think netbooting).

Uh,, as someone already mentioned, the INSTALL kernel is used
directly in this case. It's size doesn't matter (much) in this
case.

> 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.

IIRC there are some older machines that can't handle one or the
other floppy/hdd formats.
=20
> 3) Add a new ramdisk (say ramdisk-full) that does not have any
>   corresponding floppy disk image.  This could be used exclusively for
>   the new bootable CDs.  This may seem the best approach because
>   it is the most conservative, but this is also its biggest problem.  It
>   will only delay a real solution because, eventually, it will overflow
>   again (as we have been seeing for a long time).  But it may be the
>   safest to use now that 4.0 is around the corner.
>
> I'd rather go with 2 provided that we ship the bootable CDs as built
> by "distrib/i386/cdroms/installcd".  Note that the resulting ISO also
> includes tiny CD images that can be used to burn custom CDs (e.g. for
> serial console installation).  The only problem with these is that
> they cannot be extended to include also the installation sets... can
> they?
>=20
> Comments?

Somehow, just as the pc532 port is dying, it seems support for i_3_86
is dying just the same.  I guess there is a point where modern OSes
must move on and leave supporting this hardware to un-maintained
legacy releases.

Really, can't any kernel be placed in a ustarfs along with bootxx_ustarfs,
and get a bootable image?

I think that a mbr(8), bootxx_ffsv1, and a makefs(8)-generated file system
of INSTALL kernels could be used too.  This would allow different kernels
to be chosen at boot time, a plus if we still need a INSTALL_LAPTOP.

In any case, this really open up a can of worms ^W^W^W^W some
new possibilities.

> Note that if we want to enable LFS usage for root file systems in 4.0
> (something that'd be a good selling point) we must fix this issue.
> Full LFS support overflows the disk images by a good amount (100kb
> IIRC) and is not easily fixable otherwise.
>=20
> Also note that wherever I said bootfloppy-big I meant bootfloppy-big
> and bootfloppy-laptop-big.

	Jonathan Kollasch

--veXX9dWIonWZEC6h
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (NetBSD)

iD8DBQFFW3SAOjx1ye3hmokRAuMfAJwMYWDMBTuyLs6Nll0FGc1HUc6kRgCfR3n2
Burx3zk/pa6eTQ1Iz70TFiQ=
=Ih23
-----END PGP SIGNATURE-----

--veXX9dWIonWZEC6h--