Re: GENERIC and INSTALL kernels

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

On 11.02.2011 20:50, Thor Lancelot Simon wrote:
> On Fri, Feb 11, 2011 at 05:12:47PM +0100, Jean-Yves Migeon wrote:
>>
>> Problem 2:
>> Being able to mountroot the ramdisk that contains the modules is
>> sufficient in itself. However, for install ramdisks, you would have to
>> include modules + sysinst + some tools needed for install. You end up
>> having a ramdisk with a size close to 25MiB (count 10MiB for /stand, and
>> some more MiB for tools/sysinst).
> 
> And what's exactly wrong with that?

Size; for only reason though: current x86 distrib are building ramdisks
as small file system containing install tools. These ramdisks do not
include modules, as they are used to build miniroot.kmod, which is
already a module (and should be part of a set, ultimately).

> The installation sets are that
> size already; what difference is it how they're packaged?

Installation sets are way bigger than installation ramdisks, which do
not contain sets, only tools to fetch and install them :) That's
approximantely the same difference between a bootcd iso and a release
iso (50 => 250MiB)

> I have a script that effectively produces NetBSD USB key images using
> only in-tree tools (it actually produces disk images for a different
> purpose entirely, but they can be used for that).  It creates a FAT16
> filesystem and puts four things in it: bootxx_fat16 (as the FAT
> boot loader), /boot, /netbsd.gz, and /miniroot.gz
> 
> /miniroot.gz has a *complete runnable* NetBSD system in it, plus all
> the install sets.  Our install sets are somewhat smaller than the
> standard NetBSD ones (because we subset each setlist with an additional
> setlist) but the whole thing easily fits on a 128MB flash module
> and requires only about 256MB of RAM to run.  It would not take much
> more space for a fairly standard "Live NetBSD" image that put back
> most or all of what our runtime takes out.  This ends up being a very
> useful thing and can be built with only in-tree tools and can even be
> manipulated and pieced together on *other* operating systems, so long
> as they can read/write FAT.
> 
> Suffice to say I do not think "there's a giant miniroot!" is much
> reason to reject an approach to installation or upgrade.

I don't have any too :) Keep in mind that such ramdisks/kernels are used
to build floppy installation images and... with a default size of
2.88MiB, well, a giant miniroot makes lots of floppy images.

Nonetheless, we could drop that altogether, give one image file that can
fit in the 20-30MiB range (with crunchgen), and live happily ever after.
Except for those that still use 3"1/2 floppies :/

-- 
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost