>thus I'll need all the files to be local, in a Mac partition.
>Also, as I understand it, MacBSD can't read MacOS partitions. From what I know
>of the Mac filesystem, it would be best left to MacOS to read from it.

This should not be true. A few months ago, one of the hackers had an
application that read the Mac HFS. It should not be difficult to convert
into a fs driver. For our purposes, read-only is adequate.  That way we can
use a HD folder as if it were that recovery floppy that we so desparately
need. :-)

>Hmm. Perchance I should clarify my thoughts. I agree that the user interface
>I will get under MacBSD will be _very_ different from the Mac interface.

>That said, I wasn't thinking the booter would do all the steps of
>configuring the unix system. You're right; that's best left to a shell
>script.

>I only envisioned the Mac-side program transfering files,
>uncompressing tar files, doing UNIX partition formatting, and
>fscking.

I propose that
1) Disk partitioning be left to (existing) Mac side HD formatting programs.
   Eg: Silverlining, Apple HDSetup, etc.
   The Apple format is NOT "standard". Let them worry with the problem.
   We can simple find "our" partitions.
2) Use existing Mac side programs (Finder, Fetch, Stuffit, etc.) to move
   a) the core installer files to some local disk.
   b) (as needed) tarballs of the rest to some location accessible from NetBSD.
      This may require multiple iterations for someone who has neither adequate
      on-line storage nor a non-localtalk IP connection. If we ever get
      floppies to work under NetBSD, then they might be a possibility.
3) Have the booter mount the originating folder of the Mac HFS as a
read-only root. The minimal set of binaries and configuration options would
be in Apple files. This set would include
   a) a shell
   b) mkfs
   c) mount
   d) tar or cpio
   With this set you would format a file system and install enough of a
system to reboot with it as the root.
4) Reboot and continue to use tar to bring in the rest of the files.

IMHO, the key to this approach is based on:
   a) Simple step-by-step directions.
   b) Auto-resuming shell scripts to "pick up where you left off" when some
of the files were not available.
   c) A simple "fill in the blanks" form to define the configuration.

One advantage of this approach is that the same mechanisms can allow
knowledgable testers to set up test situations without destroying their
working environment.