Revision as of 00:52, 31 December 2011

This page documents the effort to bootstrap Funtoo Linux using Aboriginal Linux.

What is Aboriginal Linux?

Aboriginal Linux's motto is "we cross compile so you don't have to". It replaces cross compiling with native compiling under an emulator (generally QEMU). Funtoo can use it to natively create stage 1/2/3 root filesystems on an arbitrary target, which greatly simplifies adding support for new architectures and regression testing existing architectures.

Aboriginal Linux creates a simple native development environment for each type of target hardware, building the smallest self-contained Linux system capable of rebuilding itself entirely from source code. This requires seven packages: linux, uClibc, busybox, binutils, gcc, make, and bash.

The resulting system can then boot under the emulator QEMU (or on appropriate hardware, if available) to provide a native development environment, eliminating the need for any further cross compiling. You can wget, configure, make, and install additional source packages inside the emulator.

Aboriginal Linux's web page is at "http://landley.net/aboriginal" and a long presentation about it is available at "http://landley.net/aboriginal/downloads/presentation.pdf".

How do I use Aboriginal Linux?

Aboriginal Linux provides prebuilt native development environments for x86, x86-64, arm, mips, powerpc, and more, ready to run under the emulator. Install QEMU 1.0 or later, then go to http://landley.net/aboriginal/downloads/binaries", grab the appropriate system-image tarball, extract it, and run one of the following three shell scripts:

• ./run-emulator.sh - Boot to a shell prompt, with the simplest configuration: a read-only (squashfs) root filesystem with a tmpfs mounted on /home.

• ./dev-environment.sh - Boot to a shell prompt with a full development environment. This wrapper around run-emulator.sh adds a 2 gigabyte ext2 /dev/hdb image mounted on /home (persistent writeable space, in large amounts), and allocates 256 megabytes of physical memory for the emulator (enough to run gcc building complex packages). If distccd and the appropriate target's cross compiler are available in the host's $PATH, this script also configures the emulated environment to call out to the cross compiler via distcc, transparently moving the heavy lifting of compilation outside of the emulator.

• ./native-build.sh - Run an automated build. This requires a "control image", which is a squashfs filesystem the emulated system sees as /dev/hdc mounted on /mnt. The init script in the emulated root filesystem checks for /mnt/init and if that exists, it runs that instead of providing a shell prompt. (Actually it asks the user to press a key if they want a shell prompt, with a three second timeout.) See "http://landley.net/aboriginal/control-images" for details.

(You can build your own system images from source by following the instructions at "http://landley.net/aboriginal", but ReBootstrap does not require this.)

What is an "LFS build"?

A Linux From Scratch root filesystem built on top of Aboriginal Linux.

One of the example native-build.sh control-images Aboriginal Linux provides is "lfs-bootstrap.hdc", which natively compiles and installs (almost) all of the LFS chapter 6 packages under the emulated development environment, according to the LFS build instructions.

The control image copies the read-only root filesystem into a writeable directory under /home, chroots into that, builds packages and installs them over the existing (busybox) versions, and then tars up the resulting filesystem.

This provides a much more capable native build environment for the target. Since Aboriginal Linux can already provide this for multiple targets, Funtoo uses this as its starting point, instead of starting from the minimal build environment and building/installing all of its own prerequisites.

The plan of attack is as follows:

1. Start from an LFS build, plus necessary stuff for Portage to run. (Git, python...)
2. Create a package.provided file for the local LFS system so that Portage doesn't complain of unsatisfied /var/db/pkg entries.
3. Use Portage to build a stage1 tarball to /tmp/stage1root.

At this point, Funtoo has been bootstrapped and we can extend this approach to bootstrap Funtoo on any architecture.

Prerequisites

1. A smaller Portage tree to not eat up so much filesystem space. This has now been implemented. The script /root/git/funtoo-overlay/funtoo/scripts/generate-system-tree.py can be used to generate a system-only Portage tree.
2. A package.provided list of a current Funtoo system. This can be found at /root/git/funtoo-overlay/funtoo/scripts/stage3-provided.txt.

Update

The approach above didn't seem to correctly provide needed dependencies. Options at this point:

1. Bundle up what we have as a stage3 and see if Metro's steps are more successful at using it as a stage3 (we were trying simple emerge commands rather than the explicit metro steps for testing)
2. If package.provided is not working, simply copy /var/db/pkg from an existing stage3 for a massive injection of fake package information.