Meta-question:  Why doesn't the list include a "Reply-To:" pointing at the
list address?

On Sun, 4 May 2003, Manuel Kasper wrote:

> The goal for m0n0BSD is simply to provide CF-card-ready binary images of
> stripped (but not minimalistic) FreeBSD as a convenience to those who just
> want to give FreeBSD a quick try or who don't like working through the
> miniBSD guide over and over again as new versions of FreeBSD are released.

It might be desirable to offer it in tarball form as well, since that's
easier to customize, and also easier just to look at (since some platforms
can't mount the image).

The "rootfs" archive for m0n0wall is incomplete, since it's just the
equivalent of mfsroot.gz, and doesn't contain the rest of the files.  I
created a "cfroot" archive, which contains everything but mfsroot.gz.  I
decided to include an empty mfsroot.gz as a placeholder rather than having
it missing.

In some respects, performing the initial install via netbooting would have
some advantages over the CF-image approach, although netbooting isn't
entirely trivial to set up, either.  GRUB can currently boot the kernel
directly (with a nonfatal complaint about missing metadata), but it
doesn't know how to install an initial ramdisk.

> There will be no GUI, of course - that's where m0n0wall fits in (for less
> exotic applications).

Well, GUIs and flexibility aren't necessarily in conflict, but if I have
to choose, I'll take the latter. :-)

> UNIX:
> gzcat m0n0bsd-4.8-net45xx-std-20030504.img | dd of=[CF raw device] bs=16k

I found that the "bs=16k" caused trouble here (using a Transcend 6-in-1
reader/writer under Mac OS X).  It worked OK with the default 512-byte
blocks, though.  I'm not convinced that the larger blocksize helps the CF,
since CFs typically do a bunch of remapping of the addresses, anyway.

> I have decided to name the images .img (and not .bin.gz) because some
> browsers try to decompress them while downloading (most notably Internet
> Explorer for Windows). m0n0wall images are going to be named .img in the
> future, too.

I certainly won't miss the overused ".bin". :-) But while ".img" is
commonly used for images, it usually means an *uncompressed* image and
would be misleading for a compressed image.  So ".img.gz" would make more
sense if one ignores the stupidity of WinIE, but if one has to adopt a
weird extension to fake out the latter, then I suggest ".igz", similar to
the way ".tar.gz" is sometimes conflated to ".tgz".

> I'd really like to modularize m0n0BSD and provide something like packages
> for software that is commonly used on net45xx (like MPD, DHCPD, racoon,
> perl, zebra, etc.). I'm still thinking of a way to do that. I could make a
> web-based image building system where you could put your custom image
> together with a few clicks (probably powered by PHP), provide several
> images with different options (and CF card sizes), or release a "base" CF
> image and separate packages that can be installed over the network on the
> net45xx. I like the first approach best, but then I'll have to solve the
> bandwidth problem (I don't think I can host it all on my feeble 512 kbps.
> ;)

Yes, it would be nice to have some way to use a package manager.  I don't
know how much room it would take to have that built in, which would avoid
having to come up with a "remote package manager" scheme.  Even in the
latter case, having the PM database built in would be desirable to avoid
possible inconsistencies associated with maintaining it on another
machine.

There would need to be a site with precompiled binaries for 486.  This
wouldn't have to be your own server, but I suspect most of the existing
sites have "generic 386" binaries.  I believe GCC is smart enough to use
BSWAP for the ubiquitous ntohl()/htonl() conversions (particularly
important for network software), but only if the 386 is excluded from the
target (since the 386 doesn't have BSWAP). 

Another problem one runs into in larger setups is that a complete CF image
won't fit in RAM, which is a problem for firmware updates.  File-oriented
large-scale updates might overuse the CF, but write-on-the-fly image
updates would leave total trash if interrupted.  One possibility, given a
sufficiently large CF, would be to have two identical potential root
partitions, with the idea being that you update the inactive one and then
switch them.  That also allows for one-level rollback, as long as the new
code works well enough to change the disklabel.

Putting the config files in a separate partition (perhaps union mounted
over the root) would avoid the need to explicitly preserve them on a
firmware update.  Union mounting a ramdisk over that would allow temporary
config changes without writing the CF.  Thus, three layers:

	Ramdisk		Modified active config files
	CF /config	Saved non-default config files
	CF /		Default config files

					Fred Wright