Subject: Re: install/6625: The i386 install floppy overflows
To: None <perry@piermont.com>
From: None <Havard.Eidnes@runit.sintef.no>
List: port-i386
Date: 12/27/1998 15:30:14
> Robert Elz <kre@munnari.OZ.AU> writes:
> >   | the boot floppy image on the CD doesn't have to contain a
> >   | ramdisk kernel; it need only contain a kernel prepared to
> >   | mount a CD as a root.
> >
> > The problem with this approach is that it leads to CDs that
> > only boot correctly on one architecture (that, or a lot more
> > work indeed).  It ought be possible to do better than that.
> > Maybe a chroot into an archiecture dependent sub-dir of a
> > 9660 filesys?
>
> How about, instead, having the boot floppy load the ramdisk
> root image, either from a floppy or from a directory on the CD?
> That way, we could avoid the "root on the CD" problem entirely.

I've thought about this some more, and I've come up with a variant of
the above which is both portable and which doesn't required mucking with
kernel internals.

Instead, the initial ramdisk could be reduced to a bare minimum capable
of mounting a 9660 (or other) file system in this case, and a vnd device
could be used, vnconfig could be pointed to a disk image on the mounted
CD-ROM, and that disk image could contain something similar to the
traditional ramdisk image.  That disk image, now on a vnd device, could
then be mounted "somewhere" and it could be chroot'ed into, and this
could hopefully give a reasonable environment to perform installations
from.  The disk image file system would have to be mounted read-only, I
guess, as long as the underlying medium is read-only, but as long as you
can mount an mfs file system on /tmp that ought not to be a problem?

The contents of the "real" ramdisk image could even be gzipped in which
case the contents could be loaded into a file on a suitably large mfs
file system (which eats RAM, I guess), and that file could then be
vnconfig'ed, mounted and chrooted into as described above.

Comments?

- H=E5vard