//warning: code to do this actually isn't merged with master yet//

This page describes creating a minix system on ramdisk, capable of being netbooted.

There are two parts. One, creating the hierarchy you want to have on the ramdisk, i.e. your eventual system. Two, creating the boot-time modules, containing the ramdisk with the full filesystem.

====== Creating the hierarchy ======

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.

<code>
# make etcfiles DESTDIR=/usr/destdir
# make world DESTDIR=/usr/destdir MINIXDYNAMIC=yes
</code>
Everything is built dynamically with ''MINIXDYNAMIC=yes'' (not the default currently) to make the memory image significantly smaller.

====== Creating the boot-time modules ======
The boot-time kernel and modules are the same as always, except that the bootstrap ramdisk is now a full filesystem.
<code>
# cd releasetools
# rm ../drivers/ramdisk/image.memboot
# make  bootfiles MEMDESTDIR=/usr/destdir
</code>

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:

<code>
# make  bootfiles MEMDESTDIR=/usr/destdir IMGFILESDIR=/usr/www/ipxe/
</code>

and let Minix netbooting clients netboot from your webserver.

====== Starting them directly with qemu/kvm ======

Can be done using the builtin multiboot bootloader; no filesystem required:
<code>
$ 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       
</code>

====== Netbooting ======

//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 [[http://www.ipxe.org/|The iPXE project]]:
<code>
#!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
</code>

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:
<code>
$ kvm -m 800 -net user,bootfile=http://www.minix3.org/ipxe/minix3.ipxe -net nic,model=e1000
</code>

====== Some warts ======

    * 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.