Use the DESTDIR feature of the buildsystem. The example hierarchy is /usr/destdir, which initially doesn't exist at all. First create the skeleton hierarchy, then build world into it.

# make etcfiles DESTDIR=/usr/destdir
# make world DESTDIR=/usr/destdir MINIXDYNAMIC=yes

Everything is built dynamically with MINIXDYNAMIC=yes (not the default currently) to make the memory image significantly smaller.

The boot-time kernel and modules are the same as always, except that the bootstrap ramdisk is now a full filesystem.

# cd releasetools
# rm ../drivers/ramdisk/image.memboot
# make  bootfiles MEMDESTDIR=/usr/destdir

MEMDESTDIR being set is what triggers the ramdisk contents being the specified hierarchy.

Set IMGFILESDIR to where you want the files to go; the default is the minix bootloader directory for hdboot and .memboot in the releasetools/ source directory for bootfiles. An interesting alternative is:

# make  bootfiles MEMDESTDIR=/usr/destdir IMGFILESDIR=/usr/www/ipxe/

and let Minix netbooting clients netboot from your webserver.

Can be done using the builtin multiboot bootloader; no filesystem required:

$ kvm -m 800 -kernel kernel -initrd mod01_ds,mod02_rs,mod03_pm,mod04_sched,mod05_vfs,mod06_memory,mod07_log,mod08_tty,mod09_mfs,mod10_vm,mod11_pfs,mod12_init       

unfortunately ipxe has to be recompiled to load more than 8 multiboot modules for now

To use iPXE to boot Minix straight from a PXE environment, use this ipxe script, thanks to the good folks at The iPXE project:

#!ipxe
kernel kernel
module mod01_ds
module mod02_rs
module mod03_pm
module mod04_sched
module mod05_vfs
module mod06_memory
module mod07_log
module mod08_tty
module mod09_mfs
module mod10_vm
module mod11_pfs
module mod12_init
boot

Save that script to your webserver, and put the boot modules and kernel in the same directory as the script. Then from kvm you can boot it out of the box:

$ kvm -m 800 -net user,bootfile=http://www.minix3.org/ipxe/minix3.ipxe -net nic,model=e1000

• There is a reason we can't simply invoke a 'memboot' target to create a boot image from the current DESTDIR, although this would be cleanest. The build process would install the huge memory module there and on the next iteration the image would include it
• rm ../drivers/ramdisk/image.memboot is necessary because a change in the full hierarchy can't easily be detected. So to make incremental makes painless, and a switch of ramdisk image build modes possible without using the wrong image, the memboot image isn't updated if it exists. So additional make bootfiles invocations will update the kernel and modules, but not the ramdisk contents, even if the hierarchy has changed.
• There are some minor complications with cross-compiling a netbooting image like this, that has to do with creating the device nodes, requiring the build to be privileged. There are quirks in the privileged mode that need to be ironed out for that, so although you can do the above in a cross environment (set MEMDESTDIR to your cross-DESTDIR), you have to create the device nodes yourself manually first.