mkroot - simple linux system builder

  Compiles a toybox-based root filesystem and kernel that can boot under qemu.

  Mailing list: http://lists.landley.net/listinfo.cgi/mkroot-landley.net

The tl;dr invocation is probably something like this, but you need to
build musl-cross-make and set up the mcm symlink first, as explained below:

  $ ./cross.sh sh4 ./mkroot dropbear distcc kernel
  $ (cd output/sh4 && ./qemu-sh4.sh)

This project is a successor to https://landley.net/aboriginal/about.html
and shares most of the same goals, with a much simpler implementation.

--- Quick start

Running ./mkroot.sh with no arguments and no $CROSS_COMPILE environment
variable builds a root filesystem for the host.

  $ ./mkroot.sh 

This downloads toybox into the "download" directory (if it's not already
there), and builds a minimal root filesystem in output/host. You can
then chroot into it like this:

  $ sudo chroot output/host/root /init
    $ ls -l
    $ exit

--- Adding build modules

You can build additional things from the "module" directory by listing
them on the command line:

  $ ./mkroot.sh dropbear distcc kernel

Use "-n" as the first argument to mkroot if you're adding to an existing
root filesystem. (The default is to delete and rebuild each time.)

  $ ./mkroot.sh
  $ ./mkroot.sh -n dropbear distcc
  $ ./mkroot.sh -n kernel

We provide a few module build scripts to get you started, but aren't interested
in turning mkroot into a Linux distro. If you want to cross-compile more
packages, fork the repo and add your own modules. As long as you don't modify
existing files you should be able to cleanly pull updates into your fork
(without even a merge commit if you pull --ff).

The "Linux From Scratch" (http://linuxfromscratch.org/lfs) and
"Beyond Linux From Scratch" (http://linuxfromscratch.org/blfs) projects are
a good source of additional package build instructions.

--- Cross compiling

To build for a different target, specify a cross compiler prefix using
the CROSS_COMPILE environent variable, ala:

  $ CROSS_COMPILE=armv5l-linux-musl- ./mkroot.sh kernel

which builds a root filesystem and kernel, and writes a qemu boot script.
If you have QEMU installed, you can then go:

  $ cd output/armv5l
  $ ./qemu-armv5l.sh
    $ cat /proc/cpuinfo
    $ exit

In theory you can use many different cross compilers. In practice the project
is developed and tested against musl-cross-make:

  https://github.com/richfelker/musl-cross-make

Running the included mcm-buildall.sh script in the musl-cross-make project
directory builds cross and native compilers for all supported targets
(which takes quite a while).

  $ cd ~
  $ git clone https://github.com/richfelker/musl-cross-make mcm
  $ cd mcm
  $ ~/mkroot/mcm-buildall.sh
  $ cd ~/mkroot
  $ CROSS_COMPILE=~/mcm/output/sh4-linux-musl-cross/bin/sh4-linux-musl- \
    ./mkroot.sh kernel

If you create an "mcm" symlink under mkroot pointing to your musl-cross-make
output directory, you can use the cross.sh wrapper script to quickly select
the target to build, or use the target "all" to build all available targets.

  $ ln -s cross ~/mcm/output mcm
  $ ./cross.sh # lists available targets
  $ ./cross.sh i686
  $ tail output/i686/log.txt
  $ (cd output/i686 && ./qemu-i686.sh)
    $ exit
  $ ./clean.sh && ./cross.sh all ./mkroot.sh distcc kernel

All cross.sh does is set $CROSS_COMPILE to an appropriate value, then call
the rest of its command line. To see this value, try:

  $ ./cross.sh i686 env | grep CROSS_COMPILE

--- Building kernels for QEMU

Most modules add files to the target's root filesystem, but the "kernel"
module doesn't modify the root filesystem. Instead it packages up that root
filesystem into a cpio.gz archive, builds a bootable Linux kernel
for the target, creates a qemu-$TARGET.sh launch script to plug them
both into QEMU, and also saves the $TARGET.miniconfig file used to configure
the kernel build.

Modules are processed in order, so kernel should always come last or it won't
package up anything you add after it runs. The module/kernel script
recognizes all the musl-cross-make prefixes, and uses "uname -m" when building
for the host. When using an unknown cross compiler, you can set the environment
variable "TARGET" to override this (ala "./mkroot.sh TARGET=mips kernel").

The standard test that all available hardware is working is that you get a
shell prompt, can type at it, the date is set right, the network is working,
the hard drive images work, and the emulator quits when you exit.

  $ ./cross.sh armv5l ./mkroot.sh dropbear kernel
  $ cd output/armv5l
  $ ./qemu-armv5l.sh
    $ ls -l
    $ cat /proc/cpuinfo 
    $ ifconfig
    $ date
    $ exit

Updating QEMU or kernel versions can break any of that, so retest if you do.

The qemu-$TARGET.sh script appends any extra arguments to the QEMU command line,
like so:

  $ ./qemu-armv5l.sh -hda armv5l.miniconf -hdb qemu-armv5l.sh
    $ tail /dev/?da
    $ tail /dev/?db
  $ exit

--- Hermetic build

Mkroot uses toybox's "make install_airlock" to implement a "hermetic build"
when cross compiling, which means it tries to insulate itself from variations
in host systems by providing its own build prerequisites.

This means the first thing mkroot.sh builds when it sees CROSS_COMPILE set
is an "airlock" directory full of all the binaries it will use (most supplied
by toybox, plus symlinks to the host's native toolchain). Then it changes the
$PATH for the rest of the build to point to just this airlock directory
(plus the cross compiler if you didn't provide an absolute path for that).
Doing this prevents autoconf from finding things like python on your host
that won't be on the target.

A hermetic build also blanks all the environment variables, except for $HOME,
$PATH, and $CROSS_COMPILE. If you need to specify more, set them on the
mkroot command line (name=value arguments are interpreted as environment
variables instead of modules).

If you need to add extra things to the airlock, delete the old one (if any,
./clean.sh will do this) the set HOST_EXTRA="list of commands" on the mkroot
command line (space separated if there's more than one). For example:

  ./clean.sh && ./cross.sh i686 ./mkroot.sh HOST_EXTRA=mkimage kernel

--- Downloading and building packages

Source code for package builds is stored in the "download" directory,
either as extracted source or as tarballs. The "download" function verifies
each tarball's sha1sum, fetching a new one from the URL via wget as necessary.
To download/verify source packages without building yet, use the "-d" option.

If you provide a directory under download matching a package's name (often
via "git clone"), the build will use that instead of fetching tarballs.
Since mkroot doesn't apply patches to tarballs, the easy way to build modified
source is to provide your own source directory under download.

For example:

  mkdir download
  cd download
  git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

Using extracted source is noticeably faster when building mulitple targets.
(Re-extracting the Linux kernel source tarball takes a while, and copies
of source directories are made with cp -s which creates a tree of symlinks
to the original source, saving disk space and cache memory.)